Adótechnológiai fogalomtár

A legfontosabb ÁNYK-, ONYA-, NAV M2M- és eÁFA-kifejezések röviden, hivatalos NAV-források és fejlesztői dokumentáció alapján.

Szakmai szerző: Kovács András

Csatornák és rendszerek

Melyik felületen vagy interfészen keresztül teljesíthető a kötelezettség.

ÁNYK

Általános Nyomtatványkitöltő Keretprogram: a NAV telepíthető, fájlalapú nyomtatványkitöltő programja.

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 adott időszak nyomtatványával.

Gyakori félreértés: Nem „megszűnik”: a határidő az új bevallások beadására vonatkozik, a program az önellenőrzéshez megmarad.

Részletes magyarázat: ÁNYK

Forrás: NAV: Az ÁNYK-átállás tájékoztató oldala

API

Meghatározott üzleti célhoz kapcsolódó, egymással összefüggő interfész-műveletek és a hozzájuk tartozó adatszerkezetek együttese.

Egy API-ban több tárgyra vonatkozó művelet is lehet; egy adott tárgy műveletei fő szabály szerint egy API-ban vannak. A SOAP API-t WSDL-állomány, a RESTful API-t OpenAPI-dokumentum írja le.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

API Gateway

A kérések autentikációját és autorizációját, valamint a kérések elosztását végző előtétrendszer.

Az eÁFA M2M-ben a hívások ezen keresztül jutnak el a szolgáltatásokhoz. Gyakorlati jelentősége, hogy az azonosítási és jogosultsági hibák jellemzően már itt, az üzleti feldolgozás előtt jelentkeznek.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

eÁFA

A NAV áfabevallási rendszere, amely a hivatalnál már rendelkezésre álló adatokra épülő bevallástervezetet készít.

Három úton érhető el: webes felületen (a NAV tervezetét kell áttekinteni és jóváhagyni), XML-feltöltéssel, illetve gép–gép kapcsolaton (eÁFA M2M). A tervezet alapját az online számla, a pénztárgép- és a vámadatok adják.

Részletes magyarázat: eÁFA

Forrás: NAV: Felkészülés az eÁFA használatára

eÁFA M2M

Az eÁFA-rendszer gép–gép kapcsolata, amelyen az adózó REST API-n keresztül tölti fel az áfabevallás alapját képező adatokat.

Az adózó a Bevallás XML-t tölti fel, amelyből az eÁFA M2M előállítja a bevallást; ezt az adózó ellenőrzés után jóváhagyhatja. A jóváhagyást követően ez az XML tölti be jogilag a bevallás funkcióját.

Gyakori félreértés: Nem azonos a NAV M2M-mel: az eÁFA M2M kifejezetten az áfabevallás csatornája, a NAV M2M az általános gépi űrlap- és adatkapcsolat.

Részletes magyarázat: eÁFA M2M

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Gép–gép kapcsolat (M2M)

Rendszerek közötti közvetlen, emberi beavatkozás nélküli adatkapcsolat.

A NAV fogalomtára az M2M-et egyszerűen „gép-gép kapcsolat”-ként határozza meg. Adóügyi kontextusban két külön megvalósítása él egymás mellett: a NAV M2M és az eÁFA M2M.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

NAV M2M

A NAV M2M API: a NAV által fejlesztett, interneten webszolgáltatásként elérhető, gépi hozzáférésre tervezett publikus és nem publikus szolgáltatások gyűjteménye.

Nem közvetlen humán használatra készült: kliensprogram — ERP, könyvelő- vagy bérszámfejtő program — kapcsolódik hozzá REST vagy SOAP interfészen. A NAV nagyvállalatoknál kifejezetten ezt és az eÁFA M2M-et jelöli meg csatornaként.

Gyakori félreértés: Nem azonos az eÁFA M2M-mel. Külön a fogalomkészletük is: a NAV M2M nem ismeri a „technikai felhasználó” fogalmát, itt kliensprogram-regisztráció és felhasználói regisztráció van.

Részletes magyarázat: NAV M2M

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

ONYA

Online Nyomtatványkitöltő Alkalmazás: a NAV böngészőből használható, telepítést nem igénylő nyomtatványkitöltője.

A NAV az átállási oldalán magánszemélyeknél az ONYA-t jelöli meg, kis- és középvállalkozásoknál és könyvelőknél pedig az ONYA XML-import mellett a gépi csatornákat is. Új nyomtatványoknál egyre gyakoribb, hogy azok kizárólag az ONYA-n érhetők el.

Gyakori félreértés: Az ONYA nem áfabevallási csatorna: az áfabevallás az eÁFA-rendszerbe tartozik.

Részletes magyarázat: ONYA

Forrás: NAV: Az ÁNYK-átállás tájékoztató oldala

ONYA XML-import

Az ONYA felületén elérhető lehetőség arra, hogy az adatok XML-fájlból töltődjenek be, kézi kitöltés helyett.

Köztes lépcső a kézi kitöltés és a teljes gépi kapcsolat között: az adat egy rendszerből, strukturáltan érkezik, a beküldést azonban továbbra is ember indítja. Integrációfejlesztést nem igényel, ezért sok kkv-nál ez a reális első lépés.

Forrás: NAV: Az ÁNYK-átállás tájékoztató oldala

REST

HTTP-alapú tervezési megközelítés (representational state transfer) az interneten zajló interakciók résztvevőinek együttműködésére.

A NAV M2M és az eÁFA M2M egyaránt kínál REST-interfészt; az annak megszorításait követő interfészt nevezik RESTfulnak. A műveleteket OpenAPI-leírás dokumentálja, amely a NAV tárhelyén nyilvános.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

Adat és séma

Milyen adatszerkezetben kell a bevallás alapját átadni, és mi ellenőrzi.

Áfaanalitika

Adott bevallási időszakra vonatkozó kimutatás, amely az alapbizonylatok legfontosabb adatait és további egyedi adatokat (például adómérték, adókód) tartalmaz.

Ezek alapján rendelhetők a bizonylati adatok a bevallásűrlap megfelelő sorához. Az átállás egyik első lépése az áfaanalitika szerkezetének összevetése az eÁFA követelményeivel — a legtöbb analitikában nem szerepel minden elvárt mező.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Bevallás XML

Az az adatstruktúra, amely az elszámolt adót, az áfaanalitikát és az áfabevallás lapjain szereplő adatokat tartalmazza.

Az adózó ezt tölti fel az API-n, ebből az eÁFA M2M előállítja a bevallást, amelyet ellenőrzés után jóvá lehet hagyni. A jóváhagyás után ez az XML tölti be jogilag a bevallás funkcióját.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Bevfeld XML

Az űrlap alapú bevallás XML-állománya, amelynek adattartalma az ÁNYK programban megjeleníthető.

Ez a formátum köti össze a régi, űrlapalapú világot a fájlos kezeléssel. Az átállás tervezésekor érdemes tudni, hogy melyik időszak melyik formátumban áll rendelkezésre.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

SAF-T

Standard Audit File – Tax: az OECD által kifejlesztett, adózási célú adatállomány-struktúra leírása.

Az adózók nyilvántartási és könyvelési rendszereiből történő strukturált adatexportálás követelményét írja le. A magyar adóhivatal 2020–2021 között ügyfelek bevonásával pilot projektet hajtott végre, amelynek eredményei nyilvánosak.

Forrás: NAV: SAF-T_HU projekt tárhely

Standard adókód

A NAV által kialakított adókód-állomány, amely alapvetően ügylettípusokat definiál.

A kódolási rendszer célja, hogy a bizonylaton szereplő információról egyértelműen megadható legyen, melyik bevallássorhoz és adókulcshoz tartozik. Az adóhatóság a táblázatot fixnek tekinti: az eÁFA-rendszerben kizárólag az éppen aktuális standard adókódok szerepeltethetők, a lista viszont ügyféli javaslatok alapján bővíthető.

Gyakori félreértés: Az eÁFA M2M nem a vállalat belső adókódjait használja, hanem a NAV standard adókódjait — a kettő megfeleltetése külön feladat.

Részletes magyarázat: Standard adókód

Forrás: NAV: Standard adókód — a kódképzés logikája

Taxpoint date

Az a dátum, amelyet a bizonylathoz az adófizetési kötelezettség keletkezése, illetve az adólevonási jogosultság megnyílása alapján kell feltüntetni.

Áfafizetési kötelezettséget keletkeztető ügyletnél az a nap, amikor az Áfa tv. szerint a kötelezettség keletkezik — számlánál jellemzően a teljesítési dátum. Levonási jognál az, amikor a jogosultság megnyílik. Az értéknek az adóelszámolási időszakba kell esnie, vagy annál korábbi lehet, de nem korábbi annál, mint amit az Áfa tv. megenged elszámolni.

Gyakori félreértés: A számlán szereplő teljesítési dátum nem feltétlenül egyezik a taxPointDate-tel — nem kizárólag az ügylet teljesítési időpontja határozza meg.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Validáció

Annak ellenőrzése, hogy az adatállomány megfelel-e az előírt séma szabályainak.

A séma szerinti ellenőrzés formai: az elemek meglétét, sorrendjét, típusát és értékkészletét vizsgálja. Azt nem dönti el, hogy a bevallás adózási tartalma helyes-e — arra a NAV feldolgozása és szakmai ellenőrzés szolgál.

Gyakori félreértés: A sikeres sémavalidáció nem jelenti azt, hogy a NAV a bevallást be is fogadja: azon túl üzleti szabályokat is alkalmaz.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

XML

Kiterjeszthető Jelölő Nyelv (eXtensible Markup Language), W3C-szabvány.

A NAV gépi csatornái ebben a formátumban várják az adatot. Az elemek neve, névtere és sorrendje egyaránt kötött — a séma nemcsak azt írja elő, mely elemek szerepelhetnek, hanem azt is, milyen sorrendben.

Forrás: W3C: Extensible Markup Language (XML)

XPath

Lekérdező nyelv XML-dokumentum csomópontjainak kiválasztásához (XML Path Language).

A NAV M2M-ben az új formátumú bizonylatok validációjához és a számított mezők kalkulációjához használják. Ez teszi lehetővé, hogy az ellenőrzés akár a kliens gépén, helyben lefusson.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

XSD

XML-séma definíciós fájl (XML Schema Definition), W3C-szabvány.

Ez írja le, hogy egy adott adatszolgáltatás XML-je milyen elemeket, milyen típussal, sorrenddel és kötelezőséggel tartalmazhat. Az eÁFA 2.0 sémái a NAV eVAT tárhelyén nyilvánosak, verziózva.

Forrás: W3C: XML Schema Definition Language (XSD) 1.1

XSLT

XML-alapú stíluslapnyelv (Extensible Stylesheet Language Transformations), amellyel az XML tartalma és szerkezete más formátummá alakítható.

Az új formátumú bizonylatoknál a validáció és a kalkuláció XPath-műveleteit foglalja magában, és XML formátumban ad eredményt. A nyomtatvány repositoryban bizonylattípusonként elérhető.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

Hozzáférés és jogosultság

Ki és milyen azonosítóval fér hozzá a gépi csatornákhoz.

Aláíró kulcs

A NAV M2M-ben egyes API-üzenetek hitelesítésére szolgáló aláíráshoz használt kulcs, amely teljes egészében csak magában a kliensprogramban áll össze.

Azért áll össze csak a programban, mert két részből születik: az egyik fele az API Key-ben érkezik, a másikat a program a nonce beváltásával kapja meg. Titkosan kell kezelni úgy, hogy emberi megismerése reálisan lehetetlen legyen; az üzenet aláírásán keresztül ez biztosítja a küldött tartalom letagadhatatlanságát.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

API Key

A NAV M2M felhasználói regisztráció eredményeként kiadott, biztonsági információkat tartalmazó titkos kód.

A kliensprogram ezzel lép fel a végfelhasználó nevében. A NAV dokumentációja szerint sorrendben a felhasználó azonosítóját, a felhasználó jelszavát, az aláírókulcs első felét és a nonce-t tartalmazza. Titkos adat: a kezelése ugyanolyan gondosságot kíván, mint egy jelszóé.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

Elsődleges felhasználó

Az eÁFA-rendszer azon felhasználója, aki az adózó maga, törvényes képviselője vagy állandó meghatalmazottja, és teljes körű jogosultsággal rendelkezik a rendszer használatára.

Röviden: az a személy, aki mindenhez hozzáfér, és aki a többi hozzáférést kiosztja. Egyetlen kivétel van: a REST API-n keresztüli adatforgalom, amelyet az elsődleges felhasználó által létrehozott technikai felhasználóval kell teljesíteni. A gépi csatorna beállítása tehát mindig tőle indul.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Felhasználó

A NAV M2M-ben természetes személy számára a regisztráció során létrehozott gépi személyiség, amely az adott személy nevében, kliensprogramon keresztül folytatott kommunikációt szolgálja.

Nem összekeverendő a végfelhasználóval: a végfelhasználó az az ember, aki a kliensprogramot használja vagy az automatikus folyamatokat beállítja — a felhasználó pedig az őt képviselő gépi azonosság a NAV rendszerében.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

Felhasználói regisztráció

A NAV M2M-ben az a regisztráció, amelynek eredményeként a felhasználó megkapja az API Key-t, és amellyel a kliensprogram a nevében eljárhat.

A sorrend a NAV dokumentációja szerint: a fejlesztő regisztrálja a kliensprogramot, az ügyfél ezzel a kliensprogram-azonosítóval elvégzi a felhasználói regisztrációt, majd a kapott API Key-t rögzíti a programban. Ezen felül képviseleti jogosultsággal kell rendelkeznie arra az adózóra, akinek a nevében eljár.

Gyakori félreértés: A NAV M2M-nél nem „technikai felhasználót” kell létrehozni — az az eÁFA-rendszer fogalma. Itt a felhasználói regisztráció és az API Key a belépési pont.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

Kliensprogram

Az a szoftveralkalmazás, amely a NAV M2M API szolgáltatásaihoz hálózati kapcsolaton keresztül hozzáfér.

Független a technikai kialakítástól: lehet ERP-rendszer, könyvelőprogram, bérszámfejtő vagy személyügyi rendszer. Gyakorlati következmény, hogy a gépi csatornához nem feltétlenül kell saját fejlesztés — erre felkészített program is használható.

Forrás: NAV: M2M általános interfész-specifikáció 0.4 — fogalomjegyzék

Meghatalmazás

Az a jogosultsági rend, amely alapján valaki más nevében járhat el a NAV előtt.

Könyvelőirodánál ügyfelenként eltérhet, és az átállás során külön feladat rendezni, ki készíthet elő, ki hagyhat jóvá és ki küldhet be adatot az új csatornán. Az elsődleges felhasználó lehet az adózó állandó meghatalmazottja is.

Forrás: NAV: Az ÁNYK-átállás tájékoztató oldala

Technikai felhasználó

Az eÁFA-rendszerben a REST API-n keresztüli adatszolgáltatáshoz szükséges felhasználó, amelyet az elsődleges felhasználó hozhat létre a felhasználókezelőben.

Nem ember, hanem a programnak létrehozott hozzáférés: a gépi kapcsolat nem a napi ügyfélkapus belépéssel működik. Előzetesen technikai felhasználót kell létrehozni, vagy egy meglévőnek beállítani a megfelelő jogosultságot. Ez a fejlesztés előfeltétele, nem a következménye.

Gyakori félreértés: Ez az eÁFA-rendszer fogalma. A NAV M2M interfész-specifikációiban nem szerepel: ott kliensprogram-regisztráció és felhasználói regisztráció van, amelynek eredménye az API Key.

Részletes magyarázat: Technikai felhasználó

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Bizonylat és eljárás

A beküldés tárgya és a hozzá kapcsolódó eljárási fogalmak.

Adózó

Az a Magyarországon nyilvántartásba vett adóalany, aki vagy amely a jogszabályok alapján áfabevallásra kötelezett.

Az eÁFA M2M dokumentációjában ez a fogalom jelöli a kötelezettség alanyát. A gépi csatorna használatakor is az adózó marad a bevallás tartalmáért felelős fél.

Forrás: NAV: eÁFA M2M 2.0 interfészspecifikáció — Kifejezések, rövidítések

Bevallástervezet

A NAV által a rendelkezésére álló adatokból összeállított áfabevallás-javaslat, amelyet az adózó áttekint és jóváhagy.

A webes eÁFA-felületen a NAV automatikus adókódolással készíti el. A jóváhagyás nem formalitás: a benyújtott tartalomért az adózó felel, ezért a tervezetet a saját analitikával össze kell vetni.

Forrás: NAV: Felkészülés az eÁFA használatára

Bizonylat

A kliensprogramban kitöltött, a felhasználó nevében beküldött nyomtatvány.

A NAV M2M fogalomkészletében a bizonylat a beküldés tárgya. Egy bizonylat funkcionálisan elkülöníthető részekre — részbizonylatokra — bontható, és csatolmányok részbizonylatonként kapcsolhatók hozzá.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

Bizonylat formátum

A régi és az új formátumú bizonylatok megkülönböztetése a NAV M2M-ben.

A régi formátumúak — amelyek az ÁNYK-n keresztül is beküldhetők — minden bizonylatra nézve egy közös XSD-n alapulnak és mezőkódlistát tartalmaznak. Az új formátumúak bizonylatonként egyedi XSD-vel rendelkeznek, és a számított mezők kalkulációját, valamint a validációt önálló, XSLT-alapú műveletek támogatják, amelyek akár a kliens gépén is lefuttathatók.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

Bizonylattípus

A bizonylatok funkcionálisan jól elkülöníthető csoportja.

Ez felel meg annak, amit a mindennapokban „nyomtatványnak” hívunk. Kóddal azonosított; a NAV új bizonylat specifikációjának példája a T1042E.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

Csatolmány

A bizonylathoz kapcsolt, azt kiegészítő fájl.

Részbizonylatonként csatolható. A csatolmánytípus nem keverendő össze a fájltípussal: az előbbi a csatolmány szerepét jelöli, az utóbbi a fájl technikai formátumát.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

Nyomtatvány repository

Publikus tárhely, amely az egyes nyomtatványtípusokhoz és -verziókhoz tartozó XSD-, kalkulációs és validációs XSLT-fájlokat tartalmazza.

Innen szerezhető be, hogy egy adott bizonylatverzió pontosan milyen szerkezetet vár. Fejlesztésnél ez az elsődleges hivatkozási pont a mezők és a számítási szabályok tekintetében.

Forrás: NAV: M2M új bizonylat interfész-specifikáció 1.0

Önellenőrzés

Egy korábban benyújtott bevallás utólagos javítása az adózó részéről.

Az önellenőrzéshez 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. Az ÁNYK ezért 2027 után is elérhető marad a korábban ezen a csatornán beadott időszakokhoz — ez nem új beadási lehetőség, hanem a korábbi időszakok rendezését szolgáló átmeneti funkció.

Gyakori félreértés: Az önellenőrzés és a helyesbítés nem ugyanaz: a helyesbítés bizonylatszinten történik, az önellenőrzés a bevallást érinti.

Részletes magyarázat: Önellenőrzés

Forrás: NAV: ÁNYK-átállás – tudástár a NAV-tól

Részbizonylat

Egy bizonylat funkcionálisan jól elkülöníthető része.

Nagyjából az, amit a papíralapú világban lapnak neveznénk. A részbizonylat-típusok kóddal azonosítottak: a NAV példája szerint az áfabevallás főbizonylatának kódja 65A. A csatolmányok részbizonylatonként kapcsolhatók a bizonylathoz.

Forrás: NAV: M2M ÁNYK bizonylat interfész-specifikáció 0.7

Elsődleges források