Automatyczne wyciąganie danych z dokumentów — OCR z AI

Jeden dokument. Jedna faktura od dostawcy.

Pracownik otwiera PDF. Przeklepuje: numer faktury, data, NIP dostawcy, pozycje (nazwa, ilość, cena netto, VAT, wartość brutto), numer konta, termin płatności. Sprawdza, czy suma się zgadza. Klika „zatwierdź". Zamknął plik.

Czas: 8 minut. Stawka: 60 PLN/h. Koszt: 8 PLN za fakturę.

Firma przetwarza 500 faktur miesięcznie.

Roczny koszt: 8 PLN × 500 × 12 = 48 000 PLN rocznie.

I to bez liczenia błędów (średnio 1-3% przy ręcznym wprowadzaniu), kosztu ich poprawiania i opóźnień w płatnościach wynikających z backlogu.

Automatyzacja OCR+AI tego procesu kosztuje 15 000-25 000 PLN jednorazowo + 3 000-6 000 PLN rocznie operacyjnie. ROI: rok 1 = 100-200%, rok 2 wzwyż = 600%+.

Ten wpis to przewodnik techniczny. Pokaże ci, jak działa pipeline, jakie typy dokumentów są trudne i które rozwiązanie pasuje do jakiej skali.

Cztery typy dokumentów — inne podejście do każdego

Nie ma jednego "pipeline OCR". Podejście zależy od struktury dokumentu.

Typ 1: Dokumenty ustrukturyzowane (faktury, formularze, druki)

Stała struktura — pole "NIP" zawsze jest w tym samym miejscu. OCR czyta tekst, model wyciąga wartości z określonych pozycji. Accuracy 90-98% dla dobrej jakości skanów.

Narzędzia: Azure Form Recognizer (teraz Document Intelligence), AWS Textract, Google Document AI. Wszystkie mają pre-built modele dla faktur — nie trzeba trenować od zera.

Trudności: faktury z małych firm często mają niestandardowy layout, skany z telefonu mają niską rozdzielczość, faktury ręczne mają nieczytelny charakter pisma.

Typ 2: Dokumenty półustrukturyzowane (umowy, oferty, korespondencja)

Znana struktura semantyczna, ale zmienny layout. "Termin płatności" zawsze jest w umowie, ale może być w różnym miejscu, różną czcionką, z różnym sformułowaniem.

Tutaj potrzebujesz LLM do interpretacji, nie tylko OCR do czytania. Pipeline: OCR → tekst → LLM, który rozumie semantykę dokumentu → JSON z polami.

Accuracy dla wytrenowanego modelu: 80–92% w zależności od zmienności dokumentów.

Typ 3: Dokumenty nieustrukturyzowane (raporty, maile, notatki)

Tekst bez żadnej z góry ustalonej struktury. Celem jest wyciągnięcie konkretnych informacji (np. z maila klienta: kwota zamówienia, termin, adres dostawy).

Wymaga silnego LLM z dobrym promptem. Accuracy: 70-85% — zależy bardzo od jakości promptu i jasności dokumentu.

Typ 4: Obrazy i skany z pismem odręcznym (ręcznie wypełnione formularze)

Najczęściej podawany powód "OCR nie zadziała u nas". W rzeczywistości: modele handwriting recognition (Azure, Google) mają 85-94% accuracy dla czytelnego pisma, 60-75% dla nieczytelnego.

Strategia: automatyzuj czytelne, flaguj nieczytelne do weryfikacji człowieka. Nie próbuj automatyzować 100% — celuj w 80% auto + 20% human review.

Pipeline: skan → OCR → wyciąganie → walidacja → ERP

Krok po kroku architektury, którą wdrażam:

Krok 1: Intake (przyjęcie dokumentu) Dokument trafia przez jeden z kanałów: email attachment, folder na SharePoint/Google Drive, skan z drukarki sieciowej, upload przez formularz webowy. n8n/Make nasłuchuje i uruchamia pipeline.

Krok 2: Pre-processing Sprawdzenie: czy plik jest czytelny (DPI > 150), czy nie jest pusty, jaki format. Konwersja do PDF lub standaryzowanego obrazu. Korekcja orientacji, jeśli skan jest obrócony.

Krok 3: OCR Wysłanie do silnika OCR (Azure Document Intelligence, AWS Textract, Tesseract dla on-premise). Odbiór tekstu z confidence score dla każdego pola.

Krok 4: Extraction (wyciąganie danych) LLM (GPT-4o-mini lub GPT-4o zależnie od złożoności) otrzymuje surowy tekst OCR + schema JSON z polami do wyciągnięcia. Zwraca JSON z wartościami i confidence.

Krok 5: Validation (walidacja) Reguły biznesowe: czy NIP jest poprawny (checksum), czy suma pozycji = wartość brutto, czy data jest w sensownym zakresie, czy kontrahent istnieje w bazie. Przy naruszeniu reguły: flaga do weryfikacji.

Krok 6: Human review queue Dokumenty z confidence < threshold lub naruszeniem reguł trafiają do kolejki weryfikacji. Pracownik widzi dokument i wstępnie wypełnione pola — musi tylko potwierdzić lub poprawić.

Krok 7: ERP/system import Po weryfikacji: automatyczny import do Optima, SAP, Subiekt, własnego ERP przez API lub bezpośredni zapis do bazy.

import base64import jsonfrom pathlib import Pathfrom openai import OpenAI

client = OpenAI()

INVOICE_SCHEMA = { "invoice_number": "string - numer faktury", "invoice_date": "string - data wystawienia YYYY-MM-DD", "due_date": "string - termin platnosci YYYY-MM-DD", "seller_name": "string - nazwa sprzedawcy", "seller_nip": "string - NIP sprzedawcy (10 cyfr bez kresek)", "buyer_name": "string - nazwa nabywcy", "buyer_nip": "string - NIP nabywcy", "net_total": "number - wartosc netto", "vat_total": "number - kwota VAT", "gross_total": "number - wartosc brutto", "bank_account": "string - numer konta bankowego", "currency": "string - waluta (PLN/EUR/USD)" }

def extract_invoice_data(pdf_path: str, ocr_text: str) -> dict: schema_str = json.dumps(INVOICE_SCHEMA, ensure_ascii=False, indent=2)

prompt = f"""Wyciagnij dane z faktury. Tekst z OCR (moze zawierac bledy): --- {ocr_text} --- Zwroc JSON z tymi polami: {schema_str}

Zasady: - Jezeli pola nie mozna znalezc, zwroc null - NIP: tylko cyfry, bez kresek i spacji - Kwoty: liczby z kropka jako separatorem dziesietnym - Daty: format YYYY-MM-DD - Nie zgaduj - jezeli niepewny, zwroc null"""

response = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"}, temperature=0 )

data = json.loads(response.choices[0].message.content) return data

def validate_invoice(data: dict) -> list: errors = []

# Walidacja NIP (checksum) nip = data.get("seller_nip", "") if nip and len(nip) == 10 and nip.isdigit(): weights = [6, 5, 7, 2, 3, 4, 5, 6, 7] checksum = sum(int(nip[i]) * weights[i] for i in range(9)) % 11 if checksum != int(nip[9]): errors.append(f"Niepoprawny NIP sprzedawcy: {nip}") elif nip: errors.append(f"NIP sprzedawcy w zlym formacie: {nip}")

# Walidacja sum net = data.get("net_total") vat = data.get("vat_total") gross = data.get("gross_total") if all(x is not None for x in [net, vat, gross]): calculated = round(net + vat, 2) if abs(calculated - gross) > 0.05: errors.append(f"Suma nie zgadza sie: {net} + {vat} = {calculated}, brutto = {gross}")

return errors

# Przykladowe uzycie if __name__ == "__main__": ocr_text = """Faktura VAT nr FV/2026/05/001 Wystawiono: 15.05.2026, Platnosc: 29.05.2026 Sprzedawca: Firma XYZ Sp. z o.o., NIP: 5213456789 Nabywca: Klient ABC S.A., NIP: 9512345678 Usluga: Wdrozenie systemu AI - 15000.00 PLN netto VAT 23%: 3450.00 PLN Brutto: 18450.00 PLN Konto: 12 1234 5678 9012 3456 7890 1234"""

extracted = extract_invoice_data("invoice.pdf", ocr_text) errors = validate_invoice(extracted)

print("Wyciagniete dane:", json.dumps(extracted, ensure_ascii=False, indent=2)) if errors: print("Bledy walidacji:", errors) else: print("Dane poprawne - mozna importowac do ERP")

Porównanie rozwiązań OCR+AI

Accuracy vs koszt — jak znaleźć właściwy punkt

Wiele firm popełnia błąd: celuje w 100% automatyzacji i 99% accuracy. To niepotrzebne i drogie.

Bardziej pragmatyczne podejście:

90% automatyzacji + 10% human review jest często lepsze niż 95% automatyzacji z większym ryzykiem błędów. Dlaczego? Bo koszt pracy człowieka przy weryfikacji 10% dokumentów jest niski, a spokój ducha (i bezpieczeństwo danych) — wysoki.

Mój standard dla wdrożeń produkcyjnych: - Accuracy >= 92% dla pól krytycznych (NIP, kwoty, numery kont) - Confidence threshold: dokumenty poniżej 85% confidence automatycznie do human review - Cel automatyzacji: 80-85% dokumentów bez żadnej interwencji człowieka - Pozostałe 15-20%: human review z wstępnie wypełnionymi polami (nie przepisywanie od zera)

Trzy pułapki wdrożeń OCR

Pułapka 1: "OCR nie będzie działał, bo nasze faktury są różne"

Słyszę to w każdym projekcie. Prawda jest taka: Azure Document Intelligence i podobne narzędzia są trenowane na milionach dokumentów i radzą sobie z dużą zmiennością. Wyjątki: faktury ręcznie napisane, bardzo niskiej jakości skany, dokumenty w egzotycznych językach.

Zanim odrzucisz OCR — zrób proof of concept na 50 rzeczywistych dokumentach. Wyniki prawie zawsze są lepsze niż oczekiwania.

Pułapka 2: Brak walidacji biznesowej = błędy w ERP

System wyciągnął dane z OCR. Zaimportował do ERP. Nikt nie sprawdził. Faktura z błędnym NIP-em trafiła do deklaracji VAT, kwota zaokrąglona nie zgadza się o grosz, duplikat faktury zaimportowany dwa razy.

Walidacja biznesowa (checksum NIP, zgodność sum, duplikat check) jest obowiązkowa. Nie opcjonalna.

Pułapka 3: Ignorowanie RODO przy fakturach i umowach

Dokumenty finansowe i umowy zawierają dane osobowe. Wysyłanie ich do zewnętrznych API (Azure, AWS, OpenAI) wymaga umowy powierzenia danych (DPA). Azure i AWS mają standardowe DPA — podpisz zanim zaczniesz przetwarzać.

Alternatywa: Tesseract on-premise + własny model LLM (Ollama + Llama) dla pełnej kontroli danych. Niższa accuracy, zerowe RODO-ryzyko.

Najczęstsze pytania

---

Buduję pipeline'y OCR+AI dopasowane do specyfiki dokumentów i systemów w Twojej firmie — od prostej automatyzacji faktur po złożone systemy przetwarzania umów z walidacją i workflow zatwierdzania. Napisz do mnie — zaczynam od bezpłatnego testu accuracy na 30 Twoich dokumentach. Zanim cokolwiek wdrożymy, zobaczysz realne liczby.