A magyar CFO-k 36%-a automatizálja a bejövő számlák felét, 62% pedig további automatizálást tervez (PwC HU, 2025). Három integrációs út létezik: API, middleware (iPaaS) és RPA. A meglévő rendszereid döntik el, melyik való hozzád. A NAV Online Számla validációja 2025. szeptember 15-től szigorodott: 15 figyelmeztetés blokkoló hibává vált (KPMG HU). Egy magyar esettanulmányban a számlánkénti költség 14-20 euróról 2-5 euróra csökkent (Manutan HU). 2030. július 1-től az EU-n belüli B2B ügyletekre kötelező a strukturált e-számla (Európai Bizottság, ViDA).
A számlaautomatizálás önmagában fél megoldás. Ha a szoftver nem beszél az ERP-eddel, a könyvelőprogrammal és a NAV-val, a nyert időt visszaeszi a kézi átgépelés. A PwC 2025-ös hazai pénzügyi vezetői felmérése szerint a magyar CFO-k 36%-a dolgozza fel automatizáltan a bejövő számlák több mint felét. A többség tehát még félúton áll. Ebben a gyakorlati útmutatóban végigvesszük, hogyan tervezd meg a számlafeldolgozás integrációt úgy, hogy egyszerre feleljen meg a valós idejű NAV-adatszolgáltatásnak és a 2030-as uniós e-számla-elvárásoknak. Konkrét döntési mátrixot, magyar költségadatokat és lépésről lépésre bevezetést kapsz.
Az integráció nélkül a szoftver csak sziget marad
Egy különálló számlafeldolgozó szoftver kevesebbet ér, mint hinnéd: a valódi megtérülés az integrációból jön. 2025-ben a magyar KKV-k mindössze 57,44%-a ért el alap digitális intenzitást, szemben a 72,91%-os EU-átlaggal az Európai Bizottság adatai szerint. A sziget-megoldás kézi átgépeléshez és adatvesztéshez vezet.
Gondolj bele a napi működésbe. Az OCR vagy AI kiolvassa a számlát, de az adat egy külön felületen marad. Valakinek onnan át kell emelnie az ERP-be, a főkönyvbe és a NAV felé. Minden kézi lépés hibaforrás és időveszteség.
A ControlliQ-nál azt látjuk, hogy a leggyakoribb kudarcok nem a kiolvasásnál, hanem az adatátadásnál keletkeznek. A szoftver jól olvas, de nincs összekötve. Ilyenkor a rejtett Excel-káosz egyszerűen átköltözik egy új felületre.
A KSH szerint 2025-ben a hazai vállalkozások 61%-a rendelkezett legalább alapszintű digitális fejlettséggel, és közel felük felhőt használt. Az alap tehát megvan. A hiányzó láncszem szinte mindig a rendszerek közötti összekötés. Erről szól a számlafeldolgozás automatizálásának teljes folyamata is.
Milyen integrációs módot válassz: API, middleware vagy RPA?
Három integrációs úton indulhatsz: API, middleware (iPaaS) vagy RPA. A választ a meglévő rendszereid döntik el. Egy 2025-ös DocuClipper-összesítés szerint a válaszadók 68%-a még mindig kézzel viszi be a számlákat az ERP-be. Pontosan ezt a kézi lépést szünteti meg a jól megválasztott integráció.
Nincs univerzális helyes válasz. Mindhárom módszernek megvan a helye, és gyakran vegyesen érdemes használni őket. Nézzük, mikor melyik való hozzád.
Mikor válassz API-integrációt?
Az API a legtisztább megoldás: a két rendszer közvetlenül, valós időben beszél egymással. Akkor válaszd, ha a könyvelőprogramod vagy ERP-d (például SAP, Kulcs-Soft, Novitax) dokumentált API-t kínál. Az API stabil, gyors és jól naplózható. Cserébe fejlesztői erőforrást igényel a beállítása.
Mikor elég a middleware vagy iPaaS?
A middleware (iPaaS-platform) köztes réteg, amely több rendszert köt össze anélkül, hogy mindegyikhez egyedi kódot írnál. Akkor jó, ha sok forrásból érkeznek számlák, vagy több szoftvert kell összehangolnod. Kész konnektorokkal dolgozik, ezért gyorsabban élesíthető, mint egy nulláról írt integráció.
Mikor indokolt az RPA?
Az RPA (robotizált folyamatautomatizálás) akkor jön szóba, ha egy rendszernek nincs használható API-ja. A robot úgy kattint és gépel a felületen, mint egy ember. Gyorsan bevezethető, de törékenyebb: ha a szoftver felülete változik, a robot elakad. Áthidaló megoldásnak kiváló, tartós architektúrának kevésbé.
A gyakorlati sorrend egyszerű. Először API-t keress, ha nincs, jöhet a middleware, és csak végső esetben az RPA. A szállítói számlák automatizálásáról külön írásban is találsz döntési szempontokat.
Hogyan kösd össze a rendszert a NAV Online Számlával?
A NAV Online Számla integrációja valós idejű XML-adatszolgáltatást jelent. 2025. szeptember 15-től a NAV validációja szigorodott: 15 korábbi figyelmeztetés blokkoló hibává vált a KPMG adóhírlevele szerint. Hibás XML esetén az adat el sem jut az adóhatósághoz, ezért az integrációnak előre validálnia kell a formátumot.
Ez a szigorítás megváltoztatja a tervezés logikáját. Régen egy hibás mező is átment figyelmeztetéssel. Ma ugyanaz a hiba blokkol. Az integrációdnak tehát nem elég adatot küldenie: ellenőriznie kell, mielőtt küld.
Mit jelent ez a gyakorlatban? A számlafeldolgozó rendszer kiolvassa az adatokat, összeveti a törzsadatokkal, és csak érvényes XML-t enged tovább. A token- és aláírás-kezelést (SHA3-512) a rendszer automatikusan intézi. A NAV-integráció alap beállítása általában néhány fejlesztői nap, a teljes AP-folyamat pedig ennél több.
Egy jó integráció itt kettős védelmet ad. Egyrészt csökkenti a NAV-elutasítás kockázatát. Másrészt a hibás számlát még bejövő oldalon megfogja, mielőtt a főkönyvbe kerülne. A megfelelőségi részletekről bővebben az adatbiztonság és megfelelőség írásunkban olvashatsz.
Mit jelent a ViDA és az e-számla 2030 az integrációdra?
A ViDA-csomag 2025. április 14-én lépett hatályba, és 2030. július 1-től az EU-n belüli B2B ügyletekre kötelezővé teszi a strukturált e-számlát az Európai Bizottság szerint. Az EN 16931 szabvány lesz a közös mérce. Ha most építesz integrációt, erre a jövőbeli elvárásra is érdemes tervezned.
Magyarországon a szektorális kötelezettségek már most élnek. 2025. július 1-től a nem lakossági villamosenergia- és földgázszámlák kizárólag elektronikus formában állíthatók ki a MEKH szabályozása szerint. A kör fokozatosan bővül.
Miért számít ez az integrációnál? Mert kétféle megfelelést kell egyszerre kiszolgálnod. A NAV valós idejű adatszolgáltatását ma, és a strukturált uniós e-számlát 2030-tól. Az az integráció, amely csak a mai NAV-formátumra épül, néhány éven belül újratervezésre szorulhat.
Az okos megközelítés a strukturált adat. Ha a számla adatai már most rendezett, gépi olvasásra kész formában állnak, a jövőbeli szabványokhoz jóval könnyebb illeszkedni. Ez az OCR és az AI-alapú számlafeldolgozás közötti egyik lényegi különbség is.
Mennyit spórolsz a jól integrált számlafeldolgozással?
A jól integrált számlafeldolgozás a legnagyobb megtakarítást a számlánkénti költségen hozza. Egy magyar Manutan-esettanulmány szerint a költség 14-20 euróról 2-5 euróra csökkent számlánként. Ez nagyságrendileg 70–80% megtakarítás, kézi átgépelés és hibajavítás nélkül. A megtakarítás forrása szinte teljesen az integrált, érintés nélküli feldolgozás.
A nemzetközi tapasztalat hasonló nagyságrendet mutat: a kézi feldolgozás lényegesen drágább, mint az automatizált. A pontos érték cégenként változik, de az irány egyértelmű: a kézi lépések a legdrágábbak.
A költség csak az egyik dimenzió. A másik a hónapzárás sebessége és a hibaarány. Ha a rendszer egyben validál és könyvel, a késői hibajavítás és a duplikált fizetés kockázata is csökken. A teljes megtérülési logikát az AI-bevezetés megtérülése a pénzügyben cikkben számoljuk végig.
Egy fontos figyelmeztetés. A megtakarítás nem a szoftver árlistájából jön, hanem a folyamatból. Egy drágán megvett, de rosszul integrált eszköz nem hozza ezeket a számokat. Az integráció minősége dönt.
Bevezetés lépésről lépésre
Az integrációt érdemes pilottal indítani, nem egyszeri, teljes átállással. Egy 2025-ös DocuClipper-összesítés szerint egy számla kézi feldolgozása átlagosan 14,6 napig tart, míg automatizáltan mindössze 3-5 nap. A különbség nagyrészt az integráció mélységén és a folyamat kiforrottságán múlik. Egy jól ütemezett bevezetés reális célt tűz ki.
Így épül fel egy reális bevezetés:
- Mérd fel a rendszereidet. Nézd meg, melyik szoftverednek van API-ja, és melyikhez kell middleware vagy RPA.
- Válassz egy szűk pilot-kört. Egy beszállító vagy egy számlatípus elég a kezdéshez. Így gyorsan tanulsz.
- Kösd be a NAV-validációt. Már a pilotban ellenőrizd az XML-t, hogy a szigorúbb szabályok ne okozzanak meglepetést.
- Mérj előtte és utána. Rögzítsd a számlánkénti időt, költséget és hibaarányt. E nélkül nem látod a megtérülést.
- Skálázz fokozatosan. Ha a pilot számai jók, bővítsd további beszállítókra és számlatípusokra.
Ez a megközelítés összhangban van azzal, amit a kontrolling AI-feladatok kapcsán is javaslunk: kis lépés, mérhető eredmény, aztán skálázás.
Gyakran ismételt kérdések
Hogyan integrálható a számlaautomatizálás a NAV Online Számla rendszerrel?
A NAV-integráció valós idejű XML-adatszolgáltatással működik, token és SHA3-512 aláírás mellett. 2025. szeptember 15-től a validáció szigorodott: 15 korábbi figyelmeztetés blokkoló hibává vált a KPMG szerint. A jó integráció ezért küldés előtt validál, hogy a hibás adat ne akadjon el az adóhatóságnál.
Milyen könyvelőprogramokkal és ERP-kkel kompatibilis a szoftver: API vagy middleware kell?
A választ a meglévő rendszered dönti el. Ha van dokumentált API-ja (például SAP, Kulcs-Soft, Novitax), az a legtisztább út. Ha nincs, middleware (iPaaS) köti össze kész konnektorokkal, végső esetben pedig RPA. Egy 2025-ös DocuClipper-összesítés szerint a válaszadók 68%-a még mindig kézzel visz be számlát.
Kötelező-e az e-számla 2026-ban Magyarországon?
Általánosan még nem, de szektorálisan igen. 2025. július 1-től a nem lakossági villamosenergia- és földgázszámlák kizárólag elektronikusan állíthatók ki a MEKH szerint. Az EU-szintű, B2B ügyletekre vonatkozó strukturált e-számla 2030. július 1-től lesz kötelező az Európai Bizottság ViDA-csomagja alapján.
Mennyi idő egy számlafeldolgozás-integráció bevezetése?
A NAV-integráció alap beállítása egy tapasztalt fejlesztőnek jellemzően néhány nap. A teljes AP-folyamat integrációja ennél több, de pilottal gyorsan indul. Egy 2025-ös DocuClipper-összesítés szerint a kézi feldolgozás átlagosan 14,6 nap, automatizáltan 3-5 nap, ami reális cél jó integrációval.
Mi a különbség az API- és az RPA-alapú integráció között?
Az API közvetlenül, valós időben köti össze a rendszereket, stabilan és jól naplózhatóan. Az RPA a felületen kattint és gépel, mint egy ember, ezért felületváltozásnál törékeny. Az API a tartós megoldás, az RPA az áthidaló. A gyakorlatban először API-t keress, RPA csak végső esetben legyen.
- PwC Magyarország — Pénzügyi vezetői felmérés 2025 — (lekérés: 2026-07-04)
- KSH — Digitális világ / Információ-kommunikáció — (lekérés: 2026-07-04)
- Európai Bizottság — Digital Decade 2025 Hungary country report — (lekérés: 2026-07-04)
- Európai Bizottság — VAT in the Digital Age (ViDA) — (lekérés: 2026-07-04)
- MEKH (Magyar Energetikai és Közmű-szabályozási Hivatal) — Nem lakossági villamosenergia- és földgázszámlák elektronikus kiállítása 2025.07.01-től — (lekérés: 2026-07-04)
- KPMG Magyarország — Tax Alert 2025.09.02 (NAV validáció szigorítás) — (lekérés: 2026-07-04)
- Manutan Magyarország — Szállítói számlák kezelése, folyamatoptimalizálás — (lekérés: 2026-07-04)
- DocuClipper — Accounts Payable Statistics — (lekérés: 2026-07-04)

Támba Bence a Composite Solutions ügyvezetője (CEO). Célja, hogy a cégek AI-eszközökkel, automatizálással és egyedi szoftverfejlesztéssel minimalizálják a manuális munkát.
Támba Bence összes cikke →


