Az EU áfa-megfelelőség automatizálása felhőalapú könyvelési API-val

Gyakorlati útmutató platformoknak és piactereknek, amelyeknek valódi könyvekre, helyes áfára és olyan audit trailre van szükségük, amely évek múltán is kiállja a próbát.

Az EU áfa ma már nem számítási probléma, hanem bizonyítási kérdés. Az adókulcsok nyilvánosak, a küszöbértékek ismertek, az OSS-bevallások pedig jól dokumentáltak. Ami miatt az auditok elbuknak, és ami nagyságrendi növekedésnél megbontja a platformokat, az az, hogy képtelenség rekonstruálni, hogyan született meg egy adott áfa-döntés egy adott számlán, az akkor érvényes szabályok és adatok alapján. Egy felhőalapú könyvelési API ezt képes elejétől a végéig automatizálni, de csak akkor, ha eleve a döntési gráfra, és nem csupán az adókulcsra építve tervezik meg.

Ez a megkülönböztetés határozza meg az alábbiakban leírtakat.

Mit jelent a gyakorlatban az „EU áfa automatizálása”?

Egy több EU-s országban értékesítő platform számára az áfa-automatizálás egymásra épülő döntések láncolata:

Az ügyfél vállalkozás (B2B) vagy magánszemély (B2C), és hol található?
Melyik ország adókulcsai vonatkoznak rá, milyen adókategóriában, a számla keltezése szerint?
Az ügylet fordított adózású (reverse charge), OSS-bevallás alá eső, IOSS-bevallás alá eső vagy belföldi?
A piactér minősült az adó alanyának (deemed supplier), vagy a kereskedő?
Milyen bizonyítékok támasztják alá ezeket a válaszokat, és visszajátszhatók-e később?

Az összeg automatizálása a mögöttes indoklás nélkül vezet a klasszikus auditbukáshoz: helyes végösszegek, védhető nyomvonal nélkül. A modern adómotorok egyre inkább auditálható bizonyítási láncokkal és történelmi adókulcs-lekérdezésekkel operálnak, pontosan amiatt, mert a hatósági ellenőrzések ma már arra fókuszálnak, hogy hogyan született meg egy áfa-döntés, nem pedig arra, hogy mennyi volt az értéke.

A felhőalapú könyvelési API a legtermészetesebb hely ennek a nyomvonalnak a tárolására, hiszen már eleve tárolja a számlát, a főkönyvi bejegyzést és a partnert. A Nordlet e köré az elgondolás köré épül: egy módosíthatatlan (immutable) kettős könyvviteli főkönyv, országonkénti áfa-logika, VIES-ellenőrzés és i.SAF-nyilvántartás generálás, amelyek mind egyetlen REST felületen, típusos SDK-kon és webhookokon keresztül érhetők el. Az API nem csupán a könyvelés vékony rétege, hanem maga a döntést rögzítő nyilvántartási rendszer.

A három API-képesség, amely a legfontosabb terhet viseli

A legtöbb áfa-automatizálási feladat három olyan képességre vezethető vissza, amelyeket a könyvelési API-nak tisztán kell biztosítania.

1. Adókulcs-tartalom és adókategóriák, dátumhoz kötve. Az adókulcsok változnak. A kategóriák változnak. Kedvezményes kulcsok adódnak hozzá és kerülnek kivezetésre. A működő mintázat, ahogy azt a Sage EU áfa-reformról és könyvelési API-król szóló fejlesztői útmutatója is említi, az, hogy a tételeket adókategóriákhoz rendeljük, az adókategóriákat pedig érvényességi dátumokkal ellátott, országspecifikus kódokhoz kapcsoljuk. Cikkenként és országonként fixen beégetni egy kulcsot az az ellensablon, amely csendben addig halmozódik, amíg egy kulcsváltozás egy év múlva el nem ront valamit.

2. Áfafizetői azonosító (VAT ID) ellenőrzése hibatűrő (graceful degradation) módon. A VIES a határokon átnyúló B2B-ellenőrzések hivatalos forrása. Egyúttal időszakosan megbízhatatlan is. Az ésszerű implementációk rövid érvénytartamú (TTL) gyorstárazással (caching) tárolják az ellenőrzéseket, hiba esetén újrapróbálkoznak, és a bizonytalan eseteket ahelyett, hogy blokkolnák az eladást, egy ellenőrzési sorba irányítják. Az a feltételezés, hogy a VIES-nek minden tranzakciónál szinkron módon sikeresnek kell lennie, az a pont, ahol a platformok saját maguknak építenek be leállásokat.

3. Bizonyítékok rögzítése és módosíthatatlanság. Minden áfa-döntésnek tárolnia kell a bemeneteit: a vevő országára utaló jeleket, az adószámot és az ellenőrzés időbélyegét, az adókategóriát, az adókulcs-tábla verzióját, az alkalmazandó rendszert (belföldi, OSS, IOSS, fordított adózás), valamint a piactér szerepét. Ennek a rekordnak túl kell élnie az adókulcs-változásokat és a konfigurációs módosításokat. A lezárt időszakok szerkesztését tiltó, módosíthatatlan főkönyv, amelyet a Nordlet az API szintjén kényszerít ki, azt jelenti, hogy egy lezárt hónapot nem lehet csendben átírni egy későbbi audit szebbé tétele érdekében.

Ez a három képesség az alap. Minden más, beleértve az OSS-bevallást, az i.SAF generálást és az egyeztetést, ezekre épül.

Az áfa-döntés modellezése, nem csak az adókulcsé

A beágyazott könyvelés leggyakoribb hibaforrása az, ha a számlán szereplő adómezőt egy keresés kimeneteként kezelik. Nem az. Ez egy kis döntési gráf kimenete, és ezt a gráfot kell eltárolni.

Egy működőképes modell:

A partner besorolása. B2B vagy B2C. Ha B2B, ellenőrizni kell az adószámot a VIES-ben, és tárolni kell a választ az időbélyeggel és a státusszal együtt. Ha B2C, legalább két földrajzi helyre utaló jelet kell rögzíteni: számlázási cím, IP-cím vagy földrajzi helymeghatározás, valamint lehetőség szerint a fizetési eszköz országa.
A teljesítési hely meghatározása. Digitális szolgáltatások esetén az áfa a vevő tartózkodási helyéhez kötődik, nem a szolgáltatóéhoz. Termékek esetében a szabályok a feladás induló és érkezési helyétől függően eltérnek. Az API-nak minden egyes számlasort fel kell címkéznie a levezetett teljesítési hellyel és a felhasznált jelekkel.
A rendszer (scheme) kiválasztása. Belföldi, OSS (határokon átnyúló B2C az EU-n belül), IOSS (kis értékű import) vagy fordított adózás. A küszöbérték-logikát – különösen a digitális szolgáltatásokra vonatkozó 10 000 eurós határokon átnyúló B2C küszöbértéket – egy gördülő ablak alapján kell kiszámítani, nem pedig az aktuális számlát önmagában vizsgálva.
Az adókulcs megállapítása. Lekérdezni az ország adott adókategóriára vonatkozó kulcsát a számla keltezése szerint. Eltárolni a felhasznált adókulcs-tábla verzióját.
Könyvelésbe állítás. Kettős könyvviteli tétel írása országbontásban és rendszer szerinti megbontásban, hogy az OSS-bevallások és a belföldi áfa-bevallások az adatok újraszámítása nélkül előállíthatók legyenek.

Minden lépésnek láthatónak kell lennie az API-n keresztül. Az olyan webhookok, mint a sale_invoice.paid, lehetővé teszik a lejjebb lévő rendszerek számára, hogy lekérdezés nélkül reagáljanak az állapotváltozásokra. Az idempotencia-kulcsok megakadályozzák a duplikált főkönyvi tételeket, ha egy hálózati újrapróbálkozás rossz pillanatban fut le. Egyik sem egzotikus funkció, de mindkettő elengedhetetlen platformszinten.

OSS, IOSS és a 10 000 eurós küszöbérték

A SaaS és a digitális szolgáltatások esetében a gyakorlati automatizálási problémát az OSS jelenti. Az EU-n belül határokon átnyúló B2C értékesítést végző szolgáltató a hazai országának adókulcsát alkalmazza addig, amíg el nem éri a 10 000 eurós küszöbértéket az aktuális vagy az előző naptári évben, ezt követően pedig a vevő tagállamának adókulcsát alkalmazza, és negyedévente az OSS-en keresztül vallja be. A SaaS-re és digitális szolgáltatásokra vonatkozó áfa-megfelelőségi útmutatók ezt adatfolyamat-problémaként (data pipeline) kezelik, nem pedig regisztrációs kérdésként.

Az adatsor, amelyet a könyvelési API-nak támogatnia kell:

A határokon átnyúló B2C bevételek nyomon követése a küszöbértékhez képest gördülő alapon, naptári évenként.
Az adókulcs-meghatározás automatikus átváltása a hazai országról a célországra a küszöbérték átlépésekor, a korábbi számlák visszadátumozása nélkül.
Tranzakciók csoportosítása tagállam, rendszer és pénznem szerint a negyedéves OSS-bevalláshoz.
Összegek átszámítása euróra az OSS-bevalláshoz megfelelő devizaárfolyam-dátum alapján.
A bevalláskész adatkészlet exportálása olyan formátumban, amelyet a bevallásküldő vagy adóbevallási szolgáltatás fel tud dolgozni.

A Nordlet ezt a főkönyvben található országonkénti áfa-logikával és a rendszer, valamint tagállam szerinti csoportosítást biztosító riportokkal kezeli: az OSS-bevallások magukból a számlákból kerülnek kiszámításra, az előző időszaki helyesbítésekkel együtt, a 10 000 eurós küszöbértéket pedig a rendszer automatikusan követi. A bevallás a főkönyvből származik, nem pedig negyedévente a semmiből újraépítve. Ez a lényege annak, ha a döntési gráfot magába a könyvelési rendszerbe építjük be, ahelyett, hogy egy külön táblázatban tartanánk.

Az IOSS kis értékű importok esetén ugyanezt a mintát követi, eltérő küszöbértékekkel és másfajta bevallással.

A piactéri és platformfolyamatok saját kategóriát képeznek

A piacterek hagyományos B2C csatornaként való kezelése az a pont, ahol meglepően sok implementáció elbukik. Számos EU-s forgatókönyvben a platform minősül az adó alanyának (deemed supplier), és ő felel az áfa beszedéséért és befizetéséért. A kereskedő saját könyvelésének ezt úgy kell tükröznie, hogy a platform, és nem a végfelhasználó az áfa szempontjából releváns partner ezeknél a tranzakcióknál.

Itt mutatja meg a valódi értékét egy beágyazott könyvelési API. A platform az eladás pillanatában tudja, hogy adóalanyként (deemed supplier) járt-e el. Ezt a tényt be kell írni a számlarekordba, és át kell vinni a főkönyvbe, hogy a kereskedő könyvei ne számolják el duplán azt az áfát, amelyet a platform már kezelt. Az adószerep-jelölők API-n keresztüli átadása és a kimutatásokban való megjelenítése jelenti a különbséget a tiszta könyvek és az olyan egyeztetés között, amely soha nem stimmel pontosan.

A Nordletre építő platformok számára ez alapvető funkció: a számlák vatScheme (beleértve a marketplace_deemed értéket) és deemedSupplier jelzőt hordoznak, a kezelés-meghatározó (treatment resolver) pedig a 2006/112/EK irányelv szerinti jogi alappal együtt adja vissza az alkalmazandó rendszert. A többcéges (multi-company) támogatással kombinálva a platform könyvelése és a kereskedő könyvelése ugyanazon az API-n belül futhat, különböző cégekkel és eltérő szerepkörökkel, anélkül, hogy az áfatételek átszivárognának egymás közé.

Mit változtat meg a ViDA, és mit nem?

A digitális korban az áfa (VAT in the Digital Age – ViDA) az automatizálás formáját a „kiszámolás és könyvelés” modelljéről a „kiszámolás, könyvelés és továbbítás” modelljére módosítja. Az e-számlázás és az adóhatóságok felé történő, közel valós idejű adatszolgáltatás a folyamat részévé válik. Ez nem váltja fel a könyvelési API-t, hanem a könyvelési API strukturált számlaadatait teszi azzá a forrássá, amelyet a jelentéstételi átjáróba (reporting gateway) tükrözni kell.

Két gyakorlati következmény:

A számlák metaadatainak gazdagabbaknak kell lenniük, mint amit a legtöbb örökölt séma engedélyez. A Peppol BIS 3.0 mezőknek, a soronkénti strukturált áfa-bontásnak és a rendszerazonosítóknak elsőrendű elemnek kell lenniük a könyvelési API-ban, nem pedig szabad szöveges megjegyzésként odabiggyesztve.
A könyvelési bizonylatnak és a jelentett bizonylatnak szinkronban kell maradnia. Ha helyesbítő számla (credit note) kerül kibocsátásra, a jelentéstételi átjárónak ugyanazokkal az azonosítókkal kell látnia a korrekciót. A módosíthatatlan főkönyvek és a tiszta bizonylat-leszármazás ezt egyszerűvé teszik, a hanyag könyvelés viszont fájdalmassá.

A ViDA-ra való felkészülés kevésbé szól új funkciókról, mint inkább a már létező folyamatok fegyelmének szigorításáról.

Rövid összehasonlítás az automatizálási megközelítésekről

Megközelítés	Áfa-döntési bizonyítékok	OSS/IOSS kezelés	Piactéri szerepkör modellezése	Beágyazott platformokhoz való illeszkedés
Manuális könyvelés táblázatkezelőkkel	Gyenge, utólag rekonstruált	Manuális, hibalehetőséggel teli	Általában figyelmen kívül hagyva	Gyenge
Örökölt könyvelési szoftver kiegészítő adómodullal	Részleges, gyakran a főkönyvön kívül esik	Támogatott, de szigetszerű	Korlátozott	Gyengétől a közepesig
Általános könyvelési API (Xero, QuickBooks stílusú)	Az integrációs fegyelemtől függ	Piac és kiegészítő függvénye	EU-s kontextusban nem hivatalosan megerősített a deemed supplier folyamatokra	Közepes
Nordlet (API-központú, EU-fókuszú)	Módosíthatatlan főkönyv, számlánkénti adómetaadatok, időszakzárás	Natív országonkénti áfa, i.SAF, VIES, OSS-kész csoportosítás	Elsőrendű: `vatScheme`, `deemedSupplier` számlánként	Erős

A táblázat a cikkhez rendelkezésre álló bemeneti adatokat tükrözi. Ahol a versenytársak képességeit a kutatási anyag nem dokumentálja, ott a megbízhatóság érdekében „nem hivatalosan megerősítettként” szerepel, ahelyett, hogy feltételezésekbe bocsátkoznánk.

Mit érdemes először felépíteni, ha most kezdi?

Ha egy csapat beágyazott EU áfa-automatizálást indít el egy felhőalapú könyvelési API-n, az alábbi sorrend mentén takaríthatja meg a legtöbb utómunka általi újratervezést:

Mindenekelőtt modellezze a partnert és annak országra utaló jeleit. Minden későbbi döntés ettől függ. Tárolja el a nyers jeleket, ne csak a levezetett országot.
Építse fel az adókategória-réteget. Rendelje hozzá a termékeket és szolgáltatásokat a kategóriákhoz. A kategóriákat rendelje az országkódokhoz. Soha ne rendelje a termékeket közvetlenül az adókulcsokhoz.
Kösse be a VIES-ellenőrzést gyorstárazással (caching) és ellenőrzési sorral. Ne hagyja, hogy a VIES elérhetősége gátolja a fizetési folyamatot (checkout).
Bocsásson ki és dolgozzon fel webhookokat a számlaállapot-változásokhoz. Használjon idempotencia-kulcsokat minden írási műveletnél.
Zárja le az időszakokat, amint azok lejárnak. Ezt az API-ban kell kikényszeríteni, nem pedig belső szabályzatokban.
Az OSS-bevallásokat a főkönyvből származtassa. Ha a bevalláshoz külön táblázatkezelő szükséges, akkor a főkönyv nem hordoz elég metaadatot.
Csak ezután adja hozzá az e-számlázási és jelentéstételi átjáró integrációt. A feljebb lévő adatoknak először rendben kell lenniük.

Ezen intézkedések a legtöbbje egyszeri befektetés, amely minden negyedévben csendben meghozza a gyümölcsét. Egy korlátlan sandbox cég a legolcsóbb hely a folyamat elejétől végéig történő tesztelésére.

FAQ

Elég a VIES-ellenőrzés annak bizonyítására, hogy egy B2B értékesítés helyesen volt 0%-os áfájú?

Önmagában nem. A VIES igazolja, hogy egy adószám egy adott időpontban érvényes. Az auditálható nyilvántartás tartalmazza az ellenőrzés időbélyegét, a válaszadatokat, a vevő által megadott országot, valamint annak bizonyítékát, hogy az árut vagy szolgáltatást az adott adóalany részére szállították ki. Mindezeket tárolni kell a számlához kapcsolódóan.

Támaszkodhat-e egy platform a piactérre az áfa kezelése érdekében, kihagyva a saját logikáját?

Csak azokra a konkrét tranzakciókra vonatkozóan, ahol az EU szabályai szerint a piactér minősül az adó alanyának (deemed supplier). A kereskedő könyvelésének továbbra is helyesen kell tükröznie ezeket a tranzakciókat, és a körön kívüli eladások – beleértve a közvetlen értékesítést és a B2B ügyleteket – továbbra is a kereskedő felelősségét képezik. Biztonságosabb megközelítés tranzakciónként kifejezetten modellezni a szerepkört.

Milyen gyakran változnak az EU áfa-kulcsai annyira, hogy az számítson?

Elég gyakran ahhoz, hogy a fixen beégetett adókulcsok komoly problémákat okozzanak. A kedvezményes adókulcs-kategóriák elmozdulnak, ideiglenes kulcsok kerülnek bevezetésre és járnak le, valamint új tagállami szabályok jelennek meg. Egy érvényességi dátumokkal rendelkező adókulcs-tartalmi réteg nem túlbonyolított tervezés, hanem az alapkövetelmény.

Mi a gyakorlati különbség az OSS és az IOSS között?

Az OSS az EU-n belüli határokon átnyúló B2B/B2C áruértékesítéseket és digitális szolgáltatásokat fedi le, amelyeket negyedévente egyetlen tagállamon keresztül kell bevallani. Az IOSS az EU-ba irányuló alacsony értékű importot, jellemzően a 150 euró alatti fogyasztási cikkeket fedi le. Mindkettő ugyanazokból a könyvelési adatokból származtatható, ha a főkönyv minden tranzakciót felcímkéz a megfelelő rendszerrel.

Jelenti-e a módosíthatatlan főkönyv azt, hogy a helyesbítések lehetetlenek?

Nem. A helyesbítések új tételeken keresztül történnek, nem a régiek szerkesztésével. Egy helyesbítő számla (credit note) sztorníroz egy számlát, egy ellentétes irányú könyvelés pedig kijavít egy hibás bejegyzést. Amit a módosíthatatlanság megakadályoz, az a múlt csendes átírása, és pontosan ezt a magatartást keresik az auditorok.