OCR koji odbija da nagađa

Skener izbaci PDF, model vrati JSON, izveštaj kaže 99,1% tačnosti. Broj deluje kao kraj razgovora, a početak je: ne kaže koja su polja tačna, ne kaže šta se desilo sa preostalih 0,9%, i — najvažnije — ne kaže da li je sistem, kad nije znao, ostavio polje prazno ili upisao najverovatniju vrednost i krenuo dalje. Ta razlika odlučuje da li je automatska obrada ulazne fakture ušteda ili tiha proizvodnja grešaka koje se otkriju tek na kontroli.

Prosek krije tačno ono što košta

Ulazna faktura nije jedan podatak. To je zaglavlje sa desetak polja različite težine — PIB dobavljača, broj fakture, datum prometa, datum dospeća, poziv na broj po modelu 97, osnovica po stopi, iznos PDV-a, ukupan iznos — i telo sa stavkama, gde svaka nosi šifru, količinu, jedinicu mere, cenu i rabat.

Kad se sve to svede na jedan procenat, imenilac preuzimaju stavke: faktura sa deset stavki ima oko pedeset ćelija u telu i desetak polja u zaglavlju. Model koji savršeno pročita svih pedeset ćelija, a promaši PIB i iznos PDV-a, izlazi sa oko 97% — a ta faktura je neupotrebljiva, jer se knjiži na pogrešnog partnera i ulazi u pogrešno polje POPDV-a. Prosek nagrađuje lako: nazivi i jedinice mere brojni su i jeftini kad se pogreše, a rukom dopisan poziv na broj i osnovica na fakturi sa dve stope retki su i skupi. Jedan broj ih izjednačava.

Kako izgleda izveštaj koji ima smisla

Umesto jedne brojke, po svakom tipu polja mere se tri ishoda: tačno, odbijeno (sistem je svesno rekao „nisam siguran“) i tiho pogrešno. Samo je treći stubac bug. Prvi je posao koji je obavljen, drugi je posao koji je uredno prosleđen čoveku — radni red, a ne neuspeh.

Refuses-to-guess: metrika koja meri poštenje

Procenat polja koja sistem odbija da nagađa je udeo polja koja svesno ostavlja prazna i prosleđuje čoveku umesto da upiše najverovatniji kandidat. Zvuči kao priznanje slabosti; jeste, i to je cela poenta. Modeli to ne rade sami od sebe — izlaz uvek ima najbolji kandidat, a „ne znam“ ne postoji dok se ne napravi. Napraviti ga znači postaviti prag po polju, kalibrisati ga na golden setu dokumenata i prihvatiti da se deo posla vraća čoveku. Prag koji je dobar za naziv dobavljača katastrofalan je za osnovicu.

• Prag se postavlja po polju: jedan prag za ceo dokument znači da najskuplje polje deli sudbinu najjeftinijeg.
• Kalibracija ide na golden setu stvarnih dokumenata — loši skenovi, faksimili, fakture sa dve stope — ne na intuiciji.
• Odbijanje mora da bude jeftino za korisnika: fokus odmah na sporno polje, isečak originala pored njega, potvrda jednim potezom.
• Odbijanje se prati kroz vreme. Ako procenat odbijenih pada a tiho pogrešnih raste, prag je popustio — to je regresija, ne napredak.
• Odbijeno polje blokira automatsko knjiženje tog dokumenta; upozorenje pored aktivnog dugmeta „Proknjiži“ nije kontrola.

Cena samouverene greške

Asimetrija je merljiva. Prazno polje košta pažnju knjigovođe na trideset sekundi. Pogrešno popunjeno polje košta lanac koji ide dalje — jer ništa u njemu ne puca.

1. 1

   Faktura ulazi

   Model pročita osnovicu po opštoj stopi kao 1.180.000 umesto 1.080.000 — jedna cifra, čist sken, visoka pouzdanost. Ukupan iznos i PDV pročitani su tačno.

2. 2

   Knjiženje prolazi

   Ako se PDV knjiži kao pročitan iznos, a ne kao izračunat iz osnovice, nalog balansira. Kontrola koja proverava samo dugovna = potražna ne javlja ništa.

3. 3

   PDV evidencija preuzima grešku

   Osnovica ulazi u pogrešno polje POPDV-a i u EEO/EPP strukturu. Odnos osnovice i PDV-a više nije 20%, ali to se ne proverava po dokumentu — proverava se po zbiru, gde se greška utopi.

4. 4

   Prijava se podnosi

   PP PDV izlazi iz evidencije koja nosi grešku. Rok je prošao, prijava je predata, period se zatvara.

5. 5

   Otkriće stiže spolja

   Dobavljač šalje IOS koji se ne slaže, ili kontrola traži POPDV po dokumentima. Između čitanja i otkrića prošlo je četrdeset dana.

6. 6

   Sanacija košta više od svega uštećenog

   Izmenjena prijava, storno i ponovno knjiženje u zatvorenom periodu po pravilima koja su tada važila, usaglašavanje sa dobavljačem — i, najskuplje, gubitak poverenja u sve ostale fakture koje je isti model pročitao tog meseca. Tim počne ručno da proverava sve, i automatizacija je izgubila svrhu iako je i dalje uključena.

Duplikat je poseban problem, ne sporedan

Ista faktura u praksi stiže dva i tri puta: kao PDF u mejlu, pa kroz SEF, pa kao sken uz papirnu dokumentaciju iz magacina. Dobavljač pošalje ispravljenu verziju sa istim brojem; komercijalista prosledi mejl koji je knjigovodstvo već obradilo. Nijedan od tih puteva ne zna za druga dva, pa detekcija duplikata ne sme da bude jedno poređenje — signali su različite snage i pouzdanosti.

• Trojka (PIB, broj fakture, godina) je tvrd ključ — ali broj fakture je, po tabeli iznad, među poljima sa najviše OCR grešaka. Ključ je jak tačno onoliko koliko je pouzdano polje od kog je napravljen.
• Isti dobavljač, isti iznos, isti datum, drugi broj: mek signal koji obično znači duplikat sa pogrešno pročitanim brojem, a ponekad dve stvarne isporuke istog dana.
• Heš sadržine PDF-a je jak signal za digitalne fakture i bezvredan za skenove — dva skena istog papira nikad nemaju isti heš.
• SEF UUID je najjači signal koji postoji, ali ga nosi samo dokument koji je stigao kroz SEF, ne i njegova PDF kopija iz mejla.
• Storno i knjižno odobrenje liče na duplikat po svakoj meri sličnosti, a nisu. Detekcija koja ih ne razlikuje blokira ispravne dokumente i vrlo brzo se isključi.

Ovde se dve teme spajaju. Ako je broj fakture nagađan, ključ za duplikat je pogrešan, a kontrola tiho prolazi — ne javlja grešku, javlja da je sve u redu. Nagađanje u jednom polju gasi kontrolu u drugom. Zato refuses-to-guess nije kozmetika izveštaja.

Veza na prijemnicu je mesto gde OCR prestaje da bude OCR

OCR koji popuni zaglavlje i stane je robot za kucanje. Vrednost počinje kad pročitani dokument nađe svoje mesto u lancu: porudžbenica → prijemnica → faktura. To je 3-way matching i razlog zbog kog se ulazna faktura uopšte obrađuje automatski.

1. Suzi kandidate: prijemnice istog dobavljača, u razumnom prozoru oko datuma prometa, koje još nisu fakturisane.
2. Ako faktura nosi broj porudžbenice, poravnaj po njoj — najjeftinija i najpouzdanija veza, i razlog zbog kog se taj broj traži od dobavljača.
3. Ako ne nosi, poravnaj po stavkama: šifra iz šifarnika dobavljača, količina posle konverzije jedinice mere, cena iz ugovora ili važećeg cenovnika.
4. Primeni tolerancije koje su ugovorene, ne izmišljene: odstupanje cene, odstupanje količine, dozvoljena razlika zbog zaokruživanja na stavci.
5. Za uvoz razdvoji ono što ulazi u vrednost zalihe od onoga što ne ulazi — troškovi po JCI idu u nabavnu vrednost, a stižu drugom fakturom, često mesec dana kasnije.
6. Predloži vezu sa objašnjenjem — koja prijemnica, po kom kriterijumu, sa kojim odstupanjem — i sačekaj potvrdu čoveka.

Kako NG One radi ovaj deo

NG One obrađuje ulaznu fakturu kao tok sa čovekom u petlji, ne kao autopilot: PDF ili sken → ekstrakcija → prepoznavanje dobavljača → detekcija duplikata → predlog kontiranja → predlog veze sa prijemnicom → jasno označena nesigurna polja → potvrda čoveka. Redosled nije proizvoljan: duplikat se traži pre kontiranja, jer nema smisla predlagati knjiženje dokumenta koji je već proknjižen. Uz tok ide evaluacioni okvir koji je obavezan, a ne poželjan — bez njega je sve gore napisano namera, a ne kontrola.

• Golden set dokumenata i regresioni AI testovi u CI: model ili prompt koji obori tačnost bilo kog polja ne prolazi u granu, isto kao pali unit test.
• Metrike po tipu polja kao prag, uz procenat polja koja sistem odbija da nagađa — mereno po polju, nikad kao jedan zbirni procenat.
• AI audit log sa modelom i verzijom prompta uz svako čitanje: kad se posle šest meseci nađe greška, mora da se zna koji je model šta pročitao i ko je potvrdio.
• Prompt-injection testovi iz priloženih dokumenata — faktura je nepouzdan ulaz, a tekst u njoj sme da bude podatak, nikad instrukcija.
• Testovi tenant izolacije: model koji obrađuje dokument jednog klijenta ne sme da vidi ništa van njegovih dozvola.

Šest pitanja za bilo kog dobavljača

1. Pokažite tačnost po tipu polja, ne prosek — posebno za osnovicu po stopi, broj fakture i poziv na broj.
2. Koliki je procenat polja koja sistem odbija da nagađa i kako se prag podešava po polju?
3. Koliko je tiho pogrešnih na vašem golden setu, i koliko dokumenata taj set ima?
4. Kako se detektuje duplikat kad je broj fakture pogrešno pročitan?
5. Šta sistem radi kad se faktura ne poklopi ni sa jednom prijemnicom — predlaže, blokira, ili knjiži bez veze?
6. Postoji li trag: koji model, koja verzija prompta, koje polje je bilo nesigurno i ko je potvrdio?

Odgovor na prvo pitanje obično stigne kao jedan procenat. Odgovor na drugo najčešće ne stigne — jer metrika ne postoji, a nedostatak metrike znači da sistem nagađa, samo to niko ne meri.