Most véget ért a 2026-os SZJA-szezon. A telefonok már nem csengnek folyamatosan, az ügyfelek nagy része visszament a saját életébe. Pontosan ez az időablak az, amikor érdemes elkezdeni a következő nagy átállást: az ÁNYK kivezetését és az e-Áfa M2M bevallás bevezetését az irodádban. 2026. december 31-én kivezetik az ÁNYK-t az áfabevallásoknál, és 2027. január 1-jétől csak az e-Áfa marad. Mi most azt mutatjuk meg, mit jelent ez a gyakorlatban, és hogyan érdemes felkészülni rá.
Hol tart most az e-Áfa, és mi vár a könyvelőkre?
Az e-Áfa 2024. január 1-jén indult el, azóta pedig folyamatosan bővült. Az első időszakban még csak a havi és negyedéves áfabevallás volt elérhető rajta, de azóta már az éves bevallás, az önellenőrzés, a soron kívüli bevallások, a jogutódlás, sőt az A60-as összesítő nyilatkozat is benne van a rendszerben.
A NAV 2025 októberében a 9. Nemzeti Adókonzultáción tette közzé a digitalizációs roadmapjét. Ennek a lényege röviden: 2026. december 31-én leáll az ÁNYK új áfabevallások beadására. 2027. január 1-jétől már csak az e-Áfa webes felületén vagy M2M kapcsolaton lehet áfabevallást benyújtani. Az ONYA marad a többi nyomtatványra, az ÁNYK-ban pedig kizárólag bizonyos régi időszakokra vonatkozó önellenőrzések maradnak elérhetők.
A két leggyakrabban félreértett dátum
2026. december 31. - az ÁNYK utolsó napja az ÚJ áfabevallások beadására. Tehát 2026 decemberi időszakra vonatkozó áfabevallást már nem lehet rajta beküldeni.
2027. január 20. - havi bevallók itt nyújtják be a 2026 decemberi áfát. Ezt már KÖTELEZŐEN e-Áfa-n keresztül.
Mit jelent ez a gyakorlatban a könyvelőirodáknak?
Két különböző technikai csatorna közül lehet választani. Az egyik a webes e-Áfa felület, ahol a NAV által kiajánlott tervezetből indulsz ki, és ezt módosítod, jóváhagyod. A másik az M2M kapcsolat, ahol a könyvelőprogramodból egy XML állomány (DATA.xml) megy ki közvetlenül a NAV szerverére, a hatóság validálja, és ebből áll össze a bevallás.
Egy kis ügyfél (havi 50-100 számla) esetén a webes felület tökéletesen elég. Egy közepes vagy nagyobbügyfél (több ezer számla havonta, fordított adózás, EU-s ügyletek) esetén viszont az M2M nemcsak hatékonyabb, hanem hosszabb távon szinte elkerülhetetlen. A NAV maga is azt írja, hogy 100 ezer számla felett már nem javasolt a webesfelület.
e-Áfa web vagy M2M? Itt a döntési táblázat
A két csatorna nem helyettesíti egymást, hanem két különböző logika ugyanarra a problémára. Itt a gyakorlatiösszehasonlítás:
Egy fontos részlet, ami sokakat meglep: az M2M-en feltöltött adatok nem látszanak a webes felületen, és fordítva. Tehát ha egy ügyfélnél elkezdtél M2M-mel dolgozni, a webes tervezetben semmi sem fog megjelenni róla. Nincs átjárás a két csatorna között.
Hogyan működik az M2M technikailag?
Itt jön a mélyvíz - a sok cikk általában megáll a felszínen, és csak annyit mond, hogy „M2M kapcsolaton keresztül megy a NAV-hoz az adat". Mi most lépésről lépésre mutatjuk meg, mi történik.
1. Technikai felhasználó létrehozása az Online Számlában
Az M2M kommunikáció nem egy új NAV-felület. A meglévő Online Számla rendszer technikai felhasználóján keresztül megy minden. Ezért az első lépés:
1. Az ügyfél elsődleges felhasználója (ügyvezető, vagy állandó meghatalmazott) belép az onlineszamla.nav.gov.hu oldalra KAÜ-vel.
2. Felhasználók menü > Új technikai felhasználó.
3. Itt nem elég a számlaadat-szolgáltatási jogosultság. Be kell pipálni: „Hozzáférés az e-Áfa rendszer interfészhez",és ezen belül külön a „Bevalláskezelés" és a „Bevallás jóváhagyása"jogokat.
4. A rendszer legenerál egy felhasználónevet, jelszót (API-key), egy XML aláíró kulcsot és egy XML csere kulcsot. Ezeket a könyvelőszoftver e-Áfa moduljába kell beilleszteni.
5. 2026-tól mind az elsődleges, mind a másodlagosfelhasználóknak kötelező a kétfaktoros (2FA) azonosítás bekapcsolása. Ezt isrendezni kell a beüzemelés előtt.
Belső kontroll szempont
A „Bevalláskezelés" és a „Bevallás jóváhagyása" jogot érdemes szétválasztani két különböző technikai felhasználó között. Így az analitikát feltöltő rendszer nem ugyanaz, mint amelyik véglegesít is. Ez egy egészséges belső kontroll, főleg nagyobb iroda vagy nagyobb ügyfél esetében.
2. Adókód-mapping: az igazi időigényes lépés
Itt szokott elcsúszni az M2M-projektek 80 százaléka. Minden könyvelőprogram saját, belső adókódokkal dolgozik (pl. „01 Belföldi 27%-os értékesítés", „17 Közösségibeszerzés"). A NAV viszont egy standard adókód-struktúrát vár az M2M-en. Ate dolgod, hogy a saját kódjaidat megfeleltesd a NAV kódoknak.
A nehézséget az adja, hogy nem 1:1 megfeleltetésről van szó. Egy belső adókódhoz több NAV-paraméter istartozhat (adómérték, ügylettípus, levonási jog, fordított adózás jelölése). És minden ügylettípusra rá kell jönni:
• Belföldi 27%-os értékesítés - levonási jog jelölésével együtt
• Fordított adózás -külön soron a fizetendő és a levonható oldalon, partner adószámával együtt
• Közösségi beszerzés- az A60 összesítővel egyezően kell megjelennie
• Tárgyi adómentes -pontos jogszabályi hivatkozással (Áfa tv. melyik paragrafus)
• Pénzforgalmi áfa, részkiegyenlítés, devizaszámlák - ezek mind külön logikát igényelnek
Ezért cikkeikben a nagyobb adótanácsadók (Andersen, RSM, Deloitte) is azt írják: az M2M-projektre ne csak IT-fejlesztőt vigyél, hanem áfa-szakértőt is. A mapping valódi adójogi döntéseket tartalmaz.
3. A bevallás benyújtása lépésről lépésre
Amikor minden be van állítva, egy bevallás benyújtása így néz ki:
1. A könyvelőszoftvered összeállítja a DATA.xml-t abizonylatszintű áfa analitikából.
2. Felmegy a NAV szerverére (HTTPS, HMAC-SHA256aláírással).
3. A NAV technikai (séma) és üzleti validációt fut le, válaszul ERROR vagy WARNING üzeneteket küld.
4. Ha van ERROR: a bevallás nincs beadva. Javítás, újraküldés.
5. Ha csak WARNING-ek vannak: a bevallás beadható, de a figyelmeztetéseket érdemes átnézni - tipikusan eltérés az Online Számlaadatoktól.
6. Sikeres validáció után létrejön a bevallási XML.
7. A bevallást egy külön gépi műveletben („jóváhagyás") kell véglegesíteni.
Miért éri meg most M2M-re váltani?
Az M2M nem csak egy gyorsabb csatorna. Több olyan kedvezmény is van, amit a NAV kifejezetten az M2M-felhasználóknak nyújt:
15 napos ellenőrzési moratórium
Megbízható adózó ügyfélnél, ha M2M-en adja be a bevallást, a NAV a benyújtás utáni 15 napban nem indítadó ellenőrzést (kivéve, ha kifejezett kockázat merül fel). Ez egy biztonsági puffer, ami komolyabb ügyfeleknél nagyon sokat ér.
Pótlékmentes önellenőrzés
Ezen a 15 napon belül, hatalálsz valamit, amit javítani kell, pótlékmentesen önellenőrizhetsz. A klasszikus ÁNYK-s benyújtásnál ez nem működik így.
M-lapok automatikus generálása
Az e-Áfa rendszer az áfaanalitikából magától legenerálja az M-lapokat (tételes belföldi összesítő). Nem kell külön kitöltened. És itt jön egy érdekes részlet: 2026. július 1-jétől az M-lapokon már a ténylegesen levont áfát is részleteznetek kell adómértékenként és arányosítással érintett bontásban. Ez ÁNYK-ban komoly fejlesztést igényel egy olyan rendszerben, ami fél év múlva amúgy is megszűnik. Az e-Áfa-ban viszont 2027-től nem kell M-lap, tehát ezt a fejlesztést el is kerülöd.
Sablonosítható workflow
Egy könyvelőiroda szempontjából ez a leglényegesebb. Az első M2M-ügyfélre rámegy 2-4 hét, mire minden a helyén van (mapping, technikai felhasználó, tesztelés, oktatás). Utána viszont a hasonló profilú ügyfeleknél a sablon átemelhető, és az új ügyfél bekötése már 1-2 nap. Az iroda szintjén ez a tényleges megtérülés.
Bookkeepie könyvelő partnerség
Mi a Bookkeepie-nél folyamatosan dolgozunk azon, hogy a könyvelő partnereink modern, automatizált workflow-t építhessenek - és az ügyfeleink olyan szakemberekhez találjanak, akik ebben otthon vannak. Ha könyvelőként hasonló kérdésekkel foglalkozol, és érdekel a Bookkeepie partneri programja, nézz szét nálunk: új ügyfeleket hozunk hozzád, te pedig azokra az ügyekre fókuszálhatsz, amik fontosak.
Magyar könyvelő szoftverek és e-Áfa M2M: hol tart a piac?
2026 áprilisában a kép vegyes. Egyes szoftverek már komoly e-Áfa M2M megoldást kínálnak, mások még csak a webes csatlakozást támogatják. Itt egy gyors helyzetkép, amennyire kívülről látható (a pontos funkciókat mindig a gyártónál érdemes ellenőrizni):
Kulcs-Soft (Kulcs-Könyvelés)
Külön Windows-szolgáltatást telepít az e-Áfa-hoz (KS.Evat.WinService) és egy dedikált SQL-példányt használ. Ezzel tehermentesíti a fő könyvelési adatbázist a tömeges validációs folyamatok alatt. Hálózatos környezetben a szolgáltatás csak a szervergépen fut, a kliensgépek azon keresztül érik el a NAV-ot.
Novitax (Wintax)
Részletes dokumentációval segíti a technikai felhasználó beállítását. Külön kiemeli a„Bevallás kezelés" és a „Bevallás jóváhagyása" jogosultság elválasztását, ami belső kontroll szempontjából helyes irány.
RLB (RLB-60 Naplófőkönyv és társai)
M2M-kapcsolaton keresztül támogat bevallás-benyújtást, részben Ügyfélkapu nélkül is. A teljes e-Áfa M2M lefedettséget érdemes közvetlenül a gyártóval egyeztetni.
Octopus 8, DimSQL
Általános ERP/könyvelési rendszerek, amelyek e-Áfa M2M-támogatása nyilvánosan kevésbé részletezett. Ha ezek valamelyikét használod, a beüzemelés előtt feltétlenül kérj a gyártótól pontos tájékoztatást a 2026-2027-es roadmapról.
Specializált middleware: Taxatron, PwC SmartTax, Loginform
Ezek a megoldások jellemzően nagyvállalati ERP-khez (SAP, Oracle, Microsoft Dynamics) csatlakoznak, éstax-engine logikával végzik a mappinget és a beküldést. A Microsoft Dynamics365 Business Central magyar lokalizációjában például a Loginform 2026 nyarára ígéri az ÁNYK-kiváltó funkciókat - tehát itt érdemes lesz egy pilot-szakaszttervezni a 2026-os őszre.
Buktatók: ahol az M2M projektek tipikusan elcsúsznak
Az M2M nem rakéta tudomány, devan néhány visszatérő hiba, amibe szinte mindenki belefut. Ezeket érdemes előretudni, mert jelentősen lerövidítik a beüzemelést:
1. Adókód-mapping nélkül elindulni
A leggyakoribb hiba az, hogy valaki azt gondolja, „a szoftverem majd megoldja". A szoftver tudja asémát, de a saját adókódjaid és az ügyfeleid speciális ügyletei nem maguktól mennek a helyükre. A mapping időt és áfa-szakértői gondolkodást igényel.
2. WARNING-üzenetek figyelmen kívül hagyása
Sok könyvelő úgy gondolja, hogy ha „csak WARNING", akkor nincs probléma. Ez nem feltétlenül igaz: a WARNING jellemzően azt mutatja, hogy az általad benyújtott adatok eltérnek a NAV-nál meglévő Online Számla adatoktól. Ezek később ellenőrzési kockázattá tudnak válni. Be kell vezetned egy WARNING-feldolgozási rutint az irodában: kinézi át, ki dönt arról, hogy javítunk-e, vagy bevalljuk-e az eltérést.
3. Hash mismatch és sorvégződés-problémák
Ha a szoftvered Linux-szerverenkészíti el az XML-t, és a NAV Windows-szabvánnyal validál (CRLF vs. LF),előfordulhat, hogy a digitális aláírás hash-e nem stimmel. Ilyenkor INVALID_REQUEST_SIGNATURE hibát kapsz, függetlenül attól, hogy az adatokadózási szempontból hibátlanok. Ez egy klasszikus IT-buktató, ami a könyvelőnek kínszenvedés - jelezd a fejlesztőnek időben.
A NAV GitHub-tárhelyén(nav-gov-hu/eVAT) folyamatosan frissülnek az XSD-sémák. Az új e-Áfa 2.0-ssémában például már nem szerepelnek az ÁNYK-mezőazonosítók, és néhány korábbanopcionális mező kötelezővé vált. Ha a szoftvered nem követi ezt le, SCHEMA_VALIDATION_ERROR-tfogsz kapni az új időszakban. Tehát a szoftverfrissítések követése kulcskérdés.
5. Timeout nagy fájloknál
Egy 50 ezer számlás havibevallás XML-je nem kicsi. Ha a szoftver túl korán lekérdezi az eredményt, vagy nem kezeli az aszinkron feldolgozást rendesen, lefagyhat a folyamat. A megoldásegy exponenciálisan növekvő várakozási logika (backoff strategy) és a messageIdalapú szigorú korreláció.
Mit csináljunk WARNING-gal?
Ha a NAV WARNING-et ad vissza, jellemzően egyezést kér az Online Számla adataival. Tipikus okok: kerekítési eltérés, eltérő teljesítési dátum, hibás devizaárfolyam, partnernél nem érkezett be időben az adatszolgáltatás. Egyik sem kritikus, de mindegyik ellenőrzendő. Ha egy WARNING ismétlődően ugyanazon partnernél jön elő, nézd át a partnermestert.
Időablak: miért pont most érdemes elkezdeni?
Ezt sokszor nem mondják kinyíltan, pedig ez a cikk legfontosabb gyakorlati üzenete. A SZJA-szezon és azÁNYK-kivezetés között pontosan annyi idő van, amennyi egy M2M-pilothoz kell.
Most (2026 májusától) nyolchónap van december 31-ig. Ebbe kényelmesen belefér:
• Egy kiválasztott pilot-ügyfél bevezetése (1-2 hónap)
• Sablonosítás, dokumentáció, csapatoktatás (1 hónap)
• További 5-10 hasonló profilú ügyfél bekötése (3-4 hónap)
• Tartalék idő ahibákra, séma-változásokra, év végi pánikra (1-2 hónap)
Aki ezt 2026 ősz végéig nem kezdi el, az 2026 decemberében pánikolni fog - és pont akkor lesz a legszűkösebb a szoftverfejlesztői és tanácsadói kapacitás. Aki januárban próbál mindent egyszerre megoldani, az nem dolgozik, hanem tüzet olt.
Határidők és mérföldkövek
Teendőlista: mit csinálj a következő nyolc hónapban?
Egy gyakorlati lépéssor a 2026.május - 2026. december időszakra:
1. Auditáld az ügyfélkörödet: kinek ér meg M2M, kinek elég a webes e-Áfa? (A választóvonal jellemzően havi 200-500 számla körül van.)
2. Egyeztess a könyvelőszoftvered gyártójával: meddig készül el az e-Áfa M2M moduljuk, milyen díjakkal, és milyen séma-verzión (eÁFA2.0).
3. Válassz egy pilot-ügyfelet. Ne a legbonyolultabbat, hanem egy közepesen nagy, tipikus ügyletekkel dolgozót. Itt fogod tanulni afolyamatot.
4. Készítsd el a NAV technikai felhasználó(ka)t és állítsd be a jogosultságokat. 2FA bekapcsolása kötelező 2026-tól.
5. Adókód-mapping: ülj le egy áfa-szakértővel (saját kollégád vagy külsős), és vezesd végig a saját kódjaidat a NAV standardkódjain.
6. Tesztelj a NAV tesztrendszerén. Még nincs éles bevallás, de már látod, mit kifogásol.
7. Élesítés egy hónapra. Az első M2M-bevallás után 15-30 napig kifejezetten figyeld a WARNING-okat és az Online Számlaeltéréseket.
8. Sablonosítás: ami a pilotnál működött, dokumentáld le. Mapping-tábla, hibakezelési protokoll, jogosultsági mátrix.
9. Skálázás: a következő 4-6 ügyfelet a sablonból. Itt már nem hetek, hanem napok kérdése egy ügyfél bekötése.
10. November-december: tartalék idő. Ha a NAV ad ki új sémát (ami szokott), legyen időd lekövetni.
Összefoglalás
Az ÁNYK kivezetése nem 2027 januárjában lesz fájdalmas, hanem akkor, ha valaki addig nem készült fel rá. A NAV nyolc hónapos időablakot adott - és ez bőven elég, ha most elkezdjük. Az e-Áfa M2M nem csak egy új csatorna, hanem egy másfajta gondolkodás: nem nyomtatványt töltesz ki, hanem adatfolyamot menedzselsz a könyvelőszoftver és a NAV között. Aki ebben jó lesz 2027-re, az nem csak megfelel egy jogszabálynak,hanem egy tényleg modernebb, kevésbé kézi munkára épülő irodát fog működtetni.
Mi a Bookkeepie-nél hisszük,hogy a következő évek legjobb könyvelő partnerei pontosan azok lesznek, akik ezt az átállást nem szenvedésnek, hanem fejlődési lehetőségnek nézik.
Csatlakozz a Bookkeepie könyvelő közösségéhez
Ha könyvelőként már kiépítetted (vagy építed) az e-Áfa M2M workflow-t az irodádban, és szeretnél olyan ügyfeleket, akiknél ez tényleg számít, nézz szét a Bookkeepie partneri programjában. Mi átlátható módon hozzuk az új ügyfeleket, te pedig azt csinálod, amihez értesz: a könyvelést.
Ez a cikk tájékoztató jellegű, nem minősül személyre szabott adótanácsadásnak. Az egyedi esetek elbírálásához kérd a könyvelőd vagy adótanácsadód véleményét. A cikkben hivatkozott jogszabályi határidők és technikai adatok 2026. áprilisi állapotot tükröznek; a NAV roadmapja és a sémaváltozások további pontosításokat hozhatnak. Az aktuálishivatalos információkért keresd fel a nav.gov.hu/ado/eafa oldalt vagy a NAVGitHub eVAT tárhelyét.