Magyar OCR és AI-számlafelismerés: mi ismeri fel tényleg az ékezetes számlát?

Ez a cikk a bejövő számlák automatikus feldolgozásáról szóló írásunk folytatása. Ott a folyamatot mutattuk meg, itt a felismerést: mit tud a hagyományos OCR, mit a felhős dokumentum-AI, mit a látó AI-modell, és mennyibe kerül egy oldal a saját, mért adataink szerint. Más eszközökről konkrét pontossági százalékot nem írunk, mert nem mértük őket. Amit írunk, az vagy a mi éles rendszerünkből származik, vagy hivatkozott forrásból.

Miért nehéz a gépnek a magyar számla?

A magyar számla három rétegben nehéz: karakter, szókincs, elrendezés. Ezek közül csak az első az, amit a köznyelvi „szövegfelismerés” szó lefed — a másik kettő már értelmezés, és ott dől el, lesz-e könyvelhető adat.

Karakter. A magyar ábécé két betűje, az ő és az ű, rendszeresen kimarad a nemzetközi mintán épített karakterkészletekből. Ez nem elmélet: az Amazon Textract hivatalosan dokumentált karakterlistája felsorolja az á, é, í, ó, ö, ú és ü betűket, de az ő és az ű nem szerepel benne (2026. szeptemberi állapot). Egy „Fűtésszerelés” vagy „Bőrönd” megnevezésű tételsor tehát már karakterszinten megsérülhet.

Szókincs. A gépnek nem elég elolvasnia, hogy „Fizetendő végösszeg”, „Áfa alapja”, „Nettó összesen”, „Teljesítés kelte”. Tudnia kell, melyik szám micsoda — és ugyanaz az érték a következő beszállítónál másik felirat alatt áll.

Formátum. A magyar összeg szóközzel tagol és vesszővel tizedel: 1 234 567,89 Ft. Az angolszász mintán tanított modellnek ez fordított logika, mert ott a vessző tagol és a pont tizedel. A dátum ugyanilyen csapda: a 2026.09.01. sorrendje eltér a legtöbb nyugat-európai számláétól.

Elrendezés. Nincs két beszállító, aki ugyanoda tenné a számlaszámot. Ezért a felismerés kérdése soha nem önmagában „jó-e az OCR”, hanem az: mezőnként, megbízhatóan kijön-e az adat. Ha az automatizálás alapfogalmai újak, kezdje az AI-automatizálásról szóló útmutatónkkal.

Hagyományos OCR, felhős dokumentum-AI, LLM-vision: mi a különbség?

A három megközelítés nem ugyanazt a feladatot oldja meg, ezért az összehasonlításuk csak akkor tisztességes, ha ezt kimondjuk. A hagyományos OCR betűket ismer fel, a felhős dokumentum-AI kész mezőket ad vissza, a látó (vision) AI-modell pedig értelmezi a lapot.

Hagyományos OCR. Képből szöveget csinál. A kimenete sorokba tördelt nyers szöveg, amiben a „Kelt: 2026.” és a partner címe könnyen egy sorba kerül. Aki mezőket akar, annak ezt utólag szabályokkal kell szétszednie — és a szabályok minden új beszállítói elrendezésnél elromlanak.

Felhős dokumentum-AI. Számlára tanított szolgáltatás: számlaszámot, dátumokat, összegeket, tételsorokat ad vissza mezőnként. Ott erős, ahol a dokumentum a tanított minta közelében van; az erősen egyedi elrendezés vagy a gyenge szkennelés kimozdítja belőle.

LLM-vision. Nem sablont követ, hanem nézi és értelmezi a lapot, ezért a szokatlan elrendezést, a pecsétet, a kézzel ráírt megjegyzést is elbírja. Cserébe magabiztosan tud tévedni: nem jelzi, hogy bizonytalan — egyszerűen mond egy számot.

A táblázat a három út jellegét veti össze. Pontossági százalékot szándékosan nem írunk bele: azt felelősen csak a saját dokumentumain, saját mérésből lehet kimondani.

A gyakorlatban ez nem vagy-vagy kérdés. A vegyes forrás — e-mailben érkező PDF, papírról szkennelt köteg, telefonnal fotózott lap — vegyes eszközkészletet is elbír, ha a végén ugyanaz az ellenőrzés fut le mindegyikre.

Mi érhető el ténylegesen magyarul? (2026. szeptemberi állapot)

A magyar nyelvi támogatás eszközönként nagyon eltérő, és a hivatalos dokumentációkban ez ellenőrizhető. Az alábbiak mind a gyártók saját oldalairól származnak, 2026. szeptemberi állapot szerint — a listákat érdemes időnként újranézni, mert változnak.

Tesseract (nyílt forráskódú OCR). A magyar nyelvi modul (hun) létezik, és a hivatalos nyelvi fájl-listában minden újabb verzióhoz elérhető. A dokumentáció ugyanakkor a bemenetről is nyilatkozik: a minőségjavítási útmutató szerint legalább 300 DPI ajánlott, a ferde lap „jelentősen rontja” a sorszegmentálást, és a zaj csökkenti a pontosságot. Vagyis a munka fele nem a felismerés, hanem a kép előkészítése.

Azure AI Document Intelligence. A számlamodell (prebuilt-invoice) hivatalos nyelvi listáján a magyar (hu, Hungary) szerepel, és a támogatott pénznemek között ott a HUF is. Ez a legexplicitebb magyar számla-támogatás, amit a nagy szolgáltatók dokumentációjában találtunk.

Google Document AI. Itt szét kell választani a kettőt: a nyelvi támogatási oldal szerint az OCR-processzor listáján szerepel a magyar (hu), az Invoice parser nyelvlistáján viszont nem. Tehát a betűket olvassa, a számlamezőket magyarul nem ígéri.

Amazon Textract. A dokumentált korlátok szerint a szövegfelismerés angolt, franciát, németet, olaszt, portugált és spanyolt támogat. A magyar nincs a listán.

Egy fontos kiegészítés: az, hogy egy nyelv szerepel a támogatott listán, nem pontosság-garancia. A listán szereplés annyit jelent, hogy a gyártó vállalja a nyelvet — hogy az Ön beszállítóinak lapjain mennyire működik, azt csak egy saját mintán végzett mérés mondja meg.

Mennyibe kerül egy oldal? A mi mért számaink

Az élő rendszerünkben a látó AI-modellel végzett adatkinyerés mért költsége ~22 Ft/oldal, mért ideje ~24 másodperc/oldal. Ötszáz oldalnyi szkennelt köteg így nagyjából 11 200 Ft — ennyibe kerül a kiolvasás maga.

Ugyanezen a gépen kipróbáltuk az „ingyenes”, helyben futó OCR-alternatívát is. Az eredmény: ~15 perc/oldal. Ez nem elírás. Tizenöt perc 900 másodperc, ami a mért 24 másodpercnek a 37-szerese; ötszáz oldal ezen az úton 125 óra folyamatos gépidő. Használhatatlan — nem azért, mert rosszul olvasott, hanem mert ilyen tempóval a hétfői köteg csütörtökre sem lenne kész.

Ebből egy tanulság következik, amit érdemes kimondani: az ingyenes eszköz nem ingyen van, hanem gépidőben és emberi várakozásban fizet. A 11 200 Ft-os számla a szolgáltatótól látszik; a 125 óra nem látszik sehol, mégis valakinek a hete.

A kiolvasás költsége viszont csak az egyik tétel. Mellé jön a rendszer megépítése és az üzemeltetés — nálunk a dokumentum-feldolgozás 500 000 Ft-tól indul, az üzemeltetés 30 000 Ft/hó-tól. Hogy ez az Ön számlaforgalmánál mennyi idő alatt térül meg, azt a saját számaival a megtakarítás-kalkulátorunkban tudja végigszámolni.

Az AI hibázhat — ezért kódban ellenőrzünk, nem a modellben bízunk

Ez a cikk legfontosabb mondata: a felismerés pontossága önmagában nem megbízhatóság. Egy látó modell akkor is ad választ, ha bizonytalan — nem hagy üresen mezőt, hanem mond egy számot. Ezért nálunk a végső ellenőrzés soha nem az AI dolga.

Minden kiolvasott számlára kódban futó, kötelező matematikai ellenőrzés következik: nettó + áfa = bruttó, és a tételsorok összege egyezik-e a végösszeggel. Ez nem AI, hanem néhány sor determinisztikus logika — pont ezért lehet benne megbízni. Ami átmegy, mehet az archívumba és a nyilvántartásba. Ami nem megy át, az emberi ellenőrzésre kerül.

Automatikus javítás nincs. A rendszer nem „találja ki” a helyes értéket, mert az találgatás lenne, és a találgatás észrevétlenül épül be a könyvelésbe. Megmutatja a problémás számlát, és megvárja az embert.

Az éles számaink ehhez: 470+ számla dolgozódott fel, ebből 80% ment át teljesen automatikusan, 20% került emberi ellenőrzésre. Ez a 20% nem a rendszer kudarca, hanem a becsületes része — az a köteg, amiről a gép maga mondja meg, hogy nem biztos benne. Egy „100%-ban automatikus” ígéret ugyanezt a 20%-ot nem tünteti el, csak elrejti.

Ugyanez az adat egyébként nem áll meg az archívumnál: az ellenőrzött számlaadatból vezetői kimutatás is épülhet, ami már a riport-automatizálás terepe.

Mikor nem éri meg OCR-ezni?

Négy helyzetben mondjuk azt, hogy ne csinálja meg — vagy legalábbis ne így.

1. Ha az adat már strukturáltan megvan. A belföldi beszállítói számlák adata jó eséllyel ott van a NAV Online Számla rendszerében, és onnan lekérdezhető: a NAV hivatalos fejlesztői dokumentációja (Számlaadat-szolgáltatás REST API interfészleírás, 3.0-s verzió, 2026. február 12.) szerint a keresés iránya megadható vevő oldaliként is (INBOUND). Amit ki lehet kérni gépi felületen, azt kár képfelismeréssel újrafejteni. Két korlátot viszont ugyanez a dokumentum kimond: azok a számlák, amelyek nem tartalmazzák a vevő adószámát, vevői oldalról nem kereshetők — és a külföldi beszállító számlája eleve nincs a rendszerben. Ezért a legtöbb cégnél vegyes megoldás lesz a helyes: amit lehet, lekérdezni; a maradékot felismerni.

2. Ha a PDF-ben már van szövegréteg. Az e-mailben, gépből érkező PDF-számla gyakran nem kép: a szöveg kimásolható belőle. Ilyenkor az OCR fölösleges kerülőút, elég a szöveget kinyerni és értelmezni — olcsóbban és gyorsabban.

3. Ha kicsi a volumen. Havi 20–30 bejövő számlánál a kézi rögzítés néhány óra havonta. Ezt egy 500 000 Ft-tól induló rendszer évekig nem hozza vissza. Ha bizonytalan, hol a határ, a folyamat-audit árairól szóló cikkünk segít eldönteni, érdemes-e egyáltalán belekezdeni.

4. Ha nincs, aki a kivételeket átnézze. A 20% emberi sor nem opcionális. Ha nincs kolléga, aki hetente végigmegy rajta, a rendszer nem gyorsít, csak áthelyezi a torlódást.

És a saját kezű út? Reális. Ha van házon belül fejlesztő, a nyílt forráskódú OCR plusz egy szkript kis volumenen működhet, és nulla licencdíjba kerül. A buktató nem a felismerés: az ellenőrzés, a kivételkezelés, a naplózás és a karbantartás a munka nagyobbik fele — és a mi mérésünkben a helyben futó út 15 perc/oldalnál tartott. Ha nekivág, a mi tanácsunk ugyanaz, mint amit magunknak adtunk: a matematikai ellenőrzést írja meg elsőnek, ne utolsónak.

Gyakori kérdések

Mennyibe kerül egy oldal számla AI-os felismerése?

Az élő rendszerünkben mért adat: körülbelül 22 Ft és 24 másodperc oldalanként, ami 500 oldalnál nagyjából 11 200 Ft. Ez csak a kiolvasás díja. Mellé jön a rendszer megépítése, ami nálunk a dokumentum-feldolgozásnál 500 000 Ft-tól indul, és az üzemeltetés 30 000 Ft/hó-tól. Óradíjjal nem dolgozunk, az árat előre megmondjuk.

Felismeri az AI a magyar ékezetes betűket, az ő-t és az ű-t?

Eszközfüggő. Az Amazon Textract hivatalosan dokumentált karakterlistája például tartalmazza az á, é, í, ó, ö, ú és ü betűt, de az ő és az ű nem szerepel benne. A látó AI-modelleknél a mi tapasztalatunk szerint nem az ékezet a szűk keresztmetszet, hanem a számok pontossága — ezt viszont kódban ellenőrizzük, nem a modellre bízzuk.

Elég-e egy KKV-nak az ingyenes, magyar nyelvű Tesseract?

A magyar nyelvi modul létezik és nyilvánosan elérhető, tehát a betűket olvassa. Két gond van vele: nyers szöveget ad, nem mezőket, így a számlaszám és az összegek kinyerése külön szabályokat igényel; és a hivatalos dokumentáció szerint jó minőségű, egyenes, legalább 300 DPI-s képre van szüksége. Nálunk ez az út 15 perc/oldalnál tartott.

Kell-e emberi ellenőrzés, ha az AI kiolvassa a számlát?

Nálunk igen, és ez tudatos döntés. Minden kiolvasott számlán kódban fut le a nettó plusz áfa egyenlő bruttó és a tételösszeg-ellenőrzés. Az éles rendszerünkben 470 fölötti számlából 80 százalék ment át automatikusan, 20 százalék került emberi sorba. Automatikus javítás nincs: a rendszer nem találja ki a helyes értéket, hanem megmutatja a problémás lapot.

Hol jár az adat, ha felhős AI-t használunk?

A felhős dokumentum-AI és a látó modellek a szolgáltató infrastruktúrájában dolgozzák fel a lapot, a régió általában választható, a részleteket a szerződés rendezi. A helyben futó OCR ezzel szemben el sem hagyja a gépet. Mi minden projektnél előre tisztázzuk, mi hova kerül, és alapból csak olvasunk a meglévő rendszerekből, naplózva.

A következő lépés

Kezdje méréssel, ne eszközválasztással. Szedjen össze húsz valódi bejövő számlát — vegyesen, ahogy érkeznek: papírról szkennelve, e-mailes PDF-ben, telefonnal fotózva —, mert ez a húsz lap többet mond az Ön esetéről, mint bármelyik gyártói nyelvi lista.

Ha előbb a megtérülést nézné, a fenti kalkulátorral pár perc alatt megvan. Ha inkább átbeszélné, kérjen egy ingyenes 30 perces konzultációt — és őszintén megmondjuk azt is, ha az Ön volumenénél nem éri meg.