Az eÁFA Machine-to-Machine (gép-gép közötti, M2M) interfész 2.0-ás verziója a korábbi adatstruktúrát több ponton is érdemben átalakítja. Az új XSD-séma részletes interfészspecifikációja is publikálásra került, ezzel a változások iránya és logikája már teljes mértékben megismerhető. A cikk célja, hogy a 2.0-ás verzió módosításait nem informatikai, hanem elsősorban adószakmai és könyvelői szemszögből mutassa be. A technikai változások mögött ugyanis adózási döntések állnak és adózási folyamatok kialakítása húzódik meg, amelyek közvetlenül érintik az áfaanalitika összeállítását és a könyvelőprogramban rögzítendő adatok körét.

A változások okai

A változások mögött három fő motiváció áll. Az első a nyomtatványlogikától való teljes elszakadás. A korábbi struktúra a mellékletek vonatkozásában lényegében az ÁNYK-nyomtatványok logikáját követte, beleértve a mezőazonosítókat is. Ez a megközelítés évtizedes tradíción nyugodott, de a gépi feldolgozás érdekében több szempontból sem volt fenntartható. Az ÁNYK keretrendszer nyugdíjazásával ugyanis értelmét veszti a nyomtatvány vizuális elrendezését tükröző adatstruktúrarész, annak összes fejlesztői kihívásával együtt. A 2.0-ás verzió ezt a kapcsolatot szándékosan megszünteti, és ezáltal egy fenntartható adatstruktúra alakult ki.

A második mozgatórugó a szoftverfejlesztői visszajelzések beépítése. Az eÁFA M2M indulása óta az éles használat során több olyan tapasztalat gyűlt össze, amelyek a korábbi struktúra finomítását indokolták. Az adatstruktúra átalakításán túlmenően olyan validációs szabálymódosulásokra is sor került, amelyet a szoftverfejlesztők több fórumon keresztül is jeleztek az adóhivatal számára.

A harmadik motiváció pedig az áfaanalitika szerepének továbbfejlesztése: a cél az, hogy a melléklapok egy részét közvetlenül az analitika tételeiből származtassuk, és ne kelljen külön kitölteni azokat, amelyek tartalmilag amúgy is az analitikában rögzített adatokból következnek.

A 2.0-ás verziószám egy fontos üzenet is, hiszen nem csupán apró korrekciókat hoz magával, hanem lényeges adatstrukturális változást is. Ez azonban nem jelenti azt, hogy az eddig működő implementációk teljesen érvényüket veszítenék. Nem az eÁFA M2M alaplogikája változik meg, és nem is a teljes áfaanalitika-struktúra. A változások ugyan a jelenleg működő szoftvereknél is fejlesztéssel járnak, az új implementációk ugyanakkor egyszerűbbek és könnyebbek lesznek.

Adatstruktúra-változások: elszakadás a nyomtatványlogikától

A technikai változások közül például a melléklapok korábbi gyűjtőelemét (sheet csomópont) és a bevallás kiegészítő adatait (declarationAdditionalData) tartalmazó adatcsoportok kivezetése egyértelműen jelzi a nyomtatványalapú működéstől való elszakadást. A számlamódosítás és a sztornó jelölő vagy a közvetett vámjogi képviselő jelölő bevezetése az áfaanalitikába szintén a nyomtatványtól való elszakadásnak a következménye. Az áfaanalitika szerepe tehát jelentősen erősödött, és csak azok az adatok maradtak kiegészítő adatstruktúraként, amelyekre bár szükség van, azonban az áfaanalitika-logikától jelentősen eltérnek.

A fordított adózás alá eső értékesítések és beszerzések esetén az adóhivatal kezdetben az áfaanalitika-elemek közé emelte volna a VTSZ számokat, azonban a fejlesztői visszajelzések alapján ez számos technikai és rendszerlogikai problémával járt volna. Éppen ezért megmaradt külön nyilvántartásként.

A nyomtatványlogikától való elszakadás így nem lesz teljes, ugyanakkor a hatékonyság növelhető, és fenntartható megoldások alakulhatnak ki. Nem lehet olyan megoldásokat kialakítani, amelyeket a szoftverfejlesztők nem, vagy csupán jelentős fejlesztések árán tudnának követni. Éppen ezért az adóhivatal eÁFA M2M rendszerrel kapcsolatos kommunikációja az idei évben már eddig is nagyon aktív volt: a GitHubon, személyes megbeszéléseken és közvetlen egyeztetéseken keresztül is gyűjtött fejlesztői, adózói visszajelzéseket. Mindezek figyelembevételével alakult ki a 2.0-ás adatstruktúra és annak működése.

Interfészspecifikáció: kettős tartalom

Az eÁFA M2M 2.0 interfészspecifikáció legnagyobb értéke, hogy az adatstruktúra technikai leírása mellett adószakmai magyarázatot is ad. Az adatstruktúra az eÁFA rendszer váza, amelyet tartalommal jól megtölteni csak úgy lehet, ha mindenki ugyanazt a szabályrendszert tartja be. Az egyes adatelemek mögötti tartalom sokszor fontosabb, mint magának az adatnak a technikai leírása. Jó példa erre a taxpointDate fogalma, vagy a módosító és a sztornó számla jelölése. A könyvelőprogramokban, vállalatirányítási rendszerekben rendelkezésre álló jelentős adatmennyiségből származtatott áfaanalitika csak akkor lesz az adóhivatal számára is érthető és megfelelően feldolgozható, ha az adatok értelmezési tartománya mindkét oldalon egybeesik.

Az adóhivatal által publikált interfészspecifikáció kettős kihívásra válaszol, egyrészt technológiai, másrészt pedig adózási tartalmakra. Hiszen maga az eÁFA M2M nem csupán egy bevallástechnikai kérdés, hanem az áfaanalitikai standard kialakítása következtében az adózói, könyvelői folyamatokban betöltött szerepe alapján az adóbevallás üzleti folyamatába is beavatkozik. Ennek a beavatkozásnak a célja az adózói digitalizáció előmozdítása, hatékony folyamatok támogatása, az adóadminisztráció egyszerűsítése és az utólagos kontrollok helyett azok beépítése a bevallási folyamatba.

Az adatokra vonatkozó szabályok tisztulása

Az áfaanalitika megjelenése eddig az adózótól, a könyvelőprogramtól függött. Az áfaanalitika keretét adó mezők és azok jelentéstartalma akár jelentős eltéréseket is hordozott magában. Nem lehet úgy standardot alkotni, ha nincs egységes fogalomhasználat. Éppen ezért az adatokra vonatkozó szabályalkotás, akár validációkkal is kikényszerítve, a megfelelő működés alapját képezi.

Az adatalapú működéshez szükséges szabályok megalkotása terén hiba lenne, ha az egyes fogalmakat mindenki maga értelmezné, és találná ki hozzá a működést. Ezáltal a bevallás nem lenne egyértelmű, eltérő működések alakulnának ki. Ugyanakkor az adóhivatal csak annyiban avatkozik be a standardizációval az adminisztrációba, amennyire a céljai eléréséhez szükséges.

A számla vagy sztornó jelölő jó példa erre. Ugyanis az adóhivatal nem globálisan szeretné tudni, hogy egy számla módosító vagy sztornó számla az áfaanalitikában, hanem kifejezetten azokat a tételeket szeretné látni, ahol számlabefogadói oldalon utólagos adóalap-csökkenés történik. Ez a logika a jelenlegi nyomtatványalapú bevallásban is megtalálható, az eltérés csupán annyi, hogy az eÁFA-ban elegendő egy jelölőt alkalmazni az adott áfaanalitikai tételsorhoz.

A taxpointDate fogalma szintén egy új kihívás, mivel nem feltétlenül esik egybe a számlán szereplő teljesítési dátummal. Alapvetően az adófizetési kötelezettség vagy az adólevonási jog keletkezésének napját jelenti. Ebből adódik, hogy fizetendő adó esetén az adóbevallási időszakba kell esnie, míg a levonható oldalon lehet annál korábbi dátum is. Ugyanakkor egy bizonylatszám alatt egy bevallási időszakon belül akár többször is előfordulhat, például pénzforgalmi elszámolásnál a részkifizetés esetében.

A taxpointDate dátumát nem feltétlenül tárolja a könyvelőprogram, vagy pedig nem dátumpontossággal tárolja. Ekkor az is megfelelő megoldás, ha a hónap utolsó napja kerül feltüntetésre ebben a mezőben. Ez a gyakorlat szempontjából olyan kompromisszumot jelent, amely az adóhivatali célok szempontjából elfogadható, azonban a fejlesztőket nem tereli jelentős fejlesztések végrehajtása irányába.

A taxBase szintén olyan adat, amelyre a felkészülési folyamatban érdemes nagyobb figyelmet fordítani. Ebben a mezőben ugyanis az adott adópozícióhoz tartozó teljes adóalapot kell feltüntetni – akkor is, ha az áfa csak részben vonható le. A levonási korlátozás nem a taxBase csökkentésével, hanem a deductionOptions csomópont kitöltésével jelenik meg az analitikában.

A deductionOptions csomópont az áfaanalitika legmélyebb adójogi tartalmat hordozó eleme. Itt jelennek meg ugyanis azok az esetek, amelyekben az előzetesen felszámított áfa nem teljes egészében vonható le – legyen szó tételes levonási tilalomról, levonási hányadról vagy arányosításról. A csomópont két mezőt tartalmaz: a deductionRate (levonási hányados) és a deductionAmount (levonási összeg) elemeket. A levonási hányados megadása opcionális. Ha az MD64, MD65 vagy MD66 standard adókódok bármelyike szerepel a tételen, és a deductionOptions csomópont kitöltött, akkor a deductionRate kitöltése kötelező. Ennek hiánya esetén a rendszer hibát jelez, a bevallás nem lesz beadható.

A fentiek csupán néhány kiragadott, azonban az ügyféli, fejlesztői kérdések tekintetében nagyon is fontos példát jelentenek. Mindezeken keresztül érthető meg, hogy miért jelentős hiba, ha valaki az interfészspecifikáció figyelembevétele nélkül végez fejlesztéseket. Az interfészspecifikáció helyes értelmezéséhez azonban adószakmai ismeretek is szükségesek, hiszen végeredményként áfabevallás készül.

Validációs változások: közelebb a gyakorlathoz

Amennyiben az adóhivatal egy M2M-rendszernél validációk átalakításáról beszél, akkor az a fejlesztők számára jellemzően valamilyen szigorítást jelent. Az eÁFA M2M esetén azonban ez inkább a gyakorlati szempontok figyelembevételét jelenti. A validációs változások mögött ugyanis nem csupán új validációk megjelenése, hanem validációk törlése is áll.

A legjelentősebb változás a sourceDocumentId egyediségére vonatkozó elvárás megszüntetése. A korábbi struktúrában minden áfaanalitikai tételsorhoz egyedi forrásdokumentum-azonosítónak kellett tartoznia – ha ugyanaz a sourceDocumentId többször szerepelt, a rendszer duplicated_sourceDocumentId hibát adott vissza. Ez olyan problémákhoz vezetett, hogy eltérő partnertől ugyanaz a számlasorszám nem volt szerepeltethető, de például a pénzforgalmi elszámolás logikájába sem fért bele, vagy a fordított adózás és a közösségi beszerzés esetén is több nehézséget okozott. A 2.0-ás verzióban ez a megkötés feloldódik: egyetlen sourceDocumentId érték több tételsoron is szerepelhet egyszerre.

A partneradatok teljes körű feltüntetési kötelezettsége is eltűnik a 2.0-ás verzióból. Itt azonban erősen megjelenik az az adóhivatali elvárás, hogy a belföldi ügyletek esetén a partner adószámát szerepeltetni kell. Ugyanakkor a címadatok tekintetében a lazítás jelentős adózói, szoftverfejlesztői problémákat old meg.

Paradigmaváltás és pragmatizmus

Az eÁFA M2M 2.0 verzió XSD-változásai első ránézésre kifejezetten technikai jellegűnek tűnhetnek, de a valóságban egy jól átgondolt adózási és könyvelési paradigmaváltást hordoznak. A nyomtatványlogikától való elszakadás, az analitika központi szerepének megerősítése és a melléklapok egy részének automatikus levezetése együttesen azt eredményezi, hogy az eÁFA rendszer egyre inkább nem egy bevallási csatorna, hanem az áfaanalitika közvetlen integrálásának eszköze.

A változások mögött ugyanakkor egy fontos pragmatikus megfontolás is meghúzódik: a NAV láthatóan figyelembe vette a piaci szereplők visszajelzéseit, és a 2.0-ás verzió több olyan ponton is egyszerűsít, ahol a korábbi struktúra szükségtelenül szigorú volt.

A 2.0-ás verzióval a NAV egy olyan struktúrát publikált, amely már a 2027-től fenntartható, hosszú távon működőképes rendszer alapjait fekteti le. A szoftverfejlesztők számára ez világos és kiszámítható irányt jelent a felkészüléshez.