eÁFA M2M 2.0: új mérföldkő az áfabevallásban

Szerző: Kovács András

Mi az eÁFA M2M 2.0, hogyan épül fel az adatalapú áfabevallás, és mire kell figyelni a NAV-adókódoknál, validációnál és bevezetésnél?

Az eÁFA M2M-mel kapcsolatban a piaci kommunikáció jelentős része még mindig a beküldési csatornáról szól: „kit ér el a NAV adatállománya", „kinek éri meg az átállás", „milyen kedvezményeket ad érte a NAV". Ez a megközelítés szakmailag félrevezet. Az eÁFA M2M nem csupán új beküldési csatorna, hanem az áfabevallás logikájának áthelyezése: a nyomtatványközpontú működésről a tranzakciós szintű adatokra, az egységes NAV adókód-logikára és a beküldés előtti validációra. A 2026. május 14-én publikált 2.0-ás interfész specifikáció ezt a modellt stabilizálja olyan formában, amelyet az ÁNYK fokozatos kivezetésétől és annak későbbi ütemezésétől külön kell kezelni. Ebben a cikkben végigvesszük, mit jelent ez a váltás működési szinten, és hogyan érdemes a vállalati átállást megközelíteni.

Mi az eÁFA M2M valójában?

Az eÁFA-rendszer 2024. február 1. óta működik, és kétféle hozzáférést kínál: a webes felületet és a gép–gép (M2M) kapcsolatot. A webes felület logikája a NAV rendszeréből származó adatforrások adatain alapul – egy felületen tölt ki az adózó (vagy hagyja jóvá a NAV által előre biztosított) adatokat majd a bevallástervezet áttekintése után beküldi azt. Az M2M ezzel szemben nem felület, hanem adatfolyam: a vállalat saját rendszereiből származó, strukturált adatok XML alapú adatszolgáltatása, amely közvetlenül a NAV-hoz jut el. A különbség első ránézésre a jelenlegi áfa bevallások módszerét tekintve technikai – de a valódi különbség logikai. Az M2M-ben az áfabevallás nem egy „kitöltött űrlap", hanem az áfaanalitika strukturált kimenete. A bevallás sorai (07-es, 66-os, 69-es stb.) az adózó által átküldött tranzakciós tételekből, NAV-féle standardTaxCode-okkal kódolva, automatikusan képződnek. A folyamat súlypontja a beküldésről az adatelőállításra és az adatminőségre helyeződik át.

A három strukturális váltás

Az eÁFA M2M modellje három, egymást támogató pilléren áll. Ezek a NAV adóhatósági működésének új, adatvezérelt logikájába illeszkednek.

1. Tranzakciós szintű adatok

Az ÁNYK-bevallás aggregált összegeket vár: az adott bevallási sorra eső adóalap, illetve adó összegét. Az eÁFA M2M ehhez képest tranzakciós szinten várja az adatokat – minden számla, minden tétel külön sorként jelenik meg az áfaanalitikában, mellette az alapbizonylat azonosítójával, a partneradatokkal és további egyedi információkkal. Ez magasabb adatminőséget igényel, de cserébe nyomon követhetővé teszi a bevallás minden egyes elemét.

2. Egységes NAV adókód-logika

Az eÁFA M2M nem a vállalat belső adókódjait használja, hanem a NAV által definiált egységes standardTaxCode rendszerét. Az adókód megmutatja, hogy egy adott tétel melyik bevallássorba képződik le, és milyen adómértékkel. A NAV szempontjából ez azt jelenti, hogy ahány vállalkozás, immár nem annyi áfaanalitika-szerkezet – minden adózó ugyanabban a logikai struktúrában szolgáltat adatot. A vállalat oldalán ez a belső adókódolás és a NAV-féle kódok közötti egyértelmű leképezést (mapping) követeli meg.

Hogyan készül el a gyakorlatban a belső áfakódok és a NAV standard adókódok megfeleltetése, azt lépésről lépésre, a leggyakoribb kivételekkel az eÁFA-átállásról szóló cikksorozatunk 4. része mutatja be.

3. Előzetes, többszintű validáció

A NAV az M2M-en érkező adatokon többlépcsős ellenőrzést végez. Az áfaanalitika tételeit összeveti a saját adatbázisaiból származó információkkal: az online számla adatszolgáltatással, a pénztárgép-adatokkal és a vám-árunyilatkozat feldolgozó rendszerrel. A feldolgozás aszinkron: a hibákat és a figyelmeztetéseket a NAV a benyújtás előtt jelzi vissza, a kockázatelemzési eltérések visszajelzése pedig a NAV tájékoztatása szerint 3–5 napot is igénybe vehet. A 2.0-ás specifikáció kifejezetten ezt a réteget mélyíti tovább: a NAV maga jelezte, hogy „az eÁFA M2M rendszer egyik legnagyobb előnyét a validációk mennyisége és ügyféli értéke jelenti".

Hogy a NAV visszajelzései közül melyik akadályozza a benyújtást, és hogyan kereshető vissza a hibás tétel, azt a sorozat 7. része részletezi. Az egyes üzenetek az eÁFA-hibakódok adatbázisában kereshetők.

A 2026. májusi mérföldkő: a 2.0-ás interfész specifikáció

A NAV 2026. március 9-én publikálta az eÁFA M2M 2.0-s XSD-sémáját, majd 2026. május 14-én a hozzá tartozó interfészspecifikációt. Az új struktúra már nem tartalmaz ÁNYK-mezőazonosítókat, ezért nem kötődik az ÁNYK mezőszerkezetéhez; az ÁNYK kivezetése önmagában nem kényszerít új sémaváltást.

A 2.0 tartalmilag is mélyebb. A NAV közleménye szerint a specifikáció „a korábbihoz képest részletes adószakmai magyarázatokat is tartalmaz, amely az eddiginél jobban támogatja az implementációt".

A bevezetés legnehezebb része: adatok és adókódok

Az eÁFA M2M bevezetésének legnehezebb része jellemzően nem az interfész, hanem az adólogika rendezése. Ha az adókódok nem következetesek, a kivételek nincsenek szabályozva, vagy a manuális javítások nincsenek dokumentálva, a rendszer ezeket a hiányosságokat gyorsan felszínre hozza.

Ez rövid távon többletmunkát jelenthet, de valójában előny. Ahol ezek a problémák láthatóvá válnak, ott lehet először valóban egységes és ismételhető bevallási működést kialakítani.

Miért nem pusztán önálló IT projekt?

A közép- és nagyvállalati gyakorlatban az eÁFA M2M bevezetése nem egy új interfész fejlesztésről szól csupán. A folyamat súlypontja máshol van: a vállalat ERP- vagy könyvelő rendszere (jellemzően SAP, Oracle, Microsoft Dynamics vagy egyedi fejlesztés) határozza meg, hogy milyen áfaanalitika, milyen adókódolás és milyen kontrollpontok mellett képződnek azok az adatok, amelyek alapján az M2M XML összeállítható. A globális ERP-rendszerek ráadásul többnyire zárt, központilag verziókövetett szoftverek. Egy magyar adózási sajátosság – például az eÁFA M2M XSD egy mezője – kedvéért nem fognak egyetlen leányvállalat miatt egyedi fejlesztés készíteni, és a helyi szintű módosítások jellemzően költségesek, lassúak. A vállalat számára tehát ritkán életszerű megoldás közvetlenül az ERP-t M2M-képessé tenni.

A piaci gyakorlat ezért két fő stratégiát különít el:

Belső fejlesztés – a vállalat IT-csapata vagy egy beszállító egyedileg megvalósítja az ERP-ből az M2M XML-t generáló kódot. Előny: maximális testreszabhatóság. Hátrány: minden NAV-verziófrissítés saját fejlesztési feladat, a warning-kezelést is házon belül kell megoldani, és az adótartalom-helyességéért is saját szakértőre van szükség.

Külső Tax-Tech middleware – egy, az ERP és a NAV közé ékelődő, kulcsrakész szoftver (mint például a SimplyX). Az ERP exportált adataiból generálja a valid M2M XML-t, kezeli a verziófrissítéseket, és vizuális dashboardon jeleníti meg a NAV warning-üzeneteit, tömeges áttekintési és kezelési lehetőséggel. A megoldás mögött jellemzően egy adó- és technológiai szakértőkből álló csapat áll.

A középső réteg logikailag azért működik jól, mert pontosan azt a két problémát oldja meg, amit a vállalatok közvetlen ERP-fejlesztésben nehezen tudnak: a NAV oldalán változó specifikációkhoz való folyamatos igazodást, és a warning-üzenetek megfelelő és hatékony kezelését.

A jelenlegi adózói kedvezmények.

Az eÁFA M2M-hez ma valóban tartoznak konkrét, jogszabályban rögzített kedvezmények:

Az eÁFA-rendszer használata esetén az adózó mentesül a belföldi összesítő jelentés (M-lap, K-lap) benyújtása alól.

Az M2M-en benyújtott bevallás önellenőrzése mentesül az önellenőrzési pótlék alól, ha a bevallás benyújtásától, de legkésőbb az esedékességtől számított 15 napon belül történik (Art. 211. § (3) c)).

Megbízható minősítésű adózók M2M-en beadott áfabevallására 15 napos ellenőrzési moratórium érvényes (kivéve súlyos szabálytalanságok).

A reális üzleti érv az eÁFA M2M mellett nem a mai kedvezmény-csomag, hanem a fenti strukturális váltás: a tranzakciós szintű adatkezelés, az egységes adókód-logika, az előzetes validációk és a 2.0-val stabilizált, hosszú távú adatmodell.

Hogyan érdemes elindulni?

A jól felépített eÁFA M2M átállás nem önálló IT-projekt, hanem négy egymásra épülő munkafázis – amelyekből csak az utolsó technikai jellegű:

Az átállás teljes menetét a csatornaválasztástól a próbabevallásig az eÁFA-átállás a gyakorlatban cikksorozat vezeti végig, nyolc egymásra épülő részben.

Vezetői szemszögből: mit lát a CFO és a pénzügyi vezető?

Adatminőség – az előzetes validációk kényszerítik a forrásrendszer (ERP, számlázó, pénztárgép) adatminőségének rendben tartását. A bevallás minősége többé nem külön folyamat, hanem a tranzakciós adatminőség közvetlen kimenete.

Auditálhatóság – minden bevallás minden tétele visszavezethető egy konkrét bizonylatra, NAV adókódra és validációs eredményre. Az ellenőrzéskor nem kell „rekonstruálni", hogy mi alapján állt elő egy bevallási sor.

Skálázhatóság – tranzakciómennyiség növekedése esetén az M2M-modell lineárisan skálázható, manuális kontrollpontok lényeges növelése nélkül.

Ez a fajta átláthatóság különösen fontos egy olyan piacon, ahol a megfelelés egyre inkább digitális működési képesség kérdése. A szervezetek nem egyszerűen új NAV-csatornákat keresnek, hanem olyan rendszereket, amelyekben a megfelelés kiszámítható és kevésbé személyfüggő.

Gyakori kérdések

Kötelező-e az eÁFA M2M-re átállni az új javaslat szerint?

A NAV 2026. október 15-én fokozatos, bevallásonkénti és űrlaponkénti ÁNYK-kivezetést javasolt. A legnagyobb cégek eÁFA-átállása 2027 folyamán lenne kötelező, de a pontos kezdőnapot nem közölték: 2027. január 1. nem rögzített. Az áfabevallók többségének, például a kkv-knak 2028. január 1. a javasolt kezdőnap. Az szja- és tao-bevallások 2027-ben még ÁNYK-n is benyújthatók maradnának. Ez NAV-javaslat, nem végleges jogszabály; az érintetti kör és a pontos időpontok további hivatalos közlést igényelnek. A közlemény az eÁFA-rendszerre való átállásról szól; az eÁFA M2M választását önmagában nem teszi mindenki számára kötelezővé. A gépi kapcsolatot a volumen, az adatforrás és az automatizálási igény alapján érdemes mérlegelni.

Miben különbözik az M2M XML a hagyományos ÁNYK kitöltéstől?

Az ÁNYK egy űrlapot tölt ki: a felhasználó a bevallási sorokra aggregált összegeket ad meg. Az eÁFA M2M XML ezzel szemben tranzakciós szintű adatokat tartalmaz – minden számla, minden tétel külön sorként, NAV standardTaxCode-okkal kódolva. A bevallási sorok ebből képződnek a NAV oldalán. A kettő közötti különbség nem adatmennyiségi, hanem logikai: nem összesítést, hanem analitikát küldünk a bevallási főadatokkal egyidejűleg.

Mit változtat a 2026. május 14-én publikált 2.0-ás specifikáció?

A 2.0-s interfészspecifikáció részletesebb adószakmai magyarázatokat és bővített áfaanalitika-adattartalmat tartalmaz. A tesztkörnyezet 2026. július 1-jén, az éles rendszer 2026. augusztus 3-án állt át a 2.0-s verzióra; az 1.0-s XML az éles átállás óta nem használható.

Mit jelent, hogy „NAV standardTaxCode"?

Az áfaanalitikában minden tételt a NAV által egységesen definiált adókóddal kell ellátni. Az adókód meghatározza, hogy a tétel melyik áfabevallás-sorba kerül, és milyen adómértékkel. Ez a logika a NAV oldalán egységesíti az áfaanalitikákat – minden adózó ugyanabban a kódstruktúrában szolgáltat adatot, függetlenül attól, hogy a saját rendszerében belsőleg milyen adókódolást használ. A két kódrendszer közötti leképezés (mapping) a bevezetés egyik kulcsfeladata.

Saját fejlesztés vagy külső szoftver – melyik a jobb választás?

A többségnél a külső Tax-Tech middleware az életszerűbb választás. Nem azért, mert egyszerűbb, hanem mert ERP-k belső átalakítása aránytalanul drága és kockázatos egy magyar adózási sajátosság kedvéért. A middleware az ERP exportált adataiból generálja a valid M2M XML-t, kezeli a NAV verziófrissítéseit, és a warning-üzeneteket áttekinthető formában mutatja meg.

Mi lesz az A60-as adatszolgáltatással?

A NAV 2026. májusi közleménye szerint az A60-as adattartalom nem lesz az áfaanalitika része. A 2026. október 3-án közzétett séma ezt megerősíti: az összesítő nyilatkozat külön XML-ben, de az áfabevallással azonos eÁFA M2M-műveletekkel és API-logikával nyújtható be, a két beküldést a séma típusa különbözteti meg. Az A60-nak saját validációs üzenetei is vannak: 10 blokkoló hiba és 4 figyelmeztetés.

Honnan érhetők el a hivatalos műszaki dokumentációk?

A NAV az eÁFA M2M-mel kapcsolatos teljes műszaki dokumentációt – XSD-sémák, interfész specifikáció, példa XML-ek, változási naplók – nyilvánosan publikálja a GitHub-on: github.com/nav-gov-hu/eVAT. A fejlesztői kérdések, ötletek és észrevételek is itt, a Discussions felületen kerülnek megválaszolásra, közvetlenül a NAV szakembereitől.

Források

NAV eVAT GitHub: interfészspecifikáció a 2.0-ás verzióhoz (2026. május 14.)

NAV eVAT GitHub: az eÁFA XSD 2.0 változások ütemezése

NAV: XSD-változások az eÁFA 2.0 verzióban (PDF)

NAV: Az eÁFA gép-gép kapcsolat

NAV: eÁFA – az áfabevallás új lehetősége

Az adózás rendjéről szóló 2017. évi CL. törvény, 154. § (5)–(6) és 211. § (3) c)

NAV eVAT GitHub: az A60 séma publikálása