E, mint eÁfa…2/2.

Szerző: Sinka Júlia →

Az adóhatóság többször is újragombolta a kabátot, de várhatóan 2023 decemberében már tesztelhetjük, 2024. január 1-től pedig tényleg elindul az eÁfa rendszere.

Cikkem előző részében összefoglaltuk, mit is jelent az eÁfa, mire számíthatunk általában, az új – egyelőre még csak választható, de nem kötelező – rendszer bevezetésétől.

Vállalkozói szemmel nézve a bevallástervezet mellett és ellene is szólnak érvek. Az alábbiakban ezeket gondoljuk át.

Érvek pro és kontra

Nos, ennek az éremnek is két oldala van, jelen esetben sem csupán a hatóság online felületeiről és mögöttük álló technikáról beszélünk, hanem szólni kell egyrészt arról az elvárásról (és mindenről, ami ebben foglaltatik), hogy a gép-gép kapcsolat során, ügyféli oldalon az ügyviteli rendszernek is alkalmasnak kell lennie az eÁfa M2M rendszer sajátosságainak kezelésére. Amúgy a NAV készített ehhez fejlesztői dokumentációt is, és azt a hasznos felhasználói javaslatok megismerésére a legismertebb fejlesztői platformon, a GitHub felületén mindenki számára hozzáférhetővé tette. Elérési útvonal: https://github.com/nav-gov-hu/eVAT/

Adózói oldalon így is számolni kell a szükséges fejlesztések költségeivel.

Másrészt az új rendszer mellett és ellen is szólnak – egyaránt méltányolható – érvek.

Az eÁfa mellett tehetik le voksaikat azok az adózók, amelyek:

jellemzően olyan ügyleteket bonyolítanak, amelyek a NAV előbbiekben említett adatbázisaiban szerepelnek (vagyis nincsenek – például – közösségi ügyleteik);
viszonylag kevés számú ügyletük van (azaz, az áfa-bevallástervezet ellenőrzése nem növeli számottevően adminisztrációs feladataikat és ezek költségeit);
kettős könyvvezetésre nem kötelezettek (például: áfa-regisztráltak);
kizárólag adóköteles gazdasági tevékenységet végeznek, illetve nincs olyan számlájuk, amely adólevonási korlátozással lehet érintett.

A fentieknek megfelelő adózói kör számára igen hasznosnak bizonyulhat a NAV által összeállított bevallástervezet, amelynek adattartalma akár áfa-analitikaként is szolgálhat.

A tervezet véglegessé válásának azonban ekkor is feltétele az adózó általi ellenőrzése és jóváhagyása.

Az M2M-kapcsolattal az adózó könyvelőprogramja kommunikál a NAV rendszerével, ebből eredően ez a megoldás azoknak lesz majd kedvező,

akiknek a könyvelési szoftvere alkalmas arra, hogy szoftverfejlesztéssel vagy kiegészítő modul megvásárlásával a gép-gép kapcsolat kialakítható (többek között: standard adatstruktúra léte, alkalmazott adókódok megfeleltetése);
akik olyan nagyságrendű ügyletszámmal - és komplexitással rendelkeznek, amelynél a gép-gép kapcsolat kialakításával elérhető előnyök meghaladják a fejlesztésre szánt ráfordításokat;

· akiknél az adóbevallás készítésének folyamatára hosszabb idő is rendelkezésre áll, így mód van az egyes folyamatrészek kontrolljára, döntések meghozatalára. Különösen a külföldi könyvelési programmal dolgozó, külföldi társaságoknak kell elég időt és gondosságot szánniuk az átállásra, megfontolva annak megfelelő időzítését is.

Előnye az M2M metódusnak az is, hogy

· a könyvelő a saját (és így kiismert, megszokott) rendszerében dolgozik;

· a M2M-kapcsolat rugalmasan beépíthető a könyvelőprogramba, nincs kötelező beillesztési hely: a NAV kialakít egy, minden ügyletet leképező fix standard kódlistát, amely minden tranzakcióhoz kapcsolódóan tartalmazni fogja a szükséges kódot. Ezt a kódlistát az eÁfa M2M XML-lel együtt be kell építeni a könyvelőprogramba, az adatszolgáltatás gyakorisága pedig felhasználó által beállítható.

· az egyes ügyletekhez kötődő adatszolgáltatás, adminisztrációs tévedések száma hatékonyan csökkenthető (kontrollt, támogatást nyújt az adóhatósági ellenőrzés);

· előzetes technikai és üzleti „leválogatást” végez az adóhatóság (áfa-analitika előellenőrzése, hibalista előállítása, ellentmondások kiszűrése és erről tájékoztatás még a beküldés előtt (a rendszer figyelmezteti az adózót, ha az állományban hiba van és nem engedi a hibás bevallás benyújtását); az előzetes adóhatósági „válogatás” olyan ellenőrzéseket tartalmaz majd, amelyek jelenleg csak a bevallás beküldését követően történnek meg, és hiba esetén az utólagos javításra való adóhatósági felhívást eredményezik. Az M2M-kapcsolatnak köszönhetően az adminisztrációs hibák már a bevallás benyújtása elött helyesbíthetőek lesznek;

· a rendszer lényegében teszteli a könyvelőprogramot is: kiszűrhetőek annak rendszerhibái, bizonytalanságai, mint például ugyanazon számla adójának kétszeres levonása, cégcsoportba tartozó másik cég nevére szóló számla adójának levonásba helyezése;

· az adózó számára is egyszerűbb adóellenőrzések: a minta XML megadja az áfa-analitika mintáját és adattartalmát (célszerű a NAV által definiált sztenderd áfa-analitika használata, mivel minden olyan információt tartalmaz majd, amelyet az adóhatóság az adózótól adóellenőrzés során kérhet, így a belföldi összesítő nyilatkozatok elkészítésére és a titkosított bevallások NAV oldalra történő kézi feltöltésére sem lesz szükség: ezért adóellenőrzéskor ezeket már nem, csak további bizonylatok bemutatását (szerződések, teljesítésigazolások, stb.) kérheti az adóhatóság;

Lényeges, hogy az Online Számla mellett a NAV elérhetővé és lekérdezhetővé teszi az Online Pénztárgép (OPG) és vámigazgatási nyilvántartásokból (CDPS) rendszerekben lévő adatokat is, így az adózóknak lehetőségük lesz ezeket is beépíteniük a bevalláskészítési folyamatba (függetlenül attól, hogy az eÁfa rendszeren vagy az ÁNYK-val nyújtják be a bevallást).

Noha, az eÁfa rendszer bevezetését már évek óta tervezik, és többször is elhalasztották, de az őszi adócsomagban pedig már szerepelnek az eÁfa rendszerre vonatkozó rendelkezések. Ebből következtetve, biztos, hogy az adóhatóság tájékoztatásának megfelelően, 2024. január 1-jétől elindul és nyilvánosan is elérhetővé válik az eÁfa éles rendszer.

Az eÁfa rendszer várhatóan képes lesz – bizonyos mértékig – a beküldött adattartalom és a NAV rendelkezésére álló adatbázisok (OSZ, OPG, CDPS) keresztellenőrzésére, majd az eredmények rendelkezésre bocsátására. Amennyiben az adózók ezeket a visszajelzéseket beépítik a bevalláskészítési folyamatba, megelőzhetik a technikai hibák miatt indított adóhatósági adategyeztetéseket, jogkövetési vizsgálatokat.

Légy a levesben

Az eÁfa rendszer önmagában nem jelent megoldást a bevalláskészítési folyamat automatizálására. Az adózók feladata lesz tehát egy olyan megoldás fejlesztése, amely képes lesz kihozni a maximumot az eÁfa rendszerből: képes kommunikálni vele, a rendelkezésre bocsátott adatokat fel tudja dolgozni, a kapott visszajelzéseket ki tudja értékelni és be tudja építeni a bevallási folyamatba.

A gyakorlatban ez (ennek előkészítése) azt jelenti, hogy

az adózó ügyviteli rendszerének adókódjait össze kell kapcsolni a NAV által kiadott standard adókódokkal, azaz adatot adatmezővel kell megfeleltetni, hogy az e-ÁFA rendszer tudja, melyik adókódhoz rendelje a vállalkozás saját ügyleteit; a standard adókód és a vállalkozás adókódja közötti kapcsolatot ki kell építeni, minden egyes újabb tranzakciótípusnál (arról már nem is beszélve, hogy ha az adóhatóság változtat az adatstruktúrán, amire a kezdeti időszakban nyilván gyakran számítani lehet majd, akkor ezeket a változásokat is le kell követni;
jelenleg nincs adóhatósági kikötés arra, hogy az adózó milyen ügyviteli szoftverrel dolgozzon, de nem kizárt, hogy később előzetes szoftverregisztrációt fognak bevezetni;
XML API (alkalmazásprogramozási felület)[1] autentikáció elvégzése; ki kell alakítani az adat XML és a bevallás XML elfogadásának folyamatát, a feltöltések folyamatát, meghatározni milyen lekérdezésekre van szükség, és a kinyert adatok kezelését, feldolgozását, elemzését;
az ellenőrző funkciók visszajelző üzeneteit értelmezni, és a kapcsolódó adathalmazt szükség szerint javítani kell;
célszerű meghatározni egy adatmegőrzési rendszert is, mivel az adóhatóság oldalán csak a legfrissebb verzió automatikus mentésére kerül sor, az adózó áfa-analitikájának megőrzési kötelezettségét a NAV természetesen nem vállalja át.

Annak kapcsán, hogy amíg az nem kötelező, választja-e az adózó az eÁfa rendszert, számos, a vállalkozó működéséből eredő szempontot kell mérlegelni. Néhány példát kiemelve a sok lehetséges közül, először gondoljuk át annak a vállalkozónak a helyzetét, aki az Áfa tv. pénzforgalmi elszámolásra vonatkozó szabályai szerint jár el.

Ez a szabályok némileg leegyszerűsített összefoglalásával azt jelenti, hogy akkor kell befizetnie az áfát, ha megkapta a pénzt a vevőtől, és akkor vonhatja le a költségszámlái áfáját, ha kifizette a szállítót. Az adóhatóságnak arról van információja, hogy az adott vállalkozás ezt az elszámolási módot választotta, de azt már nem tudhatja, hogy az egyes számlák pénzügyi rendezése mikor történt.

Bonyolítsuk még egy kevéssé a helyzetet, és induljunk ki abból a szabályból, hogy az adólevonási jog egyik alapfeltétele, hogy a felmerült kiadás az adóköteles tevékenység érdekében merüljön fel, és az sem mindegy, hogy milyen arányban felel meg a vizsgált kiadás ennek az elvárásnak. Ráadásul az Áfa tv. meghatároz olyan termékeket és szolgáltatásokat, amelyeknek áfáját nem lehet, vagy csak részben (az adóköteles tevékenység tényleges arányától eltérítve) lehet levonni, mint például a személygépkocsi üzemanyagának, vagy a telefonszolgáltatásnak az áfája.

A tervezetben viszont szerepelni fognak ezek a számlák is, mindenféle „felosztás” nélkül, sőt, adott esetben olyanok is, amelyek ugyan a vállalkozás nevére szólnak, de valaki más kérte azokat. Például, ha egy üzletben olyan személy vásárol, aki tudja, hogy az adott vállalkozás kedvezményre jogosult, és ezzel visszaélve a cég engedélye nélkül kéri a számlát annak nevére, hogy hozzájusson a kedvezményhez. Bár az ilyesféle trükköket igyekeznek már mind vállalkozói, mind hatósági oldalról kiszűrni, azért nem olyan nehéz elkövetni, mert a vállalkozások adatai nyilvánosak.

Olyan számla is bekerül a tervezetbe (az Online Számla rendszer adatbázisából), amelyet a kibocsátó számlázó programja küldött a rendszerbe, de a befogadó vállalkozás nem fogadta el a teljesítést, reklamált, akár vissza is küldte a bizonylatot a szállítónak. Erről az adóhatóság nem tudhat, és nem veszi ki a számlát a tervezetből.

Az Európai Unióból vagy harmadik országból származó számlák már csak mazsolák a tortán, azok sem fognak szerepelni a tervezetben (és a NAV adatbázisból készülő további dokumentumokban sem, így a közösségi nyilatkozatban sem).

A képzeletbeli tortánkon újabb mazsola az elkésett számla is, amely az Online Számla rendszerben már szerepel, de a vevőhöz még nem érkezett meg. Azaz nem áll a bizonylat a rendelkezésére az aktuális bevallási határidőig. Az adólevonási jogra vonatkozó határidő szűkebb, mint az általános elévülési idő: a tárgyév és a rákövetkező év ad lehetőséget a levonási jog „sima” gyakorlására. A tervezetben ilyen, még „ki tudja, hol jár az eredeti” számla is bekerül, de azt az adózónak ki kell onnan vennie, és figyelnie az elévülési időt, a dokumentum kézhezvételével pedig visszarendeznie a levonható tételt.

A hibásan elfogadott tervezetet már csak önellenőrzéssel lehet majd javítani, és ez szakmai hozzáértést igényel. Ahogyan a vállalkozás által aktuálisan használt könyvelőprogram felmérése is, alkalmas-e, és milyen szükséges beavatkozásokkal a bevallástervezethez kapcsolódó feladatokra. A gyakorlatban használt szoftverek jelentős többsége a könyvelt adatok alapján elkészíti az áfa-bevallást. Ha az eÁfa rendszerbe belépünk (most még önként), akkor össze kell vetni a NAV szerinti bevallást a könyvelés szerintivel, és ha van eltérés, annak okát ki kell deríteni. Bár az új rendszer célja a vállalkozásokat terhelő adminisztráció csökkentése, kezdetben ez biztosan nem sikerül még, számolni kell az előzőek szerinti feladatok terhével is.

[1] Az API az angol „application programming interface” kifejezés rövidítése, ami magyarul „alkalmazásprogramozási felületet” jelent. Az API-k a szoftverfejlesztők munkáját hivatottak megkönnyíteni azzal, hogy hozzáférést biztosítanak egy adott szoftver vagy eszköz utasításkészletéhez.