Najważniejsze wnioski
- Przetwarzanie rachunków za media rzadko kończy się niepowodzeniem dlatego, że OCR nie potrafi odczytać strony. Zawodzi, ponieważ system nie wie, co oznacza dana liczba, czy jest kompletna, czy zgadza się z innymi liczbami i co zrobić, gdy się nie zgadza.
- Pilotaż na 50 rachunkach to demo, a nie test. Pomija szacowane odczyty, poprawione rachunki, faktury za wiele liczników i zdjęcia robione telefonem, które stanowią rzeczywistość każdego miesiąca.
- Wymagaj dokładności na poziomie pola, nigdy pojedynczego procenta dokładności OCR. Idealnie odczytana strona wciąż może wprowadzić błędną wartość do księgi głównej.
- Kolejka do weryfikacji to stały koszt działania. Przy 3000 rachunków miesięcznie różnica między wskaźnikiem wyjątków wynoszącym 5% a 20% to 450 dokumentów, które ktoś musi otworzyć.
- Wprowadź reguły walidacji między ekstrakcją a systemem ERP, w przeciwnym razie błędne liczby trafią tam, wyglądając na poprawne.
- Zbudżetuj projekt wokół najmniej efektownych części: listy pól, mapowania lokalizacji i kont, reguł walidacji oraz określenia osoby odpowiedzialnej za kolejkę wyjątków. Uruchomienie samej ekstrakcji to praca na jedno popołudnie.
Dlaczego przetwarzanie rachunków za media psuje się miesiąc po pilotażu
Przetwarzanie rachunków za media przy odpowiedniej skali psuje się, ponieważ przestaje być problemem z dokumentami, a staje się problemem operacyjnym. Ekstrakcja to najłatwiejsza ćwiartka tego zadania. Pozostałe trzy czwarte to wiedza o tym, do jakiej lokalizacji należy dany rachunek, czy został już zapłacony, czy wartość zużycia jest wiarygodna, i kto ma na to spojrzeć, gdy tak nie jest.
To ta część historii dotyczącej automatyzacji rachunków za media, której prawie nikt nie opisuje. Strony dostawców dokumentują pomyślny, idealny scenariusz (happy path) i na tym poprzestają. McKinsey odkrył, że 57% organizacji testuje automatyzację pilotażowo, podczas gdy wiele z nich ma trudności z przejściem od pilotażu do pełnego wdrożenia. To dokładnie ta sama luka, tylko liczona w skali całej gospodarki, a nie jednego biura.
Nadal zastanawiasz się, jakie pola w ogóle pobierać z rachunku? Zacznij od OCR rachunków za media i wróć tutaj. Ta strona dotyczy trzeciego miesiąca wdrożenia.

Twój pilotaż na 50 rachunkach był tylko zbiorem najlepszych momentów
Zestaw pilotażowy był czystszy niż zwykła poczta, i był taki celowo. Ktoś ręcznie wybrał te rachunki, a ludzie zazwyczaj wybierają nowsze pliki PDF od dostawców, których znają.
Oto, co zamiast tego pojawia się co miesiąc, już na zawsze:
- Szacowane odczyty, poprawione rachunki i pary "anulowanie-ponowne wystawienie", które odnoszą się do okresu, który już przetworzyłeś.
- Kilka liczników na jednej fakturze lub jeden licznik rozbity na strony.
- Strona podsumowania, a po niej sześć stron szczegółów, gdzie najciekawsze liczby znajdują się na stronie czwartej.
- Rachunki końcowe, rozliczenia ryczałtowe (budżetowe), kaucje i harmonogramy wpłat, które wyglądają jak faktury, a nimi nie są.
- Zdjęcia papierowych dokumentów zrobione telefonem, pod kątem, gdzieś na korytarzu.
- Pliki PDF z wbudowaną, błędną warstwą tekstową, co jest gorsze niż brak warstwy tekstowej w ogóle.
- Dostawca, który w marcu zmienił wygląd rachunku i nikomu o tym nie powiedział.
Żadna z tych rzeczy nie jest niczym egzotycznym. To po prostu zwykła codzienność rzeczywistego miesiąca, a 50 dokumentów to stanowczo zbyt mała próba, by to wszystko wychwycić. Silnik nie stał się gorszy między pilotażem a trzecim miesiącem. Po prostu zacząłeś pokazywać mu prawdziwą pocztę.
Rozwiązanie tego problemu ma charakter proceduralny, a nie techniczny. Wyciągnij losowo kilkaset dokumentów z prawdziwego miesiąca, włączając w to dostawców, których nikt nie lubi, i policz, co się psuje. Dostawcy pewnemu swojego silnika nie będzie to przeszkadzać.
Dokładność OCR to niewłaściwy wskaźnik do wpisania w zapytaniu ofertowym (RFP)
Wymagaj dokładności na poziomie pola w przypadku pól, które niosą za sobą konsekwencje. Dostawca podający "98% dokładności OCR" mówi Ci o znakach, a to nie znaki są przechowywane w Twojej księdze głównej.
Rachunek może zostać odczytany bezbłędnie i nadal być niepoprawny. Spójrz na to, w którym miejscu faktycznie wylądowała wartość:
- Kwota należna po terminie zamiast bieżących opłat.
- Poprzednie saldo siedzące w polu przeznaczonym na nowe opłaty.
- Sumaryczne zużycie kWh, gdy to zużycie dla poszczególnych liczników było najważniejsze.
- Adres do przelewu, który nie jest adresem świadczenia usług.
- Szacowany odczyt zarejestrowany jako rzeczywiste zużycie.
Każda z tych sytuacji to poprawnie odczytany znak i jednocześnie błędny wpis. Mechanizm pokazujący, dlaczego AI OCR zawodzi na dokumentach wyglądających na proste, podąża za tym samym schematem.
Cele, które warto wpisać do specyfikacji wymagań (na poziomie pola, a nie dokumentu):
| Pole | Docelowa dokładność | Dlaczego to pole |
|---|---|---|
| Numer konta | 99%+ | Złe konto, zła lokalizacja, błędny wpis w księdze |
| Suma na fakturze | 99%+ | Powoduje zapłatę złej kwoty |
| Mapowanie lokalizacji lub MPK | 99%+ | Po cichu uszkadza każdy raport kosztowy |
| Daty okresu rozliczeniowego | 98 do 99% | Tworzy zduplikowane lub brakujące okresy |
| Numer licznika | 97 do 99% | Łamie ciągłość danych o zużyciu dla danego licznika |
| Ilość i jednostka zużycia | 97 do 99% | Zasila alokację kosztów i raportowanie ESG |
| Opłaty za poszczególne pozycje | Niższa jest w porządku | Przydatne, rzadko kluczowe, ale system musi być uczciwy |
Są to wymagania, z których należy rozliczać dostawcę, a nie wyniki gwarantowane przez dowolne narzędzie. Z punktu widzenia realiów, Gartner podaje od 90 do 99% dokładności ekstrakcji przy parsowaniu dokumentów, w zależności od ich jakości i obecności walidacji przeprowadzanej przez człowieka.
Zapytaj również o wskaźniki pewności (confidence scores) na poziomie pól. Pewność na poziomie całego dokumentu mówi weryfikatorowi tylko tyle, że "coś" na stronie jest niepewne, co jest równie przydatne jak czujnik dymu, który nie wskazuje, w którym pokoju się pali.
Każdy dostawca drukuje inny rachunek, a potem zmienia układ
Zmienność układu to problem, którego wszyscy się spodziewają, a mimo to go nie doceniają. Każdy dostawca projektuje swój własny rachunek. Następnie ten sam dostawca drukuje inne układy dla klientów indywidualnych i biznesowych, dla prądu i gazu, dla rozliczeń zbiorczych i szczegółowych, dla deregulowanych dostaw energii oraz opłat dystrybucyjnych, dla rozliczeń zryczałtowanych i faktur końcowych. Jeśli do tej samej skrzynki dodasz faktury telekomunikacyjne, różnorodność rośnie jeszcze bardziej, ponieważ faktura od operatora to inna bajka pełniąca tę samą funkcję.
A potem te układy się zmieniają. Zmiany stawek, powiadomienia regulacyjne, nowe dopłaty i okresowe redesigny przesuwają poszczególne pola. Żadna firma użyteczności publicznej w historii nie ostrzegła zespołu księgowego klienta (Accounts Payable) z wyprzedzeniem.
Forbes klasyfikuje 80 do 90% danych biznesowych jako nieustrukturyzowane, a rachunki za media to tego doskonały przykład: te same informacje ułożone inaczej przez każdego, kto je drukuje.
Dlatego kluczowym wymaganiem jest silnik, który czyta dokumenty, a nie szuka sztywnych współrzędnych. Jeśli dostawca pracuje na szablonach, uzyskaj przed podpisaniem umowy odpowiedzi operacyjne na piśmie. Kto buduje szablon i kto go utrzymuje. W jaki sposób wykrywany jest zepsuty układ i jak szybko jest naprawiany. Czy ta praca mieści się w stałej opłacie. Czy poprawki wprowadzane przez osobę weryfikującą zasilają model zwrotny (feedback loop). Dostawca, którego odpowiedź brzmi: „Prześlij nam układ rachunku, a my go skonfigurujemy”, właśnie opisał Twoje najbliższe trzy lata.
Słabe skany to nie przypadki brzegowe, to codzienna poczta
Dokumenty napływają z biur podawczych, portali dostawców, od kierowników placówek, z dysków współdzielonych i z przekazywanych łańcuszków e-maili. Znaczna część z nich to zdjęcia, a nie skany. Niska rozdzielczość, przekrzywienie strony, ślady po zagięciach, cienie zszywek, obcięte marginesy, pismo odręczne na brzegach, strony w złej kolejności oraz okazjonalne załączniki okazujące się paragonami z parkingu.
Tradycyjny OCR wykazuje tu specyficzną kruchość. Gdy tekst jest niejasny, program nie zatrzymuje się – zgaduje. Z cyfry 8 robi się 0, numer konta dzieli się na fragmenty, a oba te błędne wyniki są eksportowane bez żadnego sygnału, że coś poszło nie tak. WifiTalents donosi, że 25 do 30% procesów biznesowych cierpi z powodu słabej jakości danych, a ciche "zgadywanie" przez system jest jednym z tego powodów. To dokładnie ten sam argument, który artykuł jakość na wejściu, precyzja na wyjściu wysuwa w kontekście potoków danych w dokumentach.
Przetwarzanie wstępne to podstawa: prostowanie i korekta obrotu, podział na strony i łączenie wielostronicowych dokumentów, wykrywanie duplikatów stron oraz walidacja wbudowanej w PDF warstwy tekstowej. Pytanie, które dzieli dostawców na lepszych i gorszych, pojawia się po tym wszystkim. Co system robi z dokumentem, którego autentycznie nie potrafi przeczytać? Jedyną akceptowalną odpowiedzią jest to, że się do tego przyznaje i kieruje go do ręcznej weryfikacji. Cichy, wyglądający na prawdopodobny, zgadnięty wynik eksportu jest gorszy niż odrzucenie dokumentu, ponieważ odrzucony dokument zostanie przez kogoś obsłużony.
Najtrudniejszą częścią jest walidacja, a nikt nie pokazuje jej na demo
Ekstrakcja dostarcza wartości. Walidacja mówi Ci, czy masz im wierzyć. Bez warstwy reguł między jednym a drugim, system ERP otrzymuje błędne liczby, które wyglądają całkowicie rozsądnie, co stanowi najdroższy rodzaj błędu, ponieważ nic na dalszym etapie procesu go nie wychwyci.
Testy, które warto wdrożyć, w podziale na grupy:
| Grupa testów | O co pyta reguła |
|---|---|
| Dokument | Czy to w ogóle jest faktura, czy tylko przypomnienie, wezwanie do odłączenia, czy zwykłe zestawienie? Czy obecne są wszystkie strony? Czy to duplikat? |
| Konto i lokalizacja | Czy numer konta istnieje w danych podstawowych? Czy adres usługi przypisany jest dokładnie do jednej lokalizacji? Czy towar/usługa (np. gaz) dotyczy tego obiektu? |
| Daty | Czy okres rozliczeniowy jest wiarygodny? Czy pokrywa się z poprzednim rachunkiem lub zostawia lukę? Czy data faktury przypada po okresie świadczenia usługi? |
| Zużycie | Czy jednostka jest odpowiednia dla tego nośnika (kWh, termy, m3, galony)? Czy odchylenie w stosunku do zeszłego roku mieści się w normie? Czy odczyt jest szacunkowy? |
| Finanse | Czy pozycje na fakturze sumują się do sumy częściowej? Czy bieżące opłaty plus poprzednie saldo dają kwotę całkowitą? Czy opłaty za zwłokę zostały wydzielone? |
Każda z tych reguł powinna być w pełni konfigurowalna z własnymi zakresami tolerancji i każda powinna mieć możliwość zablokowania eksportu, a nie tylko dodania do niego adnotacji. Reguła, która zapisuje ostrzeżenie w logach, których nikt nie czyta, nie jest żadnym mechanizmem kontrolnym.
O tę część pytają również audytorzy i ma ona krytyczne znaczenie, jeśli dokument kiedykolwiek trafi tam, gdzie nie powinien. Zapis o tym, że dana wartość została wyekstrahowana z konkretnego dokumentu w określonym czasie, sprawdzona przez imiennie wskazaną osobę (jeśli tak było), wyeksportowana jeden raz i otwarta przez te osoby, a żadne inne, sprawia, że przed zautomatyzowanymi danymi można się obronić. Raport IBM Cost of a Data Breach określa średni globalny koszt naruszenia bezpieczeństwa danych na 4,4 miliona dolarów (spadek o 9% rok do roku, napędzany przez szybszą identyfikację i minimalizację szkód). Nie da się jednak szybko zidentyfikować czegoś, czego nigdy się nie logowało (zapisywało).
Nikt nie uwzględnia w budżecie kolejki do weryfikacji
Odsetek rachunków trafiających do rąk ludzkich to liczba decydująca o tym, czy ten projekt zaoszczędził komukolwiek czas. Przy małej skali nikt tego nie zauważa. Przy kilku tysiącach dokumentów miesięcznie matematyka jest bezlitosna:
| Rachunki miesięcznie | Wskaźnik wyjątków | Dokumenty do weryfikacji |
|---|---|---|
| 3000 | 5% | 150 |
| 3000 | 10% | 300 |
| 3000 | 20% | 600 |
| 3000 | 30% | 900 |
Różnica między stawką 5% a 30% to 750 dokumentów miesięcznie, czyli niemal cały etat pracownika (FTE). A w sytuacji gdy oprogramowanie jest słabe, kolejka ta wcale nie rośnie liniowo. Weryfikator, który musi ponownie otworzyć cały rachunek, by poprawić tylko jedno pole, spędza nad nim pięć minut zamiast piętnastu sekund.
Ankieta Parseur z 2025 roku przeprowadzona wraz z QuestionPro wykazała, że pracownicy spędzają już ponad 9 godzin tygodniowo na ręcznym wprowadzaniu danych, z czego 50,4% zgłasza błędy lub opóźnienia będące bezpośrednim tego wynikiem, a 56% zgłasza wypalenie zawodowe wywołane powtarzalną pracą. Źle zbudowana kolejka do obsługi wyjątków wcale nie eliminuje tej pracy. Po prostu zmienia jej nazwę.
Dlatego też ekran do weryfikacji (review screen) to taka sama decyzja zakupowa jak silnik OCR. Poproś o jego pokazanie na realnych wyjątkach, zanim cokolwiek podpiszesz. Zależy Ci na progach pewności (confidence thresholds), które można dostroić dla każdego pola z osobna, ekranie pokazującym tylko wątpliwe pola ze zdjęciem źródłowym tuż obok, poprawkach zasilających system z powrotem zamiast "wyparowywać", oraz na routingu zapewniającym, że właściwa osoba widzi właściwy wyjątek. Utrzymanie człowieka "w pętli" jest przy tym wolumenie słusznym krokiem. Zmuszanie go jednak do czytania każdej strony takim krokiem nie jest, a artykuł human in the loop AI warto przeczytać, by zrozumieć, gdzie leży granica.
System ERP to miejsce, w którym te projekty utykają
Ekstrakcja, która kończy się arkuszem kalkulacyjnym wgrywanym przez kogoś do systemu, to po prostu automatyzacja przepisywania bez dokończenia zadania. Badanie PwC's Digital Trends in Operations Survey wykazało, że 47% liderów z obszaru operacji i łańcucha dostaw wskazuje złożoność integracji jako główny powód niedostarczenia wartości przez inwestycje technologiczne. W przypadku rachunków za media ta złożoność ma konkretną nazwę, a jest nią "mapowanie".
To powiązanie kont i lokalizacji (crosswalk) jest najtrudniejszą częścią — a nie sam transfer danych. Zanim rachunek będzie warty wyeksportowania, musi zostać przypisany do konkretnej lokalizacji, centrum powstawania kosztów (MPK) i kodu KG (Księga Główna), co oznacza, że wyciągnięty z faktury numer konta i adres dostawy muszą pasować do bazy mapowania powiązań, którą ktoś najpierw buduje, a potem aktualizuje, gdy zamykane są stare i otwierane nowe lokalizacje. Faktury wielopozycyjne muszą zachować podział na odpowiednie linie kosztowe. Scenariusz akceptacyjny musi "wiedzieć", które wyjątki blokują proces płatności, a które nie.
Wymagaj eksportu w formatach CSV, JSON, API i za pomocą webhooków, natywnych połączeń z już używaną platformą automatyzacji, mapowania dla poszczególnych pól, które sam możesz kontrolować, oraz mechanizmu, który odmawia eksportu w przypadku niespełnienia reguły walidacji.
Dziesięć pytań, które warto zadać przed podpisaniem umowy
W kolejności tego, co ma znaczenie:
- Jak działa silnik: używa szablonów, uczenia maszynowego, modeli językowych (LLM) czy jest hybrydą?
- Co się dzieje przy układzie rachunku dostawcy, którego nigdy wcześniej nie widziałeś?
- Kto odpowiada za utrzymanie ekstrakcji, gdy dostawca mediów zmienia wygląd rachunku, i jaki jest czas reakcji?
- Czy utrzymanie jest wliczone w abonament, czy jest fakturowane jako zapytanie o zmianę układu?
- Czy system raportuje wskaźnik pewności dla poszczególnych pól, czy dla całego dokumentu?
- Jak odróżniacie opłaty bieżące, kwotę całkowitą i kwotę należną po terminie płatności?
- Co system robi z dokumentem, którego nie jest w stanie przeczytać?
- W jaki sposób wykrywane są duplikaty, skorygowane faktury i te wystawione ponownie?
- Co rejestruje ścieżka audytu (logi operacji) i jak długo to przechowuje?
- Czy mogę przetestować kilkaset swoich własnych rachunków na koncie testowym, wliczając te w bardzo złym stanie?
Pytanie dziesiąte jest zresztą odpowiedzią na pozostałe dziewięć.
Jak Parseur radzi sobie z przetwarzaniem rachunków za media
Parseur to bezszablonowy parser wykorzystujący sztuczną inteligencję do ekstrakcji danych z masowej liczby dokumentów. "Bezszablonowy" (template-free) oznacza tutaj jedną konkretną rzecz: nie ma żadnego układu, który mógłby się zepsuć, gdy dostawca przeprojektuje swój rachunek. Silnik Vision AI odczytuje pliki PDF, skany i zdjęcia. Silnik Text AI obsługuje rachunki wysyłane e-mailem lub czysto tekstowe. Oba modele trafiają do Ciebie jako wstępnie wytrenowane, więc wdrożenie nowego dostawcy mediów nie urasta do rangi wielkiego projektu, a zmiana układu rachunku w połowie roku nie wymaga ponownego uczenia systemu.
Rachunki docierają do niego przez dedykowaną skrzynkę odbiorczą, po połączeniu z API lub ze stale obserwowanego folderu, i każdy z nich jest analizowany (parsowany) w momencie nadejścia, a nie w nocnych partiach. Listę niezbędnych pól definiujesz tylko raz. Pozycje kosztowe (line items) w fakturach telekomunikacyjnych eksportowane są w formie ustrukturyzowanych wierszy, dzięki czemu zespół ds. alokacji kosztów nadal ma na czym pracować. Dane wychodzą z systemu w postaci plików CSV, JSON, webhooka lub przez wywołanie API do Excela, Google Sheets, systemów księgowych i ERP oraz z pomocą integracji Zapier, Make, Power Automate i n8n.
To, co faktycznie pochłonie czas Twojemu zespołowi wdrożeniowemu, to dokładnie ta sama lista działań, co przy każdym innym dostawcy: uzgodnienie pól niezbędnych dla systemu ERP, budowa tabel powiązań między lokalizacjami a kontami (crosswalk), zapisanie reguł walidacji oraz przypisanie konkretnej osoby zarządzającej weryfikacją (kolejką wyjątków). Zaplanuj projekt oparty o te cztery czynniki, a wdrożenie pójdzie gładko. Jeśli jednak potraktujesz je po macoszemu, będzie ciężko. Koszty Parseura oparte są o wolumen przetwarzanych dokumentów, a nie liczbę osób na "stanowiskach", dlatego sprawdź swoją miesięczną ilość rachunków w symulatorze cen przed skontaktowaniem się z jakimkolwiek dostawcą — również z nami.
Każdy dokument w kolejce posiada nazwę i nazwisko klienta, adres instalacji oraz numer konta, więc zabezpieczenie danych zasługuje na co najmniej tak samo dużą uwagę jak ich poprawność przy ekstrakcji. Parseur jest rozwiązaniem zgodnym z RODO. Zapytaj nas i zapytaj wszystkich innych z tzw. krótkiej listy, gdzie przechowywane są dane z dokumentów, jak długo są przetrzymywane, kto u dostawcy posiada do nich dostęp i czy ten dostęp rejestruje się automatycznie w tzw. ścieżce audytu (audit trail).
Weryfikacja danych i zarządzanie wyjątkami to obszar, z którego powinieneś wycisnąć jak najwięcej – u nas i u reszty rynkowych graczy. Najlepiej, abyś przesłał nam na piśmie owe dziesięć powyższych pytań i otrzymał gwarancje, niż uwierzył na słowo samej tej stronie.
Aby zapoznać się z pełnym przepływem pracy, przejdź do działu ekstrakcja danych z rachunków za media lub odwiedź stronę rozwiązania do ekstrakcji rachunków za media, aby zobaczyć, jak wygląda praca z całym portfelem dokumentów.
Nic z tego nie jest powodem, by nadal wpisywać dane ręcznie
Żaden argument na tej stronie nie podważa zasadności automatyzacji przy przetwarzaniu rachunków za media. Ręczne wprowadzanie danych obarczone jest każdą pojedynczą porażką opisaną w tym artykule (i wieloma kolejnymi, które ujawniają się o szesnastej popołudniu w ostatni dzień miesiąca), a do tego nie pozostawia jakiegokolwiek wiarygodnego śladu w audytach. Różnica polega po prostu na tym, że automatyczny przepływ danych psuje się na Twoich oczach, kiedy celowo to wymusisz poprawną konfiguracją, bądź psuje się kompletnie niewidzialnie, kiedy tego nie zrobisz.
Jeśli projekt automatyzacji działa już u Ciebie w firmie i wszystko idzie jak po grudzie, nie wyrywaj go z korzeniami od razu w tym kwartale. Pobierz wyjątki dokumentowe wygenerowane z zeszłego miesiąca, podziel na grupy ze względu na powód odrzucenia i przelicz rzetelnie: ile błędów zrzucisz na konto nieporadnej ekstrakcji OCR, a ile było winą braku reguły na poziomie walidacji lub samej luki w module lokalizacyjnym (crosswalk). Z reguły powody błędu pochodzące z drugiej grupy stanowią tu większy stos na przysłowiowym biurku, i wszystkie dają się wyeliminować bez potrzeby wymiany samego oprogramowania od dostawcy.
Tak czy inaczej, podejmuj decyzje, przyglądając się temu, co system robi z uszkodzonymi i niejednoznacznymi dokumentami.
Zrób test na najbrzydszym i najgorszym miesiącu rozliczeniowym. Idealne pliki PDF zawsze wyglądają dobrze, niezależnie od tego, u kogo kupujesz technologię.
Ostatnia aktualizacja




