eÁFA M2M 2.0: miért nem elég az utolsó pillanatban felkészülni?
Az eÁFA M2M 2.0 XSD-k és specifikáció már elérhetők. Mutatjuk, miért nem csak IT-feladat az átállás, és mire figyeljenek a vállalatok 2026 augusztusa előtt.
Az eÁFA M2M rendszer 2.0-s verziója körül az elmúlt hetekben több fontos fejlemény történt. A NAV publikus GitHub tárhelyén megjelentek a 2.0-s XSD-k, elérhetővé vált az új interfész specifikáció, és a közösségi fórumokon is egyre több gyakorlati kérdés látható az átállással kapcsolatban. A NAV 2026. május 14-én publikált 2.0.1-es release-e szerint a végleges 2.0-s XSD-k és az új specifikáció is feltöltésre kerültek.
Ez jó hír, mert a felkészüléshez már nem csak tervezetek és korábbi minták állnak rendelkezésre. Ugyanakkor a határidők továbbra is szorosak. A NAV korábbi tájékoztatása szerint a 2.0-s működés tesztkörnyezetben 2026. július elejétől lesz elérhető, az éles rendszerbe pedig a jelenlegi tervek szerint 2026. augusztus 1-jével kerül bevezetésre. Ettől kezdve kizárólag a 2.0-s verzió lesz használható XML-feltöltésre.
Ezért az eÁFA M2M-re való felkészülést nem érdemes egyszerű informatikai feladatként kezelni. A kihívás nem csak az, hogy egy rendszer képes-e XML-fájlt előállítani. A valódi kérdés az, hogy a vállalat könyvelési, adózási és ERP-folyamatai képesek-e olyan adatminőséget biztosítani, amelyből az eÁFA M2M-ben megfelelő bevallás készíthető.
Az eÁFA M2M nem csak technikai csatornaváltás
Az ÁNYK-s bevallási logikához sok vállalat évek óta kialakult belső folyamatokat használ. A bevallás gyakran főkönyvi, adóanalitikai vagy Excel-alapú egyeztetések eredményeként áll össze. Az eÁFA M2M ezzel szemben sokkal részletesebb, strukturáltabb és következetesebb adatlogikát vár.
Ez különösen azoknál a vállalatoknál jelenthet kihívást, ahol:
több ERP- vagy számlázórendszer működik párhuzamosan;
a kimenő számlák részletes adatai nem ugyanabban a rendszerben vannak, mint a könyvelési adatok;
a társaság nemzetközi ERP-t használ, például SAP, Oracle, Microsoft Dynamics vagy saját fejlesztésű rendszert;
az áfa kódolás jelentős részben belső adókódokra, manuális döntésekre vagy utólagos korrekciókra épül;
rendszeresek a speciális ügyletek, például fordított adózás, közösségi ügyletek, export, import szolgáltatások, részben levonható áfa, arányosítás vagy pénzforgalmi elszámolás.
A NAV GitHub fórumán is visszatérő téma, hogy az eÁFA M2M nem mindig illeszkedik automatikusan a vállalatok jelenlegi könyvelési adatmodelljéhez. Felmerült például olyan helyzet, amikor a számlaszintű részletes adatok a számlázási alrendszerben vannak, míg a számviteli rendszerben csak időszaki, összesített könyvelési adatok találhatók.
Ez nem pusztán technikai probléma. Ha a bevalláshoz szükséges adatok nem strukturáltan, nem megfelelő részletezettséggel vagy nem egységes logika szerint állnak rendelkezésre, akkor az eÁFA M2M bevezetése előtt adatminőségi és folyamatoldali felkészülésre is szükség van.
A 2.0-s verzió egyik fő üzenete: az adólogika kerül előtérbe
Az eÁFA M2M 2.0-s dokumentáció megjelenésével a kérdés már nem az, hogy „lesz-e specifikáció”, hanem az, hogy a vállalatok mennyire tudják azt lefordítani saját működésükre.
A NAV GitHub discussions oldalán több friss téma is azt mutatja, hogy a szakmai fókusz egyre inkább az adózási tartalomra kerül: önellenőrzés és helyesbítés értelmezése, fordított adózású számlák kezelése, kimenő számlák bizonylatonkénti feladása, XML konverter, adózói helyesbítés, A60, illetve a 2.0-s XSD változásai.
Ezek alapján az eÁFA M2M projektben nem elegendő a mezők technikai feltöltése. A vállalatnak azt is meg kell határoznia, hogy az egyes gazdasági események milyen adózási tartalommal kerülnek be az analitikába.
Például más logikát igényelhet:
egy normál belföldi beszerzés;
egy részben levonható telefonszámla;
egy személygépkocsihoz kapcsolódó költség;
egy fordított adózású vas- vagy acéltermék beszerzése;
egy közösségi termékbeszerzés;
egy exportügylethez kapcsolódó előleg;
egy korábbi időszakot érintő helyesbítő vagy sztornó bizonylat.
A nyilvános issue-k alapján ezek a kérdések nem elméletiek. Több bejegyzés is részben levonható áfa, arányosítás, fordított adózás, negatív adóalap/adóösszeg, tárgyi adómentes ügyletek vagy speciális adókódolás kapcsán kér pontosítást.
Az adókód-mapping nem adminisztratív gyakorlat, hanem kulcskockázat
Sok vállalatnál az áfa kódolás történelmileg az ERP belső adókódjaira épül. Ezek az adókódok gyakran nem csak adómértéket jelentenek, hanem könyvelési logikát, riportálási sort, levonási státuszt, országlogikát vagy akár manuális döntési pontot is.
Az eÁFA M2M azonban NAV standard adókódokban és strukturált analitikus adatokban gondolkodik. Ezért az ERP-adókódok és a NAV standard adókódok közötti megfeleltetés nem lehet pusztán egy „egy az egyben” mapping tábla.
A mapping során érdemes legalább három kérdést vizsgálni:
Az ERP-adókód pontosan milyen gazdasági eseményt fed le?
Az adott ügylet milyen bevallási logika szerint kezelendő?
A szükséges részletező adatok rendelkezésre állnak-e a forrásrendszerben?
Ha ezekre nincs egyértelmű válasz, akkor az eÁFA M2M bevezetésnél később hibák, warningok, manuális korrekciók vagy akár blokkoló validációk jelenhetnek meg.
Az ÁNYK és az eÁFA közötti átmenet külön figyelmet igényel
Az eÁFA M2M bevezetése nem jelenti azt, hogy a korábbi bevallási időszakok kezelése automatikusan egyszerűvé válik. A GitHubon külön kérdésként merült fel, hogyan lehet korábbi ÁNYK-n benyújtott áfabevallásokat eÁFA M2M-ben módosítani vagy önellenőrizni.
A NAV/NTCA válasza szerint az ÁNYK nyomtatványon beküldött áfabevallást csak nyomtatványon lehet önellenőrizni; ha egy adott időszakra az adózó nyomtatványalapú áfabevallást nyújtott be, akkor azt sem eÁFA M2M-ben, sem eÁFA webfelületen nem tudja önellenőrizni. A válasz arra is figyelmeztetett, hogy időszakok között előfordulhat ÁNYK és eÁFA vegyes használata, de ez kockázatot okozhat, különösen akkor, ha ugyanarra az időszakra több csatornán is történik beadás.
Ez alapján az átállás nem csak informatikai cutover kérdés. A vállalatnak nyilván kell tartania, hogy mely időszak mely csatornán került benyújtásra, és később hogyan kezelhetők az önellenőrzések vagy javítások.
Miért fontos ez különösen a nemzetközi ERP-t használó cégeknek?
A magyar eÁFA M2M sajátossága, hogy a lokális adózási elvárásokat kell összekapcsolni a vállalat globális vagy regionális ERP-struktúrájával. Ez gyakran nehezebb, mint elsőre látszik.
Egy nemzetközi ERP-ben az adókódok sokszor több országra, több üzleti folyamatra vagy központi sablonokra épülnek. A magyar eÁFA M2M viszont részletes magyar adózási logikát, megfelelő bizonylatszintű adatokat és NAV standard adókódolást vár. Ezért előfordulhat, hogy a globális rendszer „könyvelésileg helyes” adatot ad, de az eÁFA M2M elvárásaihoz mégsem elég részletes vagy nem megfelelően strukturált.
Ez különösen igaz akkor, ha a vállalatnál:
a számlázási és könyvelési adatok külön rendszerekben vannak;
az áfa analitika több forrásból áll össze;
a magyar bevallási logika részben Excelben vagy manuális riportokban él;
az ERP standard riportjai nem tartalmazzák az összes eÁFA M2M-hez szükséges adatot;
a helyi adócsapat és a regionális IT/ERP csapat között nincs közös eÁFA adatmodell.
Ilyen környezetben az eÁFA M2M projekt sikerének kulcsa nem csak a technikai integráció, hanem az adózási logika és az adatforrások összehangolása.
Mire érdemes most felkészülni?
A 2.0-s dokumentáció publikálása után a felkészülést érdemes gyakorlati oldalról megkezdeni. A legfontosabb feladatok:
1. Adókód-mapping felülvizsgálata
Meg kell vizsgálni, hogy a vállalat jelenlegi ERP-adókódjai hogyan feleltethetők meg a NAV standard adókódoknak. Nem csak a gyakori adókódokat érdemes nézni, hanem a ritkább, de kockázatosabb eseteket is: fordított adózás, részben levonható áfa, arányosítás, export, közösségi ügyletek, pénzforgalmi elszámolás, helyesbítések.
2. Adatforrások azonosítása
Fel kell mérni, hogy az eÁFA M2M-hez szükséges adatok mely rendszerekben találhatók. Nem biztos, hogy minden szükséges adat a főkönyvben vagy az áfa riportban van. Sok esetben számlázási, beszerzési, pénztárgépes, vám- vagy egyéb alrendszerből is szükség lehet adatokra.
3. Speciális ügyletek tesztelése
Nem elég egy egyszerű belföldi számlával tesztelni. A vállalat saját működésére jellemző speciális eseteket is végig kell vinni: negatív tételek, módosító számlák, részben levonható költségek, több országot érintő ügyletek, vegyes adózási státuszú partnerek.
4. Belső felelősségi körök tisztázása
Az eÁFA M2M nem csak IT-projekt. Szükség van adózási, könyvelési, ERP és kontroll oldali felelősökre is. Már a projekt elején érdemes tisztázni, ki dönt az adókódolási logikáról, ki validálja az adatokat, ki kezeli a hibákat, és ki felel a beküldési státuszok nyomon követéséért.
5. Átállási és önellenőrzési stratégia kialakítása
A vállalatnak tudnia kell, mikortól és mely időszakokra használja az eÁFA M2M-et, hogyan kezeli a korábbi ÁNYK-s időszakokat, és milyen belső dokumentációt tart fenn az átállásról.
Következtetés
Az eÁFA M2M 2.0 megjelenése fontos mérföldkő. A dokumentáció és a sémák publikálása után a vállalatok számára a kérdés már nem az, hogy lesz-e mire fejleszteni, hanem az, hogy a saját adataik, folyamataik és adózási logikájuk készen állnak-e az új működésre.
Azok a cégek, amelyek az eÁFA M2M-et kizárólag technikai XML-feltöltésként kezelik, könnyen későn szembesülhetnek azzal, hogy a legnagyobb kihívás nem a fájl előállítása, hanem az adatok helyessége, teljessége és adózási értelmezhetősége.
A sikeres felkészüléshez ezért nem csak fejlesztői kapacitásra van szükség, hanem átgondolt adózási mappingre, adatminőségi ellenőrzésre, ERP-oldali egyeztetésre és jól dokumentált belső folyamatokra.
Az eÁFA M2M nem egyszerűen új beküldési csatorna. Inkább egy új működési modell, amelyben a vállalat áfa folyamatai sokkal átláthatóbbá, strukturáltabbá és automatizálhatóbbá válhatnak — feltéve, hogy az átállás nem az utolsó pillanatban kezdődik.
Gyakori kérdések
Mikor váltja az eÁFA M2M 2.0 az 1.0-s verziót?
A NAV tájékoztatása szerint a 2.0-s működés tesztkörnyezetben 2026. július elejétől lesz elérhető, az éles rendszerbe pedig a jelenlegi tervek szerint 2026. augusztus 1-jével kerül bevezetésre. Ettől kezdve kizárólag a 2.0-s verzió lesz használható XML-feltöltésre.
Miért nem elég az utolsó pillanatban felkészülni az eÁFA M2M-re?
Mert a kihívás nem csak az XML előállítása, hanem az adatminőség, az adókód-mapping, a speciális ügyletek kezelése és az ERP-folyamatok összehangolása. Ha ezek nincsenek rendezve, a bevezetéskor hibák, warningok vagy blokkoló validációk jelenhetnek meg.
Hogyan kezelhetők a korábbi ÁNYK-s áfabevallások az eÁFA M2M bevezetése után?
Az ÁNYK nyomtatványon beküldött áfabevallást csak nyomtatványon lehet önellenőrizni. Ha egy időszakra nyomtatványalapú áfabevallás került benyújtásra, azt sem eÁFA M2M-ben, sem eÁFA webfelületen nem lehet önellenőrizni. A vállalatnak nyilván kell tartania, mely időszak mely csatornán került benyújtásra.
Hol érhetők el a hivatalos eÁFA M2M 2.0 dokumentációk?
A NAV a GitHub-on publikálja az XSD-ket, az interfész specifikációt és a kapcsolódó anyagokat: github.com/nav-gov-hu/eVAT. A szakmai kérdések a Discussions felületen is megválaszolásra kerülnek.