Élesben az eÁFA M2M 2.0: mi változott az augusztus 3-i átállással?
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óbb, mint amilyen a legtöbb könyvelőiroda számára valójában. Az augusztus 3-i váltás azt érinti, aki gép-gép kapcsolaton, vagyis az eÁFA M2M interfészen keresztül küldi be az áfabevallást. Akinek a bevallás a webes eÁFA felületen készül, vagy még ÁNYK-val dolgozik, annak a mostani átállás közvetlenül nem változtat a napi munkáján.
A halasztás lehetősége viszont véges. Az ÁNYK-val 2026. december 31-ig nyújtható be új bevallás, tehát ugyanez a kérdés néhány hónapon belül minden érintettnél előkerül — csak akkor már ÁNYK-tartalék nélkül. Aki most nézi végig a 2.0-s változásokat, az nem a jelen kényszerére készül, hanem az év végi határidőre.
Az átállás menete
A tesztkörnyezet előbb váltott: az api-test.eafa.nav.gov.hu 2026. július 1-je óta kizárólag a 2.0-s verzióval működik. Aki a nyáron még 1.0-val tesztelt, ott már akkor hibába futott. Az éles átállás dátumát a NAV július 31-én erősítette meg, egy héttel a határidő előtt.
A döntés nem előzmények nélküli. A hatóság július 20. és 24. között szavazást tartott a fejlesztői közösségben arról, mennyire látják felkészültnek a szoftvereiket. A 48 válaszadóból 9 jelezte, hogy elkészült a fejlesztéssel, 3 vállalta, hogy augusztus 20-ig elkészül, 36 pedig további felkészülési időt kért. A NAV a közleményében utalt is a visszajelzésekre, és két indokot adott a kitartás mellett: a párhuzamos fenntartásra nem látott reális lehetőséget, a tesztkörnyezetben pedig figyelemmel követte a sikeres teszteket és az elkészült programokat.
Ami a 2.0 mögött van: az interfész elszakad a nyomtatványtól
Az eÁFA M2M első verziója egy örökséget hozott magával. A melléklapokat a sheet nevű csomóponton keresztül kellett megadni, a mezőket pedig ÁNYK-mezőazonosítókkal (NavFieldId) hivatkozni. Egy gépi interfész tehát a papíralapú nyomtatvány szerkezetét másolta: aki fejlesztett rá, annak tudnia kellett, hogy egy adat melyik nyomtatványon, hányadik sorban, milyen azonosítóval szerepel.
A 2.0 ezt vezeti ki. A NAV megfogalmazása szerint a cél, hogy az adatstruktúra „önállóbbá, fenntarthatóbbá és a gépi feldolgozás szempontjából koherensebbé" váljon. A sheet csomópontot törölték, a melléklapok saját, beszédes nevű csomópontot kaptak, a rájuk vonatkozó validációk helyére pedig új szabályok léptek. Az utolsó pont könnyen elsikkad: egy 1.0-ban hibátlanul átment állomány nem attól akad el, hogy rossz benne az adat, hanem attól, hogy más szabály méri.
Kikerült a declarationAdditionalData csomópont is: a bevallás kiegészítő adatait ezentúl az eÁFA M2M rendszer számolja ki az analitikából. Egy mező helye pedig megváltozott. A vpid korábban a sheetList alatt szerepelt, a 2.0-ban a declarationInformation alá tartozik, és a régi helyen hagyott értéket a rendszer nem dolgozza fel.
A melléklapok: mit kell kitölteni, és mit generál a rendszer
Az automatizmus mértékét könnyű túlbecsülni. Az interfészspecifikáció 68. oldala szerint a sheetList csomópont opcionális, és a benne szereplő nyolc melléklap-csomópont mindegyike szintén az. Egyetlen melléklapot állít elő a rendszer: a 03-ast, vagyis a közvetett vámjogi képviselő importonkénti nyilatkozatát, ha fennállnak a feltételek. A többi az adózó dolga marad.
Az elnevezések önmagukban is jelzik az elmozdulást: nem sorszámozott lapok, hanem tartalom szerint nevesített adatcsoportok.
| Melléklap | Csomópont a 2.0-ban | Amit tartalmaz |
|---|---|---|
| 02 — Állatbetegség | animalDisease | Határozatszám, a határozat véglegessé válásának dátuma, a kártalanítás áfatartalma, az érvényesíthető halasztás összege. Csak akkor tölthető, ha az animalDiseaseDefermentIndicator értéke true. |
| 03 — Közvetett vámjogi képviselő nyilatkozata | — (a rendszer generálja) | Nem az adózó tölti. Akkor jön létre, ha a bevallási időszak 2025. március 1-jénél későbbi, az adópozíció levonható (DEDUCTIBLE), és az importáló adószáma (importerTaxNumber) töltött. |
| 04 — Önellenőrzés | selfCheckAttachment | Az aktuális bevallás önellenőrzési adatai — pótlékalap, pótlékösszeg, a kötelezettség növekedése vagy csökkenése — és a korábbi önellenőrzési pótlék módosítása. |
| 06 — Behajthatatlan követelés | badDebt | Nyilatkozattípus (elszámolás, megtérülés, előzetesen felszámított adó csökkenése), az elszámolás oka, a törvényi feltétel teljesülése, számla- és partneradatok. |
| 07 — Fordított adózás, értékesítés | reverseChargeSupply | Vevő adószáma, teljesítés napja, vámtarifaszám zárt értéklistából, mennyiség, hibrid vetőmag jelölése, mértékegység (kg, m3, MWh), adóalap. |
| 08 — Fordított adózás, beszerzés | reverseChargeService | Ugyanez a szerkezet, az eladó adószámával (supplierTaxNumber). |
| 09 — Személygépkocsi alvázszám | chassisNumberOfTheCar | Alvázszám, és jelölés arról, hogy az adatszolgáltatás közvetett vámjogi képviselőn keresztül történik-e. |
| A88 — Új közlekedési eszköz | newMeansOfTransport | Vevő adatai (név, országkód, irányítószám) és a jármű adatai. Minden korábbi nyomtatványsor egy-egy tételnek felel meg. |
| 170 — Átvezetési és kiutalási kérelem | requestForTransferAndRefund | Terhelendő adónem, adónemkód és összeg, ugyancsak soronként egy tételben. |
A fordított adózású lapoknál a kitöltendő mező a vámtarifaszám (customsTariffNumber), zárt értéklistából: 1003 az árpa, 1001 a búza és kétszeres, 7213 a melegen hengerelt rúd, és így tovább. A vámtarifaszámhoz tartozó terméknevet az eÁFA M2M rendszer tölti automatikusan. Ugyanezeken a lapokon a mennyiség (quantity) nem kötelező mező, a hibrid vetőmag jelölése (hybridSeed) és a mértékegység (unitOfMeasure) viszont igen.
Az A88-as lapnál viszont valóban a rendszer egészíti ki az adatot: a vevő országát az országkód alapján az eÁFA M2M tölti a NAV felé küldött adatszolgáltatásban. Az országkódnál zárt lista érvényes, az uniós tagállamok kódjai és az XI.
Az analitika új mezői
Az áfaanalitika tételsora (vatAnalyticsItem) is bővült. A leggyakrabban félreértett új elem az invoiceModificationOrCancellation, ezért álljon itt pontosan, mit ír róla a specifikáció 50. oldala.
A forrásbizonylat típusát megadó sourceDocumentType értéklistája is bővült egy elemmel. A korábbi INVOICE, RECEIPT, CUSTOMS_DECLARATION és OTHER mellé bekerült a DAILY_SUMMARY, amely a pénztárgép napi zárását jelöli: így jelennek meg az Online Pénztárgép, illetve az eNyugta rendszerből érkező nyugták napi szinten aggregálva. A nyugtaadatok adóügyi napja a napi nyitástól aznap éjfélig tartó időszak.
Az adózási adatok közé került az indirectCustomsRepresentative adatcsoport, benne az importerTaxNumber mezővel. Ennek kitöltésével jelzi a bevalló, hogy közvetett vámjogi képviselő érintett az ügyletben — és ez a mező vezérli a 03-as melléklap automatikus előállítását is.
Az önellenőrzéshez 2026-ban új mező került a sémába. A nonStandardAllowanceCalcReason az önellenőrzési pótlék általánostól eltérő számításának okát jelöli, 01 és 09 közötti kóddal; mindegyik kód egy konkrét jogszabályhelyre mutat. Korábbi időszakok bevallásánál nem kell kitölteni.
Mit kell átnézni a saját rendszerben
A könyvelői és a fejlesztői teendő szétválik, de közös a kiindulópontjuk: az adat minősége előrébb került a folyamatban.
Könyvelői oldalról
A 03-as melléklap és a bevallás kiegészítő adatai a rendszertől jönnek, de csak akkor, ha az analitika rendben van: az automatizmus nem javítja ki a hiányos adatot, hanem épít rá. Ahol korábban a melléklap kitöltésekor derült ki egy hiányzó adószám vagy egy rossz adópozíció, ott most a hiba végigfut a bevalláson. Ezért a valódi kérdés az, hogy honnan jön az analitika, és ki felel a tartalmáért.
A fordított adózású ügyleteknél az adókód és a melléklap összefüggése validációs kérdéssé vált: ha az adókód szerepel, a melléklapnak is szerepelnie kell. A kettő tehát nem kezelhető külön munkafolyamatban.
A szoftverszállítóval folytatott beszélgetés ilyenkor néhány konkrét kérdésre szűkíthető. Támogatja-e a program a 2.0-s sémát, és melyik verziótól? Kezeli-e az invoiceModificationOrCancellation mezőt az MP31 adókódhoz kötve, vagy általánosan a módosító számlákra? Kitölti-e a fordított adózású lapokon a vámtarifaszámot, vagy még terméknevet vár? Elhagyta-e a NavFieldId-alapú leképezést? Ezekre a kérdésekre a válasz vagy megvan, vagy fejlesztési feladat — harmadik lehetőség nincs.
A válasz akkor is információ, ha nem megnyugtató. Bizonytalan vagy folyamatosan csúszó határidő esetén a kockázat nem technikai, hanem ütemezési: az ÁNYK-val 2026. december 31-ig lehet új bevallást beadni, utána nincs hova visszalépni. A csatorna megválasztása és a szállító felkészültsége ezen a ponton összeér, és a döntés átfutási ideje hónapokban mérhető.
Fejlesztői oldalról
A NavFieldId-alapú leképezés nem használható tovább. Az adatot a saját szerkezetében kell megfeleltetni a 2.0-s csomópontoknak.
A vpid leképezését át kell helyezni a declarationInformation alá, a declarationAdditionalData előállítását pedig ki lehet venni a kódból.
Az invoiceModificationOrCancellation logikáját az adókódhoz kell kötni, nem a bizonylat típusához: a true érték csak MP31 mellett érvényes.
A zárt értéklisták — vámtarifaszám, mértékegység, országkód, bizonylattípus — karbantartása a séma követésével jár.
Ami még nyitva van
A NAV a július 31-i közleményében két támogató anyagot ígért az átálláshoz: a 2.0-s XSD-hez tartozó minta XML-fájlokat és egy GYIK-dokumentumot. A tárház utolsó közleménye a cikk lezárásáig július 31-i keltezésű, tehát egyik sem jelent meg. Az A60 XSD és a hozzá tartozó interfészspecifikáció augusztus folyamán várható. Egy részlet ehhez: az eÁFA M2M-nek egységes specifikációja lesz, az A60-as XML beküldésének folyamatát nem választják le róla.
A kérdéseket a NAV két csatornán fogadja. Az informatikai, fejlesztéssel összefüggőket a GitHub-tárház Discussions felületén, a jogértelmezést igénylőket a nav.gov.hu levélküldő oldalán, az „eÁFA-felület használatával kapcsolatos jogi kérdések" tárgy kiválasztásával.
Kapcsolódó anyagok
Ha a beküldés hibaüzenettel tér vissza, a teljes eÁFA validációsüzenet-listánk mind a 101 üzenetet tartalmazza a NAV interfészspecifikációjából, blokkoló és figyelmeztető bontásban, kereshetően.
A séma szerinti formai ellenőrzéshez használható az ingyenes eÁFA XML-ellenőrzőnk: a fájl a böngészőben marad, feltöltés nélkül.
Az MP31 és a többi adókód visszakereséséhez elérhető a standard adókód-katalógus mind a 232 kódja, CSV és JSON formátumban is letölthetően.
Az eÁFA M2M egészének áttekintéséhez itt található az útmutatónk.
A felkészülés tágabb kérdéseit korábbi cikkeinkben jártuk körül. Az átállás előtti adatrendezésről — adókód-mapping, adatminőség, kontrollok — külön írásunk szól, a csatornaválasztásról és a 2027-es határidőről pedig az ÁNYK-kivezetés ütemterve ad képet.
eÁFA M2M: mit kell rendbe tenni az átállás előtt? — a bevallás mögötti adatok, adókódok és kontrollok rendezése.
ÁNYK-kivezetés 2027: átállási ellenőrzőlista és ütemterv — mikor mit kell eldönteni, ha az ÁNYK 2026 végén lejár.
NAV M2M és az ÁNYK kivezetése: szakmai felkészülés 2027-re — mit jelent mindez a könyvelői praxisban.
Források
A részletes mezőleírások, kötelezőségek és értéklisták: eÁFA M2M 2.0 interfészspecifikáció v1.1 (NAV, 214 oldal)
A verzióváltás összefoglalója, a törölt és áthelyezett csomópontok: XSD változások eÁFA 2.0 verzióban (NAV)
A 2.0-s sémafájlok: eVAT/src/schemas/hu/gov/nav/vdr
Az éles átállás bejelentése: eVAT Discussions #328 (2026. július 31.)
A tesztkörnyezet 2.0-ra állása: eVAT Discussions #276 (2026. június 30.)
A felkészültségi szavazás: eVAT Discussions #313
Jogértelmezési kérdések: NAV levélküldő felület — az „eÁFA-felület használatával kapcsolatos jogi kérdések" tárgy kiválasztásával.