A legjobb könyvelési API-k SaaS-platformokhoz és piacterekhez (2026)
Hét opció, amelyet egy platformcsapat valóban megfontol, az egyes eszközök rendeltetése szerint csoportosítva, a döntést meghatározó korlátokkal és árazási modellekkel.
A „legjobb könyvelési API” megválaszolhatatlan kérdés mindaddig, amíg nem tisztázzuk, mire is kell az API. Az ebben a keresésben feltűnő termékek nem versenytársai egymásnak. Négy olyan kategóriába sorolhatók, amelyek eltérő problémákat oldanak meg, és a rossz kategóriából választani a legköltségesebb hiba, amit elkövethetünk.
Ez az útmutató kategóriák szerint rendezi a valós opciókat, bemutatja, hogy miben jó az egyes eszközök mindegyike, és megnevezi azokat a korlátokat, amelyek eldöntik a választást. A többi szállítóra vonatkozó tények a saját dokumentációjukból és árazási oldalaikról származnak (ezek végig linkelve vannak); mindent, amit nem tudtunk ellenőrizni, nem feltételezésként, hanem ellenőrizetlenként jelölünk.
A négy kategória
| Kategória | Mit nyújt | Kinek ajánlott |
|---|---|---|
| Beágyazott könyvelési háttérrendszer | Törvényi előírásoknak megfelelő, a terméke tulajdonát képező kettős könyvvitel, adókezeléssel és bizonylatokkal | Olyan platformoknak, amelyeknek a nyilvántartási rendszer szerepét kell betölteniük |
| Alkalmazásközpontú könyvelés API-val | Egy érett könyvelési alkalmazás, plusz programozott hozzáférés ahhoz | Olyan termékeknek, amelyek olyan vállalkozásokat szolgálnak ki, amelyek már abban az alkalmazásban könyvelnek |
| Főkönyvi infrastruktúra | Gyors, megmásíthatatlan egyenlegkövetés törvényi könyvelés nélkül | Pénztárcák, alkalmazáson belüli egyenlegek, fizetési termékek |
| Aggregátor / egységesített API | Egyetlen felület bármelyik könyvelési apphoz, amit az ügyfél használ | Olyan eszközöknek, amelyek olvassák vagy írják az ügyfeleik könyveit |
| Adómotor | Kulcsok, számítás, néha bevallás | Bárkinek, akinek adózási döntésekre van szüksége a máshol vezetett könyvelés mellett |
Gyors összehasonlítás
| Termék | Kategória | Saját könyvek | EU áfa mélysége | Árazási modell |
|---|---|---|---|---|
| Nordlet | Beágyazott könyvelési háttérrendszer | Igen | Országonkénti áfa, VIES, OSS/IOSS bevallások | Kérések alapján mérve |
| Xero API | Alkalmazásközpontú könyvelés | Igen, a Xeróban | Áfa-bevallások a támogatott országonként | Szervezetenként, havonta |
| QuickBooks Online API | Alkalmazásközpontú könyvelés | Igen, a QuickBooksban | Áfa régiónként; nincs szabványos IOSS-eljárás | Vállalati előfizetésenként |
| Odoo | ERP RPC API-val | Igen, saját vagy felhős üzemeltetésben | Helyi támogatási modulok országonként | Felhasználónként, az API a Custom csomagban |
| Modern Treasury Ledgers | Főkönyvi infrastruktúra | Egyenlegek, nem törvényi könyvek | Nem adózási termék | Szerződéses |
| Codat / Rutter / Merge | Aggregátor | Nem, az ügyfél saját eszköze tárolja | Az alatta lévő alkalmazástól öröklődik | Szerződéses, általában kapcsolatonként |
| Stripe Tax | Adómotor | Nem | Számítás és opcionális bevallás | Számításonként és tranzakciónként |
1. Nordlet - beágyazott kettős könyvvitel EU áfával
A Nordlet egy olyan könyvelési háttérrendszer, amelyet a platform a saját kódjából hívhat meg. Egyetlen REST-felületen keresztül biztosít megmásíthatatlan kettős könyvviteli főkönyvet, számlázást, beszerzési nyilvántartásokat, banki egyeztetést, készletkezelést, bérszámfejtést és EU-s adózást (jelenleg több mint 400 végpontot 29 modulban, amelyek egyetlen OpenAPI-specifikációból generálódnak).
Mi számít különösen a platformok fejlesztése során: a könyvelési tételek egyensúlyát az adatbázis triggere kényszeríti ki a mentés (commit) pillanatában, nem pedig az alkalmazás kódja; a lezárt időszakok elutasítják az azokon belüli dátumú tételeket; a bizonylatszámok hézagmentesek és párhuzamosság-biztos módon (concurrency-safely) kerülnek lefoglalásra; minden módosítást rögzít a rendszer a végrehajtóval, a művelettel, az entitással és magával a változással együtt. Az újbóli próbálkozások ellen az Idempotency-Key fejléc védi a rendszert, amely a tárolt választ játssza vissza a második bizonylat létrehozása helyett. A webhook-események egy tranzakciós outboxba íródnak ugyanabban az adatbázis-tranzakcióban, mint a változás, így a visszagurított (rolled-back) bizonylat sosem bocsát ki eseményt.
A díjazás mérésen alapul: a csomagok havi 10 eurótól indulnak 3 000 kéréssel, 50 eurótól 30 000 kéréssel, és 300 eurótól 200 000 kéréssel, a további kérések pedig kérés alapú elszámolással számlázódnak. Minden csomag tartalmazza az összes modult és a teljes API-t; a cégek, a felhasználók és a tesztcégek (sandbox) száma korlátlan.
A fontosabb korlátok: a Nordlet korai hozzáférésű (early access) fázisban van, és az integrációs partnerek kiválasztása zajlik, így a gyártási határidők komoly megfontolást igényelnek. Az EU áfakulcs-referenciája lefedi az EU-27-et, az OSS- és IOSS-bevallások a számlák alapján számítódnak, de 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) –, a bérszámfejtés csak litván nyelvű, és az adóhatóság felé egyik bevallás sem kerül benyújtásra az Ön nevében.
Leginkább ajánlott: piacterek, SaaS-platformok és e-kereskedelmi termékek számára, amelyeknek saját termékükön belül kell birtokolniuk a könyveiket és az EU áfa-bizonyítékaikat.
2. Xero API - egy érett, alkalmazásközpontú könyvelési API
A Xero egy jól dokumentált REST API-val, alkalmazásáruházzal és népes könyvelői közösséggel rendelkező könyvelési alkalmazás. Ha az ügyfelei már a Xeróban vezetik a könyveiket, az integráció pontosan ott éri el őket, ahol nincsenek elszakadva a megszokott környezetüktől.
Beágyazott használat esetén a korlátok inkább strukturálisak, mint technikai jellegűek. A Xero dokumentációja percenkénti 60 és csatlakoztatott szervezetenkénti napi 5 000 hívásban, 5 párhuzamos hívásban, valamint egy teljes alkalmazásra vonatkozóan percenkénti 10 000 hívásban határozza meg az API-korlátokat. A nem hitelesített alkalmazások legfeljebb 25 szervezethez kapcsolódhatnak; ezen túlmenően az App Partner tanúsítvány megszerzése szükséges, ami egy többszintű ellenőrzési folyamatot és kereskedelmi feltételeket jelent. Az árazás szervezetenként és havonta történik, országonként feltüntetve a Xero árazási oldalain.
Leginkább ajánlott: olyan termékekhez, amelyek integrálódnak az ügyfelek által már használt könyvelési adatokkal. Több száz vagy ezer bérlő (tenant) könyvelési háttérrendszereként nehezebben használható, mert minden bérlő külön előfizetést és külön kapcsolatot jelent ezen korlátok mellett.
3. QuickBooks Online API - a legnagyobb felhasználói bázis
A QuickBooks Online rendelkezik a legnagyobb kisvállalkozási piaci részesedéssel számos piacon, és OAuth 2.0 REST API-val, webhookokkal, valamint nagyméretű fejlesztői ökoszisztémával bír. A korlátozási (throttling) határok általános dokumentációja szerint vállalatonként percenként 500 kérés engedélyezett, a batch- és riportvégpontokon alacsonyabb limitek mellett; az aktuális adatok ellenőrzéséhez az Intuit saját fejlesztői dokumentációja az irányadó.
Az API egy vállalati fájlra terjed ki, így a sok vállalkozást kiszolgáló platform több kapcsolatot kezel, mint egyetlen többvállalatos fiókot. Az EU-n belüli határokon átnyúló adózás terén az Intuit saját ügyfélszolgálati anyagai megjegyzik, hogy nincs szabványos eljárás az IOSS áfa rögzítésére, és könyvelő vagy adótanácsadó bevonását javasolják – amit érdemes tudni, mielőtt távértékesítési folyamatokat tervezünk köré.
Leginkább ajánlott: a már a QuickBooksot használó vállalkozások elérésére. Nem arra tervezték, hogy más platformján belül főkönyvként szolgáljon.
4. Odoo - nyílt forráskódú ERP modellszintű API-val
Az Odoo a könyvelés mellett a készletkezelést, a gyártást, a CRM-et és sok mást is lefed, saját szerveren is üzemeltethető (self-hosted), és valóban bővíthető. Külső API-ja nem domain-, hanem modellszintű: ORM-metódusokat hív meg az olyan modelleken, mint az account.move és a res.partner XML-RPC-n vagy JSON-RPC-n keresztül. Ez nagy erőt ad, de azt is jelenti, hogy Ön viseli a felelősséget a modellek helyes használatáért.
Két tény változtatja meg a számítást a platformfejlesztők számára. Az Odoo dokumentációja szerint a külső API-hozzáférés a Custom árazási szinten érhető el, a One App Free vagy a Standard csomagokban nem. Emellett az Odoo bejelentette, hogy a /xmlrpc, /xmlrpc/2 és /jsonrpc végpontokat az Odoo 22-ben és az Odoo Online 21.1-ben ki kívánják vezetni, és az újabb JSON-2 API veszi át a helyüket – így a ma felépített integrációra egy migráció vár a jövőben. Az árazás felhasználónként és havonta történik, az Odoo árazási oldalán közzétett adatok szerint.
Leginkább ajánlott: olyan cégeknek, amelyek egyetlen rendszert szeretnének a működéshez és a pénzügyekhez, és rendelkeznek házon belüli kapacitással annak üzemeltetéséhez és frissítéséhez. Részletesebb elemzés olvasható a Nordlet vs Odoo platformfejlesztőknek című cikkben.
5. Modern Treasury Ledgers - főkönyvi infrastruktúra
A Modern Treasury Ledgers nagy áteresztőképességű, megmásíthatatlan, kettős könyvviteli egyenlegkövetést biztosít fejlesztők számára, pénztárcákat, alkalmazáson belüli egyenlegeket és fizetési termékeket célozva meg. Kialakítása a nagy mennyiségű adatok konzisztenciáját és párhuzamosságát szolgálja.
Ez azonban nem törvényi könyvelés. Nincs benne az éves beszámolóhoz szükséges számlatükör, adómotor, számlázási sorszámozás vagy adónyilvántartás. A csapatoknak gyakran mindkettőre szükségük van: infrastruktúrára a valós idejű egyenlegekhez, és egy könyvelési rendszerre a benyújtandó könyvekhez.
Leginkább ajánlott: valós idejű egyenlegekhez nagy tranzakciós sebesség mellett, külön kezelt törvényi könyveléssel.
6. Codat, Rutter és Merge - egységesített API-k az ügyfél könyveihez
Ezek a termékek egyetlen olyan felületet biztosítanak, amely számos könyvelési rendszeren keresztül olvas és ír, kezelve a hitelesítést, a mezők megfeleltetését és a szinkronizálást. A Codat inkább a hitelezési és banki felhasználási esetekre fókuszál, a Rutter a kereskedelmi és fizetési adatokra, míg a Merge széles horizontális felületet kínál számos szoftverkategórián átívelően.
Amit tisztán kell látni: egy aggregátor használata esetén a könyvek továbbra is az ügyfél könyvei maradnak az ügyfél saját eszközében. Ez teljesen helyénvaló, ha hitelezést, kiadáskezelést vagy analitikát épít. Viszont teljesen rossz választás, ha a platformjának kell a nyilvántartási rendszer szerepét betöltenie, mivel így örökli az egyes mögöttes alkalmazások viselkedését, és nem tud egységes modellt kikényszeríteni közöttük.
Leginkább ajánlott: az ügyfelek meglévő könyveinek nagy tömegű olvasásához vagy írásához.
7. Stripe Tax - adószámítás, nem könyvelés
A Stripe Tax kiszámítja és beszedi az adót a Stripe-stacken belül, és a magasabb szinteken kezelt bevallást is kínál, világos, nyilvános árazással számítási hívásonként és tranzakciónként. A tranzakciós nyilvántartásai adóügyi bizonylatok, nem pedig általános könyvelési naplók.
Leginkább ajánlott: olyan vállalkozások számára, amelyek már a Stripe-ot használják, és gyorsan szükségük van a helyes adóra, míg a könyveiket máshol vezetik.
Melyiket válassza a különböző feladatokhoz?
| Feladat | Válassza ezt |
|---|---|
| A platform saját könyveinek hivatalos nyilvántartási rendszere lenni | Beágyazott könyvelési háttérrendszer |
| Olyan vállalkozások kiszolgálása, amelyek a Xeróban vagy a QuickBooksban könyvelnek | Az adott szállító API-ja, vagy aggregátor, ha többre van szüksége |
| Pénztárcaegyenlegek követése másodpercenkénti ezer tranzakció mellett | Főkönyvi infrastruktúra |
| Sok ügyfél könyveinek olvasása hitelezéshez vagy elemzéshez | Aggregátor |
| A megfelelő adókulcs beszerzése fizetéskor (checkout) | Adómotor |
| Pénzügyek és műveletek futtatása egy rendszerben, házon belül | ERP |
A legtöbb platform a végén kettőt használ ezek közül, nem csak egyet. A tervezésre érdemes párosítás egy olyan könyvelési háttérrendszer, amely a könyveket birtokolja, kiegészülve egy adómotorral vagy aggregátorral a széleken – és az elsőként meghozandó döntés az, hogy melyik termék birtokolja a nyilvántartást, mivel minden más ehhez igazodik.
FAQ
Melyik a legjobb könyvelési API egy piactér számára?
Egy olyan piactér számára, amelynek birtokolnia kell a könyveit, a beágyazott könyvelési háttérrendszer a megfelelő kategória, mivel az eladói kifizetetlen számlákat, a jutalékbevételeket, a visszatérítéseket és az országonkénti áfát egy helyen, auditálható nyomvonallal kell rögzíteni. Az olyan alkalmazásközpontú API-k, mint a Xero és a QuickBooks, jobban illeszkednek az ügyfelek által már használt könyvek integrálásához, mintsem hogy száz bérlő főkönyveként szolgáljanak.
Használhatom egyszerűen a Stripe-ot a piactér könyveléséhez?
A Stripe mozgatja és felosztja a pénzt, valamint képes adót számítani. Nem vezet kettős könyvvitelt a platformja számára: az elért jutalékot, a díjak után fizetendő áfát, a fizetés és a kifizetés közötti eladói kötelezettségeket, a visszatérítéseket és a tartalékokat valahol rögzíteni kell, és ezt a nyilvántartást egyeztetni kell a Stripe-pal ahelyett, hogy vakon megbíznánk benne.
Az egységesített könyvelési API helyettesíti a saját főkönyvet?
Nem. Az egységesített API egy utat jelent mások főkönyveibe. Ha az Ön platformja a nyilvántartási rendszer, szüksége van a sajátjára.
Mennyibe kerülnek a könyvelési API-k?
A modellek jobban különböznek egymástól, mint maguk az árak. A szervezetenkénti és felhasználónkénti árazás a vállalkozás struktúrája alapján terhel, míg a mérésen alapuló árazás a használat szerint. A Nordlet nyilvános csomagjai havi 10 eurótól indulnak, 3 000 kérést tartalmazva. A Xero, a QuickBooks és az Odoo a saját oldalain teszi közzé az előfizetési árakat szervezet-, vállalat- vagy felhasználónként, és ezekkel az adatokkal érdemes kalkulálni a költségvetésben.
Mit kell letesztelni, mielőtt elkötelezi magát bármelyik mellett?
Könyveljen le egy felosztott tranzakciót, és ellenőrizze a naplót. Küldje el ugyanazt a kérést kétszer, és számolja meg az eredményeket. Próbáljon meg szerkeszteni egy már lekönyvelt tételt, illetve lezárt időszakba könyvelni. Exportáljon egyhavi adatot, és nézze meg, hogy egy könyvelő tudja-e értelmezni. Ez a négy teszt gyorsabban szétválasztja a kategóriákat, mint bármilyen funkciólista.