Automatizált számlafeldolgozás 2026-ban: mit old meg az AI és hol kell még ember?

A havi zárás előtti héten sok magyar kisvállalkozásnál ugyanaz a jelenet ismétlődik: valaki a pénzügyön egy közös e-mail-fiókból, három szállítói portálról és egy irattartónyi papírból próbálja összeszedni a hónap bejövő számláit, hogy a könyvelő határidőre megkapja őket. Az automatizált számlafeldolgozás pontosan erre a munkára ígér megoldást, 2026 szeptemberében pedig két hír miatt is újra napirendre került. Az OpenAI szeptember 3-án bemutatott GPT-6 Astra modellje a gyártó szerint kifejezetten a sablonok követésében és a jól strukturált dokumentumok kezelésében lépett előre, a Zapier és az Artificial Analysis nyári AutomationBench-mérése viszont azt mutatta, hogy az üzleti folyamatok közül éppen a pénzügyieket viszik végig a legnehezebben az AI-ügynökök.

A két hír együtt adja ki a lényeget: a modellek ma már jól olvasnak számlát, a számlafeldolgozás azonban nem olvasási feladat, hanem szabályokkal, jogosultságokkal és felelősséggel teli folyamat. A folytatásban 2026. szeptember 22-i állapot szerint végigmegyünk a teljes láncon a beérkezéstől a könyvelésre kész tételig, megnézzük a friss pénzügyi benchmarkokat, a NAV Online Számla és a könyvelő szerepét, végül forintra számoljuk a megtérülést. Az írás tájékoztató jellegű: adózási és számviteli kérdésekben mindig a könyvelőd vagy az adótanácsadód véleménye a mérvadó.

Röviden

• Az automatizált számlafeldolgozás 2026. szeptember 22-i állapot szerint a bejövő számlák fogadását, adatkinyerését, egyeztetését és könyvelési előkészítését jelenti, amelyből az AI az adatkinyerést és a kategorizálási javaslatot már megbízhatóan elvégzi, a kivételek kezelése és a jóváhagyás viszont emberi feladat marad.
• A Zapier és az Artificial Analysis 2026 júliusában közzétett AutomationBench-AA mérésében az AI-ügynökök a pénzügyi feladatoknak nagyjából csak az egyharmadát teljesítették, miközben az ügyfélszolgálati és operációs feladatoknál 60% körüli volt a sikerarány. Ráadásul minden tesztelt modell megszegett legalább néhány üzleti szabályt.
• Az Ardent Partners 2025-ös felmérése szerint a kötelezettség-kezelésben a számlák átlagosan 18,4%-a kivételként akad el, egy számla feldolgozása pedig átlagosan 9,84 dollárba kerül, vagyis a kivételkezelés megszervezése legalább annyit számít, mint a modell kiválasztása.
• Magyarországon a belföldi szállítók számláinak adatai a NAV Online Számla rendszeréből strukturáltan lekérdezhetők, így ezeknél nem kell képfelismeréssel kinyerni az adatokat, a külföldi szolgáltatók (hirdetési platformok, SaaS-előfizetések) számlái viszont továbbra is PDF-feldolgozást igényelnek.
• Saját becslésünk szerint egy havonta 400 bejövő számlát kezelő cégnél a feldolgozásra fordított idő nagyjából 47 munkaóráról 13 munkaórára csökkenhet, ami havi körülbelül 96 000 Ft nettó megtakarítást és öt-hat hónapos megtérülést jelent, havi 100 számla alatt viszont egyedi fejlesztés helyett elég a könyvelőprogram beépített NAV-importja.

Mi az automatizált számlafeldolgozás és miért most aktuális?

Az automatizált számlafeldolgozás olyan folyamat, amelyben a bejövő szállítói számlák fogadását, adataik kinyerését, ellenőrzését és könyvelési előkészítését szoftver végzi, az ember pedig csak a kivételeknél és a jóváhagyásnál lép be. 2026 őszén azért aktuális, mert az új AI-modellek olcsón és pontosan olvasnak dokumentumot, a pénzügyi szabályok betartásában viszont még rendszeresen hibáznak.

A témát érdemes rögtön leszűkíteni, mert a kimenő és a bejövő oldal egészen más helyzetben van. A kimenő számlázás, vagyis amikor te állítasz ki számlát a vevőidnek, Magyarországon a számlázó programok és a NAV felé történő kötelező adatszolgáltatás miatt a legtöbb cégnél már most is jórészt automatikus. A valódi kézimunka a másik oldalon van: a szállítóktól, alvállalkozóktól, közműcégektől és online szolgáltatóktól érkező számlák begyűjtésében, ellenőrzésében, jóváhagyatásában és a könyvelőnek való átadásában. A nemzetközi szakirodalom ezt a területet accounts payable (AP), magyarul szállítói kötelezettség-kezelés néven tárgyalja, a továbbiakban mi is erről beszélünk.

Az elmúlt években ezen a területen az OCR volt az úr. Az OCR (optical character recognition, optikai karakterfelismerés) olyan technológia, amely a képen vagy a szkennelt dokumentumon lévő betűket gépi szöveggé alakítja. A régebbi OCR-alapú számlafeldolgozók sablonokkal dolgoztak: minden szállító számlaképéhez meg kellett tanítani, hol van a számlaszám, hol a végösszeg és hol a teljesítés dátuma. Ha a szállító új számlaképre váltott, a sablon eltört. A nagy nyelvi modellek, különösen a képet is értő, úgynevezett multimodális változatok ezt a korlátot nagyrészt eltüntették, mert sablon nélkül is megtalálják a mezőket egy eddig sosem látott számlán, akár német, angol vagy lengyel nyelven.

A mostani szeptemberi hír ennek a fejlődésnek a következő lépcsője. Az OpenAI 2026. szeptember 3-i bejelentése szerint a GPT-6 Astra a cég eddigi legjobb modellje a meglévő sablonok követésére, amely (saját fordításunkban) „áttekinthető, jól strukturált dokumentumokat, prezentációkat, táblázatokat és elemzéseket készít, amelyek követik a sablonjaidat”. Ugyanebben a bejelentésben az OpenAI egy AutomationBench nevű, több lépéses üzleti automatizálási teszten 41,4%-os eredményt közölt az Astrára, szemben az előd GPT-5.6 Sol 18,1%-ával. Ez kétszeresnél nagyobb javulás, de azt is jelenti, hogy a tesztelt üzleti feladatok nagyobbik részét a legújabb modell sem vitte végig hibátlanul.

Ebből adódik a cikk alaptézise: a számlafeldolgozásban a jó folyamat többet ér, mint a jó modell. Egy közepes modell egy jól megtervezett ellenőrzési lánc közepén megbízhatóbb eredményt ad, mint a világ legjobb modellje egyedül, szabályok és kontrollpontok nélkül. A jó hír az, hogy a folyamat megtervezése nem igényel mesterséges intelligenciát, csak rendszerezett gondolkodást és egy őszinte beszélgetést a könyvelővel.

A folyamat: beérkezés, kinyerés, egyeztetés, könyvelési előkészítés

Minden számlafeldolgozási folyamat négy szakaszból áll, akár kézzel csinálod, akár géppel: a számla beérkezik, kinyered belőle az adatokat, egyezteted valamivel, amiről tudod, hogy igaz, végül előkészíted a könyvelésre és a fizetésre. Az AI mind a négy szakaszban másképp teljesít, ezért érdemes külön megnézni őket.

Beérkezés: honnan jönnek a számlák?

Egy tipikus 10 és 50 fő közötti magyar cégnél a számlák legalább négy csatornán érkeznek. A legtöbb PDF-ként jön e-mailben, gyakran nem a pénzügyi címre, hanem annak a kollégának a postafiókjába, aki a beszerzést intézte. A közműcégek, a telekommunikációs szolgáltatók és a nagyobb nagykereskedők egy része csak a saját ügyfélportálján teszi elérhetővé a számlát, ahonnan havonta le kell tölteni, ugyanígy a fiókon belül található a Google Ads, a Meta vagy egy felhőszolgáltató számlája is. Végül ott vannak a papírszámlák, amelyek az áruval együtt, a futárral vagy postán érkeznek.

A beérkezés automatizálásának első és legolcsóbb lépése egy központi számlafogadó cím (például szamla@cegneved.hu), amelyet minden szállító megkap. Erről a címről egy levelezési szabály vagy automatizációs munkafolyamat közös mappába gyűjti a mellékleteket. Ehhez még nem kell mesterséges intelligencia, csak egy kis szervezési fegyelem. Az AI ott segít, ahol a levélből kell eldönteni, hogy számla, díjbekérő, fizetési emlékeztető vagy reklám érkezett-e. A postafiók AI-alapú rendezése külön téma, a számlák kiválogatása mindenesetre az egyik legkönnyebben automatizálható részfeladat.

A magyar helyzet egyik sajátossága, hogy a beérkezést a NAV Online Számla is segíti. A belföldi áfaalanyok által kiállított számlák adatai 2021 óta gyakorlatilag teljes körűen bekerülnek a NAV rendszerébe, a vevő pedig lekérdezheti a neki kiállított számlák adatait a webes felületen vagy gépi interfészen keresztül. Ez azt jelenti, hogy a belföldi szállítók számláiról gyakran már a PDF vagy a papír megérkezése előtt tudhatsz. Egy jól beállított folyamat ezért naponta összeveti, mi jelent meg a NAV-ban és mi érkezett be ténylegesen, így a hiányzó számlák nem a hónap végén derülnek ki.

Kinyerés: az adatok a számláról a rendszerbe

A kinyerés az a lépés, amelyben a számlából strukturált adat lesz: szállító neve és adószáma, számlaszám, kiállítás és teljesítés dátuma, fizetési határidő, nettó összeg, áfa, bruttó összeg, pénznem, tételsorok, bankszámlaszám. A forrás négyféle lehet, az alábbi sorrend pedig egyben a megbízhatósági sorrend is.

• Strukturált adat a NAV Online Számlából: géppel olvasható XML, nincs benne felismerési hiba, de csak azt tartalmazza, amit a szállító bejelentett.
• Strukturált elektronikus számla, ha a szállító XML-t vagy beágyazott adatot is küld a PDF mellé.
• Szöveges réteggel rendelkező PDF, amelyet számlázó program generált: a szöveg kimásolható, a modellnek csak értelmeznie kell.
• Szkennelt vagy lefotózott papírszámla: itt kell igazi képfelismerés, ez a leggyakoribb hibaforrás.

A nagy nyelvi modellek a harmadik és a negyedik esetben hozták a legnagyobb ugrást. Egy multimodális modell a számla képéről sablon nélkül is kiolvassa a mezőket, a kimenetet pedig előre megadott szerkezetben, például JSON formátumban adja vissza, amelyet a következő lépés már géppel feldolgoz. A kinyerés után viszont mindig jönnie kell egy gépi ellenőrzésnek: stimmel-e a nettó és az áfa összege a bruttóval, érvényes formátumú-e a magyar adószám (xxxxxxxx-y-zz), logikus-e a kiállítás, a teljesítés és a fizetési határidő sorrendje, egyezik-e a tételsorok összege a végösszeggel. Ezek egyszerű, kiszámítható szabályok, amelyekhez nem kell AI, mégis a kinyerési hibák jelentős részét kiszűrik.

Egyeztetés: stimmel-e, amit kaptunk?

Az egyeztetés az a pont, ahol a számlafeldolgozás könyvelési feladatból üzleti feladattá válik. A nemzetközi gyakorlatban a háromutas egyeztetés (three-way match) a bevett módszer: a számlát összevetik a megrendeléssel és az áruátvételt igazoló szállítólevéllel, a számla pedig csak akkor mehet tovább, ha mindhárom egyezik. Magyarországon ehhez jön negyedik forrásként a NAV-ban látható számlaadat, így nálunk akár négyutas egyeztetésről is beszélhetünk.

A kisebb cégeknél ritkán van formális megrendelés minden vásárlás mögött, ezért az egyeztetés itt inkább józan észből áll: van-e szerződés vagy árajánlat, amelyhez az összeg igazodik, megjött-e az áru vagy elvégezték-e a munkát, nem érkezett-e már ugyanez a számla egyszer, illetve nem változott-e meg a szállító bankszámlaszáma az előző számlához képest. Az AI itt remekül tud gyanús eltéréseket jelezni, például ha egy havidíjas szolgáltatás számlája 30%-kal magasabb a szokásosnál. Dönteni viszont nem tud, mert nem látja, hogy közben díjemelésről vagy csomagváltásról állapodtatok meg.

Könyvelési előkészítés: kész tétel a könyvelőnek

Az utolsó szakaszban a számla megkapja mindazt, ami a könyveléshez és a fizetéshez kell: javasolt főkönyvi számla, költséghely vagy projekt, áfakezelés, fizetési ütemezés, jóváhagyó személy. Az AI itt a korábbi hónapok mintáiból tanul: ha a helyi nyomdától érkező számlák eddig mindig a marketingköltségek közé kerültek, a következőt is oda fogja javasolni. A javaslatot tapasztalatunk szerint a legtöbb tételnél elég jóváhagyni, a könyvelő mégis ellenőrzi, mert a főkönyvi besorolás és az áfakezelés az ő szakmai felelőssége.

Mit old meg ma megbízhatóan az AI a számlafeldolgozásban?

Az AI 2026 őszén megbízhatóan elvégzi a számlák szétválogatását, a mezők kiolvasását szinte bármilyen számlaképről, a szállítók és a költségtípusok felismerését, a korábbi minták alapján adott könyvelési javaslatot és a szokatlan eltérések jelzését. Ezekben az a közös, hogy a hiba olcsón észrevehető és javítható, a döntés súlya pedig kicsi.

Az olvasás, vagyis az adatok kiolvasása a számlaképről, a legerősebb terület. Egy mai multimodális modellnek nem okoz gondot egy kétoldalas, német nyelvű fuvarozói számla vagy egy tizenöt tételsoros építőanyag-számla, amelyen a kedvezmény soronként eltérő, a kimenetet pedig pontosan abban a szerkezetben adja vissza, amelyet a következő rendszer vár. Itt jön képbe a GPT-6 Astra erőssége, a sablonkövetés: ha a könyvelőd programja egy meghatározott oszloprendű importtáblát fogad, vagy a vezetőség minden hónapban ugyanolyan szerkezetű költségriportot kér, a modell ezt a formát fegyelmezetten tartja.

A második erős terület a kategorizálás, vagyis annak eldöntése, hová tartozik egy költség. Ha a rendszer hozzáfér az elmúlt 12 hónap feldolgozott számláihoz, egy új számlánál nagy biztonsággal meg tudja mondani, melyik költséghelyre és melyik főkönyvi számlára került eddig az adott szállító hasonló tétele. Egy új szállítónál is ad értelmes javaslatot a megnevezés alapján, például egy szoftverelőfizetést nem sorol be anyagköltségnek. A javaslat mellé érdemes bizonyossági szintet is kérni, mert ebből lehet később szabályt építeni: a magas bizonyosságú, ismert szállítótól érkező, szokásos összegű tétel mehet gyorsított úton, minden más ember elé kerül.

A harmadik terület, ahol az AI már most sokat hoz, az eltérések jelzése. A modell észreveszi, ha egy havidíj hirtelen megugrik, ha ugyanaz a számlaszám kétszer érkezik be eltérő fájlnévvel, ha egy szállító számláján más a bankszámlaszám, mint a korábbiakon, vagy ha a teljesítés dátuma a hónap zárása utánra esik. Ezek közül egyik sem döntés, csak figyelmeztetés, ezért ideális terep egy AI-nak: ha téved, a kolléga egy kattintással továbbengedi a tételt.

Van egy terület, ahol érdemes óvatosnak lenni még a legjobb modellel is: a számolás. A nyelvi modellek szövegként kezelik a számokat, ezért egy összeadásnál vagy egy áfa-visszaszámolásnál ritkán, de előfordul, hogy elcsúsznak egy kerekítésen. A jól tervezett rendszerben ezért a modell olvas, a kód pedig számol. Ez a munkamegosztás szinte semmibe sem kerül, mégis a hibák egy teljes kategóriáját megszünteti.

Végül ott van a számítógép-használat, amelyről az Astra kapcsán a legtöbb szó esik. Az OpenAI szerint a GPT-6 Astra önállóan tölt ki online űrlapokat, így egy ügynök elvileg a szállítói portálokról is letöltheti a havi számlákat ott, ahol nincs gépi interfész. Ezt csak végső megoldásnak javasoljuk, mert a képernyőn kattintgató ügynök lényegesen drágább egy egyszerű dokumentumfeldolgozásnál, ráadásul át kell adni neki a portálok belépési adatait.

Hibaarány: mit mutatnak a pénzügyi benchmarkok?

A friss pénzügyi benchmarkok két, egymást kiegészítő tanulsággal szolgálnak. Az AI-ügynökök a pénzügyi folyamatokat viszik végig a legalacsonyabb arányban, nagyjából a feladatok egyharmadát, a hagyományos, emberek által végzett kötelezettség-kezelésben pedig átlagosan minden ötödik-hatodik számla kivételként akad el. A hibát tehát nem eltüntetni kell, hanem kezelhetővé tenni.

Mit mért az AutomationBench a pénzügyi feladatokon?

Az AutomationBench-AA a Zapier és az Artificial Analysis 2026. július 6-án közzétett közös tesztje, amely 657 feladaton méri, hogyan boldogulnak az AI-ügynökök valós üzleti munkafolyamatokkal. A feladatok hat területet fednek le (pénzügy, HR, marketing, operáció, értékesítés és ügyfélszolgálat), az ügynökök pedig 40 szimulált üzleti alkalmazásban dolgoznak. Az Artificial Analysis összefoglalója szerint a pénzügyi munkafolyamatok automatizálása a legnehezebb: az ügynökök ezeknek nagyjából az egyharmadát teljesítették, miközben az ügyfélszolgálati és operációs feladatoknál 60% körüli volt a sikerarány.

A mérés másik fontos megállapítása, hogy minden modell megszegett üzleti szabályokat, feladatonként átlagosan 0,46 és 1,26 közötti alkalommal. Összesítésben a legjobb eredményt a Claude Fable 5 érte el 48,6%-kal, a júliusban mért modellek azóta viszont újabb verziókra cserélődtek, a benchmark részletes elemzése pedig külön írást érdemel. A számlafeldolgozás szempontjából a lényeg annyi, hogy a pénzügyi szabálykövetés 2026 nyarán a leggyengébb pontja volt az AI-ügynököknek, ezen pedig egyetlen modellcsere sem változtat egyik napról a másikra.

Hogy miért éppen a pénzügy a legnehezebb terület, arra a feladat természete adja meg a választ. Egy ügyfélszolgálati válaszban a „majdnem jó” még elfogadható, egy könyvelési tételnél viszont nincs majdnem jó: az összeg vagy stimmel, vagy nem. A pénzügyi folyamatokban ráadásul sok az íratlan szabály (ezt a szállítót mindig csak a projektvezető jóváhagyása után fizetjük), sok a visszafordíthatatlan lépés (az elutalt pénzt nehéz visszahozni) és sok a más rendszerekből származó kontextus, amelyet az ügynök nem lát.

Mit mutatnak az emberi csapatok számai?

Az AI teljesítményét érdemes az emberi referenciához mérni, mert a kézi számlafeldolgozás sem hibátlan. Az Ardent Partners nevű amerikai elemzőcég State of ePayables 2025 című jelentése szerint, amelyet a cég 2026. január 22-én összegzett, egy számla feldolgozása a kötelezettség-kezelési osztályokon átlagosan 9,84 dollárba kerül és 8,2 napig tart, a számlák 18,4%-a pedig kivételként akad el, vagyis valamilyen eltérés miatt emberi beavatkozást igényel. A legjobban teljesítő szervezetek 79%-kal olcsóbban és 79%-kal gyorsabban dolgoznak, a kivételarányuk 47%-kal alacsonyabb, a számláik közül pedig 1,8-szor annyi fut át emberi érintés nélkül, mint a többieknél.

Kerekített, 320 Ft-os dollárárfolyammal számolva az átlagos 9,84 dollár nagyjából 3 150 Ft számlánként, a legjobbaknál ez saját számításunk szerint körülbelül 660 Ft. A kivételarány a legjobbaknál 18,4% helyett körülbelül 9,8%. Ezek dedikált kötelezettség-kezelési osztályok átlagai, ezért a forintos összeg egy magyar KKV-ra nem vetíthető át egy az egyben. Az arányok viszont tanulságosak: a legjobbak sem nulla kivétellel dolgoznak, csak kevesebbel, a kivételeket viszont gyorsan és szervezetten kezelik.

Háromféle hiba, háromféle védekezés

A számlafeldolgozásban háromféle hibát érdemes megkülönböztetni, mert mindegyik ellen más véd.

• Kinyerési hiba: a modell rosszul olvas ki egy mezőt, például felcserél két számjegyet vagy a kiállítás dátumát teljesítési dátumnak veszi. Ellene a gépi ellenőrzés véd (összegek, adószám-formátum, dátumlogika), valamint a NAV-adatokkal való összevetés.
• Értelmezési hiba: a modell jól olvas, de rosszul következtet, például egy fordított adózású tételt normál áfás tételként kezel, vagy rossz főkönyvi számlát javasol. Ellene a bizonyossági küszöb és az emberi ellenőrzés véd.
• Szabálysértés: az automatizáció olyasmit tesz, amire nem kapott felhatalmazást, például jóváhagyás nélkül továbbít egy tételt a fizetési listára. Ellene a jogosultságok szűkítése véd: amit a rendszer technikailag nem tud megtenni, azt hibából sem teszi meg.

Egy egyszerű számítás megmutatja, miért nem elég a mezőszintű pontosságot nézni. Tegyük fel, hogy a rendszer számlánként 12 mezőt olvas ki és mezőnként 98%-os pontossággal dolgozik. Ha a hibák egymástól függetlenek, annak az esélye, hogy egy számla mind a 12 mezője hibátlan, 0,98 a tizenkettediken, vagyis körülbelül 78,5%. Minden ötödik számlán lesz tehát legalább egy hibás mező, ami közel esik az Ardent-féle 18,4%-os kivételarányhoz. Ha a mezőszintű pontosság 99,5%-ra javul, a teljesen hibátlan számlák aránya körülbelül 94,2%-ra nő. Ha egy szoftvergyártó pontossági adatot mond, mindig kérdezz rá, hogy mező- vagy számlaszintű értékről van-e szó, mert neked a számlaszintű eredmény számít, ezt pedig a saját számláidon kell megmérni.

Hol kell még ember a számlafeldolgozásban?

Ember kell mindenhol, ahol a döntésnek pénzügyi, adózási vagy jogi következménye van és a helyes válasz nem olvasható ki magából a számlából. Ilyen a kifizetés jóváhagyása, az áfakezelés különleges eseteinek eldöntése, a vitatott vagy hibás számlák rendezése, az új szállítók felvétele és minden bankszámlaszám-változás. Ezekben a helyzetekben az AI előkészít és javasol, de nem dönt.

A számviteli és adózási felelősség akkor is a cégé és a könyvelőé marad, ha a feldolgozást gép végzi, ezért minden automatikus lépésnél tudnod kell, melyik ember felel a hibáért és hol látja, mit csinált a gép. Ha erre nincs válasz, az adott lépés még nem érett meg az automatizálásra.

Áfakezelés és különleges számlatípusok

A legtöbb bejövő számla egyszerű: belföldi szállító, 27%-os áfa, egyösszegű fizetés. A problémák a maradék néhány százalékban bújnak meg, ezek viszont viszik el a legtöbb időt. Ide tartozik a fordított adózás, amikor nem a szállító számítja fel az áfát, hanem a vevőnek kell azt megállapítania, ez jellemző például az Európai Unión belüli szolgáltatásoknál és bizonyos belföldi ügyleteknél. Ide tartoznak a devizás számlák, ahol az árfolyam kiválasztása szabályhoz kötött, a korlátozottan levonható áfát tartalmazó költségek, az előleg- és végszámlák párosítása, valamint a módosító és sztornó számlák, amelyek egy korábbi számlát helyesbítenek vagy érvénytelenítenek. Az AI ezeket jól felismeri és megjelöli, a helyes kezelésről viszont a könyvelő dönt, mert ez szakmai és felelősségi kérdés.

Vitatott tételek és részteljesítés

Ha a szállító 100 zsák cementet számláz, de csak 80 érkezett meg, vagy a megállapodott óradíj helyett a régit számolta, a számla formailag hibátlan, tartalmilag mégsem fizethető ki. Ezt a helyzetet a gép jelezni tudja, ha van mihez viszonyítania (megrendelés, szállítólevél, szerződés), a teendőt viszont ember intézi: felhívja a szállítót, helyesbítő számlát kér, vagy részleges kifizetésről dönt. Az AI ebben is segít, például megírja a helyesbítést kérő levél vázlatát, de a levelet a kolléga küldi el.

Új szállító és bankszámlaszám-változás

Az egyik legismertebb számlacsalási módszer, hogy a csalók egy valódi szállító nevében e-mailben új bankszámlaszámot közölnek, a következő utalás pedig már hozzájuk érkezik. Egy automatizált folyamat ebben a helyzetben kétélű fegyver. Ha rosszul van beállítva, a gép gondolkodás nélkül átveszi az új számlaszámot, ha jól, akkor minden eltérést azonnal megfog. Az aranyszabály: bankszámlaszám-változást és új szállító felvételét soha ne fogadjon el automatizáció, mindig ember hagyja jóvá, lehetőleg a szállító korábbról ismert telefonszámán visszaigazolva.

Ide kapcsolódik egy újabb keletű kockázat is, amely kifejezetten az AI-alapú feldolgozásnál jelentkezik. A számla PDF-je vagy a kísérőlevél tartalmazhat szemmel nem látható szöveget, amely egy AI-ügynöknek szóló utasításnak tűnik, ezt nevezik prompt injectionnek. A számlafeldolgozásra vonatkozó tanulság egyszerű: a dokumentumot olvasó modellnek ne legyen joga fizetést indítani, törzsadatot módosítani vagy levelet küldeni emberi jóváhagyás nélkül.

NAV Online Számla, könyvelő és jóváhagyás egy folyamatban

Magyarországon a számlafeldolgozás automatizálásának van egy olyan előnye, amellyel sok nyugat-európai cég nem rendelkezik: a belföldi számlák adatai egy állami rendszerben, strukturáltan elérhetők. Ha ezt a forrást, a könyvelő munkamenetét és a belső jóváhagyási láncot egyetlen folyamatba kötöd, a kézi adatrögzítés nagy része egyszerűen eltűnik.

Mit ad a NAV Online Számla a vevőnek?

A NAV Online Számla a Nemzeti Adó- és Vámhivatal számlaadat-szolgáltatási rendszere, amelybe a belföldi adóalanyok számlázó programjai a kiállított számlák adatait beküldik. A vevő oldaláról két módon lehet hozzáférni a neki kiállított számlák adataihoz. A webes felületen bejelentkezés után lekérdezhetők és exportálhatók a bejövő számlák, ez kisebb mennyiségnél kézzel is működik. Gépi kapcsolathoz technikai felhasználót kell létrehozni a rendszerben, amelyhez felhasználónév, jelszó, XML aláírókulcs és XML cserekulcs tartozik, ezekkel egy program a NAV 3.0-s interfészén keresztül lekérdezheti az adatokat.

Az interfész lekérdező műveletei (például a queryInvoiceDigest és a queryInvoiceData) a kiállító és a vevő oldaláról is használhatók, a lekérdezés irányát a kimenő (OUTBOUND) vagy a bejövő (INBOUND) jelölés adja meg. A NAV a műszaki dokumentációt és a sémákat nyilvánosan közzéteszi, több hazai könyvelő- és számlázóprogram pedig már beépítve kínálja a bejövő számlák NAV-ból történő letöltését. Ha a te programod is tudja, a folyamat első lépése készen van.

Két dolgot viszont mindig tarts észben, amikor a NAV-adatokra építesz. Az egyik, hogy a NAV-ban látható adat a szállító adatszolgáltatása, nem maga a számla: ha a szállító hibásan küldte be az adatot, a NAV-ban is hibás lesz, ezért a PDF és a NAV-adat összevetése önmagában is értékes ellenőrzés. A másik, hogy a külföldi szállítók (egy ír hirdetési platform, egy amerikai szoftvercég, egy német beszállító) jellemzően nem szerepelnek a rendszerben, az ő számláikat a hagyományos úton, dokumentumként kell feldolgozni. Egy sokat hirdető cégnél ez a számlák jelentős része.

Hol áll a könyvelő ebben a láncban?

Sok magyar KKV külső könyvelőirodával dolgozik, ezért a legnagyobb hiba, amit elkövethetsz, hogy a könyvelő megkérdezése nélkül automatizálsz. A könyvelőnek megvan a saját programja, a saját importformátuma és a saját munkarendje, sőt valószínűleg ő maga is használ már valamilyen automatizációt. Ha a te rendszered egy olyan formátumban adja át az adatokat, amelyet az ő programja nem tud beolvasni, a munka egyszerűen átkerül hozzá, a könyvelési díjadban pedig ez meg is jelenik.

Vegyünk egy képzeletbeli budapesti könyvelőirodát, amely harminc ügyfelet visz. Ha az ügyfelek fele egységes szerkezetű, előre kategorizált, a NAV-adatokkal már egyeztetett csomagot küld a hónap ötödik napjáig, az iroda a rögzítés helyett az ellenőrzésre és a tanácsadásra fordíthatja az idejét. Ez a könyvelőnek is érdeke, ezért jó eséllyel partner lesz a tervezésben. Az első egyeztetésen öt kérdést érdemes tisztázni: milyen formátumban kéri az adatokat, ki rendeli hozzá a főkönyvi számlát, hogyan jelöljétek a kérdéses tételeket, meddig kell átadni a havi csomagot, végül hol érhetők el az eredeti számlaképek.

Hogyan épül fel a jóváhagyási lánc?

A jóváhagyási lánc azt rögzíti, hogy melyik számlát ki és milyen összeghatárig engedhet fizetésre. Egy 20 fős cégnél például így nézhet ki: 100 000 Ft alatt a költséghely felelőse hagyja jóvá, 100 000 és 1 000 000 Ft között az ügyvezető, e fölött két vezető együtt. Az ismert szállítótól érkező, szerződés szerinti összegű rendszeres számlák (bérleti díj, könyvelési díj, szoftverelőfizetés) előre rögzített szabály alapján automatikusan jóváhagyottnak tekinthetők, amíg az összeg a megszokott sávban marad.

Az automatizáció itt nem dönt, hanem futárt játszik: a jóváhagyónak elküldi a számla képét, a kinyert adatokat, a kapcsolódó megrendelést és a rendszer megjegyzéseit egy üzenetben, amelyet egy gombnyomással jóváhagyhat vagy visszadobhat. A fizetés indítása maradjon ember kezében: az automatizáció összeállíthatja a jóváhagyott tételekből az utalási listát, de a netbankban a gombot a pénzügyes nyomja meg.

Mire figyelj jogilag: kötelező számlaadatok, e-számla és megőrzés?

Automatizálás mellett is ugyanazok a szabályok érvényesek, mint kézi feldolgozásnál: a számlának tartalmaznia kell az áfatörvényben előírt kötelező adatokat, az elektronikusan kapott számlát elektronikusan kell megőrizni, a számviteli bizonylatokat pedig a számviteli törvény szerint legalább 8 évig. A gép segíthet ezek betartásában, a felelősséget viszont nem veszi át.

Ez a szakasz általános tájékoztatás, nem adótanácsadás, a kereteket viszont érdemes ismerni, mert ezekből épülnek fel a gépi ellenőrzések.

Kötelező számlaadatok mint ellenőrzőlista

Az általános forgalmi adóról szóló törvény, röviden az áfatörvény 169. §-a sorolja fel, mit kell tartalmaznia egy számlának. A legfontosabbak: a kiállítás kelte, a sorszám, az eladó és a vevő neve és címe, az eladó adószáma, meghatározott esetekben a vevő adószáma, a teljesítés dátuma, ha eltér a kiállításétól, a termék vagy szolgáltatás megnevezése és mennyisége, az adóalap, az egységár, az alkalmazott adómérték és az áthárított adó összege. Devizás számlánál az áthárított áfát forintban is fel kell tüntetni. Ez a lista egy automatizált rendszerben kiváló ellenőrzőlistává alakítható: ha valamelyik kötelező adat hiányzik, a számla nem megy tovább, a rendszer pedig előkészíti a szállítónak szóló hiánypótló levelet.

E-számla, PDF és megőrzés

Sokan elfelejtik, hogy az e-mailben kapott PDF-számla is elektronikus számlának minősül, ha elektronikus formában állították ki és úgy is fogadták. Az ilyen számla kinyomtatott példánya nem helyettesíti az eredetit, ezért az elektronikus fájlt kell megőrizni, mégpedig úgy, hogy a megőrzési idő alatt végig biztosított legyen az eredet hitelessége, a tartalom sértetlensége és az olvashatóság. A számviteli törvény 169. §-a szerint a számviteli bizonylatokat legalább 8 évig kell megőrizni. Egy automatizált archívumnál ez gyakorlati követelményeket jelent: a fájlokat nem lehet felülírni, kell mentés, naplózni kell a hozzáféréseket, a rendszernek pedig nyolc év múlva is elérhetőnek kell lennie, akkor is, ha közben szolgáltatót váltasz. A papíron érkezett számlák digitalizálása és a papír eredeti kiváltása külön feltételekhez kötött, ebben mindenképp kérd ki a könyvelőd véleményét.

Merre tart az e-számlázás az EU-ban?

Az Európai Unió Tanácsa 2025. március 11-én fogadta el a VAT in the Digital Age (ViDA) csomagot. Az Európai Bizottság tájékoztatása szerint a digitális adatszolgáltatási követelmények 2030. július 1-jétől vonatkoznak a határon átnyúló, vállalkozások közötti ügyletekre, 2035. január 1-jéig pedig a valós idejű hazai adatszolgáltatást működtető tagállamoknak (ilyen Magyarország is a NAV Online Számlával) össze kell hangolniuk rendszerüket az uniós modellel és szabványokkal. A KKV-k számára ennek a lényege, hogy a géppel olvasható, strukturált számla várhatóan egyre általánosabb lesz, így hosszabb távon egyre kevesebb számlát kell képről felismerni. Aki most épít rendszert, tervezze úgy, hogy strukturált bemenetet is fogadni tudjon.

Adatvédelem

A számlák személyes adatokat is tartalmaznak, például egyéni vállalkozók nevét és címét vagy kapcsolattartók elérhetőségét. Ha AI-szolgáltatón keresztül dolgozod fel őket, a GDPR szerint adatfeldolgozói szerződés kell, olyan szolgáltatóval, amely nem tanít a feltöltött adatokon. Ingyenes, fogyasztói chatfelületre számlát feltölteni akkor is rossz ötlet, ha kényelmes.

Megtérülés: havi munkaóra forintban

Saját becslésünk szerint egy havi 400 bejövő számlát kezelő cégnél az automatizált számlafeldolgozás havonta nagyjából 33 munkaórát szabadít fel, ami a futási költségek levonása után körülbelül 96 000 Ft nettó megtakarítás, egy 500 000 Ft-os bevezetés így öt-hat hónap alatt térül meg. Havi 100 számla alatt viszont egyedi rendszer helyett a meglévő szoftverek beépített funkciói a jobb választás.

Vegyünk egy képzeletbeli, 25 fős debreceni építőanyag-kereskedést, amelyhez havonta 400 bejövő számla érkezik. A számítás minden eleme becslés, a menetét azért mutatjuk meg, hogy a saját számaiddal újra tudd számolni.

• Kézi feldolgozás: számlánként átlagosan 7 perc (letöltés, rögzítés, egyeztetés, jóváhagyás kérése, iktatás), ez havonta 2 800 perc, vagyis 46,7 munkaóra.
• Óraköltség: egy pénzügyi munkatárs teljes havi bérköltsége a munkáltatói terhekkel együtt legyen 700 000 Ft, ez 168 munkaórával osztva óránként körülbelül 4 170 Ft, kerekítve 4 200 Ft.
• Automatizálás után: a számlák 75%-a gyorsított úton megy, ezeknél 1 perc a gyors ránézés, a maradék 25% kivétel, ezeknél számlánként 5 perc a kezelés. Ez 300 plusz 500, összesen 800 perc, vagyis 13,3 munkaóra.
• Az AI-díj számításához számlánként 3 000 bemeneti és 600 kimeneti tokent feltételezünk (a token a modellek elszámolási egysége, nagyjából egy szótagnyi szövegdarab), az árfolyamot kerekítve 320 Ft/dollárral számoljuk.

A modellválasztás a teljes képben meglepően kis tétel. Az Astra az OpenAI által közölt API-listaárával (10 dollár millió bemeneti és 50 dollár millió kimeneti tokenenként) számlánként 0,06 dollárba, vagyis körülbelül 19 Ft-ba kerül, mert 3 000 × 10 / 1 000 000 = 0,03 dollár a bemenet és 600 × 50 / 1 000 000 = 0,03 dollár a kimenet. Az xAI Grok 4.7 modelljével (2 dollár és 6 dollár millió tokenenként) ugyanez körülbelül 3 Ft, az Alibaba Qwen3.8-Omni-Flash modelljével (0,15 és 0,47 dollár) nagyjából 0,23 Ft. Havi 400 számlánál a teljes AI-díj így 94 Ft és 7 680 Ft között mozog, miközben a munkaidő költsége ennek sokszorosa. A modellt ezért a pontosság, az adatkezelési feltételek és a megbízhatóság alapján válaszd, ne az ár alapján.

Érdemes kiszámolni a fordított irányt is. Az automatizálás számlánként körülbelül 5 perc munkát spórol meg, ami 4 200 Ft-os óraköltséggel 350 Ft, ebből a 19 Ft-os AI-díj levonása után 331 Ft marad. A fix havi költség (platform és karbantartás) 36 400 Ft, ezt havi nagyjából 110 számla fedezi, a bevezetés egyéves megtérüléséhez pedig körülbelül havi 236 számla kell. Egy képzeletbeli balatoni panziónál, amelyhez havonta 60 számla érkezik, a teljes kézi munka 7 óra, vagyis 29 400 Ft, a megtakarítás (nagyjából 21 000 Ft) így még a havi fix költséget sem fedezné. Ott a könyvelőprogram NAV-importja, egy központi számlafogadó cím és egy rendezett havi átadás a helyes megoldás.

A táblázatból kimaradtak a nehezebben számszerűsíthető nyereségek. A gyorsabb átfutással elérhetők a szállítói skontók, elkerülhetők a késedelmi kamatok, a duplikált kifizetések pedig még az utalás előtt kiszűrhetők. Egy elkerült, 250 000 Ft-os dupla kifizetés, amelynek visszaszerzése hetekig tartó levelezéssel járna, már a bevezetési költség felét teszi ki, a hónap tizedike helyett ötödikére elkészülő havi zárás pedig a vezetői döntéseket is gyorsítja.

Hogyan vezesd be lépésről lépésre?

A bevezetés nyolc lépésben végezhető el biztonságosan: a mérés és a könyvelővel való egyeztetés az elején, az élesítés a végén áll. Egy 400 számlás cégnél a teljes folyamat két-három hónap, ebből egy hónap az árnyéküzem, amikor a gép és az ember párhuzamosan dolgozik.

• Mérd fel két héten át a kiinduló állapotot: hány számla érkezik, milyen csatornákon, mennyi időt visz el egy számla, illetve milyen gyakran kell valamit utólag javítani. Mérés nélkül később nem tudod bizonyítani a megtakarítást.
• Ülj le a könyvelővel, majd rögzítsétek közösen az átadás formáját, a határidőket, a főkönyvi besorolás felelősét és a kérdéses tételek jelölésének módját.
• Hozz létre központi számlafogadó e-mail-címet, értesítsd róla a szállítókat, a portálos szolgáltatóknál pedig állítsd át a számlaértesítőket erre a címre.
• Kapcsold be a NAV Online Számla lekérdezést, vagy a könyvelőprogram beépített importján keresztül, vagy technikai felhasználóval egy saját munkafolyamatban.
• Állítsd be a kinyerést és a gépi ellenőrzéseket: kötelező adatok, összegek egyezése, adószám formátuma, duplikáció, bankszámlaszám-változás.
• Rögzítsd a jóváhagyási szabályokat és összeghatárokat írásban, majd építsd be őket a munkafolyamatba úgy, hogy a fizetés indítása ember kezében maradjon.
• Futtasd a rendszert négy hétig árnyéküzemben: a gép feldolgoz, a kolléga is, a végén pedig számlaszinten összeveted az eredményt.
• Élesíts fokozatosan: először az ismert szállítók rendszeres számlái menjenek gyorsított úton, majd havonta nézd át a kivételeket és a tapasztalatok alapján bővítsd a szabályokat.

Milyen eszközökkel épül fel egy automatizált számlafeldolgozó rendszer?

Az automatizált számlafeldolgozás négyféle alapra építhető: a könyvelő- vagy számlázóprogram beépített NAV-importjára, kész, havidíjas számlafeldolgozó szoftverre, egy ERP-rendszer moduljaira vagy egy automatizációs platformon épített egyedi munkafolyamatra. A választást a számlák mennyisége, a meglévő rendszerek és a kivételek aránya dönti el.

Az egyedi munkafolyamatnál a legfontosabb tervezési elv a modellfüggetlenség. 2026 szeptemberében szinte hetente jelenik meg új modell új árazással, ezért a kinyerést végző modell legyen cserélhető alkatrész, amelyet egy beállítás átírásával lecserélhetsz. Az ellenőrzési szabályok, a jóváhagyási lánc és a könyvelői export maradjon a modelltől független kódban, mert ezek a te folyamatod részei, nem a gyártóé.

Az n8n fair-code licencű (Sustainable Use License) automatizációs platform, amely saját szerveren és felhőszolgáltatásként is futtatható, 1 500-nál több integrációval. A 2026. augusztus 25-én kiadott 2.37.0-s verziótól az adminisztrátor példányszinten kezelheti a hitelesítő adatokat, ami megkönnyíti, hogy a NAV technikai felhasználó kulcsait központilag és szűk körben tartsd. A Zapier vagy a Make ugyanerre szintén alkalmas. Bármelyiket választod, a buktatók ugyanazok: a duplikált számlák (ugyanaz a számla a NAV-ból, e-mailben és papíron is megérkezik), a kihagyott árnyéküzem, a túl széles jogosultságok és az, ha a könyvelő csak az élesítés után értesül a változásról.

Miben segít a Convergo?

A Convergo a számlafeldolgozás automatizálását a folyamat felől közelíti meg, nem a modell felől. Egy AI-felmérés során közösen megnézzük, hány számla érkezik hozzátok és mennyi munkát visz el ma a feldolgozás, majd a könyvelőddel egyeztetve eldöntjük, elég-e a meglévő szoftverek beállítása vagy érdemes saját megoldást építeni. Ha az utóbbi, a dokumentumfeldolgozás és OCR, a workflow automatizáció, valamint az Odoo ERP és integrációk szolgáltatásunk keretében felépítjük a NAV-lekérdezést, a kinyerést, a jóváhagyási láncot és a könyvelői átadást, árnyéküzemmel és méréssel. Az első lépés egy ingyenes egyeztetés, amelyen kiderül, nálatok hol a legnagyobb a megtakarítási lehetőség.