OCR faktur: od PDF do plan kont, automatycznie.

Co konkretnie załatwia OCR faktur

Pełny pipeline OCR faktur to cztery etapy:

1. Ingest: faktura przychodzi mailem, pocztą (skan), przez formularz dostawcy, albo z portalu B2B. Pipeline musi ją wyłapać niezależnie od kanału.
2. OCR i ekstrakcja pól: z PDF (często obraz zeskanowany) wyciągamy konkretne pola: dostawca, NIP, numer faktury, data wystawienia i sprzedaży, netto, VAT, brutto, pozycje (opis plus kwota plus stawka VAT).
3. Mapowanie na plan kont: każda pozycja musi trafić na konkretny account (np. "usługi doradcze" → 403-01, "paliwo" → 401-10). Mapping zwykle per dostawca plus reguły słownikowe.
4. Push do systemu księgowego: Comarch Optima, enova365, iHurt, Subiekt GT, Fakturownia. Każdy ma swoje API (albo webhook, albo import CSV, albo Playwright upload w UI).

Automatyzacja zastępuje księgową w etapach 1-3. Ostateczne zatwierdzenie zostaje u człowieka (jedną kliknięciem "OK" zamiast ręcznego przepisywania).

Technologie OCR: co wybrać

Cztery podejścia do OCR, każde ze swoim miejscem:

• Google Document AI (Vertex AI): dedykowany processor invoice_processor wytrenowany na milionach faktur z całego świata. Polskie faktury obsługuje solidnie, dokładność 90-95 procent na dobrze zeskanowanych. Cena: około 0.08 PLN per faktura. Mój default dla średnich i dużych wolumenów.
• Custom Document AI processor: jeśli masz specyficzny layout (konkretny dostawca, własna faktura proforma), możesz trenować custom processor. 50-100 przykładów annotated, trening 2-4 godziny. Dokładność na specyficznym layoucie podskakuje do 98 procent.
• Tesseract plus custom parsing: open-source, za darmo, self-hosted. Dokładność raw OCR 85-90 procent, plus trzeba napisać parser pól (regex, heurystyki). Sensowne dla klientów z compliance wymagającym self-hosted albo bardzo niskim wolumenem (kilka faktur dziennie).
• LLM vision models: Gemini Vision, GPT-4o z image input. Bardzo dobre przy skomplikowanych układach, dokładność 92-97 procent. Koszt wyższy niż Document AI, ale elastyczność większa. Używam dla korekt, zaliczek, faktur w nietypowym formacie.

Pola, które zawsze muszę wyciągnąć

Minimalny set pól dla poprawnej faktury w Polsce:

• Dostawca: nazwa, NIP, adres. NIP używam jako klucz identyfikacyjny (weryfikacja w VIES, mapowanie na konto dostawcy w księdze).
• Numer i data faktury: numer jest unique identifier, data wystawienia plus data sprzedaży (dla VAT). Termin płatności jeśli jest.
• Kwoty: netto, VAT (per stawka: 0, 5, 8, 23, "np", "zw"), brutto. Trzeba wyciągnąć per stawka VAT, nie tylko sumę, bo deklaracja VAT tego wymaga.
• Pozycje: opis, kwota netto, stawka VAT, kwota VAT. Dla mapowania na plan kont.
• Waluta: PLN, EUR, USD. Jeśli nie PLN, dodatkowo kurs przeliczeniowy (NBP średni z dnia poprzedzającego wystawienie faktury, per polskie prawo).
• Metoda płatności: przelew, karta, gotówka. Mechanizm podzielonej płatności (MPP) jeśli stosowany.

Plus flagi walidacyjne: czy suma pozycji zgadza się z kwotą brutto (fakturowe sprawdzenie), czy NIP waliduje się checksumą, czy faktura nie jest duplikatem (po numerze i dostawcy).

Edge case'y, których nie da się zignorować

Szczegóły, które w produkcji wychodzą:

• Faktury korygujące: łączą się z oryginałem (różnica w pozycjach, zmiana kwoty). Automatyzacja musi rozpoznać, że to korekta (nie zwykła faktura), zlokalizować oryginalną i zaksięgować delta.
• Zaliczki i faktury końcowe: faktura zaliczkowa (np. 30 procent z góry) i końcowa (reszta plus rozliczenie zaliczki). Każda ma inne konto, księgowanie wymaga łączenia.
• Stawka "np" (nie podlega) albo "zw" (zwolniony): różne od 0. System księgowy musi je obsłużyć osobno w deklaracji VAT.
• MPP (mechanizm podzielonej płatności): dla transakcji powyżej 15 000 PLN z listy towarów/usług wrażliwych. Automatyzacja powinna to flaggować do ręcznej weryfikacji.
• Wielowalutowe faktury: faktura w EUR przeliczona na PLN według kursu NBP z dnia poprzedzającego. Mam dedykowany workflow pobierający kursy NBP i aplikujący do faktur.
• Skany z telefonu: zdjęcie faktury papierowej, pod kątem, z palcem w kadrze. Document AI sobie radzi, Tesseract zwykle nie. Pre-processing (rotate, crop, deskew) przed OCR.

Integracja z systemami księgowymi

Polskie systemy księgowe mają różne API:

• Comarch Optima: eAPI (REST) dla najnowszych wersji, plus import XML dla starszych. Uwierzytelnianie przez token. Integracja stabilna, dokumentacja dostępna.
• enova365: moduł "Serwer SOA" oferuje REST API. Wymaga konfiguracji po stronie klienta, ale kiedy działa, workflow stabilny.
• iHurt: SOAP API (starsze) albo REST w nowych wersjach. Dobry do integracji dla firm handlowych.
• Subiekt GT / Sfera: import CSV i własny format plików. Mniej elastyczne, ale działa dla prostych setup'ów.
• Fakturownia: REST API jest solidne, ale to platforma bardziej dla mikrofirm niż średnich.

Dla klientów z wyjątkowymi systemami (custom ERP, branżowy soft) robię wrapper integracyjny: n8n wysyła JSON, mikroserwis konwertuje na format oczekiwany przez docelowy system. Dzięki temu workflow n8n jest stabilny mimo ewentualnych zmian w tym legacy systemie.

Najczęstsze pytania

Co warto przeczytać obok