OCR potrafi bezbłędnie odczytać kwotę 12 300,00 zł, termin płatności i numer faktury, a jednocześnie pomylić jedną cyfrę NIP. Jeszcze groźniejszy jest inny wariant: OCR odczytuje formalnie poprawny NIP, ale należący do niewłaściwego podmiotu. Na ekranie wszystko wygląda wiarygodnie, operator widzi zielone pole z wysokim confidence score i zatwierdza dokument.
Dlatego DMS obsługujący faktury nie może być zbudowany według zasady „OCR odczytał — człowiek zaakceptował”. OCR odpowiada za ekstrakcję danych, a nie za potwierdzenie ich prawdziwości. Między odczytem a księgowaniem potrzebna jest warstwa walidacyjna, która sprawdza pojedyncze pola, związki między nimi oraz zgodność dokumentu z danymi znajdującymi się poza fakturą.
To ważne również dlatego, że wysoki wynik confidence nie jest dowodem poprawności. Dostawcy technologii OCR sami opisują confidence jako statystyczną ocenę pewności predykcji. Model może być bardzo pewny błędnego odczytu — szczególnie gdy znak wygląda jednoznacznie, ale został przypisany do niewłaściwego pola albo OCR pobrał NIP nabywcy zamiast NIP sprzedawcy.
Najpierw matematyka, potem tożsamość kontrahenta
Pierwsza kontrola NIP powinna odbywać się automatycznie, jeszcze zanim dokument trafi do akceptacji. Polski NIP składa się z 10 cyfr, a dziesiąta jest cyfrą kontrolną. DMS może więc natychmiast sprawdzić, czy OCR zwrócił ciąg, który w ogóle może być poprawnym NIP.
Algorytm jest prosty:
- pierwsze dziewięć cyfr mnoży się kolejno przez wagi 6, 5, 7, 2, 3, 4, 5, 6, 7;
- iloczyny są sumowane;
- z sumy oblicza się resztę z dzielenia przez 11;
- wynik musi być równy dziesiątej cyfrze NIP;
- jeżeli wynik modulo 11 wynosi 10, numer jest nieprawidłowy.
To kontrola tania obliczeniowo i powinna działać przy każdym odczycie, niezależnie od confidence OCR. Dokument z NIP-em, który nie przechodzi sumy kontrolnej, nie może zostać dopuszczony do automatycznej akceptacji: DMS powinien wykryć niezgodność i skierować dokument do kolejki wyjątków do wyjaśnienia.
Problem zaczyna się krok później. Poprawna suma kontrolna nie oznacza, że podmiot istnieje. Nie dowodzi też, że kontrahent ma odpowiedni status VAT ani że rachunek bankowy wpisany na fakturze można bez dalszej kontroli wykorzystać do płatności.
Praktyczny scenariusz wygląda tak: faktura ma prawidłowo rozpoznaną kwotę 18 450,00 zł. OCR omyłkowo pobiera jako NIP sprzedawcy inny dziesięciocyfrowy numer występujący na dokumencie. Numer przypadkiem przechodzi sumę kontrolną. System oparty wyłącznie na walidacji matematycznej przepuści fakturę.
Dlatego poprawny algorytm DMS powinien wykonywać kontrole warstwowo:
- Format i suma kontrolna NIP — czy numer jest technicznie prawidłowy.
- Status NIP w systemie KAS — czy taki numer istnieje.
- Słownik kontrahentów ERP — czy NIP odpowiada kontrahentowi przypisanemu do dokumentu.
- Status podatnika VAT — jeżeli jest istotny dla danej operacji.
- Wykaz podatników VAT — gdy proces wymaga kontroli rachunku i statusu podmiotu na określony dzień.
- VIES — dla transakcji, dla których znaczenie ma potwierdzenie numeru VAT UE.
Słownik ERP powinien być przy tym traktowany jako źródło biznesowe, a nie urzędowe. Jeżeli w SAP, Microsoft Dynamics 365, Comarch ERP albo innym systemie zapisano kiedyś błędny NIP, porównanie faktury z ERP jedynie potwierdzi stary błąd.
Dobrym sygnałem alarmowym jest natomiast konflikt danych. Przykładowo:
OCR: NIP A
ERP dla dostawcy: NIP B
numer zamówienia PO: wystawiony dla dostawcy B
W takim przypadku dokument nie powinien automatycznie przejść dalej nawet wtedy, gdy NIP A ma prawidłową sumę kontrolną i istnieje w KAS. System nie wie jeszcze, czy OCR pomylił kontrahenta, czy fakturę wystawiono dla niewłaściwego podmiotu.
Szczególnie rygorystyczna powinna być obsługa zmiany rachunku bankowego. Jeżeli kontrahent używał dotychczas rachunku X, a nowa faktura podaje rachunek Y, samo odczytanie Y z wysokim confidence nie wystarcza. Nie powinno wystarczać również to, że numer rachunku wygląda formalnie poprawnie.
Taka zmiana powinna uruchamiać co najmniej niezależną weryfikację zgodnie z procedurą firmy: sprawdzenie właściwego wykazu, porównanie z kartoteką kontrahenta i — w przypadkach podwyższonego ryzyka — potwierdzenie zmiany kanałem niezależnym od wiadomości, z której przyszła faktura. Telefon należy wykonywać na numer zapisany wcześniej w kartotece lub umowie, a nie na numer dopisany do wiadomości informującej o zmianie konta.
Automatyzacja ma sens, gdy źródła są zgodne. Konflikt źródeł powinien tworzyć wyjątek, a nie automatyczną korektę danych.
DMS powinien sprawdzać dokument w poprzek, nie pole po polu
Najczęstszy błąd projektowy polega na walidowaniu każdego pola osobno. NIP ma dziesięć cyfr. Data ma właściwy format. Kwota jest liczbą. Waluta to PLN. Wszystko jest więc „zielone”.
Tyle że faktura może nadal być biznesowo błędna.
DMS powinien stosować reguły krzyżowe, czyli sprawdzać relacje pomiędzy wartościami. Dla faktury zakupowej podstawowy zestaw obejmuje między innymi:
- netto + VAT = brutto w modelu właściwym dla dokumentu;
- sumę pozycji wobec podsumowania faktury;
- stawki i kwoty VAT wobec pozycji, których dotyczą;
- walutę dokumentu wobec zamówienia i umowy;
- datę wystawienia, sprzedaży lub wykonania usługi oraz termin płatności pod kątem logicznych konfliktów;
- numer faktury razem z NIP sprzedawcy pod kątem duplikatu;
- numer zamówienia PO, dostawcę, indeksy, ilości i ceny jednostkowe;
- rachunek płatniczy wobec kartoteki kontrahenta i wymaganych źródeł zewnętrznych.
W praktyce najbardziej użyteczna nie jest jedna „superreguła”, lecz zestaw reguł o różnych konsekwencjach.
Przykład. Zamówienie przewiduje 100 sztuk po 48,00 zł netto. Faktura zawiera 110 sztuk po 48,00 zł. OCR wszystkie wartości odczytał idealnie. Klasyczny system OCR oceni dokument jako wysokiej jakości. DMS połączony z PO powinien jednak znaleźć przekroczenie ilości o 10 sztuk, czyli o 480,00 zł netto.
Co system ma zrobić dalej, zależy od procesu zakupowego. Jeżeli firma dopuszcza fakturowanie ponad zamówienie w określonym zakresie, można zastosować tolerancję. Jeżeli zamówienie jest limitem bezwzględnym, dokument trafia do wyjątku.
Nie należy natomiast wpisywać jednej tolerancji do wszystkich kontroli. Tolerancja ceny, ilości oraz różnicy wynikającej z zaokrągleń podatkowych rozwiązują trzy różne problemy.
Dobrym przykładem jest różnica jednego grosza. Nie każda różnica 0,01 zł oznacza błędną fakturę. Wynik może zależeć od tego, czy system porównuje obliczenia wykonywane na poszczególnych wierszach, czy wartości zagregowane oraz w którym miejscu następuje zaokrąglenie.
Z tego powodu silnik walidacyjny powinien:
- wykonywać obliczenia pieniężne na typie decimal/fixed-point, a nie na binarnym floating point;
- znać model obliczeń zastosowany dla konkretnego dokumentu;
- odróżniać różnicę wynikającą z dozwolonego sposobu obliczenia od rzeczywistej niezgodności;
- nie stosować automatycznie zasady „0,01 zł zawsze akceptujemy”.
Jeszcze ważniejsza jest kontrola duplikatów. Porównanie wyłącznie numeru faktury jest za słabe. Dwóch sprzedawców może legalnie wystawić dokument „FV/10/2026”. Rozsądny klucz powinien uwzględniać przynajmniej identyfikator kontrahenta i numer dokumentu, a zależnie od systemu również datę, kwotę, walutę lub identyfikator KSeF.
Dla faktur powiązanych z zamówieniem najlepiej stosować matching dwu- albo trójstronny:
- faktura ↔ PO;
- faktura ↔ PO ↔ przyjęcie towaru lub potwierdzenie wykonania usługi.
Drugi wariant lepiej odpowiada na pytanie, czy firma rzeczywiście powinna zapłacić. Samo zamówienie potwierdza bowiem zamiar zakupu, nie wykonanie dostawy.
Nie każdą fakturę warto jednak przepuszczać przez PO matching. Czynsz, energia, opłaty telekomunikacyjne, część usług abonamentowych czy rozliczenia wynikające z umów mogą mieć inny model kontroli. Próba wymuszenia zamówienia na każdym dokumencie zwykle kończy się produkowaniem fikcyjnych PO tylko po to, aby system pozwolił zaksięgować koszt.
Tu potrzebna jest decyzja procesowa: jakiego dowodu oczekujemy dla danego typu wydatku. Dla jednego będzie nim PO i PZ, dla innego umowa i okres rozliczeniowy.
Najważniejsze jest jednak zachowanie oryginału. DMS nie powinien po wykryciu niezgodności po cichu zastępować wartości odczytanej przez OCR wartością ze słownika ERP. Powinien przechowywać co najmniej:
- wartość źródłową;
- wartość odczytaną przez OCR;
- confidence;
- wynik walidacji;
- wartość zaakceptowaną;
- informację, kto lub jaka reguła dokonała zmiany.
W przeciwnym razie system naprawia dokument tak skutecznie, że później nie da się ustalić, co rzeczywiście znajdowało się na fakturze.
KSeF usuwa część problemów OCR, ale nie usuwa błędów biznesowych
Dla faktury otrzymanej w KSeF podstawowym źródłem danych powinien być ustrukturyzowany XML, a nie OCR wykonany na PDF-ie lub innej wizualizacji faktury. Od 1 lutego 2026 r. dla faktur ustrukturyzowanych stosowana jest struktura FA(3).
To istotna zmiana architektoniczna. Jeżeli DMS pobrał z KSeF XML z polami NIP, datami, wartościami i pozycjami faktury, ponowne rozpoznawanie tych samych informacji z obrazu wprowadza dodatkowe źródło błędu bez wyraźnej korzyści.
PDF może nadal służyć człowiekowi do wygodnego podglądu. Nie powinien jednak wygrywać z XML-em jako źródłem wartości przeznaczonych do automatycznego księgowania.
To nie oznacza, że fakturę z KSeF można księgować bez kontroli. Poprawna struktura XML mówi, że system otrzymał dane w określonym formacie. Nie mówi, że dane odpowiadają zamówieniu, umowie czy rzeczywistej dostawie. Ministerstwo Finansów wskazuje również, że KSeF nie wykonuje za odbiorcę sprawdzenia kontrahenta w Wykazie podatników VAT.
Przykład jest prosty. Dostawca wystawia prawidłową technicznie e-fakturę na 64 000 zł. XML przechodzi walidację schematu. NIP ma właściwy format. Wszystkie wymagane pola są obecne. Zamówienie opiewa jednak na 46 000 zł.
Tu OCR nie popełnił żadnego błędu, bo OCR w ogóle nie był potrzebny. Mimo tego DMS ma 18 000 zł rozbieżności biznesowej, którą powinien zatrzymać przed księgowaniem lub płatnością.
Dlatego system po odebraniu XML powinien wykonać co najmniej trzy grupy kontroli.
Pierwsza: tożsamość stron. NIP z faktury należy skonfrontować ze słownikiem ERP i — gdy wymaga tego proces — odpowiednimi źródłami Ministerstwa Finansów. Sprawdzenie statusu NIP, statusu VAT i Wykazu podatników VAT nie jest jedną operacją logiczną.
Druga: zgodność transakcji. DMS sprawdza PO, umowę, ilości, ceny, walutę, dane dostawy i wcześniejsze dokumenty.
Trzecia: bezpieczeństwo płatności. Rachunek należy kontrolować według procedury właściwej dla danej płatności. Jeżeli używany jest Wykaz podatników VAT, wynik kontroli powinien być powiązany z datą sprawdzenia i zapisany w ścieżce audytowej. Przy zmianie rachunku potrzebna jest oddzielna reguła podwyższonego ryzyka.
VIES należy włączać tam, gdzie znaczenie ma status VAT UE kontrahenta. Nie ma natomiast sensu odpytywać VIES mechanicznie dla każdej zwykłej krajowej faktury tylko dlatego, że system potrafi to zrobić.
Podobnie należy traktować confidence OCR. Próg można wykorzystać do sterowania kolejką, ale nie jako certyfikat poprawności. Przykładowa polityka może wyglądać tak:
- confidence poniżej 0,90 — obowiązkowa kontrola człowieka;
- confidence 0,90–0,98 — automatyzacja tylko wtedy, gdy przechodzą wszystkie reguły deterministyczne i krzyżowe;
- confidence powyżej 0,98 — możliwość automatycznego przetworzenia, ale nadal bez pomijania kontroli NIP, duplikatu, wartości, kontrahenta i reguł płatniczych.
To przykład konfiguracji DMS, a nie próg wynikający z polskich przepisów. W praktyce progi powinny wynikać z własnych danych o błędach. Identyfikatory podatkowe i rachunki bankowe zasługują na ostrzejsze reguły niż opis pozycji albo nazwa ulicy, ponieważ konsekwencja błędu jest znacznie większa.
Najlepszym miejscem dla niejednoznacznych dokumentów jest osobna exception queue. Operator nie powinien dostawać komunikatu „sprawdź fakturę”, lecz dokładny powód:
- NIP nie przechodzi sumy kontrolnej;
- NIP istnieje, ale nie zgadza się z dostawcą wskazanym w PO;
- rachunek różni się od ostatnio zatwierdzonego;
- kwota brutto nie odpowiada modelowi netto/VAT;
- przekroczono wartość PO;
- dokument wygląda na duplikat;
- waluta faktury różni się od waluty zamówienia.
Taki komunikat skraca kontrolę, bo człowiek nie musi ponownie czytać całej faktury. Dostaje konkretną sprzeczność do rozstrzygnięcia.
FAQ
Czy prawidłowa suma kontrolna NIP oznacza, że kontrahent jest prawdziwy?
Nie. Potwierdza tylko matematyczną poprawność numeru. Istnienie NIP należy zweryfikować w odpowiedniej usłudze KAS, a status VAT i inne cechy kontrahenta w źródłach przeznaczonych właśnie do tego celu.
Czy confidence OCR na poziomie 99% pozwala automatycznie zaksięgować fakturę?
Nie powinien być jedynym warunkiem. Confidence opisuje pewność modelu, a nie zgodność faktury z ERP, zamówieniem, statusem podatnika czy rachunkiem. Dla pól finansowych wysoki confidence powinien działać razem z regułami deterministycznymi.
Czy faktura z KSeF nie wymaga już walidacji DMS?
Wymaga. XML eliminuje część błędów związanych z przepisywaniem i OCR, ale nadal można otrzymać dokument z niewłaściwą ceną, ilością, kontrahentem, rachunkiem albo odniesieniem do zamówienia. KSeF nie zastępuje kontroli biznesowej.
Od czego zacząć poprawę istniejącego procesu OCR?
Najpierw usuń automatyczne księgowanie oparte wyłącznie na confidence OCR. Następnie wdroż kolejno: walidację NIP i innych identyfikatorów, kontrolę duplikatów, reguły netto–VAT–brutto, porównanie z kartoteką kontrahenta oraz PO lub umową. Dopiero potem stroiłbym progi confidence. Jeśli system potrafi dziś odczytać fakturę, ale nie potrafi wykryć sprzeczności między NIP-em, kontrahentem, rachunkiem i zamówieniem, problemem nie jest jakość OCR. Problemem jest brak warstwy walidacyjnej.
