Számviteli integráció költsége: Minden szolgáltató külön projekt

A becslések szerint egy-egy számviteli rendszer integrációja három héttől tizenkét hónapig terjed, és a munka nem vihető át az egyik szolgáltatótól a másikra. Íme a számok, a források és az alternatíva.

Az a platform, amely az ügyfelei számviteli rendszereihez csatlakozik, szolgáltatónként külön integrációt épít ki. Az egyes integrációkra vonatkozó nyilvános becslések a QuickBooks első működő kapcsolatának 3-4 hetétől a NetSuite 6-12 hónapjáig terjednek, és minden általunk talált becslés olyan cégtől származik, amely éppen egy olyan megoldást árusít, amellyel ez a munka elkerülhető. A munka nem vihető át egyik rendszerből a másikra: a QuickBooks, a Xero, a NetSuite és a Microsoft Dynamics 365 Business Central saját bejelentkezési módszerrel, token-élettartammal, lekérdezési szintaxissal, kérésszám-korláttal, díjazással és verzióelavulási ütemtervvel rendelkezik. Hat szolgáltató hat projektet és hat karbantartási költségvetést jelent.

Ez a cikk összegyűjti a nyilvános adatokat a forrásaikkal együtt, bemutatja, hol térnek el egymástól a szolgáltatók, és ismerteti a másik lehetőséget: a könyvelést a saját terméken belül vezetni egyetlen számviteli API-n keresztül, így szolgáltatónkénti integrációk helyett csak egyet kell felépíteni.

Mennyi ideig tart egy számviteli integráció?

Senki sem tesz közzé semleges felmérést az integrációk bevezetési idejéről. Az alábbi adatok mind olyan cégektől származnak, amelyek egységesített számviteli API-kat árusítanak, így érdekükben áll a munka nagyságrendjének feltüntetése. Ennek ellenére ezek a legkonkrétabb elérhető számok, és összhangban vannak egymással, ha elválasztjuk az „első működő verziót” a „production” környezettől.

Forrás	Mit állítanak	Mi a saját érdekük
Apideck (2026)	QuickBooks: „egy képzett fejlesztő 3-4 hét alatt összehozhat egy működő prototípust”. Több mint 35 összekötő fenntartásához „legalább egy, az integráció karbantartásának szentelt fejlesztő szükséges”.	Egységes API-t árusít
Rutter (2026. április)	„Három fejlesztői hónap platformonként”, amit a Rutter konzervatív becslésnek nevez. A NetSuite esetében „a határidő hat-tizenhét hónapra nyúlik”. Egy ügyfél a QuickBooksot két fejlesztőre becsülte pár hónapra; „legalább három hónapig tartott több iterációval”.	Egységes API-t árusít
Merge	150 óra egy integráció felépítésére és 300 óra évente a karbantartására, 150 000 dolláros fizetéssel számolva. A Merge a költséget „évi 50 000 és 150 000 dollár közé” teszi.	Egységes API-t árusít

Ezekben a számokban két dolog fontosabb, mint a végösszegek.

Először is, a három hét és a három hónap közötti rés a demó és a production környezet közötti különbség. Egy számlát létrehozó kapcsolat gyorsan működik. Az a kapcsolat viszont, amely túléli a tokenek lejáratát, a duplikált webhookokat, a sebességkorlátokat, a részleges hibákat és azt, amikor az ügyfél egy másik cégfájlt csatlakoztat újra, kitölti a fennmaradó időt. A felhőalapú számviteli API integrálása SaaS platformba című útmutatónk lépésről lépésre felsorolja ezt a munkát.

Másodszor, a Merge modelljében a karbantartás nagyobb feladat, mint maga az építés: évi 300 óra szemben a egyszeri 150 órával. Ez a költség minden évben megismétlődik minden egyes támogatott szolgáltató után.

Miért kerül ugyanolyan sokba a második integráció, mint az első?

Ha a szolgáltatók ugyanazt az felületet biztosítanák, a második integráció az első nagy részét újrahasznosíthatná. De nem ezt teszik. A táblázat négy széles körben használt rendszert hasonlít össze.

	QuickBooks Online	Xero	NetSuite	Business Central
Bejelentkezés	OAuth 2.0	OAuth 2.0	OAuth 2.0; a tokonalapú hitelesítés lezárva az új integrációk előtt a 2027.1-es kiadástól	Kizárólag Microsoft Entra ID OAuth
Hozzáférési token élettartama	1 óra	30 perc	60 perc	Az Entra ID által beállított
Frissítési (refresh) token	100 napos gördülő, legfeljebb öt év	60 napos gördülő	7 nap	Az Entra ID által beállított
Lekérdezési stílus	SQL-szerű `SELECT … FROM Invoice`, nincs `OR`, nincsenek joinok	REST `where` paraméterrel	SuiteQL (SQL) REST-en keresztül, plusz SOAP 2028-ig	OData v4
Kérésszám-korlát	500 kérés percenként és 10 másodpercenként cégenként	60 percenként, 5000 naponta és 5 párhuzamos cégenként	5-20 párhuzamos kérés fiókonként, szolgáltatási szint alapján	6000 kérés 5 percenként és 5 párhuzamos felhasználónként
Külön API díj	App Partner Program: ingyenes szint, majd havonta 300 - 4500 USD	Alkalmazáscsomagok az ingyenesektől havi 1445 AUD-ig	Nem található; a plusz párhuzamosság SuiteCloud Plus licencekként vásárolható meg	Nem található

Források: Intuit authorization FAQ, Intuit limits and throttles, Intuit App Partner Program guide, Xero OAuth 2.0 guide, Xero API limits, Xero pricing, NetSuite OAuth 2.0 tokens, NetSuite token-based authentication, Business Central operational limits.

A tokenek négy különböző ütemezés szerint járnak le

Egy integrációnak frissítenie kell az egyes szolgáltatók tokenjeit a lejáratuk előtt, és minden alkalommal el kell mentenie az új frissítési tokent, különben az ügyfélnek újra kell csatlakoznia. Az ütemezések tizennégyszeres eltérést mutatnak: egy NetSuite frissítési token hét napig tart, míg a QuickBooks esetében 100 napig. A QuickBooks egy szigorú felső határt is bevezet: a frissítési tokenek legfeljebb öt évig érvényesek, így a hosszú ideig futó kapcsolatok a használattól függetlenül egy fix dátummal lejárnak. Minden ütemezés megköveteli a saját frissítési háttérfolyamatát, a saját hibakezelését és a saját „kérjük, csatlakozzon újra” üzenetét az ügyfél felé.

Minden szolgáltatónak saját lekérdezési nyelve van

Az adatok beolvasása az a terület, ahol a kód a legtöbb helyen eltér. A QuickBooks egy korlátozott SQL-dialektust fogad el OR és joinok nélkül, oldalanként legfeljebb 1000 rekordot visszaadva. A Xero az URL-ben található where kifejezéssel szűr, és nagy szervezetek számára egyszerű egyenlőségi teszteket javasol. A NetSuite a SuiteQL-t használja, amely egy saját végpontra elküldött teljes SQL-dialektus. A Business Central OData szűrőket használ. Az a lekérdezés, amely egy ügyfél kifizetetlen számláit keresi meg, négy különböző kódrészletet jelent, amelyek mindegyike saját lapozással és saját élponti esetekkel rendelkezik.

Minden szolgáltató másképp korlátozza a forgalmat

A QuickBooks és a Xero cégenként és percenként számolja a kéréseket. A NetSuite a teljes fiókra vonatkozóan számolja a párhuzamos kérések számát, így az integráció osztozik a kereten az ügyfél által futtatott összes többi integrációval, és a NetSuite elutasítja a korlátot meghaladó hívásokat. A Business Central ötperces ablakban, felhasználónként számol. Egy olyan tömeges importálás, amely biztonságos az egyik szolgáltatónál, a másiknál korlátozásba ütközik, így a forgalomszabályozási és újrapróbálkozási logikát szolgáltatónként külön meg kell írni.

A hozzáférés kereskedelmi kapcsolat

A négy szolgáltató közül kettő már felszámít díjat az API-hozzáférésért a forgalom alapján. Az Intuit App Partner Programja méri a „CorePlus” hívásokat (amelyek az adatleolvasások nagy részét lefedik), és az ingyenes szinten a benne foglalt mennyiség felett blokkolja azokat; a fizetős szintek havonta 300, 1700 és 4500 USD-be kerülnek. A Xero 2026. március 2-án tért át a fizetős alkalmazáscsomagokra: az 5 kapcsolatra korlátozott ingyenes csomagtól kezdve a 10 000 kapcsolatot biztosító, havi 1445 AUD összegű csomagig terjed a kínálat. Az integráció futtatási költsége ezért attól függ, hogy az ügyfelei közül hányan használják az adott szolgáltatót, és mennyi adatot olvas be.

A szolgáltatók a saját ütemtervük szerint változtatják a szabályokat

A ma működő integrációk esetében máris bejelentették a kényszerű átírások listáját:

A NetSuite a 2027.1-es kiadástól kezdve leállítja a tokonalapú hitelesítést használó új integrációk fogadását, az Oracle SOAP-ról szóló értesítése szerint pedig „a 2028.2-es NetSuite kiadással az összes végpont le lesz tiltva, és a SOAP-alapú integrációk leállnak” (NetSuite SOAP notice).
A Xero a 2026 márciusától létrehozott alkalmazásokhoz részletes engedélyköri hatóköröket (scopes) rendel, a meglévő alkalmazásoknak pedig 2027 szeptemberéig kell átállniuk (Xero OAuth 2.0 overview).
A QuickBooks alkalmazza a fent említett ötéves frissítési token felső határt, és kivezette a régebbi API alverziókat, így a 75-ös verzió lett az alap.
A Business Central online verziója 2022-ben leállította a webszolgáltatások hozzáférési kulcsainak (alapszintű hitelesítés) fogadását; az integrációknak át kellett állniuk az Entra ID OAuth hitelesítésre (Microsoft deprecation list).

Ezek a változtatások egyike sem ad hozzá új funkciót az ügyfelei számára. Mindegyik olyan fejlesztési időt jelent, amelyet a meglévő kapcsolat működőképességének megőrzésére fordítanak, megszorozva a támogatott szolgáltatók számával.

Hat integráció matematikai számítása

Vegyük a Rutter platformonkénti három fejlesztői hónapra vonatkozó adatát és a Merge évi 300 órás karbantartási adatát, és alkalmazzuk ezt hat számviteli rendszerre:

	Egy szolgáltató	Hat szolgáltató
Bevezetés	3 fejlesztői hónap	18 fejlesztői hónap
Karbantartás évente	300 óra	1800 óra, ami közel egy teljes munkaidejű fejlesztőnek felel meg

Ezek a szolgáltatók saját feltételezései, nem a miéink, és önmagában a NetSuite meghaladná ezeket. A lényeg a struktúra: a költség a szolgáltatók számával növekszik, a karbantartási sor pedig soha nem ér véget. Az egységes API csökkenti a bevezetési sort, de ettől kezdve függni fog attól, hogy az API milyen jól kezeli az egyes szolgáltatók írási műveleteit és élponti eseteit, ráadásul kapcsolatok vagy hívások alapján kell fizetni érte. Az építés versus vásárlás cikkünk végigvezeti Önt ezen költségek őszinte kiszámításán.

Integráljon egyszer: vezesse a könyvelést a termékén belül

Az összekötő (connector) modell feltételezi, hogy az ügyfél könyvelése egy olyan rendszerben él, amelyet az ügyfél választott, és az Ön platformja átmásolja oda az adatokat. Létezik egy második modell is: az Ön platformja maga vezeti a könyvelést egyetlen számviteli API-n keresztül, és azt a saját felületén jeleníti meg. A Nordletet erre tervezték. Egyetlen integrációt kell felépíteni, függetlenül attól, hogy milyen számviteli szoftvert használtak korábban az ügyfelei.

Így néz ki ez az egyetlen integráció a Nordletben:

Egységes kérésszerkezet. Minden művelet a POST /v1/{module}/{resource}/{action formátumot követi. Minden list művelet ugyanazt a szűrési, rendezési és lapozási törzset fogadja el, és minden hiba ugyanazt a burkolékot használja. Az egyik végpontra megírt kód ugyanúgy működik a többinél is. Lásd az API konvenciókat.
API-kulcsok a frissítési tokenek helyett. Egy kulcs egy céghez tartozik, rögzített engedélyköri hatókörökkel rendelkezik, beállítható lejárati dátummal bír, és visszavonható. Nincs forgatandó és tárolandó frissítési token.
Biztonságos újrapróbálkozások. Minden módosítás elfogad egy Idempotency-Key fejlécet. Ha egy kérést ugyanazzal a kulccsal megismétel, az a tárolt választ adja vissza ahelyett, hogy egy második számlát hozna létre.
Aláírt webhookok újrapróbálkozással. Az események ugyanabban az adatbázis-tranzakcióban íródnak, mint a változás, HMAC-SHA256 aláírással vannak ellátva, és körülbelül 24 órán keresztül újrapróbálkoznak.
Egyetlen nyilvános kérésszám-korlát. API-kulcsonként percenként 300 kérés, amit az x-ratelimit-* felécek jeleznek vissza.
Típusos SDK-k kilenc nyelven, egyetlen OpenAPI-specifikációból generálva. Lásd az SDK-kat.
Korlátlan tesztcég (sandbox) egyetlen fiók alatt az integrációs teszteléshez.
Egyetlen árlista. A csomagok kérésalapúak, havi 3000 kéréstől 10 eurótól indulva. Lásd a díjszabást.

A kettős könyvviteli főkönyv, a számlák, a banki egyeztetés, az áfabevallások és a kimutatások ugyanazon az API-n keresztül érhetők el, így az integráció magát a könyvelést fedi le a másolat helyett. A funkciók oldala felsorolja a benne foglaltakat, a mi az a számviteli API cikk pedig részletesebben elmagyarázza a modellt.

Ügyfelek, akiknek már máshol van a könyvelésük

Két dolog váltja fel azokat a szolgáltatónkénti összekötőket, amelyeket egy platformnak különben ki kellene építenie ezekhez az ügyfelekhez:

Átköltözés. Egy cég számlatükre, partnerei, nyitóegyenlegei vagy teljes naplótörténete, nyitott számlái, tárgyi eszközei és készletei egyetlen hívással importálhatók. Lásd a másik rendszérből történő migrálást.
Fájlok a könyvelő számára. Azokon a helyeken, ahol az ügyfél könyvelője a saját szoftverében dolgozik, a Nordlet abban a formátumban exportálja a főkönyvet, amelyet az a szoftver olvas: német könyvelők számára DATEV könyvelési köteggel (POST /v1/reports/datev), svéd könyvelők számára pedig SIE 4 fájllal (POST /v1/reports/sie). A fájlexporthoz nincs szükség bejelentkezésre, token-frissítésre és a számviteli szolgáltató hívásonkénti díjára sem.

Mikor jelentenek mégis helyes választást az összekötők?

A könyvelés terméken belül történő vezetése nem minden platform számára a helyes választás:

Ha ügyfeleinek pénzügyi csapatai megkövetelik, hogy a meglévő számviteli rendszerük maradjon a nyilvántartási rendszer (system of record), akkor közvetlenül vagy egységes API-n keresztül épített összekötőkre van szükség.
Ha csak néhány dokumentumot kell átküldenie az ügyfél könyvelésébe (például rendelésenként egy számlát), akkor elegendő lehet egyetlen közvetlen összekötő ahhoz a szolgáltatóhoz, amelyet a legtöbb ügyfele használ.
Ha az ügyfelei többsége egyetlen szolgáltatót használ, akkor egyetlen közvetlen integráció egyetlen projektbe kerül, nem hatba.

Az egyszeri integráció érve akkor érvényes, ha a platformjának kell futtatnia a felhasználói könyvelését, nem pedig tükröznie azt: a kifizetéseket az eladóknak teljesítő piacterek, a felhasználóik nevében számlázó platformok, valamint azok a SaaS termékek, amelyekben a könyvelés a termék részét képezi. Melyik út kiválasztása előtt a számviteli API előzetes tesztelési terve című cikkünk felsorolja, mit érdemes tesztelni.

FAQ

Mennyi ideig tart egy QuickBooks integráció felépítése?

Az Apideck becslése szerint egy képesített fejlesztő három-négy hét alatt készíthet el egy első működő verziót. Egy Rutter-ügyfél két fejlesztővel számolt pár hónapra, de végül legalább három hónapra és több iterációra volt szükség. A production munkálatok - a tokenek frissítése, az újrapróbálkozások, a kérésszám-korlátok, az újracsatlakozás és a megeyeztetés - jelentik a különbséget ezek között az adatok között.

Mennyi ideig tart egy NetSuite integráció?

A Rutter hat és tizenkét hónapra teszi a NetSuite integrációját. A NetSuite fiókszintű párhuzamossági korlátokat, hétnapos frissítési tokeneket, a SOAP mellett SuiteQL-t, valamint bejelentett változásokat hoz: a 2027.1-es kiadástól kezdve nincsenek új tokonalapú hitelesítéses integrációk, a 2028.2-es kiadásban pedig a SOAP-végpontok le lesznek tiltva.

Megszünteti-e egy egységes számviteli API a szolgáltatónkénti munkát?

Csökkenti az építési időt, mivel egyetlen felület fedi le a különböző szolgáltatókat. Nem szünteti meg a szolgáltatók közötti különbségeket: az írási műveletek, az egyedi mezők és az élponti esetek gyakran egyenetlenül támogatottak, ráadásul az egységes API ára hozzáadódik a szolgáltatók saját API-díjaihoz. A kompromisszumokat a SaaS integrációs útmutatónkban tárgyaljuk.

Mennyibe kerül a QuickBooks és a Xero API-hozzáférése?

Az Intuit App Partner Programja egy ingyenes Builder szinttel, valamint havonta 300, 1700 és 4500 USD-be kerülő fizetős szintekkel rendelkezik, ahol a benne foglalt mennyiséget meghaladó adatleolvasásokat mérik. A Xero 2026. március 2 óta érvényes alkalmazáscsomagjai az 5 kapcsolatra szóló ingyenes csomagtól a 10 000 kapcsolatra vonatkozó, havi 1445 AUD összegű csomagig terjednek, a nagyobb csomagok ára pedig egyedi megállapodás alapján alakul.

Kiválthatja-e a Nordlet az ügyfeleim számviteli rendszereivel meglévő integrációkat?

Ha a platformja a saját rendszerében vezeti a felhasználói könyvelését, akkor igen: a szolgáltatónkénti integrációk helyett egyetlen integrációt épít ki a Nordlet API-jával. A meglévő könyvelés egyetlen hívással importálható, a DATEV- vagy SIE-kompatibilis szoftvert használó könyvelők pedig exportfájlokat kapnak. A Nordlet nem szinkronizál a QuickBooks, Xero, NetSuite vagy Business Central rendszerekbe; ha azoknak kell maradniuk a nyilvántartási rendszernek, továbbra is szüksége lesz a hozzájuk tartozó összekötőkre.