Dlaczego jeden parser nie wystarczy do dokumentów od kilku wystawców

Automatyczne wczytywanie dokumentów do systemu wygląda na zadanie zamknięte. Bierzesz plik, wyciągasz numer, kwotę i datę, zapisujesz. Przy dokumentach od jednego wystawcy tak właśnie jest i robota schodzi w kilka dni.

Problem zaczyna się przy piątym wystawcy. Nie dlatego, że jest ich pięciu, tylko dlatego, że każdy rozumie słowo „dokument" inaczej.

Poniżej rzeczy, które w tego typu wdrożeniach wychodzą dopiero w praktyce. Jeśli rozważasz taki projekt, ta lista przyda Ci się bardziej niż zapewnienie, że „AI to ogarnie".

Ten sam typ dokumentu, pięć różnych światów

Weźmy dokument, który u każdego wystawcy zawiera dokładnie te same dane: numer, strony, kwoty, daty obowiązywania. Wydawałoby się, że wystarczy jeden zestaw reguł.

W praktyce trafiasz na:

  • etykiety w dwóch językach w jednym pliku. Dokument dla podmiotu międzynarodowego potrafi mieć nagłówek „NUMER DOKUMENTU / DOCUMENT NUMBER" i całą treść w takich parach. Reguła szukająca polskiej etykiety znajduje ją, ale zbiera wartość zza ukośnika, czyli angielski nagłówek zamiast numeru;
  • etykiety z dwukropkiem i bez. „NIP 1234567890" i „NIP: 1234567890" to dla wyrażenia regularnego dwa różne przypadki. Brzmi trywialnie, ale to najczęstsza przyczyna pustego pola;
  • sumy zamiast składników. Jeden wystawca podaje pozycje osobno, drugi jedną kwotę zbiorczą z opisem w nawiasie. Jeśli system po drugiej stronie oczekuje rozbicia, trzeba je odtworzyć z opisu;
  • daty w mianowniku. „15 czerwiec 2026" zamiast „15 czerwca 2026". Biblioteki do przetwarzania dat tego nie łykają, bo to nie jest poprawna polszczyzna, a jednak tak bywa w dokumentach generowanych automatycznie.

Znak, którego nie widać

Najlepszy przykład tego, dlaczego takich projektów nie wycenia się z opisu, tylko z plików.

W jednym z formularzy zakres dat wyglądał tak: 01.06.2026-31.05.2027. Reguła szukająca myślnika nie działała. Data początkowa wpadała, końcowa nie.

Powód: między datami nie było zwykłego myślnika, tylko miękki myślnik, znak o kodzie U+00AD. To znak sterujący, który mówi przeglądarce albo drukarce, gdzie wolno przenieść wyraz do następnego wiersza. Na ekranie i na wydruku jest niewidoczny. W tekście wyciągniętym z pliku jest i nie równa się myślnikowi.

Takich rzeczy nie da się przewidzieć z opisu procesu. Wychodzą, kiedy weźmiesz dwadzieścia realnych dokumentów i sprawdzisz, ile z nich przechodzi.

Zabezpieczenie hasłem, które da się obejść legalnie

Część wystawców wysyła dokumenty zaszyfrowane. Zwykle hasłem jest coś, co odbiorca i tak zna: numer sprawy, numer umowy, ciąg cyfr z nazwy pliku.

Jeśli tak jest, odszyfrowanie może być pierwszym krokiem przetwarzania i nikt nie musi otwierać plików ręcznie. To nie jest łamanie zabezpieczenia, tylko użycie hasła, które zostało przekazane odbiorcy razem z dokumentem.

Warto o to zapytać na starcie, bo zmienia to kształt całego rozwiązania. Przy hasłach nadawanych ręcznie i przesyłanych osobnym kanałem automat nie ma jak działać.

Skany to osobna kategoria

Dokument natywny, czyli wygenerowany z programu, ma tekst w środku i wystarczy go odczytać. Skan to obraz i potrzebuje rozpoznawania znaków, a to wprowadza własne problemy:

  • kartka położona bokiem albo do góry nogami. Automatyczne wykrycie orientacji i obrót przed rozpoznaniem rozwiązuje to raz na zawsze, ale trzeba o tym pomyśleć;
  • blady wydruk, przebijający druk z drugiej strony, pieczątka na kwocie. Tu żadne narzędzie nie zrobi cudu i taniej wychodzi poprawić sam proces skanowania;
  • ta sama treść, inna jakość odczytu za każdym razem. Przy skanach zawsze zakładam próg pewności i kierowanie wątpliwych odczytów do sprawdzenia.

Dobra wiadomość: w typowej firmie większość dokumentów przychodzi dziś mailem jako pliki natywne, a skany to margines.

Jak to poukładać, żeby dało się utrzymać

Wzorzec, który sprawdza się przy wielu wystawcach, ma dwie warstwy.

Warstwa pierwsza rozpoznaje, z kim mamy do czynienia. Po nadawcy wiadomości, po nazwie pliku, po charakterystycznym fragmencie treści. To tania operacja i jej wynik decyduje o dalszej ścieżce.

Warstwa druga czyta pola według reguł właściwych dla tego wystawcy, z ogólnym odczytem jako zapasem, gdy rozpoznanie zawiedzie.

Dzięki temu zmiana formularza u jednego wystawcy psuje jedną ścieżkę, a nie całe narzędzie. To brzmi jak szczegół techniczny, ale ma bezpośrednie przełożenie na koszt: dopisanie szóstego wystawcy zajmuje dzień, a nie tydzień przepisywania wszystkiego od nowa.

Do tego warstwa kontrolna, o której łatwo zapomnieć w euforii, że „działa": reguły sprawdzające format numeru, zakres kwoty, zgodność sumy ze składnikami. Wynik, który reguły odrzucą, ma trafić do człowieka, a nie po cichu do systemu. Błędny odczyt, który nikogo nie zaalarmował, jest gorszy od braku automatu.

Kiedy to się nie opłaca

Trzy sytuacje, w których odradzam i mówię to przed wyceną.

Dokumentów jest kilka dziennie. Trzy minuty na dokument i dwa dokumenty dziennie to niecałe trzydzieści godzin rocznie. Wdrożenie kosztuje więcej, niż odzyskasz, a dochodzi utrzymanie.

Wystawcy zmieniają formularze co chwilę. Jeśli układ dokumentu zmienia się kilka razy w roku u każdego z kilku wystawców, poprawki zjedzą oszczędność. Wtedy lepszy jest odczyt oparty na znaczeniu, z pełną weryfikacją przez człowieka, czyli wsparcie zamiast automatu.

Nie ma gdzie zapisać wyniku. Jeśli dane i tak trzeba potem wklejać do systemu ręcznie, bo nie ma sposobu zapisania ich z zewnątrz, oszczędność jest połowiczna. Najpierw sprawdzam, czy da się je tam wprowadzić automatycznie.

Co przygotować przed rozmową

Jeśli myślisz o takim wdrożeniu, najbardziej przyda się jedno: kilka realnych dokumentów od każdego wystawcy, w tym te nietypowe. Nie opis procesu, nie wzór z internetu. Realne pliki, na których ktoś dziś siedzi.

Na podstawie kilkunastu plików da się powiedzieć, ile z nich przechodzi bez ludzkiej ręki, gdzie będą problemy i czy w ogóle warto. To pół godziny sprawdzania i oszczędza rundę domysłów po obu stronach.

Jak wygląda część z odczytem znaczenia, opisałem osobno we wpisie o OCR i AI zamiast ręcznego przepisywania dokumentów. Ten tekst dotyczy tego, co dzieje się wcześniej: jak w ogóle dobrać się do treści, gdy każdy wystawca robi to po swojemu.

Najczęstsze pytania

Liczy się nie liczba dokumentów, tylko czas. Policz, ile minut zajmuje przepisanie jednego i ile ich wpada tygodniowo. Kilkanaście dokumentów dziennie po trzy minuty to około pięciu godzin tygodniowo, czyli ponad dwieście godzin rocznie. Przy takiej skali odczyt automatyczny zwraca się w kilka miesięcy. Przy dwóch dokumentach dziennie zwykle nie warto.
Tak, ale nie jednym uniwersalnym rozwiązaniem. Model językowy szuka danych po znaczeniu, a nie po pozycji na stronie, więc radzi sobie z wariantami tego samego typu dokumentu. Więcej o samym odczycie znaczenia w [dokumentacji biblioteki pypdf](https://pypdf.readthedocs.io/en/stable/user/extract-text.html), która pokazuje, jak różnie wygląda tekst wyciągnięty z pliku wobec tego, co widać na ekranie. Przy wystawcach o zupełnie różnej strukturze i tak potrzebne jest rozpoznanie, z kim mamy do czynienia, zanim ruszy właściwy odczyt.
Da się je otworzyć automatycznie, jeśli hasło jest przewidywalne, na przykład wynika z numeru sprawy albo z nazwy pliku. Wtedy odszyfrowanie jest jednym z pierwszych kroków przetwarzania. Przy hasłach nadawanych ręcznie i przekazywanych osobno automat się nie sprawdzi.
Zakładam, że część odczytów będzie wymagała sprawdzenia, i buduję to od początku. Pola kluczowe, jak kwoty i numery, mają reguły kontrolne: format, zakres, zgodność sumy ze składnikami. Wynik, który reguły odrzucą, trafia do szybkiego zatwierdzenia przez człowieka, zamiast wejść po cichu do systemu.
To się zdarza i trzeba to założyć. Rozpoznanie wystawcy oddzielone od odczytu pól sprawia, że zmiana układu psuje jedną ścieżkę, a nie całość. Dlatego pytam o to na etapie wyceny: ile jest wystawców, jak często zmieniają formularze i czy stare dokumenty też mają być czytane.
Jeden typ dokumentu o powtarzalnej strukturze to kilka dni. Każdy kolejny wystawca to zwykle dzień do trzech, zależnie od tego, jak bardzo odbiega od reszty. Najwięcej czasu zjada nie kod, tylko zebranie przykładów pokrywających realne przypadki, w tym te nietypowe.

Przyślij kilka przykładowych plików od różnych wystawców. Powiem, ile z tego da się wczytywać automatycznie, co będzie wymagało sprawdzenia przez człowieka i ile to kosztuje.

Porozmawiajmy