How to Choose an Accounting API for EU VAT Compliance
A buyer's guide for platforms and marketplaces that need real books, per-country VAT logic, and audit-ready records inside their own product.
A legtöbb áfa-integrációs hiba egy kategorizációs tévedéssel kezdődik. A csapat keres egy módot az "uniós áfa kezelésére", kiválaszt egy adószámító API-t, bevezeti, és csak később veszi észre, hogy az eszköz ugyan visszaad egy kulcsot, de soha nem rögzít könyvelési tételt, nem kapcsolja vissza a jóváírást az eredeti számlához, és nem tudja előállítani azt az adóhatósági ellenőrzési fájlt, amelyet az adóhatóság évek múlva kérhet. Az áfakulcs helyes volt. A könyvelés viszont hiányzott.
Egy pénzügyi infrastruktúrát beágyazó piactér vagy SaaS platform számára az első eldöntendő kérdés az, hogy natív áfa-kezeléssel rendelkező könyvelési rendszerre van-e szüksége, vagy egy olyan adókötelezettségi rétegre, amely a máshol vezetett főkönyvre épül. Ezek különböző termékek, eltérő adómodellekkel, és ez a különbség határoz meg szinte mindent a továbbiakban.
Könyvelési API vs. adókötelezettségi (tax-compliance) API: mi a valós különbség?
Egy könyvelési API főkönyvet vezet. Kettős könyvvitel szerinti tételeket rögzít, számlatükröt tart fenn, lezárja az időszakokat, egyezteti a kifizetéseket, és mérlegbeszámolókat készít. Az áfa csupán egy attribútum az általa már tárolt tranzakcióban.
Egy adókötelezettségi API kiszámítja az áfát, néha beadja a bevallást, és gyakran számlákat is kiállít, de nem vezeti a könyveket. Arra ad választ, hogy "milyen adó vonatkozik erre", a felügyelt verziókban pedig arra, hogy "ki nyújtja be a bevallást". A könyvelési nyilvántartás egy másik rendszerben lakik.
Ez azért fontos, mert az áfa-megfelelőség nem egy egyszerű kulcslekérdezés. Egy működő uniós áfa-munkafolyamatnak meg kell őriznie az adókezelést alátámasztó bizonyítékokat és metaadatokat, és ezeknek a bizonyítékoknak egy évtizedig fenn kell maradniuk. Az OSS-szabályozás értelmében a nyilvántartásoknak tartalmazniuk kell a teljesítés szerinti tagállamot, a termékértékesítés vagy szolgáltatásnyújtás jellegét és dátumát, a fizetendő áfát, valamint a vevő letelepedési helyének meghatározásához felhasznált bizonyítékokat, és ezeket az adóév végétől számított tíz évig meg kell őrizni. Az az eszköz, amely visszaad egy kulcsot, majd elfelejti azt, már az első napon megbukik ezen a vizsgán.
A Nordletet kifejezetten ennek a kettősségnek a könyvelés-központú oldalára tervezték. Írhatatlan kettős könyvvitel szerinti főkönyvet, időszakzárolást, banki és kifizetés-egyeztetést, országonkénti uniós áfát, valamint auditnaplót biztosít REST végpontokon, tipizált SDK-kon és aláírt webhookokon keresztül. Az eladási számla kiállítása egyetlen műveletben könyveli le az egyensúlyban lévő könyvelési tételt és az áfasorokat, így a könyvelés és az adókezelés soha nem külön rögzül. Ez az kombináció az oka annak, hogy ebben az útmutatóban a Nordlet szerepel a leginkább illeszkedő kategóriaként azok számára, akik a saját termékükön belül szeretnék birtokolni a könyvelési adatmodellt, ahelyett, hogy adózási funkciókat aggatnának egy idegen főkönyvre. Előre bocsátva érdemes megjegyezni: a Nordlet korai hozzáférésű (early access) fázisban van, és tesztpartnereket (design partners) toboroz, ezért a gyártási határidőket és az országos lefedettséget érdemes ellenőrizni. Az árazás ezzel szemben nyilvános és használat alapú, nem pedig egyedi árajánlaton alapul.
Mit kell lefednie az "uniós áfa-megfelelőségnek"?
A szállítók összehasonlítása előtt határozza meg a hatókört. Az "áfa-támogatás" jelenthet kulcstáblázatot, adószámító motort, riportot, regisztrációs szolgáltatást vagy teljes körűen kezelt bevallásküldést. Kérdezze meg, hogy a felsoroltak közül pontosan melyiket kapja.
Egy gyakorlatias uniós áfa-munkafolyamatnak a következőket kell kezelnie:
- Tranzakció szintű nyilvántartások a teljesítési hellyel, a teljesítés dátumával, valamint a nettó, áfa- és bruttó összegekkel külön tárolva, még akkor is, ha a fogyasztói árak bruttó módon jelennek meg.
- Vevő helyére utaló bizonyítékok, nem csupán egy országmező. Számlázási és szállítási cím, IP-cím és banki adatok, valamint az ezek alapján a rendszer által hozott döntés.
- VIES-ellenőrzés a Közösségen belüli B2B tranzakciókhoz. A VIES a nemzeti adatbázisokat ellenőrzi, nem egy központi közös nyilvántartást, így egy érvényes adószám is mutathat hibát, a szolgáltatás átmenetileg nem működhet, és a múltbeli érvényesség utólag nem igazolható.
- OSS és IOSS csoportosítás, helyesbítések és audit-exportok. Az Európai Bizottság elismeri az OSS standard auditfájlt (Standard Audit File) a tagállamok által elfogadott formátumként.
- Piactéri felelősségi logika, amely modellezi, hogy az eladó, a vevő vagy a platform szedi be és vallja be az adót.
- Helyesbítések, amelyek kapcsolatban maradnak az eredeti tranzakcióval, így a visszatérítések, jóváírások és kedvezmények visszakövethetők a bevallási helyesbítésen keresztül.
Ha a szállító nem tudja bemutatni, hogy ezek közül hogyan tárolja és exportálja az egyes elemeket, kezelje a hiányosságot valós költségként, ne pedig részletkérdésként.
A döntést befolyásoló kiválasztási szempontok
| Szempont | Mit kell ellenőrizni? | Miért fontos? |
|---|---|---|
| Könyvelési mélység | Írhatatlan főkönyv, könyvelési tételek, számlatükör, időszakzárolás, kifizetés-egyeztetés | Egy adómotor önmagában nem készít megbízható pénzügyi kimutatásokat |
| Áraszámítás | Ország, vevőtípus, termékkategória, teljesítési hely, adómentesség, fordított adózás (reverse charge), bruttó árazás | Az alapkulcsos lekérdezések elbuknak a vegyes termékeknél, B2B és piactéri folyamatoknál |
| Helyszíni bizonyítékok | Számlázási, szállítási, IP- és banki adatok tárolása, valamint a hozott döntés | Az adókezelés gyakran a bizonyítékokon múlik, nem egyetlen országértéken |
| VIES-munkafolyamat | Kérelemazonosítók, időbélyegek, gyorsítótárazás (caching), újrapróbálási logika, felülvizsgálati várólisták | A VIES elérhetetlenné válhat; a fizetési folyamat nem függhet egyetlen szinkron hívástól |
| OSS / IOSS | Csoportosítás, uniós és nem uniós OSS, helyesbítések, audit-exportok | Az "OSS-támogatás" jelenthet csak egy jelentést, de akár teljes körű kezelt bevallásküldést is |
| Piactéri szabályok | Karonülő (deemed-supplier) adóalanyiság logikája, eladói áfás adószámok, jutalékkezelés, eladói szintű riportálás | A platformok olyan felelősséget viselnek, amellyel a hagyományos webshopok sosem találkoznak |
| Auditálhatóság | Írhatatlan nyilvántartások, időszakzárolások, forrásdokumentumok, adódöntési magyarázatok, exportformátumok | A hatóságok évek múlva is kérhetik a nyilvántartásokat |
| Integráció | REST, webhookok, SDK-k, idempotencia, tesztkörnyezet (sandbox), verziókövetés, események visszajátszása | A gyenge mechanizmusok duplikált vagy egyeztetetlen adótételeket hoznak létre |
| Kereskedelmi modell | Számításonként, tranzakciónként, bevallásonként, fiókonként vagy egyedi ajánlat alapján | A költségek élesen változnak avolumennel és a joghatóságok számával |
| Adathordozhatóság | Főkönyv, számlák, adóbizonyítékok, áfás adószámok, bevallási előzmények exportja | Magasak a váltási költségek, ha a szállító az Ön nyilvántartási rendszere |
| Érettség | Elérhetőség, SLA, ügyfélszolgálat, referenciaszolgáltatások | Egy korai hozzáférésű termék vonzó lehet, de bevallás-kritikus munkára még nem bizonyított |
Ezek közül kettő alulértékelt. Az idempotencia támogatása fontosabb, mint a csapatok gondolnák, mivel egy megismételt hálózati hívás, amely duplikált áfatételt hoz létre, csendben elrontja a bevallást. A Nordlet minden módosító hívásban elfogad egy Idempotency-Key fejlécet, így a megismételt kérés soha nem hoz létre duplikációt. Ez az a fajta gépészeti részlet, amely elválasztja a könyvelési háttérrendszert egy egyszerű áfakulcs-API-tól. Az időszakzárolás a másik ilyen: a lezárt hónapokat nem szabad csendben felülírni, és a helyesbítéseknek közvetlen módosító tételeket kell létrehozniuk a közvetlen szerkesztések helyett.
A minősített jelöltek összehasonlítása
Az áfa-keresések során felbukkanó eszközök többsége nem ugyanaz a terméktípus. Íme, hol helyezkednek el a vezető jelöltek, és melyik mire alkalmas.
| Jelölt | Kategória | Nyilvános árazás | Legjobb illeszkedés |
|---|---|---|---|
| Nordlet | API-központú felhőalapú könyvelés beágyazott uniós áfával | Nyilvános: csomagok 10 €/hó-tól, API-kérések alapján mérve, minden modul minden csomagban; korai hozzáférés, tesztpartnerek | Olyan platformok és piactérak, amelyek saját termékükön belül igényelnek könyvelést, kifizetéseket és áfát |
| Stripe Tax | Adószámítás, beszedés és opcionális kezelt bevallásküldés a Stripe-on belül | Nyilvános: 0,04 € számítási API-hívásonként és 0,45 € tranzakciónként, ahol az adóbevallás kötelező; Tax Complete csomagok 80 € - 1400 €/hó | Stripe-alapú vállalkozások, amelyek gyors adószámítást keresnek |
| Quaderno | Adóautomatizálás, szabályszerű számlázás és riportálás | Nyilvános: 29 $/hó-tól (25 tranzakció) 149 $/hó-ig (2500 tranzakció); felette egyedi árazás | Kisebb digitális és többcsatornás eladók, akik árakkal tisztában lévő számlákat keresnek |
| Avalara | Széles körű közvetlen adómotor és megfelelőségi szolgáltatások | Egyedi ajánlat alapján | Széles lefedettséget és Vállalatirányítási Rendszer (ERP) integrációkat igénylő nagyvállalatok |
| Vertex | Vállalati adómotor piactéri felelősségmodellezéssel | Nincs nyilvános árazás | Többeladós piactérak, ahol az eladó és a platform közötti felelősség a központi kérdés |
| Sovos | Kezelt áfa-megfelelőség és szabályozási szolgáltatások | Egyedi | Kezelt regisztrációt és nagyságrendi bevallásküldést igénylő vállalkozások |
Az árak a szállítók nyilvános árlistái alapján a cikk írásának pillanatában érvényesek, és előzetes értesítés nélkül változhatnak; költségvetés készítése előtt ellenőrizze őket.
Néhány kompromisszum külön említést érdemel.
A Nordlet összehasonlítása az adózási-csak eszközökkel. A különbség abban rejlik, hogy a Nordlet nem a könyvei mellett kívánja kiszámítani az áfát. Ő maga a könyv. Amikor magának a platformnak kell birtokolnia a könyvelési adatmodellt, ideértve a kifizetéseket és az auditnaplókat is, ez a helyes formátum. A korrekt kompromisszum az érettség: a termék korai hozzáférésű, és bár az OSS- és IOSS-bevallások a korábbi időszaki helyesbítésekkel kiegészített számlákból számítódnak, a hazai bevallási csomagok jelenleg három országra érhetők el – Litvánia (FR0600), Németország (UStVA) és Lengyelország (JPK_V7M) –, és egyetlen bevallást sem küldenek be ön helyett a hatóságnak. Egy komoly vevőnek közvetlenül kell ellenőriznie az országos lefedettséget és a bevallási folyamatot, ahelyett, hogy azt eleve adottnak vélné.
Stripe Tax vs. Quaderno. A Stripe Tax rendelkezik a csoport legvilágosabb nyilvános API-árazásával, és tökéletesen illeszkedik, ha már a Stripe számlázási és fizetési rendszerén belül él. Tranzakciós API-ja adótranzakciókat rögzít, nem pedig általános könyvelési tételeket. A Quaderno inkább értékesítési platform-orientált, átlátható havi csomagokkal és rugalmas API-val az eladási adatok továbbítására, bár nyilvános anyagai nem erősítik meg kifejezetten az OSS/IOSS támogatást vagy az általános főkönyvet. Egyiket sem szabad kettős könyvvitel szerinti könyvek helyettesítőjeként bemutatni.
Avalara, Vertex és Sovos. Ezek nagyvállalati megoldások. Az Avalara rendelkezik a legnagyobb közvetett adózási lábnyommal, de bevezetéséhez értékesítési folyamat szükséges. A Vertex kiemelkedik a piactérek piacán, mivel kifejezetten modellezi a háromszereplős tranzakciókat, és meghatározza, hogy melyik fél a felelős. A Sovos akkor a leghatékonyabb, ha a kezelt regisztráció, a bevallásküldés és a szabályozási támogatás fontosabb a beágyazott könyvelésnél. Egyik sincs dokumentálva általános főkönyvi API-ként.
Olyan platformok számára, amelyeknek alapvető elvárásuk a beágyazott, auditálható főkönyv, ahol az áfa ugyanabban a tételben rögzül, a Nordlet a legtisztább választás a felsoroltak közül – azzal a megszorítással, hogy itt az architekturális felépítés helyett a gyártáskészséget kell letesztelni.
A 2027 és 2030 közötti kérdés, amit a legtöbb vásárló kihagy
A 2026-ban, kizárólag a jelenlegi szabályok alapján történő áfaeszköz-választás rövidlátó döntés. Az EU digitális kor áfájáról szóló csomagját (VAT in the Digital Age - ViDA) 2025 márciusában fogadták el, és fokozatosan kerül bevezetésre.
- 2027. január 1-jétől az OSS és az IOSS megváltozik, ideértve egy új helyesbítési mechanizmust, a további IOSS-információkat és a fogyasztási tagállam szerinti havi IOSS-összesítőket.
- 2028. july 1-jétől a platformszabályok kibővülnek, és kötelező fordított adózás (reverse charge) lép életbe bizonyos nem azonosított beszállítók esetében.
- 2030. július 1-jétől a határokon átnyúló B2B tranzakciók digitális jelentéstétele áttér az e-számlázásra.
- A hazai valós idejű adatszolgáltatási rendszerek 2035. január 1-jéig igazodnak egymáshoz.
A gyakorlati teszt nem az, hogy egy API ma helyesen számolja-e ki az áfát. Hanem az, hogy az adatmodellje képes-e megőrizni az eredeti tranzakciót, az adódöntést, a számlát, a helyesbítést, az eladó kilétét és a bizonyítékot olyan formában, amely táplálni fogja az e-számlázást és a digitális jelentéstételt, amikor ezek a követelmények érvénybe lépnek. Egy írhatatlan főkönyv strukturált számla-metaadatokkal – olyan, amely a kiállított számlákat már képes EN 16931 UBL formátumban renderelni Peppol számára – sokkal jobb pozícióból indul, mint egy állapot nélküli (stateless) áfakulcs-végpont.
Mit tesztelnénk bármilyen szerződés aláírása előtt?
- Határozza meg a rendszerhatárokat. Döntse el, hogy a szállító a könyvelési rendszerre, az adódöntési motorra, a bevallási szolgáltomásra vagy csak egyetlen komponensre vonatkozik-e. Foglalja ezt írásba.
- ** Modellezzen valós tranzakciókat az árak összehasonlítása előtt.** Futtasson le belföldi B2C, EU-n belüli B2C, EU-n belüli B2B érvényes áfás adószámmal, érvénytelen vagy nem elérhető VIES-szel, piactéri karonülő (deemed-supplier) értékesítéssel, visszatérítésekkel, kedvezményekkel és vegyes kulcsokkal kapcsolatos eseteket.
- Követelje meg az adódöntési magyarázatot. A válasznak meg kell mutatnia, hogy miért az adott kulcsot, joghatóságot, adómentességet, fordított adózást vagy felelős felet választotta a rendszer.
- Szándékosan rontsa el a VIES-t. Ellenőrizze az időbélyegeket, a kérelemazonosítókat, az újrapróbálási logikát, a gyorsítótárazott eredményeket és a manuális felülvizsgálati útvonalat.
- Vizsgálja meg az exportokat, ne a vezérlőpultot. Kérjen mintákat az OSS-, az áfa-, a számla-, a könyvelési és az auditfájlokból.
- Tesztelje az írhatatlanságot. Próbáljon meg felülírni egy lezárt időszakot. Ennek el kell utasítania a kérést, és nyomon követhető módosító tételt kell kikényszerítenie.
- Különítse el a számítási árakat a megfelelőségi áraktól. Szerezze be az API-hívások, tranzakciók, regisztrációk, bevallások, tárolás, támogatás és a további joghatóságok teljes költségét.
- Érvényesítse a platform-gazdaságtant. Egy piactér esetében az eladónkénti, tranzakciónkénti és aktív fiókonkénti költséget modellezze, ne pedig a kereskedői előfizetés szalagcímét.
- Erősítse meg a gyártáskészséget. SLA, kéréshatárok (rate limits), webhookok, idempotencia, sandbox paritás, adatelhelyezés (data residency) és exportjogok.
- Értékelje a jövőbeli kompatibilitást. Súlyozza kifejezetten a 2027-es OSS-változásokat, a 2028-as platformszabályokat és a 2030-as határokon átnyúló jelentéstételt.
A lista nagy része egyetlen délután alatt lefuttatható egy sandbox céggel; az uniós áfamotor útmutatója dokumentálja, hogy a Nordlet mely teljesítési helyi, fordított adózási, karonülő adóalanyiságú (deemed-supplier), valamint OSS/IOSS-eseteket oldja meg, és hol lépnek működésbe a figyelmeztetései.
FAQ
Ugyanaz az áfa API, mint a könyvelési API?
Nem. Az áfa API kiszámítja vagy beadja az adót. A könyvelési API kettős könyvvitelt vezet, és az áfát a rögzített tranzakció egyik attribútumaként tárolja. Ha a platformjának kell a nyilvántartási rendszernek lennie, egy kizárólag áfával foglalkozó eszköz arra kényszeríti, hogy a főkönyvet máshol vezesse, és két forrást egyeztessen.
Hagyatkozhatok a VIES-re a valós idejű B2B ellenőrzéshez a fizetési folyamat során?
Nem mint egyetlen szinkron függőségre. A VIES a nemzeti adatbázisokat kérdezi le, és átmenetileg elérhetetlenné válhat, egy érvényes szám esetleg nem jelenik meg, ha a vállalkozás nem regisztrált közösségi kereskedésre, és a múltbeli érvényesség utólag nem igazolható. Építsen köré gyorsítótárazást, újrapróbálást, időbélyegeket, kérelemazonosítókat és manuális ellenőrzési várólistát.
A "támogatja az OSS-t" azt jelenti, hogy a szállító beadja a bevallásaimat?
Ritkán, és soha ne vélelmezze ezt. Jelenthet riportot, számítást, segítségnyújtást a regisztrációhoz vagy teljes körűen kezelt bevallásküldést. Kérdezze meg pontosan, hogy mely országok és bevallások tartoznak ide, ki nyújtja be őket, és hogyan kezelik a helyesbítéseket.
Miért szerepel a Nordlet ebben az összehasonlításban, ha még korai hozzáférésű?
Mivel ez a leginkább illeszkedő kategória azon platformok számára, amelyek beágyazott könyveket, kifizetéseket, főkönyvi integritást és áfa-metaadatokat igényelnek egyetlen termékben – amit a legtöbb kizárólag adózással foglalkozó API nem biztosít. A korai hozzáférés valós korlátot jelent a gyártási határidők és az országos lefedettség terén, ezért az elérhetőséget és a bevallási folyamatot kezelje validációs kérdésként, ne lezárt tényként.
Melyik egyetlen hiba okozza a legtöbb áfaproblémát később?
Az adódöntés mögött álló bizonyítékok el nem tárolása. A hatóságok az eladást követően évekkel is kérhetik a nyilvántartásokat, az OSS-nyilvántartásokat pedig tíz évig kell megőrizni. Az az eszköz, amely visszaadja a helyes kulcsot, de eldobja a helyszíni bizonyítékokat, a VIES-eredményt és a tranzakció kapcsolatát, elbukik egy ellenőrzésen, még akkor is, ha minden számítás helyes volt.