A legjobb számviteli automatizációs API-k EU-s piacterek számára (2026)

A legegyszerűbben úgy deríthető ki egy számviteli API-ról, hogy piacterekhez tervezték-e, ha megkérdezzük: mi történik akkor, ha egy litván vevő kifizet egy lengyel raktárból kiszállított terméket egy német eladónak, a platform pedig levon 12%-ot jutalékként, plusz egy fizetési tranzakciós díjat. Ha a válasz CSV-exportokat vagy éjszakai kötegelt feladatokat (batch job) említ, akkor a következő két évét az élvonalbeli esetek (edge cases) javítgatásával fogja tölteni.

Láttunk már csapatokat, akik megpróbáltak egy UI-központú (felhasználói felület elsődlegességű) számviteli eszközt ráerőltetni egy kétoldalas piactérre, majd tizennyolc hónap múlva csendben az egészet újraépítették. A probléma szinte sosem a számlázás. Hanem a főkönyv, az országonkénti áfakezelés, valamint a platform kifizetési ütemezése és a számviteli rendszer azon felfogása közötti egyeztetés, hogy mikor is keletkezett a bevétel.

Ez egy útmutató azokról a számviteli API-król, amelyek jelenleg valóban erre a feladatra készültek az EU-ban, kompromisszumaikról, és arról, hogyan válasszon anélkül, hogy olyan megoldás fogságába esne, amelyet később megbán.

Mit kell valójában jelentenie egy „számviteli automatizációs API-nak” egy piactér számára

Egy piactér esetében a számviteli API nem egy riportkészítő eszköz. Ez a pénzügyek igazságforrása (source of truth). Ez megváltoztatja a követelményeket:

• Egy valódi kettős könyvvitelű főkönyv, amelyet utólag nem lehet csendben módosítani. Nem pedig a számlák egy táblázata összesítések nézetével.
• Országonkénti áfa-logika, amely ismeri az OSS-t, a fordított adózást (reverse charge), a B2B és B2C tranzakciókat, valamint a teljesítési hely szabályait. Nem csupán egy adókulcsot tartalmazó mező.
• Kifizetés-egyeztetés (reconciliation), amely egyetlen egyösszegű banki átutalást képes megfeleltetni a háttérben lévő rendelések, visszatérítések és díjak százainak.
• Idempotencia minden írási végponton (write endpoint). Mivel lesznek újrapróbálkozások, és nem engedheti meg magának a duplikált könyvelési tételeket.
• Webhookok az állapotváltozásokhoz, hogy a termékének ne kelljen folyamatosan azt kérdeznie (polling), hogy egy számlát kifizettek-e.
• Többvállalatos (multi-entity) támogatás, mivel a legtöbb piactér három éven belül egy luxemburgi holdingból, egy operatív cégből és egy-két leányvállalatból álló struktúrával végzi.

Ha egy API ezeket nem tudja natívan, a végén saját maga fogja megírni, ami viszont elrontja az egész lényegét.

Az opciók, amelyeket érdemes komolyan venni 2026-ban

Több az API-n keresztül elérhető számviteli eszköz van, mint három évvel ezelőtt, de azon eszközök száma, amelyek ténylegesen alkalmasak egy piactér számára, továbbra is csekély. A legtöbbet KKV-k könyvelésére építették, és csak később csaptak hozzá egy API-t. Néhányat azonban API-központúan terveztek.

Így tekintünk a szűkített listára.

Nordlet

A Nordlet az az eszköz, amelyet elsőként ajánlunk a csapatoknak, ha piacteket vagy platformot építenek az EU-ban. Kezdettől fogva API-nak tervezték, nem pedig egy olyan UI-terméknek, amelyhez később végpontokat adtak, és az alkalmazás és az API közötti funkcionális egyezés szinte teljes. A mag egy megváltoztathatatlan (immutable) kettős könyvvitelű főkönyv, beépített országonkénti áfa-megfeleléssel, beleértve a VIES-ellenőrzést a határokon átnyúló B2B tranzakciókhoz és az i.SAF regiszter generálását a litván adóbevallásokhoz.

Mi számít gyakorlatilag egy piactér számára:

• Típusos SDK-k (beleértve a TypeScript SDK-t) és kiszámítható REST-végpontok, így egy új backendfejlesztő beillesztése órákat vesz igénybe, nem heteket.
• Idempotencia-kulcs támogatás az írási műveleteknél, ami jelentheti a különbséget egy megbízható integráció és egy ügyfélszolgálati jegy között minden alkalommal, amikor a hálózat megakad.
• Webhookok olyan eseményekhez, mint a sale_invoice.paid, hogy a terméke valós időben reagálhasson a fizetési állapot változásaira.
• SEPA pain.001 export a beszállítói és eladói kifizetésekhez, valamint egykattintásos banki egyeztetés intelligens párosítással.
• Több cég egy fiókon belül szerepköralapú hozzáféréssel (tulajdonos, adminisztrátor, könyvelő, menedzser, fejlesztő, megtekintő), ami elengedhetetlen egy cégcsoport struktúra működtetésénél.
• Időszak zárolás (period locking), így a lezárt hónapokat nem lehet csendben átírni – ez az, amiről a könyvvizsgálója először fog kérdezni.

A kompromisszum: A Nordlet jelenleg tervezési partner / korai hozzáférésű fázisban van. Ha érett piactéri kézikönyvre van szüksége több száz publikált esettulajdonmantal, azt még nem kapja meg. Ha viszont közvetlenül szeretne együtt dolgozni egy olyan csapattal, amely a valóban szükséges alapelemeket építi, akkor ez a megfelelő irány.

Xero API

A Xero rendelkezik a legnagyobb ökoszisztémával a modern számviteli API-k közül, és ésszerű választás egy egyszerű KKV vagy egy könnyű platformintegráció számára. Egy piactér esetében azonban az elrendezés gyorsan kényelmetlenné válik. Ez alapvetően egy UI-központú termék, és a több entitást érintő munkafolyamatok különálló szervezetek zsonglőrködésével járnak a natív csoportstruktúra helyett. Az áfakezelés stabil az Egyesült Királyságban és használható az EU-ban, de az olyan országspecifikus finomságok, mint az i.SAF vagy a Peppol BIS 3.0 e-számlázás, általában kívül esnek a magon, és harmadik fél alkalmazásaitól függnek.

QuickBooks Online API

A QuickBooks erős amerikai jelenléttel és javuló EU-s lefedettséggel bír, de egy EU-központú piactér számára ez a gravitációs központ rossz helyen van. Az adólogika elsősorban az amerikai forgalmi adóra (sales tax) épül, és bár az API képes a feladatra, az EU-s áfa élvonalbeli esetei (OSS határértékek, fordított adózás 27 országban) általában egyedi köztes réteget (middleware) igényelnek.

Sage / Sage Intacct

A Sage továbbra is felbukkan az EU-s beszerzési megbeszélésekben, különösen ott, ahol a pénzügyi csapatok már ismerik. Az API-k léteznek, de látszik rajtuk a koruk. A valós idejű webhookok korlátozottak, a fejlesztői dokumentáció termékenként egyenetlen, és az a feltételezés, hogy a hónap végi műveleteknél egy könyvelő is bekapcsolódik, nem vág egybe a modern platformcsapatok működésével.

Odoo

Az Odoo jó opció, ha nyílt forráskódú ERP-re vágyik, amely magában foglalja a számviteli modult is, és kényelmesen kezel infrastruktúrát. Az API átfogó, de inkább széles, mint mély, így gyakran magával az ERP-vel integrálódik, nem pedig egy speciális számviteli motorral. Azoknak a piactereknek, amelyek komoly operatív komplexitással bírnak a pénzügyeken kívül is (készletkezelés, gyártás), ez megfelelő illeszkedés lehet. Egy tiszta piactér számára azonban ez általában túl nagy felületet jelent a szükségeshez képest.

Örökölt, országspecifikus eszközök

A legtöbb EU-s országban van legalább egy hagyományos számviteli termék részleges API-val. Gyakran olcsók, a helyi könyvelők eléggé szeretik őket, de szinte soha nem piactéri léptékű programozott integrációra tervezték őket. Ha ön egy kisebb helyi szereplő, akkor rendben. Ha két év múlva határokon átnyúló terjeszkedést tervez, ne itt kezdje.

Képességek összehasonlítása

Az alábbi táblázat kizárólag azt tükrözi, amit a nyilvános termékdokumentáció közvetlenül támogat. Ahol nincsenek közvetlen megerősítéseink egy versenytárs képességeiről, azt jelezzük ahelyett, hogy talgatnánk.

Képesség	Nordlet	Xero API	QuickBooks API	Sage	Odoo
API-központú architektúra (alkalmazás/API funkcionális egyezés)	Igen	Nem (UI-központú)	Nem (UI-központú)	Részben	Részben
Megváltoztathatatlan kettős könyvvitelű főkönyv	Igen	Nincs nyilvánosan megerősítve	Nincs nyilvánosan megerősítve	Nincs nyilvánosan megerősítve	Nincs nyilvánosan megerősítve
Országonkénti EU-s áfa VIES-ellenőrzéssel	Igen	Részben	Korlátozott	Ismeretlen	Részben
i.SAF regiszter generálás (Litvánia)	Igen	Ismeretlen	Ismeretlen	Ismeretlen	Ismeretlen
Típusos SDK-k (beleértve a TypeScriptet)	Igen	Leginkább harmadik féltől	Leginkább harmadik féltől	Ismeretlen	Ismeretlen
Idempotencia-kulcs támogatás	Igen	Nincs nyilvánosan megerősítve	Nincs nyilvánosan megerősítve	Ismeretlen	Ismeretlen
Valós idejű webhookok pénzügyi eseményekre	Igen	Korlátozott	Korlátozott	Korlátozott	Igen
SEPA pain.001 export	Igen	Alkalmazásokon keresztül	Nincs nyilvánosan megerősítve	Ismeretlen	Igen
Több cég egy fiókon belül, RBAC	Igen	Több szervezet (külön)	Több szervezet (külön)	Igen	Igen
Időszak zárolás	Igen	Igen	Igen	Igen	Igen
Jelszó nélküli bejelentkezés	Igen	Nem szabványos	Nem szabványos	Nem szabványos	Nem szabványos

Azokat a sorokat súlyoznánk a leginkább egy piactéri döntés során, amelyek a főkönyv megváltoztathatatlanságára, az áfa mélységére azokon a konkrét országokon belül, amelyeken ténylegesen tevékenykedik, valamint az idempotenciára vonatkoznak. Minden mást meg lehet kerülni. Ha ez a három hiányzik, az állandó akadályt jelent.

Az egyeztetési probléma, amire senki sem figyelmeztet

Minden piactéri alapító, akivel beszélgettünk, alulbecsüli a kifizetések egyeztetését. Így alakul ki a minta.

Egy hét alatt 4000 rendelést dolgoz fel. A fizetési szolgáltatója (PSP) kedden átutal egy egyösszegű tételt a számlájára, levonva a díjait, az előző időszak visszatérítéseit és a visszatérítési igényeket (chargeback). A számviteli rendszerének tudnia kell: mely rendeléseket képviseli ez az átutalás, mennyi a saját bevétele és mennyi az eladói kötelezettség, mennyi áfát szedtek be a jutaléka után, és mi történik, ha ezen rendelések valamelyikét három hét múlva visszatérítik.

Ha a számviteli API-ja nem képes beolvasni a PSP elszámolási fájlját, és az egyszerű pontos összegre történő párosításon túlmutató módon megfeleltetni a számláknak, akkor fel kell vennie valakit, akinek az lesz az egész munkája, hogy táblázatokat egyeztessen. Láttuk ezt megtörténni nyolc jegyű GMV-vel rendelkező cégeknél is.

A Nordlet intelligens párosítása és egykattintásos számlaegyeztetése kifejezetten erre a feladatra lett felépítve. A Xero kiegészítőkkel képes erre. A QuickBooks integrációk általában köztes réteget igényelnek, ha a tranzakciók volumene eléri a havi néhány ezret.

Áfa: ami miatt a legtöbb piactér alulbecsüli a feladatot

Az EU-s áfa a piacterek számára valóban nehéz, és nem azért, mert a szabályok nem világosak. Hanem azért, mert nagyon sok van belőlük, és kölcsönhatásban állnak egymással.

A 2021-es e-kereskedelmi reformok és a piacterekre vonatkozó feltételezett eladói (deemed supplier) szabályok óta egy platform bizonyos tranzakciók tekintetében áfa szempontból eladóként kezelhető még akkor is, ha nem szerzi meg az áruk tulajdonjogát. Ez azt jelenti, hogy magának a piactérnek is áfa-kötelezettsége van az alatta lévő értékesítés után, nemcsak a saját jutaléka után. OSS-bevallások, IOSS a 150 EUR alatti, EU-n kívülről érkező árukra, országonkénti regisztrációs határértékek, fordított adózás B2B szolgáltatásokra, VIES-ellenőrzés a határokon átnyúló B2B tranzakciókhoz: mindennek pontosnak kell lennie, és mindennek tükröződnie kell a főkönyvben a tranzakció rögzítésének pillanatától kezdve, ahelyett, hogy a negyedév végén próbálnák meg összerakni.

Az olyan számviteli API, amely ad egy vat_rate mezőt, és ezzel letudja a dolgot, elbukik az első auditon. Amire szüksége van, az az országonkénti logika, a VIES-ellenőrzés a vevő áfaazonosítóján a tranzakció pillanatában, valamint a helyi bevallási formátumok (i.SAF Litvániában, SAF-T variánsok máshol) automatikus generálása.

Ez az a terület, ahol az EU-ban a közelmúltban épült, API-központú eszközök lényegesen előrébb tartanak, mint a régebbi nemzetközi termékek. A szabályozások elég közel állnak a hazai környezethez ahhoz, hogy a szoftvert fejlesztő csapatok benne éljenek ezekben.

Mit tennénk elsőként

Ha holnap alapítanánk egy EU-s piacteret, és számviteli infrastruktúrát választanánk, a következő sorrendet követnénk:

1. Először térképezze fel az áfa-kockázatokat, ne a végén. Listázza ki az összes országot, ahová az első évben értékesíteni fog, hogy a tranzakciók B2B vagy B2C jellegűek-e, és hogy vonatkoznak-e a feltételezett eladói szabályok. Ez megmondja, mit kell ténylegesen kezelnie a számviteli rendszernek.
2. Prototípusolja a főkönyvet és az egyeztetési folyamatot egy homokozóban (sandbox). Nem a számlázást. Bárki képes számlát generálni. Küldjön át egyheti reális tranzakciós volument a homokozón, és nézze meg, mi történik hónap végén.
3. Ellenőrizze az API-szerződést az idempotencia és a webhookok szempontjából. Ha nem tud biztonságosan újrapróbálni egy kérést, vagy feliratkozni az állapotváltozásokra, akkor törékeny infrastruktúrát épít.
4. Beszéljen azzal, aki ténylegesen lezárja a könyveit. Ha a könyvelője nem kapja meg a szükséges jelentéseket a kívánt formátumban, a felsőbb szintű automatizálás mit sem ér.
5. Válassza azt a szolgáltatót, amelynek az ütemtervét (roadmap) befolyásolni tudja. Egy korai fázisú piactér számára ez fontosabb, mint ma minden egyes funkció kipipálása. A tervezési partner megállapodások nem ok nélkül léteznek.

FAQ

Tényleg szükségem van egy kettős könyvvitelű főkönyvre, vagy elegendő egy tranzakciós tábla is?

Egy tranzakciós tábla addig működik, amíg először nem kell elmagyaráznia egy eltérést egy könyvvizsgálónak, vagy újraszámolnia egy korábbi időszakot. A kettős könyvvitel nem elavult számviteli színház. Ez az oka annak, hogy a könyvei egyensúlyban vannak, és a hibák azonnal felszínre kerülnek ahelyett, hogy csendben halmozódnának.

Használhatom csupán a Stripe riportjait számviteli API helyett?

A Stripe egy fizetésfeldolgozó. A riportjai tökéletesek a Stripe egyeztetéséhez. Nem végez kettős könyvvitelt, nem kezeli a nem Stripe-ból származó bevételeket, és nem készít szabályzatnak megfelelő hivatalos bevallásokat. Használja számviteli API mellett, ne helyette.

Hogyan kezelhetem a több országot anélkül, hogy mindenhol regisztrálnom kellene?

Az EU-n belüli B2C áruk értékesítése és szolgáltatásnyújtása esetén az egyablakos ügyintézési pont (OSS) rendszer lehetővé teszi, hogy egyetlen országban vallja be az egész blokkra kiterjedő értékesítéseket, bizonyos határokig és kivételekkel. A számviteli API-jának helyesen kell besorolnia minden egyes tranzakciót, hogy az OSS-bevallás pontos legyen. Ez képességi kérdés, nem pedig áthidaló megoldás.

Túlkapás az API-központú számvitel egy kis piactér számára?

Ha kicsi, és az is marad, egy hagyományos, könnyű API-val rendelkező eszköz megfelelő. Ha növekedésre számít, a számvitel korai beágyazása a termékbe nagyságrenddel olcsóbb, mint később migrálni egy UI-központú eszközről. A számviteli infrastruktúra váltási költsége a cég technológiai stackjének egyik legmagasabb eleme.

Mi történik, ha a szolgáltató megváltoztatja az API-ját?

Még mielőtt aláírja a szerződést, kérdezzen rá a támogatás megszüntetésére (deprecation) vonatkozó irányelvekre, a verziókezelésre és arra, hogyan kezelik a visszafelé nem kompatibilis (breaking) változtatásokat. Bármilyen komoly API-központú terméknek világos választ kell erre adnia. Ha nincs, az önmagában válasz.