ÁNYK kivezetés 2027: minden, amit tudni kell
Szakmai szerző: Kovács András · Utolsó szakmai ellenőrzés: 2026. július 25.
Az ÁNYK-val 2026. december 31-ig nyújtható be új bevallás. 2027. január 1-jétől új beadásra már nem használható — a korábban ezen a csatornán beadott időszakok önellenőrzéséhez viszont átmeneti funkcióként elérhető marad. Az, hogy az új beadásoknál melyik csatorna lép a helyébe — ONYA, ONYA XML-import, eÁFA webes felület, NAV M2M vagy eÁFA M2M —, ügyfélkörönként és kötelezettségenként eltér.
Mit mond pontosan a NAV?
Az átállás körül sok a félreértés, ezért érdemes a NAV saját megfogalmazásából kiindulni. A NAV átállási oldala szerint „az átállásra jogszabály is kötelezi a NAV-ot, 2026. december 31-ig biztosíthatja az elektronikus ügyintézést az ÁNYK-val”. Ez a mondat két dolgot rögzít: az átállás nem üzleti döntés, hanem jogszabályi kötelezettség, és van egy külső határnap, ameddig az ÁNYK-s elektronikus ügyintézés még biztosítható.
Itt jön a leggyakrabban félreértett pont: a határidő az ÚJ bevallások beadására vonatkozik, nem az ÁNYK létezésére. A NAV 2025. október 30-i, Nemzeti Adókonzultáción tett bejelentése és 2025. december 5-i kommunikációja szerint 2027. január 1-jétől új bevallás már nem nyújtható be ÁNYK-n keresztül — a program azonban korlátozott átmeneti funkcióként elérhető marad a korábban ezen a csatornán beadott időszakok önellenőrzéséhez.
Az önellenőrzésnél az adott időszak bevallási nyomtatványát kell használni, és az általános elévülési szabályok is érvényesek. Ennek egy nagyon gyakorlati következménye van: a vállalatoknak és a könyvelőirodáknak 2027 után is nyilván kell tartaniuk, hogy melyik időszak melyik csatornán került beadásra. Enélkül egy két évvel későbbi önellenőrzésnél nem lesz egyértelmű, hol és milyen nyomtatvánnyal kell javítani.
Ez a különbség a tervezés szempontjából lényeges. Aki arra vár, hogy majd „lekapcsolják”, az egy egyszeri eseményre készül. Aki viszont kötelezettségenként végigmegy a saját listáján, az egy több hónapos, ütemezhető projektet lát — és ez utóbbi a valósághoz közelebb álló kép, különösen ott, ahol fejlesztés vagy ERP-integráció is érintett.
Átállási idővonal
-
2026. július — A NAV átállási tudástára elérhető
A NAV egy helyen, ügyfélkörök szerint mutatja be az ÁNYK utáni lehetőségeket és a gyakori kérdésekre adott válaszait. Kérdéseket az anykkivaltas@nav.gov.hu címen lehet feltenni.
-
2026. július 31. (várható) — NAV M2M 4.0 / BizonylatAPI publikálása
A NAV 2026. július 15-i tájékoztatása szerint az adatstruktúra új verziójának publikálása erre a napra várható — a korábban jelzetthez képest egy hónappal előrehozva.
-
2026. december 31. — Az utolsó nap új bevallás beadására ÁNYK-n
Eddig a napig nyújtható be új bevallás az ÁNYK-val. A NAV közlése szerint jogszabály alapján eddig biztosíthatja az ÁNYK-s elektronikus ügyintézést.
-
2027. január 1. — Új beadás csak az új csatornákon — az ÁNYK marad önellenőrzésre
Új bevallás és adatszolgáltatás kizárólag az ONYA, az eÁFA-rendszer vagy a NAV M2M felé mehet. Az ÁNYK korlátozott átmeneti funkcióként megmarad a korábbi időszakok önellenőrzéséhez.
Melyik ügyfélkörnek mit ajánl a NAV?
A NAV az átállási oldalán ügyfélkörök szerint bontja meg az ajánlott csatornákat. Az alábbi táblázat ezt foglalja össze. Fontos: ez iránymutatás, nem kötelezettségenkénti előírás — a konkrét nyomtatványnál mindig ellenőrizni kell, hogy az adott úton ténylegesen beadható-e.
| Ügyfélkör | A NAV által megjelölt csatornák | Mit jelent ez a gyakorlatban? |
|---|---|---|
| Magánszemélyek | ONYA | Böngészőből, külön szoftver telepítése nélkül intézhető ügyek. A legegyszerűbb átállási út. |
| Kis- és középvállalkozások | ONYA · ONYA XML-import · eÁFA webes felület · NAV M2M · eÁFA M2M | A legszélesebb választék, egyben a legtöbb döntés. A volumen és az adatforrás dönt: kézi kitöltés, XML-import vagy gépi kapcsolat. |
| Nagyvállalatok | NAV M2M · eÁFA M2M | A NAV itt kizárólag gépi csatornákat jelöl meg. Ez fejlesztési vagy szolgáltatói projektet jelent, nem felületváltást. |
| Könyvelők | ONYA · ONYA XML-import · eÁFA webes felület · NAV M2M · eÁFA M2M | Ügyfelenként eltérhet a helyes csatorna. Egy irodán belül jellemzően többféle utat kell párhuzamosan üzemeltetni. |
Két gyakran figyelmen kívül hagyott pont. Egy: az ONYA XML-import köztes megoldás — nem kézi kitöltés, de nem is teljes gépi integráció, így sok kkv-nál ez a reális első lépés. Kettő: nagyvállalatoknál a NAV nem ajánl böngészős alternatívát, tehát ott az átállás mindenképpen fejlesztési feladat.
Melyik digitális csatorna lehet megfelelő?
ONYA és NAV webes felületek
Egyszerűbb, böngészőben kezelhető ügyek és olyan kötelezettségek, amelyeknél a NAV ezt a csatornát biztosítja.
Mindig ellenőrizze, hogy az adott nyomtatvány és ügytípus ténylegesen elérhető-e ezen az úton.
ONYA XML-import
Ha az adat már előáll egy rendszerben, de nincs kapacitás vagy igény teljes gépi integrációra.
Köztes lépcső a kézi kitöltés és az M2M között: az adat gépből jön, a beküldést viszont ember indítja.
NAV M2M
Rendszeres, nagyobb volumenű, ügyviteli vagy bevallási szoftverhez kapcsolódó elektronikus folyamatok.
Kliensprogramot, jogosultságokat és a NAV műszaki előírásaihoz illeszkedő integrációt igényelhet.
eÁFA webes felület vagy eÁFA M2M
Áfabevallási folyamatoknál, a volumen és az adatforrások alapján.
Az eÁFA M2M külön, áfaspecifikus adat-, validációs és jóváhagyási folyamat.
Az áfabevallást külön kell kezelni
A leggyakoribb tervezési hiba az, hogy a szervezet egyetlen csatornát választ minden kötelezettségre. Az áfabevallás azonban nem követi a többi űrlap útját: 2027-től nem az ONYA-ba kerül. A NAV az áfabevallásra az eÁFA webes felületét, az eÁFA XML-feltöltést és az eÁFA M2M-kapcsolatot kínálja — az ONYA a jelenlegi tervek szerint nem áfabevallási csatorna.
Ez azt jelenti, hogy egy kkv-nak vagy könyvelőirodának jó eséllyel párhuzamosan két irányt kell kezelnie: az áfát az eÁFA-rendszerben, a többi bevallást és adatlapot pedig az ONYA-n, ONYA XML-importon vagy a NAV M2M-en. Aki csak egy csatornára készül fel, az év végén szembesül azzal, hogy a másik felére nincs megoldása.
Az eÁFA 2024. február 1. óta működik, és arra épül, hogy a NAV-nál már rendelkezésre állnak adatok — online számla, pénztárgép, vám. A webes felületen a NAV automatikus adókódolással bevallástervezetet készít, amelyet az adózó áttekint és jóváhagy. Az eÁFA M2M ezzel szemben strukturált XML-adatszolgáltatás, amely a vállalatirányítási vagy könyvelőrendszerbe integrálva működik.
Fontos fogalmi különbség, amit a gyakorlatban sokan összekevernek: a NAV M2M és az eÁFA M2M nem felcserélhető. A NAV M2M az általános gépi űrlap- és adatkapcsolat; az eÁFA M2M az áfabevallás alapját képező nyilvántartás strukturált beküldésének saját, áfaspecifikus csatornája.
eÁFA webes felület
A NAV a rendelkezésére álló adatokból tervezetet készít, amelyet átnézni és jóváhagyni kell. Alacsonyabb volumennél, kevés kivétellel működő folyamatnál elegendő lehet.
eÁFA XML-feltöltés
Az adat egy rendszerből, strukturáltan érkezik, de a beküldést ember indítja. Köztes lépcső integrációfejlesztés nélkül.
eÁFA M2M
Teljes gépi kapcsolat: az áfanyilvántartás strukturált beküldése az ERP-ből vagy könyvelőrendszerből. Rendszeres, nagy volumenű működésnél ez skálázódik.
Egy szempont, amit érdemes ismerni: az Áfa törvény 10. számú mellékletének 15. pontja szerint az eÁFA-rendszerben benyújtott bevallás esetén az adózó mentesül az M-lap benyújtása alól — akár webes felületen, akár M2M-en adta be. A 2026. július 1-jétől hatályos szigorúbb M-lap szabályok visszavonását a Pénzügyminisztérium 2026 júniusában javasolta, így az átmeneti fejlesztési kényszer megszűnt. A korai eÁFA-átállás gazdasági indoka viszont megmaradt: 2027-től új bevallás ÁNYK-n nem adható be, tehát minden további rövid távú ÁNYK-fejlesztés egyre kevésbé térül meg.
ERP-t használó szervezetnél hol van a valódi munka?
Közép- és nagyvállalatnál az átállás ritkán szól csak az új beküldési felületről. A tapasztalat szerint a projekt nem az XML előállításán bukik el, hanem az alatta lévő adaton és a felelősségi rendben. Négy terület, amit érdemes a fejlesztés előtt felmérni.
Adókód-megfeleltetés (mapping)
Az eÁFA M2M XML nem a vállalat belső adókódjait használja, hanem a NAV standard adókódjait. A párosítás minősége dönti el, hogy a beküldött adat értelmes-e. Ezt a felmérést érdemes előbb elindítani, mint az integrációt — utólag javítani lényegesen drágább.
Áfaanalitika audit
A legtöbb áfaanalitikában nem található meg minden mező, amit az eÁFA-rendszer elvár, vagy nem a megfelelő minőségben. A felkészülés egyik első lépése az áfaanalitika szerkezetének összevetése az eÁFA követelményeivel.
Felelősségi mátrix és audit nyomvonal
Ki készíti az adatot, ki validálja, ki hagyja jóvá, ki küldi be? Gépi kapcsolatnál minden beküldésnek egyértelmű digitális nyoma van, ezért a vállalat oldaláról is dokumentáltnak kell lennie, hogy ki, mikor, milyen adat alapján mit hagyott jóvá.
Parallel run és tesztelési ütemterv
Az új csatornát célszerű több hónapig az ÁNYK-val párhuzamosan futtatni. Az összevetés nélkül nem lehet biztosra venni, hogy az eÁFA-tervezet ugyanazt mondja, mint a saját analitika — és pont ezt a különbséget nem érdemes a határidő hetében felfedezni.
Egy megközelítés bizonyul rendre jobbnak: ne külön fejlesszétek az átmeneti és a végleges modellt. Ha a szervezet ugyanazokra az adatokra, szabályokra és kontrollpontokra épít, az átállás később jóval kisebb súrlódással vihető végig.
A négy leggyakoribb hiba
A „majd ősszel megnézzük” hozzáállás
Aki őszre halasztja az indulást, az év végén kényszermegoldásra szorul — kevesebb idővel, nagyobb nyomás alatt, és jellemzően drágábban.
Az átállás IT-projektként kezelése
A változás folyamatszervezési és jogosultságkezelési kérdés is. Egy ERP-konfigurációval csak a felszínt érinti a szervezet; a jóváhagyási lánc és a kivételkezelés ettől nem lesz rendben.
Kihagyott parallel run
Az új és a régi eredmény összevetése nélkül nem lehet biztos, hogy a két folyamat ugyanazt adja. Ez a lépés az, amit a legkönnyebb kihagyni, és amit a legdrágább pótolni.
Az adatminőség és a mapping elhanyagolása
Mivel az eÁFA M2M a NAV adókódjait használja, a belső kódok megfeleltetése nélkül a technikailag hibátlan XML is tartalmilag rossz adatot vihet be.
Hogyan válasszon csatornát?
A NAV ügyfélkörönként ad iránymutatást, a döntést viszont kötelezettségenként kell meghozni. Az alábbi szempontok gyakorlati tapasztalaton alapulnak, nem NAV-előírások — de ezek mentén szokott eldőlni, hogy melyik út működik hosszú távon.
Honnan jön az adat?
Ha az adat ma is egy rendszerben (ERP, könyvelőprogram, számlázó) keletkezik, akkor a kézi újragépelés nemcsak lassú, hanem hibaforrás is. Ilyenkor XML-import vagy gépi kapcsolat felé érdemes indulni. Ha az adat ma is kézzel áll össze, a böngészős út elegendő lehet.
Milyen gyakori és mekkora a volumen?
Havi néhány tétel esetén a felületi kitöltés fenntartható. Rendszeres, sok soros adatszolgáltatásnál viszont a kézi működés a hónap végén torlódik, és pont akkor kell gyorsan hibát javítani, amikor a legkevesebb az idő.
Hány cégre vagy entitásra kell beadni?
Egyetlen cégnél a felületváltás kezelhető. Több tucat ügyfélnél a jogosultságok, meghatalmazások és státuszok követése önmagában is feladattá válik — ez a könyvelőirodák tipikus szűk keresztmetszete.
Ki ellenőrzi és ki hagyja jóvá?
A gépi kapcsolat nem szünteti meg a szakmai felelősséget. Érdemes már most rögzíteni, hogy ki nézi át az adatot beküldés előtt, és ki hagyja jóvá — mert ez a folyamat az új csatornán is kell, csak más felületen.
Van-e fejlesztői vagy szolgáltatói kapacitás?
A gépi csatorna műszaki előírásokat, regisztrációt és jogosultságkezelést igényel. Ha nincs belső fejlesztő, akkor vagy erre felkészített szoftvert kell választani, vagy időben kell szolgáltatót keresni — a negyedik negyedév erre már szűk.
Mit tegyen most — szervezettípus szerint
Könyvelőiroda
Kezdje ügyfélszegmentálással: melyik ügyfélnél melyik kötelezettség megy ma ÁNYK-val, és melyikük hoz gépből adatot. A NAV a könyvelőknél mind az öt csatornát felsorolja, ezért egy irodán belül reálisan többféle utat kell majd párhuzamosan vinni. A legnagyobb rejtett munka nem a beküldés, hanem a jogosultságok és a státuszok követése több tucat cégen keresztül.
ERP-t használó közép- vagy nagyvállalat
A NAV nagyvállalatoknál kizárólag gépi csatornát jelöl meg, tehát ez fejlesztési projekt. A tapasztalat szerint a kritikus pont nem az XML előállítása, hanem az alatta lévő törzsadat minősége: áfakódok, partneradatok, bizonylattípusok. Érdemes az adatminőségi felmérést előbb elindítani, mint az integrációt.
Kisvállalkozás saját könyveléssel
Nézze meg, hogy a ma használt nyomtatványai elérhetők-e az ONYA-n. Ha az adat már egy programban áll elő, az ONYA XML-import gyakran elegendő, és nem igényel fejlesztést. Teljes gépi kapcsolatra csak akkor van szükség, ha a volumen indokolja.
Szoftverfejlesztő és ERP-szállító
A NAV M2M 4.0 / BizonylatAPI publikálása 2026. július 31-re várható. Ügyfelei akkor fognak egyszerre jelentkezni, amikor a határidő közeledik, ezért érdemes a specifikáció megjelenésekor elkezdeni a felkészülést, és nem az utolsó negyedévben.
Négy gyakori félreértés
„2027-től az ÁNYK megszűnik, és eltűnik minden.”
Ez a leggyakoribb tévedés. A határidő az új bevallások beadására vonatkozik: 2027. január 1-jétől új bevallás nem nyújtható be ÁNYK-n. A program viszont korlátozott átmeneti funkcióként elérhető marad a korábban ezen a csatornán beadott időszakok önellenőrzéséhez, az adott időszak nyomtatványával. Vagyis nem „megszűnésről”, hanem szerepváltásról van szó: napi munkaeszközből archív javítóeszközzé válik.
„Elég lesz átállni az ONYA-ra.”
A NAV ügyfélkörönként eltérő csatornákat jelöl meg, és nagyvállalatoknál kifejezetten a gépi kapcsolatokat (NAV M2M, eÁFA M2M) nevezi meg. Az ONYA tehát nem univerzális válasz.
„Az M2M csak nagyvállalatoknak való.”
A NAV a kis- és középvállalkozásoknál és a könyvelőknél is felsorolja a NAV M2M-et és az eÁFA M2M-et a lehetséges csatornák között. A méret önmagában nem dönti el a kérdést — a volumen és az adatforrás igen.
„A gépi kapcsolat után nem kell ellenőrizni az adatot.”
A gépi csatorna az adatcsere és a beküldés infrastruktúráját adja. A jogosultságok, az adat szakmai előkészítése, ellenőrzése és a felelősségi rend továbbra is az adózó oldalán marad.
Felkészülési ellenőrzőlista
- Készítsen leltárt a ma ÁNYK-val kezelt bevallásokról, adatlapokról és adatszolgáltatásokról.
- Minden kötelezettséghez azonosítsa a NAV által támogatott jövőbeli csatornát.
- Mérje fel, honnan érkeznek az adatok, ki ellenőrzi és ki hagyja jóvá a beküldést.
- Nézze meg, hol elegendő az ONYA XML-import, és hol indokolt a teljes gépi kapcsolat.
- A szoftveres vagy ERP-integrációt érintő folyamatoknál egyeztessen időben a fejlesztővel vagy szolgáltatóval.
- Rögzítse, kinek milyen jogosultsága és meghatalmazása kell az új csatornán.
- Tervezzen tesztidőszakot: az első éles beküldés ne a határidő napjára essen.
- Rögzítse időszakonként, hogy a bevallás melyik csatornán került beadásra — egy későbbi önellenőrzésnél ez dönti el a javítás módját.
- Kövesse a NAV átállási tudástárának frissítéseit és a konkrét ügytípusokra vonatkozó tájékoztatókat.
Gyakori kérdések
Megszűnik az ÁNYK 2027-ben?
Nem szűnik meg, hanem a szerepe változik. Új bevallás 2026. december 31-ig nyújtható be ÁNYK-val; 2027. január 1-jétől új beadásra már nem használható. A korábban ezen a csatornán beadott időszakok önellenőrzéséhez azonban korlátozott átmeneti funkcióként elérhető marad, az adott időszak nyomtatványával és az általános elévülési szabályok szerint.
Az ONYA minden esetben kiváltja az ÁNYK-t?
Nem. A megfelelő csatorna az ügytípustól, az érintett nyomtatványtól és a szervezet működésétől függ. A NAV az átállási tudástárban ügyfélkörök szerint ad iránymutatást: magánszemélyeknél az ONYA-t nevezi meg, nagyvállalatoknál viszont a NAV M2M és az eÁFA M2M csatornákat.
Mikor lehet indokolt a NAV M2M?
Jellemzően akkor, ha rendszeres, nagyobb volumenű adóügyi vagy adatszolgáltatási folyamatot ügyviteli rendszerrel kezelnek, és a böngészős, kézi működés nem skálázódik jól. A NAV nagyvállalatoknál kifejezetten ezt a csatornát jelöli meg.
Mi az ONYA XML-import, és mikor elég ez?
Az ONYA XML-import köztes megoldás a kézi kitöltés és a teljes gépi kapcsolat között: az adat egy rendszerből, XML formátumban érkezik, a beküldést azonban továbbra is ember indítja a felületen. Akkor lehet elegendő, ha az adat már előáll valamilyen programban, de nincs igény vagy kapacitás integrációfejlesztésre.
Kell-e saját fejlesztő a gépi csatornához?
Nem feltétlenül. Használható erre felkészített kliensprogram vagy platform is. Saját fejlesztés esetén viszont a vállalatnak vagy a szoftverfejlesztőnek követnie kell a NAV műszaki specifikációit, valamint a regisztrációs és jogosultsági követelményeket.
Hogyan tudok önellenőrzést beadni egy korábbi, ÁNYK-s időszakra?
Az önellenőrzéshez az adott időszak bevallási nyomtatványát kell használni, és erre az ÁNYK 2027 után is elérhető marad átmeneti funkcióként. Ez nem új beadási lehetőség: kizárólag a korábban ezen a csatornán benyújtott időszakok rendezését szolgálja. Az általános elévülési szabályokat is figyelembe kell venni.
Miért kell nyilvántartani, hogy melyik időszak melyik csatornán ment be?
Mert egy későbbi önellenőrzésnél ez dönti el, hol és milyen nyomtatvánnyal kell javítani. Az átállás után egy ideig párhuzamosan lesznek ÁNYK-n és az új csatornákon beadott időszakok, és az elévülési időn belül bármelyikhez érkezhet javítási igény. Érdemes tehát már most rögzíteni időszakonként a beadás csatornáját.
Hol lehet kérdezni az átállásról?
A NAV az átállási tudástár mellett külön e-mail-címet is megadott a témához: anykkivaltas@nav.gov.hu. Konkrét ügytípusra vonatkozó kérdésnél érdemes közvetlenül itt vagy a NAV ügyfélszolgálatán érdeklődni.
Hivatalos források
- NAV: ÁNYK-átállás – tudástár a NAV-tól (2026. július 15.)
- NAV: Az ÁNYK-átállás központi tájékoztató oldala (ügyfélkörönkénti bontás)
- NAV: Információs füzetek (évenkénti bontásban, az önellenőrzési füzettel)
- NAV: Adókerekasztal – partnerség a digitális átállásban
Ez a tartalom tájékoztató jellegű, és nem minősül adótanácsadásnak. A leírtak a 2026. július 25-én elérhető NAV-tájékoztatásokat tükrözik; konkrét ügyben egyeztessen adótanácsadójával vagy a NAV-val.