AI za računovodstvo: problem ni OCR, problem je slovenski kontekst

Vsako AI orodje za računovodstvo bo na predstavitvi pokazalo, kako prebere PDF račun in izvleče znesek. To je impresivno, a tudi rešen problem. Branje teksta z dokumenta je danes splošno dostopno. Razlika med uporabnim in neuporabnim AI orodjem se pokaže šele, ko je treba te zneske tudi pravilno poknjižiti, povezati z ERP-jem in obvladati izjeme.

Pri tem se večina tujih AI rešitev znajde v težavah. Ne zato, ker je njihov OCR slab, ampak zato, ker je slovenski računovodski kontekst pravzaprav zapleten. Spodaj je pregled tipičnih točk, kjer se veliki projekti lomijo. Vsako od teh smo videli pri dejanskih uvedbah Kontiqo.

1. Slovenski DDV ni »še ena stopnja«

Splošen AI sistem zna prepoznati številko, ki ji sledi znak za odstotek. To pa ni isto, kot razumeti slovenski DDV. Konkretni primeri, ki v praksi povzročajo težave:

• Dobavitelj A izpiše račun v obliki »MATERIAL + DDV« v eni postavki. Sistem mora razdeliti na osnovo in davek.
• Dobavitelj B uporablja ločene postavke neto / carina / DDV, kar zahteva drugačno logiko zajema.
• Dobavitelj C izvaja storitev z obrnjeno davčno obveznostjo, a na računu nima eksplicitne oznake. Razpoznava temelji na vrsti storitve, državi dobave in davčni obravnavi.

Splošen sistem na vsakem od teh primerov najprej napačno predlaga knjižbo. Po nekaj iteracijah se nauči, ampak za vsakega dobavitelja posebej. Slovensko grajen sistem ima vzorce vgrajene od začetka. To je razlika med tem, ali računovodja popravi 5 % vnosov ali 25 %.

2. Kontni plan in vzorci dobaviteljev

Račun, prebran kot »1.234,56 € od dobavitelja Kovinarstvo Novak«, ne pomeni nič, dokler ga ne knjižite na pravi konto. Pri eni firmi gre Kovinarstvo Novak na konto materialnih stroškov, pri drugi na konto storitev, pri tretji se razdeli po projektih.

Splošen model tega ne ve. Ve le, da je prepoznal dobavitelja in znesek. Pravo avtomatizacijo dobite šele, ko se sistem nauči vzorcev specifično za vaše podjetje: kateri dobavitelj običajno gre kam, kdaj se vzorec spremeni, kdaj zahtevati ročno potrditev. Tuji sistemi to zmorejo, a šele po tednih učenja in s tesnim sodelovanjem njihove uvajalne ekipe, kar za slovensko stranko pogosto ni prioritetno.

3. Integracija z ERP je delovni proces, ne le API

Integracija z ERP ni en vmesnik. Je sinhroniziran tok statusov, šifrantov, izjem in sprememb skozi čas.

»Imamo API« je premajhna obljuba. Realna integracija z Vascom, Pantheonom ali SAOP iCenter zahteva več kot en vmesnik. Konkretne stvari, ki morajo delovati:

• Pravilen prenos statusa knjižbe: osnutek, čaka na potrditev, potrjeno, knjiženo. Vsako stanje ima v ERP-ju svojo logiko.
• Dvosmerna sinhronizacija šifrantov: ko v Vascu dodate novega dobavitelja, mora to AI sistem zaznati. Obratno tudi.
• Spreminjanje preteklih knjižb: kaj se zgodi, če se račun po mesecu zaključi z dobropisom?
• Avtomatsko polnjenje stroškovnih mest in nosilcev glede na vzorce, ki jih ERP že pozna.

Splošna AI orodja tipično rešijo prvi del (zapis knjižbe), preostale točke pa so prilagoditve. To pomeni dodaten IT projekt, ki ni vključen v začetno ceno.

4. Izjeme: dobropisi, EU pridobitve, neobičajne dobavnice

Standardni dobaviteljski računi so tipično 80 do 90 % volumna. Preostalih 10 do 20 % so izjeme, in te izjeme so tiste, ki povzročijo največ ročnega dela:

• Dobropisi za reklamacije, ki so povezani s točno določenim preteklim računom.
• EU pridobitve z drugačno DDV obravnavo in obveznostjo poročanja v rekapitulacijskem poročilu.
• Trojni posli, kjer slovensko podjetje deluje kot vmesni člen.
• Uvoz iz tretjih držav s carinsko deklaracijo kot ločenim dokumentom, ki ga je treba povezati z računom.
• Predračuni, ki postanejo končni računi, in njihova povezava v sistemu.

Splošen AI sistem te primere obravnava enako kot navadne prejete račune, kar pomeni napačne knjižbe. Specifična logika za vsako vrsto dokumenta mora biti vgrajena, ne nadgrajena.

5. Potek odobritev in revizijska sled

V večjih podjetjih en zaposleni ne potrdi vseh knjižb. Račun do 1.000 € lahko potrdi referent, do 10.000 € vodja oddelka, večji zneski gredo na finančnega direktorja. Računi za marketing imajo drugačno verigo kot računi za proizvodnjo.

AI orodje, ki se obravnava le kot »OCR z integracijo«, te plasti nima. Potreben je dodaten sistem za odobritve, ki se ne ujema dobro z avtomatičnim tokom. Sistem, ki je grajen za računovodstvo večjih podjetij, ima logiko odobritev kot del produkta, ne kot zunanjo komponento.

6. Tihe napake

Največji problem računovodske avtomatizacije niso očitne napake. Tiste se hitro opazijo. Problem so tihe napake.

Napačna DDV stopnja pri enem računu mesečno lahko ostane neopažena več kvartalov. Napačen konto pri enem dobavitelju izkrivi stroškovna poročila za celoten oddelek. Napake se naberejo, dokler jih ne odkrije inšpekcija ali letna revizija.

Zato je pri računovodskem AI pomembnejša zanesljivost kot natančnost na demo podatkih. Dober sistem prepozna primere, kjer ni prepričan, in zahteva ročno potrditev. Slab sistem na vsak primer odgovori s samozavestjo, tudi ko je v zmoti. Razlika ni vidna na predstavitvi, je pa vidna v davčnem obračunu šest mesecev kasneje.

Pravna in skladnostna plat

GDPR in ZVOP-2 zahtevata jasen odgovor na vprašanje, kje so podatki shranjeni in kdo do njih dostopa. Tuji ponudniki s sedežem v ZDA pogosto uporabljajo storitve, ki spadajo pod CLOUD Act, kar pri pravnem oddelku zahteva dodatno presojo. To ni nujno izločitveni dejavnik, pomeni pa daljši cikel ocenjevanja in pogosto dodatna pogodbena zavarovanja.

Lokalni ponudnik s shrambo v EU in pogodbo o obdelavi osebnih podatkov v slovenščini poenostavi pravno presojo. Za podjetja s strogimi zahtevami glede skladnosti je to praktična razlika v hitrosti uvedbe.

Realna natančnost na slovenskih dokumentih

Ne pišemo o napovedih, pišemo o izmerjenem. Na internih testih Kontiqo na slovenskih prejetih računih (mešanica strukturiranih e-računov, PDF priponk in skenov) dosega:

• Več kot 98 % natančnost pri zajemu osnovnih podatkov (dobavitelj, znesek, DDV, datum).
• 95 do 97 % natančnost pri predlogu konta po prvem mesecu učenja na strankinih podatkih.
• Stabilnost na šumnikih, vejicah kot decimalnem ločilu in slovenskih datumskih formatih.

Za splošne tuje sisteme nimamo neodvisnih primerjalnih meritev. V praksi pri strankah, ki so prej testirale tuje rešitve, vidimo, da je delež ročnih popravkov višji, predvsem na izjemnih primerih in pri dobaviteljih z manj standardnimi računi.

Kdaj je tuji ponudnik kljub temu pravi izbira

Niso vsi tuji ponudniki neprimerni za slovensko podjetje. Smiselna izbira je v treh primerih:

• Multinacionalka s konsolidacijo: centralna IT zahteva enotno orodje za vse države. Slovenska enota uporablja, kar uporabljajo drugi.
• Specifična niša z zelo zrelo rešitvijo: npr. specializirano orodje za farmacijo ali javno upravo, ki ga slovenski trg sam ne bi razvil.
• Strateška povezava z globalnim partnerjem, kjer je orodje pogoj sodelovanja.

V vseh ostalih primerih je lokalna rešitev praktično ugodnejša, ker zmanjša obseg prilagoditev, skrajša čas uvedbe in zniža tveganje, da se po šestih mesecih izkaže, da določen robni primer ni pokrit.

Bistvo

Branje računa je rešen problem. Vsa AI orodja zmorejo prebrati znesek, datum in dobavitelja. Razlika nastane v naslednjih korakih: razumevanje slovenskega DDV, učenje vzorcev kontiranja, polna integracija z ERP-jem, ravnanje z izjemami in procesom odobritev. Tam se pokaže razlika med generičnim OCR sistemom in rešitvijo, grajeno za slovensko računovodsko okolje.

Pri izboru AI orodja ne vprašajte, kaj zna prebrati. Vprašajte, kaj zna narediti potem.