OCR in AI knjiženje računov: kje je dejanska razlika

OCR za prejete račune je danes v veliki meri rešen problem. Sodobni modeli z razumno natančnostjo izluščijo dobavitelja, znesek, DDV stopnje in postavke. To ni več tehnični izziv in ni več konkurenčna prednost. Težave se začnejo za njim.

Tisto, kar dela razliko med igračo in sistemom, ki ga računovodski oddelek dejansko uporablja vsak dan, ni branje. Je odločanje. Konto stroška, DDV stopnja, obrnjena davčna obveznost, stroškovno mesto, kontrola duplikatov, učenje iz zgodovine dobavitelja, obravnava izjem, ki jih AI ne zna rešiti sam. Vse to je težko, kontekstualno, lokalno specifično delo. Tu se začne pravi izziv.

OCR pove, kaj piše. AI knjiženje pove, kaj s tem narediti.

Ko računovodja prejme račun, ga ne le vnese. Sprejme vrsto odločitev, ki morajo biti vse pravilne, da se račun pravilno knjiži in pravilno odbije DDV.

• Na kateri konto stroška spada (telekom, gorivo, najem, pisarniški material, storitve, blago)
• Katera DDV stopnja velja (22 %, 9,5 %, 5 %, 0 %), ali gre za neobdavčeno transakcijo
• Ali velja obrnjena davčna obveznost (reverse charge), tipično pri tuji storitvi ali gradbeništvu
• Na katero stroškovno mesto se račun pripiše, če podjetje vodi po enotah ali projektih
• Ali je račun morda že prišel (duplikat preko različnih kanalov)
• Ali se znesek ujema z naročilnico ali pogodbo, če taka obstaja

Klasični OCR ne reši nobene od teh odločitev. Vse ostane računovodji, kar pomeni, da OCR sam po sebi prihrani le del časa, povezan z vnosom številk.

AI knjiženje doda predlog knjižbe na podlagi zgodovine. Sistem si zapomni, kako je računovodja knjižil prejšnji račun istega dobavitelja, in pri naslednjem takoj predlaga isti konto, isto DDV stopnjo, isto stroškovno mesto. Ko račun od telekoma prispe drugič, sistem ve. Računovodja predlog preveri in potrdi, ne sestavlja od ničle. Pri stalnih dobaviteljih je to obravnava v sekundah, ne minutah.

Kje se začne težki del: obravnava izjem

Avtomatsko knjiženje v testnem okolju vedno deluje. V realnem podjetju se zlomi pri robovih. Tam, kjer sistem ne sme samozavestno reči "knjižim", ker bi naredil drago napako.

• Nov dobavitelj, ki ga sistem še ne pozna in nima zgodovine
• Nestandardni format računa, ki odstopa od običajnega vzorca dobavitelja
• Dobropis ali popravek, ki spremeni že knjižen račun
• Račun v tuji valuti z menjalnim tečajem
• Mešani DDV (več stopenj na istem računu)
• Dvoumnost: račun bi lahko šel na dva različna konta, oba sta legitimna

Sistem, ki to obravnava resno, mora znati eno ključno stvar: reči "tu nisem prepričan, naj odloči računovodja". Brez tega AI knjiženje izgubi zaupanje v prvih dveh tednih, ker en sam napačno samozavesten predlog v zaključku meseca pomeni večerno iskanje napake. Eskalacija človeku ni dodatek, je osnovna funkcija.

Zakaj generični tuji OCR pade v slovenskem računovodstvu

Slovenski računovodski kontekst je ozek trg z lastnimi pravili, formati in programi. Splošna AI rešitev iz tujine zna prepoznati račun, ampak ne zna nobene od stvari, ki dejansko šteje za slovenskega računovodjo.

• Slovenski kontni plan. SRS in praksa določata strukturo kontov, ki se ne ujema z mednarodnimi standardi. AI sistem brez slovenskih knjižb v učnih podatkih predlaga nekaj, kar zveni razumno, a ni pravilno.
• DDV pravila in reverse charge. Obrnjena davčna obveznost ima v Sloveniji svoje specifike (gradbeništvo, tuji ponudniki, EU posli). Generični model tega ne prepozna iz teksta računa, ker zahteva poznavanje konteksta dobavitelja.
• e-Slog format. Format e-Računa po standardu eSlog 2.0 je slovenski. Tuji sistem ga ne prebere, dokler ga nekdo ne nauči.
• Integracija v Vasco, SAOP iCenter, Minimax. Slovenske računovodske programe pozna kdor jih dela. Tuj ponudnik pošlje API specifikacijo in pričakuje, da bo nekdo drug zgradil most. V praksi most ni nikoli postavljen.
• Spomin na slovenske dobavitelje. Telekom Slovenije, Petrol, Pošta Slovenije, A1, ELES. Sistem, ki je videl tisoče knjižb teh dobaviteljev, predlaga drugače kot sistem, ki teh imen ne pozna.

Vsaka od teh točk se da rešiti. Vse skupaj je pa toliko dela, da generični tuji ponudnik tega ne naredi za slovenski trg, ker ni dovolj velik. To ni tehnična ovira, je ekonomska.

Kdo to gradi v Sloveniji

Doma se s to problematiko ukvarja Kontiqo, ki gradi platformo za avtomatsko obdelavo prejetih računov v slovenskem kontekstu. Sem soustanovitelj in pri tehnični strani projekta sodelujem od začetka. Ker se s strankami pogovarjam predvsem o B2B trgovinah in ERP integracijah, mi vprašanje o avtomatskem knjiženju prihaja redno z druge strani podjetja: računovodstvo s 300 do 2000 računov mesečno. Vsi sprašujejo isto. Ali se da to avtomatizirati.

Da. S sistemom, ki pozna slovenski kontni plan, slovenske DDV specifike, eSlog format, slovenske računovodske programe in slovenske dobavitelje. Razlika med splošno OCR storitvijo in prepoznavo računov za slovensko računovodstvo je v vseh teh detajlih, ki jih je videti šele po prvem mesecu uvajanja.

Na strani Kontiqo deluje preizkusno orodje, kjer naložite svoj račun in v živo vidite rezultat prepoznave in predloga knjižbe.