Élesben az eÁFA M2M 2.0: mi változott az augusztus 3-i átállással?

Szerző: Kovács András

2026. augusztus 3-án élesedett az eÁFA M2M 2.0, párhuzamos üzem nélkül. Mi változott a sémában, mit generál a rendszer, és mit kell átnézni a saját rendszerben.

Az eÁFA M2M 2.0 nem egyszerű technikai frissítés, hanem valódi főverzióváltás. Az új verziót 2026. augusztus 3-án vezették be az éles rendszerben, párhuzamos üzem nélkül: azóta az 1.0-s formátum már nem használható.

A legfontosabb változás, hogy az új verzió elszakad az ÁNYK áfabevallási nyomtatványának szerkezetére épülő logikától. Az 1.0-s verzióban a melléklapokat egy általános, sheet — vagyis „lap” — nevű csomópont alatt kellett megadni, az egyes adatokat pedig az ÁNYK mezőazonosítói, az úgynevezett NavFieldId-k kapcsolták a nyomtatvány megfelelő mezőihez. A gépi interfész így lényegében az ÁNYK-nyomtatvány felépítését követte.

Az így létrejövő XML-struktúra rendkívül körülményes volt, és — bár az XML feldolgozása alapvetően gépi feladat — az állományok tartalmának emberi értelmezését és ellenőrzését is megnehezítette.

A 2.0-s verzió megszüntette ezt a közvetett leképezést. A melléklapok saját, a tartalmukat leíró csomópontokat kaptak, így az adatstruktúra már nem a nyomtatvány mezőire, hanem közvetlenül a közölt adatokra épül. Emiatt azoknak is módosítaniuk kell a meglévő integrációjukat, akiknek az 1.0-s beküldés eddig hibátlanul működött.

Az alábbi összefoglaló a NAV 214 oldalas interfészspecifikációja és az XSD-változáslista alapján mutatja be a legfontosabb szerkezeti és működési változásokat.

Kit érint, és kit nem

A hír első olvasásra riasztónak hathat, ám nem mindenki számára releváns. Az augusztus 3-i átállás közvetlenül azokat a vállalkozásokat, könyvelőirodákat és szoftverszállítókat érinti, amelyek az eÁFA M2M interfészen, vagyis gép–gép kapcsolaton keresztül készítik elő vagy nyújtják be az áfabevallást. Az általuk használt rendszereket a 2.0-s sémához kell igazítani.

Aki a webes eÁFA felületen készíti el a bevallását, vagy egyelőre ÁNYK-val dolgozik, annak ez a konkrét verzióváltás nem okoz azonnali változást. Az ÁNYK-t használók számára azonban ez csak átmeneti haladék: új bevallás 2026. december 31-ig nyújtható be ezen a csatornán, utána másik benyújtási módot kell választaniuk.

Ez nem jelenti azt, hogy minden könyvelőirodának saját M2M-integrációt kell fejlesztenie. Aki azonban az M2M használatát tervezi, annak már most érdemes ellenőriznie, hogy a választott szoftver támogatja-e a 2.0-s verziót.

Így zajlott az átállás

A tesztkörnyezet 2026. július 1-jén állt át a 2.0-s verzióra. Ettől kezdve az api-test.eafa.nav.gov.hu kizárólag a 2.0-s séma szerint összeállított állományokat fogadta, az 1.0-s formátummal végzett tesztek pedig hibára futottak.

A NAV július 20. és 24. között a fejlesztői közösség bevonásával mérte fel a szoftverek felkészültségét. A 48 válaszadóból mindössze 9 jelezte, hogy elkészült a szükséges fejlesztésekkel. További 3 válaszadó augusztus 20-ig vállalta a befejezést, 36-an pedig hosszabb felkészülési időt kértek.

A NAV ennek ellenére kitartott az augusztus 3-i éles átállás mellett, amelynek időpontját július 31-én, mindössze három nappal korábban erősítette meg. A döntést azzal indokolta, hogy az 1.0-s és a 2.0-s verzió párhuzamos működtetésére nem látott reális lehetőséget, a tesztkörnyezetben pedig már sikeres teszteket és működő megoldásokat is látott.

Ami a 2.0 mögött van: az interfész elszakad a nyomtatványtól

A 2.0 szakít az ÁNYK nyomtatványlogikájával

Az eÁFA M2M első verziójának adatstruktúrája még az ÁNYK-nyomtatványok felépítését követte. A melléklapokat egy általános, sheet — vagyis „lap” — nevű csomópont alatt kellett megadni, az egyes adatokat pedig ÁNYK-mezőazonosítók, az úgynevezett NavFieldId-k rendelték a nyomtatvány megfelelő mezőihez. A fejlesztőnek ezért az adat jelentése mellett azt is tudnia kellett, hogy az az ÁNYK melyik lapján, sorában és mezőjében szerepel.

A 2.0-s verzió ezt a nyomtatványközpontú megközelítést szüntette meg. A NAV megfogalmazása szerint az adatstruktúra így „önállóbbá, fenntarthatóbbá és a gépi feldolgozás szempontjából koherensebbé” válik. Az általános sheet csomópont helyett minden melléklap saját, a tartalmát leíró csomópontot kapott.

A változás nem merül ki a szerkezet átalakításában: a korábbi ellenőrzési szabályokat is újak váltották fel. Emiatt egy 1.0-s formátumban hibátlan állomány nem alakítható át a mezők egyszerű átnevezésével. Az XML-t az új szerkezet és az új ellenőrzési szabályok szerint kell előállítani.

A 2.0 ugyanakkor egyszerűsítést is hozott: megszűnt a bevallás kiegészítő adatait tartalmazó declarationAdditionalData csomópont. Ezt az adatcsoportot a beküldő rendszernek már nem kell külön előállítania, mert a szükséges adatokat az eÁFA M2M számítja ki a beküldött analitika alapján. Az automatizmus azonban csak helyes és hiánytalan analitikából tud megfelelő eredményt előállítani.

A vámhatósági partnerazonosítót, vagyis a VPID-t tartalmazó vpid mező helye is megváltozott. Korábban a melléklapokat összefogó sheetList alatt szerepelt, a 2.0-ban viszont a bevallás alapadatait tartalmazó declarationInfo csomópont alá került. A régi helyén megadott értéket a rendszer már nem dolgozza fel.

Melléklapok: mit tölt ki a rendszer, és mi marad az adózó feladata?

A 2.0-s verzió több számítást is átvállal, de ez nem jelenti azt, hogy a melléklapokat automatikusan elkészíti. Az interfészspecifikáció 68. oldala szerint a melléklapokat összefogó sheetList csomópont, valamint az alatta szereplő nyolc melléklap-csomópont egyaránt opcionális.

A rendszer mindössze egy melléklapot állít elő automatikusan: a 03-as lapot, vagyis a közvetett vámjogi képviselő importonkénti nyilatkozatát, amennyiben ennek feltételei teljesülnek. A többi melléklapot szükség esetén továbbra is az adózónak kell megadnia.

Az alábbi táblázat a 2.0-s sémában kezelt melléklapokat, a hozzájuk tartozó XML-csomópontokat és azok legfontosabb adattartalmát foglalja össze. A 03-as melléklap kivétel: ezt nem a beküldő rendszer adja meg a sheetList részeként, hanem az eÁFA M2M állítja elő a beküldött analitikából, ha teljesülnek a szükséges feltételek.

A fordított adózású melléklapokon a vámtarifaszámot (customsTariffNumber) egy előre meghatározott értékkészletből kell kiválasztani. Ilyen például az árpa 1003-as, a búza (ideértve a kétszeresnek nevezett búza–rozs keveréket) 1001-es, a melegen hengerelt rúd pedig 7213-as vámtarifaszáma és így tovább. A vámtarifaszámhoz tartozó terméknevet az eÁFA M2M automatikusan tölti ki.

A mennyiség (quantity) a sémában opcionális mezőként szerepel, a kitöltése azonban a hibridvetőmag-jelölés (hybridSeed) értékétől függ. Ha a termék hibrid vetőmag, vagyis a hybridSeed értéke true, akkor a mennyiséget nem szabad megadni. Ha az érték false, a quantity kitöltése kötelező. A hybridSeed és a mértékegység (unitOfMeasure) minden esetben kötelező; utóbbinál a kg, m3 és MWh értékek használhatók.

Az A88-as mellékletnél a vevő országának nevét nem kell külön megadni: az eÁFA M2M azt a vevő országkódja (customerCountryCode) alapján tölti ki. Az országkódot zárt értékkészletből kell kiválasztani, amely az uniós tagállamok kódjai mellett az XI kódot is tartalmazza. Az XI Észak-Írországot jelöli, amelyet az uniós áfaszabályok az áruforgalom tekintetében különleges módon kezelnek.

Új mezők

Az analitika új mezői

Az áfaanalitika egyes tételeit leíró vatAnalyticsItem több új elemmel bővült. Ezek közül különösen könnyű félreérteni az invoiceModificationOrCancellation mezőt (specifikáció 50. oldal).

A forrásbizonylat típusát meghatározó sourceDocumentType értékkészlete is bővült. Az INVOICE, RECEIPT, CUSTOMS_DECLARATION és OTHER értékek mellé bekerült a DAILY_SUMMARY, amely a pénztárgép napi zárását jelöli. Ezzel az értékkel jelennek meg az Online Pénztárgép és az eNyugta rendszeréből származó nyugták napi szinten összesített formában. Az adóügyi nap ebben az esetben a napi nyitástól aznap éjfélig tartó időszak.

Az adózási adatokat tartalmazó taxInformation az indirectCustomsRepresentative adatcsoporttal is bővült, amelyben az importáló adószáma, az importerTaxNumber adható meg. A mezőt akkor kötelező kitölteni, ha a tétel importhoz kapcsolódik, és a közvetett vámjogi képviselő engedményezés alapján gyakorolja a levonási jogot. Ilyenkor az importáló adószámának nyolc számjegyű törzsszámát kell megadni, áfakód és megyekód nélkül.

Az eÁFA M2M ezt az adatot is felhasználja a 03-as melléklap automatikus előállításához. A melléklap azonban nem önmagában az importerTaxNumber kitöltésétől jön létre: ehhez a specifikációban meghatározott további feltételeknek is teljesülniük kell.

Új mező a 04-es önellenőrzési mellékleten

A nonStandardAllowanceCalcReason az önellenőrzési pótlék általánostól eltérő számításának okát jelöli. Akkor kell megadni, ha a pótlék alapját vagy összegét valamely kivételes szabály miatt nem az általános módon kell meghatározni.

A mezőben 01 és 09 közötti kód használható. A 01–08 értékek egy-egy meghatározott jogszabályi eltérési okot jelölnek, a 09 pedig azt, hogy ezek közül egyszerre több is fennáll.

Mit kell átnézni a saját rendszerben?

A könyvelői és a fejlesztői feladatok eltérnek, de közös kiindulópontjuk a beküldött analitika pontossága és teljessége.

Könyvelői oldalról

A 03-as melléklapot, valamint a korábban a declarationAdditionalData csomópontban közölt kiegészítő adatokat a 2.0-ban az eÁFA M2M állítja elő a beküldött analitika alapján. Ez könnyítés, de az adatminőségi problémákat nem oldja meg: a rendszer nem pótolja a hiányzó azonosítókat, és nem javítja ki a téves adópozíciót.

Egy hiányzó importőri adószám vagy hibás adópozíció ezért a rendszer által előállított adatokra is hatással lehet, illetve ellenőrzési hibát okozhat. Könyvelői szempontból az egyik legfontosabb kérdés tehát az, hogy milyen forrásból készül az analitika, ki ellenőrzi, és ki felel annak tartalmáért.

A fordított adózású ügyleteknél az adókód és a melléklap kitöltése sem kezelhető egymástól függetlenül. Bizonyos standard adókódok használata esetén a hozzájuk tartozó melléklapot is meg kell adni, amit az eÁFA M2M külön ellenőrzési szabályokkal vizsgál. A séma szerint opcionális melléklap így a bevallás tartalmától függően kötelezővé válhat.

A szoftverszállító felkészültségét néhány konkrét kérdéssel lehet ellenőrizni:

Támogatja-e a program a 2.0-s sémát, és pontosan melyik verziótól?

Az invoiceModificationOrCancellation mezőt kizárólag az MP31 adókódhoz kapcsolva kezeli, vagy általánosan minden módosító és érvénytelenítő számlánál?

A fordított adózású melléklapokon a customsTariffNumber értékét adja át, vagy még a korábbi tervek szerinti terméknevet várja?

Megszüntette-e a NavFieldId-alapú leképezést?

Kezeli-e a melléklapok és az analitika közötti új ellenőrzési szabályokat?

Milyen tesztekkel igazolta, hogy a 2.0-s állományokat az éles eÁFA M2M rendszer elfogadja?

A nemleges vagy bizonytalan válasz is fontos információ. Ha nincs tesztelt programverzió és vállalt bevezetési időpont, a kockázat már nem pusztán technikai, hanem ütemezési is. Az ÁNYK 2026. december 31-én leáll, így 2027-től már nem használható tartalék benyújtási csatornaként (NAV-tájékoztató az ÁNYK kivezetéséről).

Fejlesztői oldalról

A NavFieldId-alapú leképezést meg kell szüntetni. A saját adatmodell elemeit közvetlenül a 2.0-s séma beszédes csomópontjaihoz kell rendelni.

A vpid mezőt a declarationInfo csomópont alatt kell előállítani.

A declarationAdditionalData csomópont előállítása elhagyható, mert az abban közölt adatokat a 2.0-ban az eÁFA M2M számítja ki.

Az invoiceModificationOrCancellation értékét az adókódhoz, nem pedig önmagában a bizonylat módosító vagy érvénytelenítő jellegéhez kell kötni. A true érték kizárólag az MP31 adókóddal együtt használható.

A zárt értékkészleteket — többek között a vámtarifaszámokat, mértékegységeket, országkódokat és bizonylattípusokat — az aktuális XSD-hez és NAV-dokumentációhoz kell igazítani.

A melléklapok és az analitika közötti összefüggéseket külön tesztelni kell. Nem elegendő pusztán azt ellenőrizni, hogy az XML megfelel-e az XSD-nek.

Az 1.0-s teszteseteket felül kell vizsgálni, mert az új szerkezet mellett az üzleti ellenőrzési szabályok is megváltoztak.

Ami még hiányzik

A NAV a július 31-i közleményében két további segédanyagot ígért az átálláshoz: a 2.0-s XSD alapján elkészített minta XML-fájlokat, valamint egy gyakran ismételt kérdéseket összegyűjtő dokumentumot. A cikk 2026. augusztus 18-i lezárásakor egyik sem volt elérhető a NAV eVAT GitHub-tárházában. A tárházban található korábbi minta XML-ek még az 1.0-s sémára épülnek, ezért a 2.0-s fejlesztéshez nem használhatók változtatás nélkül.

További nyitott kérdés volt az A60 összesítő nyilatkozat gépi benyújtása. A NAV az augusztusra ígért sémát végül 2026. október 3-án tette közzé, a validációs listával együtt, egyelőre a GitHub-tárház külön fejlesztési ágán. Az A60 nem kap különálló interfészspecifikációt: a NAV az eÁFA M2M specifikációját egészíti ki vele.

A NAV az informatikai és fejlesztési kérdéseket az eVAT GitHub-tárház Discussions felületén fogadja. A jogértelmezést igénylő kérdéseket a NAV levélküldő oldalán lehet feltenni, az „eÁFA-felület használatával kapcsolatos jogi kérdések” tárgy kiválasztásával.

Kapcsolódó anyagok

Kapcsolódó eszközök és útmutatók

A NAV visszajelzéseinek értelmezéséhez használható az eÁFA validációs üzenetek kereshető listája. Az adatbázis az interfészspecifikáció üzenetein kívül a NAV későbbi közleményeiben bejelentett változásokat és az A60 összesítő nyilatkozat üzeneteit is tartalmazza, súlyosság szerint szűrhetően.

Az XML XSD szerinti szerkezeti és formai ellenőrzésére szolgál az ingyenes eÁFA XML-ellenőrző. Az ellenőrzés helyben, a böngészőben fut, maga az XML-fájl nem kerül feltöltésre. A sikeres sémaellenőrzés ugyanakkor nem jelenti azt, hogy az állomány a NAV további üzleti ellenőrzésein is átmegy.

Az MP31 és a többi standard adókód a 232 elemű adókód-katalógusban kereshető vissza. A teljes lista CSV- és JSON-formátumban is letölthető.

Az eÁFA M2M működésének és bevezetési szempontjainak átfogó bemutatása az eÁFA M2M útmutatóban található.

További cikkek az átálláshoz

eÁFA M2M: mit kell rendbe tenni az átállás előtt? — adókódok, adatminőség és kontrollok az átállás előtt.

ÁNYK-kivezetés 2027: átállási ellenőrzőlista és ütemterv — mikor milyen döntést kell meghozni az ÁNYK kivezetéséig.

NAV M2M és az ÁNYK kivezetése: szakmai felkészülés 2027-re — az átállás következményei a könyvelői gyakorlatban.

Források

eÁFA M2M 2.0 interfészspecifikáció v1.1 (NAV, 214 oldal) — részletes mezőleírások, kitöltési szabályok, értéklisták és validációs szabályok.

XSD változások eÁFA 2.0 verzióban (NAV) — a verzióváltás összefoglalása, valamint a törölt, áthelyezett és átalakított adatelemek bemutatása.

Az eÁFA M2M 2.0 XSD-sémafájljai — a 2.0-s XML-állományok szerkezetét meghatározó sémafájlok.

Éles környezet 2.0-ás átállása: 2026. augusztus 3. — a NAV 2026. július 31-i bejelentése az éles átállásról.

Az eÁFA 2.0 tesztrendszeren elérhető — a tesztkörnyezet 2026. július 1-jei átállásának bejelentése.

eÁFA M2M 2.0 felkészültségi szavazás — a 2026. július 20. és 24. között megtartott fejlesztői felmérés.

Jogértelmezést igénylő kérdések

A jogértelmezést igénylő kérdések a NAV levélküldő felületén, az „eÁFA-felület használatával kapcsolatos jogi kérdések” tárgy kiválasztásával tehetők fel.