Előbb a csavar, mert ez mindent átrendez
A nemzetközi ismertetők azt mondják, hogy a számlakiolvasás azért éri meg, mert a papírból adatot csinál. Az Európai Unióban ez csak félig igaz — és hogy mennyire, azon múlik, melyik országban vagy, nem azon, melyik szoftvert veszed meg.
Egyetlen kérdés dönt el mindent: az adóhatóság visszaadja-e neked a szállítód adatát, vagy csak a sajátodat. Ahol visszaadja, ott az OCR nagyrészt fölösleges munka a belföldi számlákon. Ahol nem, ott az OCR maga a bemenet, és nincs mivel helyettesíteni. A két helyzet ugyanazon a kontinensen, ugyanabban az évben létezik egymás mellett. Nyisd le, amelyik érint:
Magyarország — a NAV már megkapta a szállítói számlád adatát
A NAV saját tájékoztatója szerint az elektronikus áfarendszer használatának előnyei között szerepel a közvetlen hozzáférés a NAV rendelkezésére álló tranzakcióalapú adatokhoz — online számlaadatok, pénztárgépi nyugták, vámárudokumentumok —, valamint hogy számlabefogadóként mentesülsz az M-lapos adatszolgáltatás alól (áfatörvény, 10. számú melléklet 15. pont).
És ez nemcsak webes felületen érhető el. A gép-gép kapcsolatról szóló NAV-anyag szerint az áfaalanyok saját vállalati rendszerében érhetők el a NAV-nál meglévő tranzakcióalapú adatok. A gépi interfészt ráadásul nemcsak a legnagyobbak használhatják: a NAV szerint azok is, akik egy bevallási időszakban százezernél kevesebb számlával rendelkeznek, ha a könyvelésük eleve digitalizált.
Két további, pénzben és kockázatban mérhető előny ugyaninnen: nem kell önellenőrzési pótlékot fizetni, ha a gép-gép kapcsolaton bevallást teljesítő adózó az önellenőrzést a benyújtástól, legkésőbb az esedékességtől számított tizenöt napon belül nyújtja be; és a megbízható minősítésű adózó gép-gép kapcsolaton benyújtott áfabevallását a NAV tizenöt napig nem ellenőrizheti (bevételeltitkolás és hamis bizonylat esetén nem áll fenn a moratórium).
Két friss dátum is ide tartozik: 2026. augusztus 3-tól a NAV bevezette az új gépi interfész XSD-t, és 2026. szeptember 1-jétől azokról a nyugtákról is adatot kell szolgáltatni, amelyeket nem online vagy e-pénztárgéppel állítottak ki.
Mit jelent ez a gyakorlatban? A belföldi, áfás szállítói számla adata már ott van a NAV-nál, mert a szállítód beküldte. Az OCR értéke itt nem az áfaadat előállítása, hanem három másik dolog: a nem belföldi és nem áfás bizonylatok (külföldi szállító, díjbekérő, nyugta, számlának nem minősülő bizonylat), a tételsor olyan részletességben, amit a te könyvelésed igényel, és a dokumentumnál maradó információ — szerződésszám, projektkód, szállítólevél-hivatkozás.
Érdemes tudni, hogy ebben Magyarország előre szaladt: a többi tagállam most építi ki azt, ami nálunk 2018 óta él.
Spanyolország — az adóhatóság a saját könyvedet adja vissza, a szállítódét nem
Ami él, az a SII. 2017. július 1-je óta az, aki havonta áfabevalló — 6 010 121,04 euró fölötti forgalom, REDEME vagy áfacsoport —, majdnem valós időben küldi a számlanyilvántartásait az adóhatóságnak. Cserébe eltűnik a 347-es és a 390-es nyomtatvány. A legtöbb kkv viszont nincs a SII-ben, és ez dönt el mindent, ami utána jön.
És itt a csavar, mert pont fordítva működik, mint gondolnád. A SII-nek van gép-gép lekérdező szolgáltatása is, nemcsak beküldő — de amit visszaad, az a te saját, már bevallott könyved, egy egyeztetési státusz („nem alkalmazható"-tól „egyeztetett"-ig), és ha van eltérés, a partnered összesített összegei. Amit soha nem ad vissza: a szállítód teljes számláját, a tételsorait, sem olyan számlát, amit te még nem rögzítettél.
Ebből két következmény jön, mindkettő pénzben és kockázatban mérhető: az adóhatósági adat nem helyettesíti a rögzítést — a bejövő számlák könyvét spanyol jogban nem lehet abból felépíteni, amit az adóhatóság tart, legfeljebb auditálni; és az egyeztetés csak akkor működik, ha a szállítód is a SII-ben van — ha nincs, és a legtöbb kkv nincs, a számla státusza „nem alkalmazható", és a hatóság semmit nem mond róla.
Két óra, ami mozgott. A Verifactu (RD 1007/2023) kétszer csúszott: a társaságiadó-alanyoknak 2027. január 1-ig, a többieknek 2027. július 1-ig van idejük — és nem terjed ki arra, aki már a SII-ben van. A Crea y Crece törvény szerinti B2B e-számlának végre van végrehajtási rendelete (RD 238/2026), de a határidő egy miniszteri rendelettel indul, ami máig nem jelent meg.
Mit jelent ez a gyakorlatban? Spanyolországban a számlakiolvasás nem redundáns, hanem maga a bemenet. És három helyen hoz a legtöbbet: a nyugtáknál és egyszerűsített számláknál, amelyek csak akkor levonhatók, ha rajtuk van az adószámod, a címed és külön az áfa összege — azt kiszűrni, ami nem jó, még akkor, amikor teljes számlát lehet kérni, többet ér, mint begépelni; a tételsoroknál, amiket a hatóság sosem ad meg; és a dokumentumnál maradó információnál.
És van egy spanyol elem, ami közvetlenül a számításba tartozik, és a legtöbb szomszédos országban nincs: a hitelesített digitalizálás. Az adóhatóság által jóváhagyott szoftverrel (Orden EHA/962/2007) elhagyhatod a papíralapú eredetiket, és a hatóság naprakészen közzéteszi a jóváhagyott termékek listáját. Ha ma kötelezettségből őrzöl papírdobozokat, az a költség eltűnik — és ez az egyetlen tétel ebben a cikkben, ami tiszta megtakarítás, a pontosságról szóló vita nélkül.
Az irány viszont egyirányú. A digitális kor áfacsomagja — a Tanács (EU) 2025/516 irányelve — szerint a határon átnyúló B2B digitális adatszolgáltatás 2030. július 1-jén indul, a nemzeti rendszerek összehangolása pedig 2035. január 1-ig tart.
Addig két dolgot érdemes fejben tartani bárhol: ezek az interfészek változnak — a sémaverziókat hónapokban mérhető átmenettel cserélik, ezért bármit építesz rájuk, cserélhető sémával építsd —, és a hatály inkább bővül, mint szűkül: ami számlával indult, azt kiterjesztik más bizonylatokra, nyugtákra is, jellemzően néhány hónapos előrejelzéssel. Mielőtt egy évre előre terveznél, nézd meg, mi kerül be a te országodban.
Mit olvas ki pontosan a rendszer
Az Odoo dokumentációja — szokatlan módon — tételesen felsorolja a felismert mezőket:
| Hol | Mezők |
|---|---|
| Fejléc | szállító, számlahivatkozás, számla dátuma, fizetési hivatkozás (csak belga formátumban), fogadó bank, fizetési határidő, pénznem |
| Tételsorok | terméknév vagy megnevezés, mennyiség, egységár, adó, nettó összeg, végösszeg |
Három dolog, ami ebből a listából következik:
Az adószám nincs a listán. A szállító mező szállítóazonosítást jelent, de a dokumentáció nem állítja, hogy adószámot olvasna ki. Magyar szempontból ez lényeges, mert az áfalevonáshoz az adószám kötelező adattartalom — ezt hiányként kell kezelni, nem feltételezni, hogy megvan.
A tételsorokat felismeri — de ez az a rész, ahol a szakirodalom szerint a legtöbb hiba van (lásd lejjebb).
Új szállítónál mindig van kézi lépés. A dokumentáció szerint ha a szállító nincs az adatbázisban, a mező üresen marad.
A gyakorlati beállításokból három számít:
- Beviteli utak: fájl behúzása a naplóra, e-mail-alias, vagy a dokumentumkezelő aliasa. Formátumkorlát: aliason keresztül csak PDF és XML dolgozódik fel, a JPEG csak a dokumentumkezelő aliasán át megy.
- Automatikus könyvelés szállítónként: mindig, soha, vagy — és ez a legjobb beállítás — „kérdezz rá három hibátlan ellenőrzés után". Ez a gyártó saját javaslata, és pontosan egy beépített emberi ellenőrzési kapu.
- „Adónemenként egy sor" beállítás: ha bekapcsolod, a számlán szereplő sorok számától függetlenül adónemenként egy sor jön létre. Ez gyorsít, de elveszíted a tételszintű adatot.
Mennyire pontos? A gyártó nem mondja meg
Végignézve a hivatalos dokumentációt és a szolgáltatáskatalógust: az Odoo sehol nem közöl mért pontosságot, hibaarányt vagy benchmarkot a számlakiolvasásra. Ez önmagában is információ.
Amit a független szakirodalom mond a feladatról:
A feladat kettéválik. A területet meghatározó akadémiai mérce (6 700 annotált valódi üzleti dokumentum, 55 annotációs osztály) külön feladatként kezeli a fejlécmezők kiolvasását és a tételsor-felismerést, amit „rendkívül gyakorlatias információkinyerési feladatként" ír le, ahol a kulcsinformációt egy táblázat elemeihez kell rendelni. A tételsor a nehéz eset.
A legjobb modell sem hibátlan. Egy folyamatosan frissülő dokumentumértési ranglistán — amit fontos kiírni: a lista üzemeltetője saját modellel szerepel rajta, méghozzá az első helyen, tehát ez nem független mérés — a legjobb összesített pontszám 85,9, a huszonhatodik helyezetté 41,9. Kétszeres különbség. A „azAI kiolvassa a számlát" mondat önmagában értelmetlen: a modelltől függ.
És amit ebből nem lehet levezetni: hogy „az Odoo OCR-je X százalékos". A mögötte lévő szolgáltatás klasszikus képfelismerés, nem multimodális nyelvi modell, és nem szerepel ezen a ranglistán. A kettő nem összemérhető.
A számolás — ez a cikk gerince
Nincs forrásolt szám arra, hogy „az AI hány százalékkal gyorsítja a könyvelést". Ami van: egy képlet, amibe a saját számaidat írod.
N = bejövő számlák száma havonta [db]
t_kezi = egy számla kézi rögzítésének ideje [perc]
t_ell = egy kiolvasott számla átnézése [perc]
p = a javításra szoruló számlák aránya [0..1]
t_jav = egy javítás EXTRA ideje [perc]
B = a rögzítést végző óraköltsége [€/óra]
C = a kredit egységára [€/dokumentum]
Megtakarítás számlánként: Δt = t_kezi − (t_ell + p · t_jav)
Havi megtakarított óra: H = N · Δt / 60
Havi nettó megtakarítás: M = H · B − N · C
Az első meglepetés: a kredit ára nem számít
[Saját számítás] Az a minimális időmegtakarítás, ami a kreditet kitermeli: Δt_min = 60 · C / B.
| Óraköltség | 0,15 €/db | 0,12 €/db | 0,10 €/db | 0,05 €/db |
|---|---|---|---|---|
| 10 €/óra | 54 mp | 43 mp | 36 mp | 18 mp |
| 15 €/óra | 36 mp | 29 mp | 24 mp | 12 mp |
| 20 €/óra | 27 mp | 22 mp | 18 mp | 9 mp |
| 30 €/óra | 18 mp | 14 mp | 12 mp | 6 mp |
Ha a kiolvasás egy percnél többet spórol számlánként, a kredit a táblázat minden kombinációjában megtérült. A kérdés tehát nem az ár. A kérdés az, hogy az ellenőrzés gyorsabb-e, mint a rögzítés.
A második meglepetés: meglepően nagy a tűréshatár
[Saját számítás] Legyen a kézi rögzítés három perc egy egyszerű számlánál. Meddig érdemes még kiolvasni? A küszöb: p_max = (t_kezi − t_ell) / t_jav.
| Átnézés | Javítás extra ideje | Max. hibaarány, ameddig megéri |
|---|---|---|
| 1 perc | 2 perc | mindig megéri |
| 1 perc | 4 perc | 50% |
| 1 perc | 8 perc | 25% |
| 1,5 perc | 4 perc | 37,5% |
| 2 perc | 4 perc | 25% |
| 2 perc | 8 perc | 12,5% |
Két tanulság. Egy: még 25–50%-os javítási aránynál is nyerhetsz időt — feltéve, hogy a javítás olcsó, vagyis egy mező átírása. Kettő: a tételsor öli meg a számítást. Ha a hiba a tételsorokban van, és beszerzési rendeléshez kell egyeztetni, a javítás nem 2–4 perc, hanem 8–15 — ott a küszöb 12–25%-ra esik. Ezért kell a fejlécmezőt és a tételsort külön kezelni.
És a végigszámolt példa
[Saját számítás] Feltevések: 200 számla havonta, kézi rögzítés 3 perc, átnézés 1 perc, javítási arány 30%, javítás 4 perc, óraköltség 15 €, kredit 0,12 €.
Δt = 3 − (1 + 0,30 · 4) = 0,8 perc/számla
H = 200 · 0,8 / 60 = 2,67 óra/hó
M = 2,67 · 15 − 200 · 0,12 = 40,00 − 24,00 = 16,00 €/hó
Éves szinten 32 óra és 192 euró. Négy munkanap és egy közepes előfizetés ára. Ez kevés.
Most javítsd meg két számot — legyen a kiolvasás pontosabb (10%) és az ellenőrzés gyakorlottabb (fél perc):
Δt = 3 − (0,5 + 0,1 · 4) = 2,1 perc → H = 7 óra/hó → M = 81 €/hó ≈ 972 €/év
Ötszörös különbség, és csak a pontosság meg az ellenőrzési fegyelem változott. Ez a cikk üzenete: nem az eszköz dönt, hanem az, hogy mennyire kell utánanyúlni.
Az őszinteségi pont: ez a levezetés nem tartalmazza a bevezetés egyszeri költségét — beállítás, szállítótörzs rendbetétele, betanulás —, és azt sem, hogy az első hónapokban a hibaarány magasabb. Egy 200 számla/hó méretű cégnél az alsó forgatókönyv az első évben nem térül meg.
A mérési séma, amit le tudsz futtatni
- Alapvonal, AI nélkül: 20 számla kézi rögzítése, stopperrel. Ez a kézi idő mediánja.
- Kapcsold be a digitalizálást — kérésre, ne automatikusan.
- 20 számla kiolvasással: mérd külön az átnézés idejét, és jegyezd fel, hányat kellett javítani és mennyi ideig.
- Mezőnként jegyezd, mi hibázott — szállító, dátum, összeg, adó, tételsor.
- Számold ki a megtakarítást. Ha negatív, kapcsold ki — és ez is eredmény.
Banki egyeztetés és anomáliakeresés: kevesebb AI, mint hinnéd
A banki párosítás szabálylánc, nem gépi tanulás. Ha a tranzakcióhoz nincs partner rendelve, a rendszer a közleményt veti össze a meglévő bizonylatok számával és hivatkozásaival; ha van partner, akkor összeg alapján párosít, mégpedig meghatározott sorrendben: pontos egyezés, majd kedvezményes egyezés (korai fizetési kedvezmény esetén), majd az összeg keresése a közleményben. A kiegészítő szabálymodellek reguláris kifejezéseket is használnak, és a sorrendjük számít: ha több modell illeszkedne, az első fut le.
Mért automatikus párosítási arányt nem találtam — sem a gyártótól, sem függetlenül. A siker a saját adataid minőségén múlik: azon, hogy benne van-e a közleményben a számla hivatkozása. Ez viszont a saját rendszeredben mérhető.
A duplikátumkeresés is szabályalapú: összeg, dátum és számlaszám, banki szinkronnál a tranzakcióazonosító alapján.
A „szokatlan összeg" típusú anomáliakeresésre viszont nincs dokumentált beépített funkció. Ezt fontos kimondani, mert sok ismertető AI-t képzel oda.
Amit viszont meg tudsz építeni magadnak: egy AI szerveri művelettel. A logika ugyanaz, mint minden agentnél: az AI eldönti, melyik eszközt hívja; az eszköz egy általad megírt, hagyományos szerveri művelet, ami a tényleges vizsgálatot végzi. Az ellenőrzési szabályt a kódba írod — például: az adott szállítónál az elmúlt tizenkét hónap átlagának kétszeresét meghaladó összeg, vagy az elmúlt 90 napban már szereplő számlahivatkozás. Két dolgot kell kézzel deklarálnod: az eszköz sémáját (mit kap meg az AI-tól) és magát a szabályt. Amit nem deklarálsz a sémában, azt az AI nem tudja átadni. A szerepmegosztásról az ERP beépített AI-ja című írás szól bővebben.
Ki felel, ha a gép olvasta ki?
A kérdés jogilag rosszul van feltéve. Az áfatörvény nem azt kérdezi, ki gépelte be az adatot.
A 168/A. § (1) bekezdése szerint a számla kibocsátásától a megőrzési időszak végéig biztosítani kell a számla eredetének hitelességét, adattartalma sértetlenségét és olvashatóságát. A (2) bekezdés pedig megmondja, hogyan: bármely olyan üzleti ellenőrzési eljárással, amely a számla és a teljesítés között megbízható üzleti kapcsolatot biztosít. És ezt a kibocsátónak és a befogadónak is teljesítenie kell, egymástól függetlenül is.
A NAV magyarázata szerint az üzleti ellenőrzési eljárás lényege, hogy a számlát az üzleti és számviteli folyamaton belül ellenőrzik, nem független dokumentumként — és elsődlegesen azt nézik, hogy a számlában feltüntetett ügylet ténylegesen a feltüntetett mennyiségben és minőségben teljesült-e.
Ezt az AI nem tudja elvégezni. Nem tudja ellenőrizni, hogy az áru megérkezett-e. Ezt csak az tudja, aki átvette. Az OCR a rögzítést váltja ki, nem az ellenőrzést. Aki az automatikus könyvelést bekapcsolja anélkül, hogy bárki összevetné a számlát a teljesítéssel, nem időt spórol, hanem jogszabályi követelményt hagy ki.
Ezért jó a „kérdezz rá három hibátlan után" beállítás: nem a kiolvasásban bízik, hanem a folyamatban.
A megőrzésről röviden: az elektronikus számlát — kibocsátóként és befogadóként is — elektronikus formában kell megőrizni. És egy részlet, amit sokan nem tudnak: az elektronikusan megőrzött számlaadatokat adóhatósági ellenőrzéskor a számlarendelet szerinti adatszerkezetben kell rendelkezésre bocsátani, és ez a szabály minden elektronikus formában megőrzött számlára vonatkozik, nem csak az elektronikus számlára — tehát a beszkennelt papírszámlára is. A digitális archiválás szabályait külön rendelet tartalmazza.
Két eljárást a törvény erejénél fogva elfogad az eredet hitelességére és az adattartalom sértetlenségére: a minősített elektronikus aláírással ellátott számlát és az EDI-ként létrehozott és továbbított számlát. Ezeknél nem kell külön üzleti ellenőrzési eljárás e feltételek teljesítéséhez.
Amit érdemes elvinni
Magyarországon a számlakiolvasás nem ott spórol, ahol a nemzetközi marketing állítja: a belföldi áfaadat már a NAV-nál van. Ahol tényleg spórol: a külföldi és nem áfás bizonylatoknál, a tételsoroknál és a dokumentumnál maradó információnál.
A kredit ára gyakorlatilag sosem a döntő tényező — fél perc megtakarítás már kitermeli. A döntő tényező a hibaarány és az ellenőrzés fegyelme: ugyanaz a folyamat ötszörös megtérülési különbséget mutat aszerint, mennyire kell utánanyúlni. És a gyártó nem méri meg helyetted: a fenti ötlépéses séma negyven számlából megadja a saját számodat.
A felelősség pedig nem osztható meg a géppel. Az üzleti ellenőrzési eljárás a tiéd marad — az AI csak a gépelést veszi le.