Jak AI czyta faktury papierowe i PDF bez przepisywania danych i co z RODO, gdy model działa na Twoim serwerze?

Model AI wyciąga z faktury numer dokumentu, NIP dostawcy i nabywcy, datę wystawienia, termin płatności, pozycje z kwotami i numer konta bankowego, bez udziału człowieka przy każdym pliku. Cały przepływ, od skanu lub PDF-a do wpisu w ERP, zajmuje kilkanaście sekund. Gdy model uruchomiony jest na Waszym własnym serwerze, żaden obraz faktury nie trafia do żadnego zewnętrznego API, co zdejmuje z Was podstawowy problem compliance przy przetwarzaniu danych kontrahentów i pracowników.

Jak wygląda przepływ od skanu do ERP krok po kroku?

Pracownik skanuje fakturę papierową przy drukarce wielofunkcyjnej albo zapisuje PDF z e-maila w wyznaczonym folderze sieciowym. Skrypt monitorujący folder wykrywa nowy plik i przesyła go do modelu multimodalnego działającego lokalnie jako kontener na Waszym serwerze. Model "widzi" obraz lub dokument, odczytuje strukturę i zwraca dane w formacie JSON z wyciągniętymi polami. Skrypt pobiera ten JSON, waliduje podstawowe reguły i zapisuje wpis w ERP albo wiersze w arkuszu.

Cały łańcuch jest asynchroniczny. Pracownik nie musi czekać przy skanerze. Wrzuca plik, wraca do swoich zadań, a faktura pojawia się w systemie finansowym w ciągu minut. Dokumenty, przy których model nie był wystarczająco pewny odczytu, trafiają do osobnej kolejki z podglądem: pracownik widzi obraz faktury obok wyciągniętych pól i poprawia tylko te, które model oznaczył jako wątpliwe.

Które pola wyciąga model i skąd wie, że odczytał poprawnie?

Na typowej fakturze kosztowej model wyciąga następujące pola:

• Dane dostawcy: nazwa firmy, NIP, adres
• Dane nabywcy: nazwa firmy, NIP, adres (ważne przy fakturach zbiorczych lub dokumentach z kilkoma nabywcami)
• Numer faktury i data wystawienia
• Termin płatności lub data płatności: na różnych fakturach to pole ma różne nazwy, "płatność do", "termin zapłaty", "data wymagalności", model rozpoznaje każdą z nich
• Pozycje: opis towaru lub usługi, ilość, cena jednostkowa, stawka VAT
• Kwoty sumaryczne: netto, kwota VAT, brutto
• Numer konta bankowego do przelewu
• Waluta dokumentu

Walidacja działa na kilku poziomach. NIP przechodzi przez algorytm sumy kontrolnej przed zapisem. Kwota brutto musi zgadzać się z sumą pozycji. Data terminu płatności musi być datą, a nie przypadkowym ciągiem cyfr. Gdy coś nie przechodzi walidacji, dokument nie trafia do ERP bez poprawki człowieka. To istotna różnica wobec klasycznych narzędzi OCR, które przepisują mechanicznie znaki bez rozumienia kontekstu.

Co się dzieje z odręczną fakturą albo słabej jakości skanem?

Ręcznie pisana faktura od podwykonawcy z budowy albo od serwisanta sprzętu to realny scenariusz w wielu firmach. Modele multimodalne radzą sobie z tym lepiej niż klasyczny OCR, bo rozumieją układ dokumentu: wiedzą, że pole po słowie "NIP:" to ciąg cyfr, a kwota w prawym dolnym rogu formularza to prawdopodobnie brutto. Nie przepisują mechanicznie znak po znaku.

Ale nie są bezbłędne. Przy odręcznym piśmie, zmiętem papierze albo zdjęciu robionym telefonem pod kątem model zwraca w JSON dodatkowe pole informujące o niskiej pewności odczytu. Skrypt wyłapuje tę informację i kieruje dokument do kolejki ręcznej weryfikacji zamiast zapisywać dane automatycznie.

U jednego z naszych klientów z branży budowlanej spora część faktur trafiała na początku do tej kolejki, bo dostawcy przysyłali zdjęcia odręcznych rachunków. Pracownik poprawiał błędnie odczytane pola, a model z każdą poprawką uczył się wzorców pisma konkretnych wystawców. Odsetek dokumentów przekierowanych do ręcznej weryfikacji stopniowo malał, w miarę jak model zobaczył dość przykładów od tych samych dostawców.

RODO przy fakturach: dlaczego własny serwer to nie jest zbędna komplikacja

Faktura kosztowa od osoby fizycznej prowadzącej działalność zawiera dane osobowe w rozumieniu RODO: imię i nazwisko, adres zamieszkania używany jako adres firmy, NIP powiązany z konkretną osobą. Gdy wysyłacie obraz takiej faktury do zewnętrznego API, usługi OCR w chmurze albo modelu vision od dostawcy SaaS, dane przetwarzane są na serwerach zewnętrznych. Wymaga to umowy powierzenia przetwarzania danych, a przy dostawcach spoza Unii Europejskiej pojawia się kwestia transferu danych poza EOG.

Gdy model działa na Waszym serwerze lub w prywatnym centrum danych w Polsce, obraz faktury nigdy nie opuszcza Waszej sieci. JSON z wyciągniętymi polami wraca do skryptu wewnętrznego. Z punktu widzenia rejestru czynności przetwarzania mamy do czynienia z jednym zdarzeniem wewnętrznym: bez podmiotu przetwarzającego z zewnątrz, bez transferu danych.

Ma to szczególne znaczenie dla kilku typów firm:

• Biur rachunkowych przetwarzających faktury wielu klientów jednocześnie
• Firm obsługujących faktury od osób fizycznych na działalności: budowlańcy, usługodawcy, freelancerzy
• Firm rozliczających faktury pracownicze za delegacje i wydatki służbowe
• Podmiotów działających w sektorach regulowanych: zdrowie, finanse, gdzie transfer danych do chmur publicznych wymaga dodatkowych analiz prawnych

Warto mieć to czarno na białym w dokumentacji wdrożenia: gdzie fizycznie stoi model, kto ma do niego dostęp sieciowy i jak logowane są wywołania. To konkretna odpowiedź dla inspektora ochrony danych lub audytora, gdy zapyta o podstawę prawną i techniczny opis procesu.

Automatyczna dekretacja: co dzieje się po wyciągnięciu pól?

Ekstrakcja pól to pierwsza warstwa. Druga to automatyczna dekretacja: przypisanie faktury do właściwego konta kosztowego bez angażowania księgowej przy każdym dokumencie.

Model, który wyciągnął dane, może jednocześnie zaproponować dekret na podstawie nazwy dostawcy, opisu pozycji i historii dokumentów od tego kontrahenta. Faktura za internet od tego samego operatora co zawsze trafia na konto 402 bez pytania. Faktura za naprawę maszyny trafia na odpowiednie konto remontowe. Booking noclegu służbowego ląduje w kosztach podróży.

Księgowa przegląda tylko wyjątki: nowe kategorie wydatków, faktury powyżej ustalonego progu kwotowego, dokumenty z opisami, których model nie widział wcześniej. Do ERP trafiają jednocześnie rekord z danymi faktury i gotowa propozycja dekretu: numer konta kosztowego, centrum kosztów (jeśli firma go stosuje), numer projektu lub zamówienia, jeśli jest widoczny na dokumencie.

Z jakimi systemami ERP to działa i od czego zaczynamy?

Integracja działa z każdym ERP, który ma API lub obsługuje import pliku CSV albo XML. Z polskich systemów są to Comarch ERP Optima, Comarch ERP XL, Symfonia ERP, wFirma. Dla większych firm SAP Business One lub Microsoft Dynamics 365 Business Central. Wdrożenie nie wymaga zmian w ERP po stronie dostawcy oprogramowania: integracja łączy się przez dostępne API lub mechanizm importu, bez dotykania struktury bazy danych systemu finansowego.

Firmy bez ERP, rozliczające się w arkuszu, mogą zapisywać wyciągnięte pola wprost do Google Sheets lub Excela na dysku sieciowym. Mniej eleganckie, ale w pełni wystarczające jako punkt startowy.

Pierwsza rozmowa przy każdym wdrożeniu obejmuje trzy pytania: skąd faktury do Was trafiają (e-mail, papier, portal dostawcy), z jakim systemem finansowym macie do czynienia i ile dokumentów miesięcznie przez to przechodzi. Na tej podstawie dobieramy model i decydujemy, czy wystarczy kontener na obecnym serwerze, czy potrzebne jest osobne środowisko. Jeśli chcecie zobaczyć, jak ten przepływ działa na Waszych własnych fakturach, zapraszamy na bezpłatny audyt. Pokazujemy proces na przykładowych dokumentach, bez żadnych zobowiązań. Możecie też sprawdzić realne wdrożenia, żeby zobaczyć, jak wygląda to w firmach o podobnym profilu do Waszego.