Az ePénztárgépek műszaki dokumentációja elérhető a NAV GitHub-oldalán, de a specifikáció és az interfészek 2026 nyarán is változnak. A fejlesztőknek úgy kellene piacra szánt terméket készíteniük és engedélyeztetniük, hogy közben több alapvető műszaki és eljárási részlet még nem tekinthető véglegesnek.
A specifikáció talán már megvan, de még mindig változik
A NAV a nav-gov-hu/eRECEIPT GitHub-repozitóriumban közzétette az ePénztárgépek fejlesztői dokumentációját, az adatstruktúrákat, az XSD-állományokat, az API-leírásokat és egyes mintafájlokat. A dokumentáció tehát nyilvánosan hozzáférhető, és a fejlesztők számára rendelkezésre áll egy műszaki kiindulópont. Fontos körülmény, hogy a régi TRIS már „nem játszik”.
A kiindulópont azonban továbbra is mozog. A NAV 2026. május végén még az 1.1-es XSD-t és az 1.5-ös fejlesztői dokumentációt hangolta össze, július 10-én pedig újabb nyugta-adatszolgáltatási interfészspecifikációt és XSD-t tett közzé. Ez azt jelenti, hogy a fejlesztési és engedélyezési időszak közben is változnak azok az interfészek, amelyekre a gyártóknak a termékeiket építeniük kell. A helyzet olyan, mintha a NAV egy repülőteret üzemeltetne és felszállásra kötelezik a gyártókat, de most készül még csak a kifutópálya.
Nyitott kérdések maradtak a fejlesztői felületen
A GitHub-repozitóriumban nemcsak dokumentáció, hanem fejlesztői kérdések is találhatók. Ezek között olyan alapvető architekturális kérdés is szerepel, hogy a felhőalapú ePénztárgépek számára lesz-e a NAV rendszeréből elérhető terméktörzs-lekérdező végpont, vagy ez a funkció csak a hardveres pénztárgépekre vonatkozik.
Ez a kérdés 2025 júniusa óta nyitva van. A fejlesztők számára ugyanakkor nem mellékes részletről van szó: a terméktörzs kezelése meghatározhatja az alkalmazás adatmodelljét, felhasználói működését, integrációját és későbbi karbantartását. Ha egy ilyen kérdésre nincs egyértelmű és végleges válasz, akkor a fejlesztés során több lehetséges rendszerarchitektúrával is számolni kell.
A hardveres engedélyezés nehezen követi a szoftverfejlesztést
Az ePénztárgép-rendszerben továbbra is erősen jelen van a hagyományos pénztárgépekből örökölt típusengedélyezési logika. A hardveres eszközt be kell vizsgálni, a gyártónak vagy forgalmazónak referenciaeszközt kell biztosítania, és egyes szoftver- vagy hardvermódosítások az engedély módosítását is szükségessé tehetik.
Ez a modell egy zárt, ritkán változó készüléknél kezelhető. Egy internetkapcsolatra, távoli szolgáltatásokra, rendszeres biztonsági frissítésekre és folyamatos szoftverkarbantartásra épülő rendszer esetében azonban az engedélyezett állapot gyorsan elválhat a ténylegesen használt szoftververziótól. A hatósági folyamatnak ezért nemcsak az első forgalomba hozatalt, hanem a későbbi frissítések gyors és ellenőrizhető kezelését is támogatnia kellene.
A távfelügyelethez szükséges funkciók már rendelkezésre állnak
Az ePénztárgépek tervezett műszaki működése eleve tartalmazza a távoli ellenőrzés több alapvető elemét. A rendszer állapot- és hibajelentéseket továbbíthat, naplókat küldhet, távoli feladatokat fogadhat, kezelheti a tanúsítványokat, támogathatja a szoftverfrissítést, és bizonyos esetekben lehetőséget adhat az eszköz távoli blokkolására vagy feloldására is.
Ezek alapján az ePénztárgépek felügyelete jelentős részben távolról is megszervezhető. A hatóság folyamatosan ellenőrizhetné az eszköz állapotát, szoftververzióját, kommunikációját és sértetlenségét, míg helyszíni vizsgálatra elsősorban rendellenesség, manipulációgyanú, tartós kommunikációs hiba vagy célzott kockázatelemzés alapján lenne szükség.
Az éves helyszíni felülvizsgálat helyett folyamatos ellenőrzés kellene
A hagyományos online pénztárgépeknél továbbra is létezik az éves felülvizsgálat rendszere. Ennek keretében a szerviz többek között ellenőrzi a készülék állapotát, az adóügyi egység működését és azt, hogy történt-e illetéktelen beavatkozás.
Az ePénztárgépeknél ennek automatikus továbbvitele nem következik a technológiából. A készülék fizikai alkatrészeinek javítása és karbantartása természetesen továbbra is szükséges lehet, de az adóügyi megfelelőség ellenőrzése folyamatos távfelügyelettel, digitális naplózással és automatizált integritásvizsgálattal is megoldható. Így a hatósági kontroll nem évente egyszer, hanem a működés teljes időtartama alatt rendelkezésre állhatna.
A gyártásnak már el kellett volna indulnia
Egy új pénztárgéptípus kifejlesztése nem a specifikáció elolvasásával ér véget. A gyártóknak hardvert kell tervezniük vagy beszerezniük, szoftvert kell fejleszteniük, tesztelniük kell az integrációkat, fel kell készülniük a tanúsításra és az engedélyezésre, majd meg kell szervezniük a gyártást, a forgalmazást és az ügyféltámogatást.
Ehhez stabil műszaki és jogi környezet szükséges. Ha az interfészek, a fejlesztői dokumentáció és az engedélyezési feltételek közvetlenül a bevezetés előtt is változnak, akkor a gyártók számára csökken a tényleges fejlesztési és tesztelési idő. A késedelem így nemcsak a hatósági oldalon jelenik meg, hanem átkerül a fejlesztőkhöz, a forgalmazókhoz és végül a pénztárgépet használó vállalkozásokhoz is.
Az eNyugtát be kell vezetni, önálló új készülék viszont még nincs
Az elektronikus nyugtarendszer bevezetése az uniós digitalizációs és adatszolgáltatási elvárásokhoz is kapcsolódik, ezért az eNyugta-rendszer kialakítása nem hagyható el és azt már az EU is megköveteli. A szabályozásnak és a technikai infrastruktúrának olyan időpontban kell működőképessé válnia, hogy a vállalkozások, a fejlesztők és a forgalmazók ténylegesen fel tudjanak készülni az átállásra.
Jelenleg azonban az a vállalkozó, aki nem mobiltelefonos vagy felhőalapú alkalmazást szeretne használni, hanem önálló, új generációs pénztárgépet vásárolna, még nem talál ilyen eszközt a piacon. Számára továbbra is a korábbi technológiára épülő online pénztárgép áll rendelkezésre. Az eNyugta bevezetése úgy közeledik, hogy a NAV nem gondoskodott a rendelkezésre álló technológiáról, mert elkésett a specifikációval.
A számlázz.hu beadta a kérelmet, de engedély még mindig nincs
A piacvezető Számlázz.hu részéről megerősítették, hogy a társaság benyújtotta az ePénztárgép-megoldására vonatkozó pályaművet, az engedélyezés azonban nem zárult le. Elmondása szerint az ügyintézési határidő is eltelt, miközben a társaság továbbra sem kapott olyan döntést, amely alapján biztosan tervezhetné a szolgáltatás piaci bevezetését. A bizonytalanságot növeli, hogy a fejlesztők további specifikációmódosításokkal is és ezért további költségekkel számolnak, ami korántsem elfogadható üzleti környezet.
A NAV alkalmazása és az eÁfa eltérő adatokat is mutathat
Egy – jogkövetésben jeleskedő – piacozó egyéni vállalkozó már hónapok óta alkalmazza a NAV ePénztárgép alkalmazását. A 2026. június hónapra már július első hónapjaira kérte az eÁfa adatok zárását. Csakhogy az eÁfa bevallásban és az ePénztárgép alkalmazás összesített adata között jelentős eltérés volt. Míg az ePénztárgép összesen 900 ezer körüli forgalmat mutatott, addig az eÁfa 1 millió feletti összeget.
Miután az eltérést nem lehetett vizsgálni a még nem lekérdezhető KOBAK adatok miatt, így csak arra lehetett támaszkodni, amit a képernyőképén küldött és a bevallást – miután az eÁfa adataiban a bevétel nem módosítható – végül ÁNYK 2665-ös nyomtatványon kellett beküldeni, igaz az XKR állományt a ChatGPT simán előállította a táblázatok és a májusi XKR fájl segítségével, 2 perc alatt. Jogosan merül fel a kérdés: valóban eltérhet az ePénztárgép által gyűjtött forgalom és az eÁfa oldalon ugyanarra az időszakra vonatkozó adat?
Nem fogják kérni a próbavásárlások során a papíralapú nyugtát
A hivatali forrásaink megerősítették, hogy a NAV próbavásárlást végző revizorai nem fogják rutinszerűen kérni az eNyugta papíralapú változatát – ahogy egy rendőrtől se szép, ha mindent rendben talál és előveteti az elakadásjelző háromszöget… Ha ugyanis az elektronikus nyugta szabályosan elkészült, és a kibocsátása a QR-kóddal igazolható. Ez azonban nem változtat a jogszabályon: az Áfa tv. 174. § (2) bekezdése szerint az eNyugtát kizárólag elektronikusan lehet kiállítani és kibocsátani, a 174. § (3) bekezdése alapján viszont a vásárló kérésére papíralapú másolatot kell rendelkezésre bocsátani. A revizori gyakorlat tehát nem új mentesség, hanem annak elfogadása, hogy az ellenőrzés során önmagában az elektronikus nyugta bemutatása elegendő lehet.
A papírmásolat lehetőségéhez ugyanakkor a vállalkozónak technikailag – elvileg – fel kellene készülnie. Egy egyszerű Bluetooth-os hőnyomtató hozzávetőleg 20–30 ezer forintos többletköltséget jelent, de a probléma nem áll meg a vásárlásnál. A készüléket párosítani kell a telefonnal, be kell állítani az alkalmazásban, kezelni kell a jogosultságokat, a papírméretet, a kapcsolat megszakadását és a nyomtatási hibákat. Sok fodrász, kozmetikus vagy piaci árus nem rendelkezik ehhez megfelelő informatikai rutinnal, ezért a bevezetéshez nem elég egy használati útmutató: közérthető oktatás, rövid videók, ügyfélszolgálat és tényleges telepítési segítség kellene, de jelenleg a NAV ilyen edukációt nem folytat.
A gyakorlatban persze egy fodrász kuncsaftja várhatóan nem fog papírnyugtát kérni. Első alkalommal azonban azt sem feltétlenül érti majd, miért mutogat neki a fodrásza egy QR-kódot, és miért mondja azt, hogy a nyugtát már kiállította, miközben semmilyen papírt nem kapott a kezébe. Ezt az idősebb vásárlók is majd csak lassan fogják megérteni. Hasonló átállás történt a repülőtéri beszállókártyáknál is: először szokatlan volt, hogy a dokumentum nem papíron, hanem egy telefonos alkalmazásban jelenik meg, ma viszont sok utas számára – még az idősebbeknek is – ez már természetes.
A témáról megkérdeztem az adóhatóságot, ha válaszolnak, akkor frissítem a cikket.
Ruszin Zsolt, a FairConto Zrt. részvényese
Save as PDF
