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

Szerző: Kovács András

Az eÁFA M2M az áfabevallás új logikája: tranzakciós adatok, egységes NAV adókódok, előzetes validáció. A 2.0-ás specifikáció stabilizálja a modellt.

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, amely 2027-es év eleji változásokra is kiterjed az ÁNYK új bevallásokra való kivezetése nyomán. 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.

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

A NAV az M2M-en érkező adatokon a beküldés pillanatában 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. Az eltérésekről a NAV ellenőrzéseit és warning-üzeneteit szinkron módon visszamutatja az adózónak, még a beküldés előtt. 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".

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ész specifikációt is. A 2.0-ás verzió legfontosabb tulajdonsága az adatmodell hosszú távú stabilizálása: az új struktúra már nem tartalmaz ÁNYK-mezőazonosítókat, így 2027. január 1. után, az ÁNYK kivezetésével változatlan formában használható marad.

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, az esedékességtől számított 15 napon belül beadott önellenőrzés mentesül az önellenőrzési pótlék alól.

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).

Hiánytalanul beadott M2M-analitika esetén az adóhatóság a későbbi ellenőrzés során nem kér többletadatot.

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ű:

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 2027 előtt?

Az eÁFA-rendszer (webes vagy M2M) használata várhatóan 2027. január 1-jétől kötelező az áfabevalláshoz, mert az ÁNYK 2026. december 31-én utolsó napjához ér. Konkrétan az eÁFA M2M választása viszont nem kötelező – a webes eÁFA is megoldás. Az M2M kifejezetten a közép- és nagyvállalatoknak, illetve könyvelőirodáknak ajánlott, ahol a tranzakciómennyiség és az adatstruktúra-komplexitás indokolja a rendszerintegrációt. Azonban kis vállalkozásoknak is hasznos, így nem kell újra meghozni manuálisan azokat a döntéseket, melyeket már könyvelő programban az áfa bevallás készítése előtt meghatározásra kerültek. 2027 előtt az átállás nem kötelező.

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ész specifikáció részletesebb adószakmai magyarázatokkal és bővített áfaanalitika-adattartalommal rendelkezik. Az adatstruktúra már nem tartalmaz ÁNYK-mezőazonosítókat, ezért 2027 után is változatlan formában használható – ez stabilizálja a fejlesztési befektetést. A 2.0 előzetes tervek szerint júliustól tesztelhető, augusztustól váltja az 1.0-t.

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: önálló operációként fog megjelenni az eÁFA M2M rendszerben. A kommunikációs alap (XML, autorizáció, beküldési protokoll) azonos lesz az áfaanalitikával.

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.