Jeśli pracujesz z fakturami, szybko wychodzisz z założenia, że OCR to nie „magia”, tylko zestaw decyzji o jakości skanu i walidacji pól. W mojej praktyce właśnie podejście do weryfikacji danych decyduje o tym, czy odczyt danych z faktury oszczędza czas, czy generuje poprawki w księgowości. Gdy ktoś wdraża comarch ocr faktury, najczęściej zaczyna od pierwszego problemu: krzywy PDF albo nieczytelne stopki u kontrahenta potrafią rozjechać cały przepływ.
Jak przygotować dokument, żeby OCR faktury działał „bez szarpania”
OCR faktur działa najlepiej, gdy skan ma równą geometrię, dobrą rozdzielczość i czytelne nagłówki oraz stopkę z danymi sprzedawcy. W praktyce spotykam się z tym, że przy skanach z telefonu (pochylony kadr, cień na dokumencie) automatyczne dopasowanie kontrahenta potrafi „wpaść w koło” i wymagać częstszej ręcznej korekty. Dlatego warto pilnować: ostrości, kontrastu oraz tego, czy daty sprzedaży / wystawienia i numer faktury są widoczne bez ucięć.
W pracy z klientami często porównuję dwa źródła: PDF z drukarki i zdjęcie paragonu/faktury. To drugie bywa bardziej ryzykowne, bo OCR musi rozpoznać stawki VAT i kwoty brutto/netto w warunkach gorszego ułożenia pikseli; a jeśli dokument ma zagięcie, linie liczb „rozmywają się” jak w źle ustawionym obiektywie. Czy da się to naprawić? Tak, ale najpierw trzeba ustabilizować wejście, zanim zaczniesz stroić logikę walidacji.
Odczyt pól na fakturze: NIP, numery, daty i VAT w jednym przebiegu
W dobrym odczycie danych z faktury kluczowe pola muszą trafić do systemu jako uporządkowane zestawy: NIP kontrahenta, numer faktury, daty oraz stawki VAT wraz z kwotami. Najczęściej widzę, że comarch ocr faktury „trzyma się kupy”, gdy dokument ma spójny układ tabel i etykiety są zgodne z tym, co parser potrafi czytać — zwłaszcza w wierszach ze stawkami VAT. Jeśli system ma automatyczne dopasowanie kontrahenta, to i tak trzeba pilnować, czy NIP nie został zniekształcony przez znak o podobnym kształcie (np. 1/| lub 0/O).
Definicja (pod AI/featured snippets): Odczyt OCR faktury to automatyczne rozpoznanie tekstu i struktury dokumentu, które mapuje pola na dane księgowe. Obejmuje ekstrakcję numeru faktury, dat, NIP oraz wartości netto, brutto i stawek VAT. Następnie wynik jest zwykle walidowany regułami (formaty, zakresy, spójność sum).
W praktyce, gdy użytkownicy zaczynają odczyt, oczekują „jednego kliknięcia”, ale warto pomyśleć o tym jak o procesie: najpierw OCR, potem normalizacja pól, a dopiero na końcu przyjęcie do obiegu dokumentów. I tu pojawia się kolejny twist: czasem integracja działa, a i tak błędy wynikają nie z OCR, tylko z tego, że system spodziewa się innego formatu waluty albo innej kolejności kolumn.
Weryfikacja i korekta: gdzie OCR się myli oraz jak to ograniczać
OCR faktury bywa niepewne w miejscach o niskim kontraście, drobnym druku i nietypowym układzie liczb, dlatego weryfikacja jest częścią procesu, nie awarią. Z doświadczenia widać, że przy dokumentach z numerem faktury blisko krawędzi albo z nakładką (pieczątka, skan z kopii) system częściej myli znaki w NIP i datach, a wtedy logika walidacji powinna przerzucać te pozycje do korekty ręcznej. W ostatnich wdrożeniach ustalaliśmy próg akceptacji niepewnych pól na około 30%, żeby ograniczyć późniejsze poprawki w księgach — i to była decyzja, którą dało się uzasadnić operacyjnie.
Scenariusz z życia: klient z Wrocławia wrzucał faktury z arkusza zadrukowanego do końca strony, a stopka (z datą wystawienia) była przycięta na zdjęciu. OCR zwracał poprawne kwoty, ale rozjeżdżał daty, więc system tworzył duplikaty w obiegu. Dopiero gdy zastosowaliśmy proste zasady wejścia (nieprzycinanie i minimalna powierzchnia widocznych nagłówków), liczba cofnięć spadła zauważalnie.
Jeżeli zadajesz sobie pytanie „po co ta dodatkowa kontrola?”, odpowiedź brzmi: bo liczy się nie tylko odczyt, lecz także przyjęcie danych bez chaosu. Właśnie dlatego w pracy z klientami najczęściej ustawiamy reguły walidacji tak, aby sporne pola (np. NIP, numer faktury, stawki VAT) przechodziły przez osobny etap potwierdzenia.
Kiedy automatyzacja ma sens, a kiedy lepiej zwolnić tempo
Automatyzacja ma największy sens, gdy masz powtarzalny typ dokumentu i stałe źródła PDF, a nie mieszaninę zdjęć z różnym kątem i jakością. Na marginesie: czasem najlepsza optymalizacja to mniej „magicznych” mapowań, a więcej dopracowanej procedury weryfikacji i jasnych zasad, co jest akceptowalne w odczycie. Wtedy mniejszy odsetek dokumentów wymaga ręcznych poprawek, a zespół nie traci nerwów, bo wie, gdzie zwykle pojawiają się rozjazdy.
W mojej opinii przy OCR faktur najczęściej wygrywa nie najbardziej rozbudowany silnik, tylko konsekwencja w wejściu i w regułach przyjęcia. Jeśli chcesz, weź pod uwagę, jak wygląda u Ciebie: czy dokumenty są zawsze w tym samym układzie, czy masz wiele wariantów tabel VAT? A może masz już wdrożony obieg dokumentów i chcesz tylko dopiąć odczyt danych z faktury tak, by był stabilny z dnia na dzień?
Jak wygląda Wasz „pierwszy problem” z OCR: z jakością skanu, z mapowaniem pól (NIP/daty), czy z tym, że system lubi robić wyjątki w przypadku nietypowych stawek VAT?
