Grāmatvedības integrācijas izmaksas: viens projekts katram pakalpojumu sniedzējam
Publiskie aprēķini svārstās no trim nedēļām līdz divpadsmit mēnešiem katrai grāmatvedības sistēmai, turklāt ieguldītais darbs netiek pārcelts no viena pakalpojumu sniedzēja uz nākamo. Šeit ir apkopoti rādītāji, to avoti un alternatīvais risinājums.
Platforma, kas izveido savienojumu ar savu klientu grāmatvedības sistēmām, katram pakalpojumu sniedzējam izstrādā atsevišķu integrāciju. Publiski pieejamās aplēses vienai integrācijai svārstās no trim līdz četrām nedēļām pirmajam strādājošajam QuickBooks savienojumam un līdz sešiem vai divpadsmit mēnešiem NetSuite gadījumā, turklāt katra atrasta aplēse nāk no uzņēmuma, kas tirgo veidu, kā šo darbu novērst. Šis darbs netiek pārcelts: QuickBooks, Xero, NetSuite un Microsoft Dynamics 365 Business Central katrai ir sava pieteikšanās metode, marķieru (tokens) derīguma termiņš, vaicājumu sintakse, pieprasījumu limiti, maksas un novecošanas grafiks. Seši pakalpojumu sniedzēji nozīmē sešus projektus un sešus uzturēšanas budžetus.
Šajā rakstā ir apkopoti publiskie rādītāji un to avoti, parādīts, ar ko pakalpojumu sniedzēji atšķiras, un izskaidrots otrs variants: grāmatvedības datu kārtošana jūsu pašu produktā, izmantojot vienu grāmatvedības API, lai vietā, kur katram pakalpojumu sniedzējam nepieciešama atsevišķa integrācija, būtu jāizveido tikai viena.
Cik ilgā laikā tiek izveidota viena grāmatvedības integrācija
Neviens nepublicē neitrālu pētījumu par integrācijas izstrādes laiku. Zemāk redzamie rādītāji visi ir ņemti no uzņēmumiem, kas pārdod vienotas grāmatvedības API (unified accounting APIs), tāpēc tiem ir pamats padarīt šo darbu šķietami apjomīgu. Tomēr tie joprojām ir viskonkrētākie pieejamie skaitļi, un tie ir savstarpēji saskaņoti, kad atšķirat "pirmo strādājošo versiju" no "produkcijas vides".
| Avots | Ko viņi apgalvo | Viņu ieinteresētība |
|---|---|---|
| Apideck (2026) | QuickBooks: "prasmīgs inženieris var izveidot strādājošu risinājumu trīs līdz četrās nedēļās". 35+ savienotāju uzturēšanai ir nepieciešams "vismaz viens inženieris, kura vienīgais pienākums ir integrāciju uzturēšana". | Pārdod vienotu API |
| Rutter (2026. gada aprīlis) | "Trīs inženiera mēneši uz vienu platformu", ko Rutter dēvē par piesardzīgu aplēsi. NetSuite gadījumā "laika grafiks izstiepjas līdz sešiem vai divpadsmit mēnešiem". Viens klients aprēķināja, ka QuickBooks izstrādei nepieciešami divi inženieri uz pāris mēnešiem, taču tas aizņēma "vismaz trīs mēnešus ar vairākām iterācijām". | Pārdod vienotu API |
| Merge | 150 stundas vienas integrācijas izveidei un 300 stundas gadā tās uzturēšanai, rēķinoties ar 150 000 USD algu. Merge novērtē izmaksas no "50 000 līdz 150 000 ASV dolāru gadā". | Pārdod vienotu API |
Šajos skaitļos divas lietas ir svarīgākas par kopējiem rādītājiem.
Pirmkārt, atšķirība starp trim nedēļām un trim mēnešiem ir atšķirība starp demonstrācijas versiju (demo) un produkcijas vidi. Savienojums, kas izveido rēķinu, sāk darboties ātri. Savienojums, kas spēj pārdzīvot marķiera derīguma termiņa beigas, dubultotus tīmekļa āķus (webhooks), pieprasījumu limitus, daļējas kļūmes un situāciju, kad klienti atkārtoti pievieno citu uzņēmuma datu failu, prasa atlikušo laiku. Mūsu ceļvedī par mākoņgrāmatvedības API integrēšanu SaaS platformā šis darbs ir aprakstīts solis pa solim.
Otrkārt, Merge modelī uzturēšana prasa vairāk laika nekā izveide: 300 stundas gadā pret 150 stundām vienreizēji. Šīs izmaksas atkārtojas katru gadu par katru pakalpojumu sniedzēju, kuru jūs atbalstāt.
Kāpēc otrā integrācija maksā tikpat, cik pirmā
Ja pakalpojumu sniedzēji nodrošinātu vienādu saskarni (interface), otrā integrācija izmantotu lielāko daļu no pirmās paveiktā. Taču tā nav. Tabulā ir salīdzinātas četras plaši izmantotas sistēmas.
| QuickBooks Online | Xero | NetSuite | Business Central | |
|---|---|---|---|---|
| Pieteikšanās | OAuth 2.0 | OAuth 2.0 | OAuth 2.0; uz marķieriem balstīta autentifikācija jaunām integrācijām slēgta no 2027.1 laidiena | Tikai Microsoft Entra ID OAuth |
| Piekļuves marķiera derīguma termiņš | 1 stunda | 30 minūtes | 60 minūtes | Nosaka Entra ID |
| Atsvaidzināšanas marķieris (refresh token) | 100 dienas ar atjaunošanos, ne ilgāk par pieciem gadiem | 60 dienas ar atjaunošanos | 7 dienas | Nosaka Entra ID |
| Vaicājumu stils | SQL līdzīgs SELECT … FROM Invoice, bez OR, bez savienojumiem (joins) |
REST ar where parametru |
SuiteQL (SQL) caur REST, plus SOAP līdz 2028. gadam | OData v4 |
| Pieprasījumu limits | 500 pieprasījumi minūtē un 10 sekundē uz vienu uzņēmumu | 60 minūtē, 5000 dienā un 5 vienlaicīgi uz vienu uzņēmumu | 5 līdz 20 vienlaicīgi pieprasījumi uz kontu, atkarībā no pakalpojuma līmeņa | 6000 pieprasījumi uz 5 minūtēm un 5 vienlaicīgi uz lietotāju |
| Atsevišķa API maksa | Partneru programma (App Partner Program): bezmaksas līmenis, pēc tam no 300 līdz 4500 ASV dolāriem mēnesī | Lietotņu plāni no bezmaksas līdz 1445 AUD mēnesī | Nav atrasta; papildu vienlaicīgums tiek tirgots kā SuiteCloud Plus licences | Nav atrasta |
Avoti: Intuit autorizācijas FAQ, Intuit limiti un ierobežojumi, Intuit lietotņu partneru programmas ceļvedis, Xero OAuth 2.0 ceļvedis, Xero API limiti, Xero cenu noteikšana, NetSuite OAuth 2.0 marķieri, NetSuite uz marķieriem balstīta autentifikācija, Business Central darbības limiti.
Marķieru derīguma termiņi beidzas pēc četriem dažādiem grafikiem
Integrācijai ir jāatsvaidzina katra pakalpojumu sniedzēja marķieri pirms to termiņa beigām un katru reizi jāsaglabā jaunais atsvaidzināšanas marķieris, pretējā gadījumā klientam savienojums būs jāizveido no jauna. Grafiki atšķiras četrpadsmitkārtīgi: NetSuite atsvaidzināšanas marķieris ir derīgs septiņas dienas, bet QuickBooks - 100 dienas. QuickBooks nosaka stingru ierobežojumu: atsvaidzināšanas marķieri ir derīgi ne ilgāk kā piecus gadus, tāpēc ilgstoši strādājoši savienojumi sāks beigties noteiktā datumā neatkarīgi no to izmantošanas. Katram grafikam ir nepieciešams savs atsvaidzināšanas uzdevums (job), sava kļūmju apstrāde un savs paziņojums klientam ar aicinājumu "lūdzu, atkārtoti izveidojiet savienojumu".
Katram pakalpojumu sniedzējam ir sava vaicājumu valoda
Datu nolasīšana ir posms, kurā kods atšķiras visvairāk. QuickBooks pieņem ierobežotu SQL dialektu bez OR un bez savienojumiem (joins), vienā lapā atgriežot ne vairāk kā 1000 ierakstus. Xero filtrē datus, izmantojot where izteiksmi URL, un lielām organizācijām iesaka izmantot vienkāršas vienlīdzības pārbaudes. NetSuite izmanto SuiteQL, pilnvērtīgu SQL dialektu, kas tiek nosūtīts uz tā pašu galapunktu (endpoint). Business Central izmanto OData filtrus. Vaicājums, kas atrod neapmaksātos rēķinus vienam klientam, sastāv no četriem dažādiem koda gabaliem, katram ar savu lappušu pāršķirošanu (paging) un specifiskām situācijām (edge cases).
Katrs pakalpojumu sniedzējs ierobežo datu plūsmu atšķirīgi
QuickBooks un Xero uzskaita pieprasījumus uz vienu uzņēmumu minūtē. NetSuite uzskaita vienlaicīgos pieprasījumus visā kontā, tāpēc jūsu integrācija dalās ar kopējo limitu ar katru citu integrāciju, ko klients izmanto, un NetSuite noraida izsaukumus, kas pārsniedz šo limitu. Business Central uzskaita pieprasījumus uz lietotāju piecu minūšu logā. Apjomīgs datu imports, kas ir drošs pret vienu pakalpojumu sniedzēju, var tikt ierobežots (throttled) pie cita, tāpēc plūsmas kontroles un atkārtotu mēģinājumu loģika jāraksta katram pakalpojumam atsevišķi.
Piekļuve ir komerciālas attiecības
Divi no četriem pakalpojumu sniedzējiem tagad iekasē maksu par API piekļuvi atbilstoši apjomam. Intuit partneru programma mēra "CorePlus" izsaukumus, kas ietver lielāko daļu datu nolasīšanu, un bloķē tos, ja bezmaksas līmenī tiek pārsniegts iekļautais apjoms; maksas līmeņi maksā 300, 1700 un 4500 ASV dolāru mēnesī. Xero 2026. gada 2. martā pārgāja uz maksas lietotņu plāniem, sākot no bezmaksas plāna ar limitu līdz 5 savienojumiem un beidzot ar 1445 AUD mēnesī par 10 000 savienojumiem. Līdz ar to integrācijas uzturēšanas izmaksas ir atkarīgas no tā, cik daudzi no jūsu klientiem izmanto attiecīgo pakalpojumu sniedzēju un cik daudz datu jūs nolasāt.
Pakalpojumu sniedzēji maina noteikumus pēc sava grafika
Integrācijai, kas darbojas šodien, jau ir paziņots zināms saraksts ar obligātām koda izmaiņām:
- NetSuite pārstāj pieņemt jaunas integrācijas, kas izmanto uz marķieriem balstītu autentifikāciju, sākot no 2027.1 laidiena, un Oracle SOAP paziņojumā norādīts, ka "sākot ar NetSuite 2028.2 laidienu, visi galapunkti tiks deaktivizēti un uz SOAP balstītās integrācijas pārtrauks darboties" (NetSuite SOAP paziņojums).
- Xero piešķir detalizētas tiesību kopas (permission scopes) lietotnēm, kas izveidotas, sākot ar 2026. gada martu, un dod esošajām lietotnēm laiku līdz 2027. gada septembrim pāriet uz šo sistēmu (Xero OAuth 2.0 pārskats).
- QuickBooks piemēro iepriekš minēto piecu gadu atsvaidzināšanas marķiera ierobežojumu un pārtrauc vecāku API mazāko versiju (minor versions) atbalstu, nosakot 75. versiju par bāzi.
- Business Central tiešsaistes versija 2022. gadā pārtrauca pieņemt piekļuves atslēgas (pamata autentifikāciju) tīmekļa pakalpojumiem; integrācijām bija jāpāriet uz Entra ID OAuth (Microsoft novecojušo funkciju saraksts).
Neviena no šīm izmaiņām nepievieno jaunu funkciju jūsu klientiem. Katra no tām ir inženierijas darbam veltīts laiks, lai saglabātu esošā savienojuma darbību, reizināts ar to pakalpojumu sniedzēju skaitu, kurus jūs atbalstāt.
Aprēķins sešām integrācijām
Ņemiet Rutter rādītāju par trim inženiera mēnešiem uz vienu platformu un Merge rādītāju par 300 uzturēšanas stundām gadā un pielietojiet tos sešām grāmatvedības sistēmām:
| Viens pakalpojumu sniedzējs | Seši pakalpojumu sniedzēji | |
|---|---|---|
| Izveide | 3 inženiera mēneši | 18 inženiera mēneši |
| Uzturēšana gadā | 300 stundas | 1800 stundas, kas ir tuvu viena pilna laika inženiera darbam |
Šie ir pašu pakalpojumu sniedzēju pieņēmumi, nevis mūsu, un tikai NetSuite vien tos pārsniegtu. Būtība slēpjas proporcijās: izmaksas pieaug līdz ar pakalpojumu sniedzēju skaitu, un uzturēšanas apjoms nekad nebeidzas. Vienotais API samazina izstrādes apjomu, taču tad jūs esat atkarīgs no tā, cik labi tas aptver katra pakalpojumu sniedzēja datu ierakstīšanu un nestandarta situācijas, un jūs maksājat par to par katru savienojumu vai izsaukumu. Mūsu raksts par izstrādi pašu spēkiem vai gatava risinājuma iegādi palīdz godīgi aprēķināt šīs izmaksas.
Integrējieties vienu reizi: kārtojiet grāmatvedību savā produktā
Savienotāju modelis balstās uz pieņēmumu, ka katra klienta grāmatvedības dati atrodas sistēmā, ko klients pats ir izvēlējies, un jūsu platforma tajā kopē datus. Pastāv otrs modelis: jūsu platforma pati kārto grāmatvedību, izmantojot vienu grāmatvedības API, un attēlo to jūsu saskarnē. Tieši tam ir izveidots Nordlet. Jums ir jāizveido tikai viena integrācija neatkarīgi no tā, kādu grāmatvedības programmatūru jūsu klienti ir izmantojuši iepriekš.
Kā šī viena integrācija izskatās Nordlet:
- Viens pieprasījuma formāts. Katra operācija ir
POST /v1/{module}/{resource}/{action}. Katralistdarbība pieņem vienu un to pašu filtra, kārtošanas un lappušu pāršķirošanas pamatni (body), un katra kļūda izmanto vienotu struktūru. Kods, kas uzrakstīts vienam galapunktam, darbojas tāpat arī pārējiem. Skatiet API konvencijas. - API atslēgas atsvaidzināšanas marķieru vietā. Atslēga pieder vienam uzņēmumam, tai ir fiksētas tiesību kopas, tai var iestatīt derīguma termiņu, un to var anulēt. Nav nepieciešams rotēt un saglabāt atsvaidzināšanas marķierus.
- Droši atkārtoti mēģinājumi. Katra izmaiņa pieņem
Idempotency-Keygalveni. Atkārtojot pieprasījumu ar to pašu atslēgu, tiek atgriezta saglabātā atbilde, nevis izveidots otrais rēķins. - Parakstīti tīmekļa āķi (webhooks) ar atkārtotiem mēģinājumiem. Notikumi tiek ierakstīti tajā pašā datubāzes transakcijā, kurā notiek izmaiņas, parakstīti ar HMAC-SHA256, un kļūmes gadījumā tiek atkārtoti mēģināti aptuveni 24 stundas.
- Viens publisks pieprasījumu limits. 300 pieprasījumi minūtē uz vienu API atslēgu, kas tiek ziņoti
x-ratelimit-*galvenēs. - Tipizēti SDK deviņās valodās, kas ģenerēti no vienas OpenAPI specifikācijas. Skatiet SDK.
- Neierobežots smilšu kastes (sandbox) uzņēmumu skaits vienā kontā integrācijas testēšanai.
- Viens cenu saraksts. Plāni tiek mērīti pēc pieprasījumu skaita, sākot no 10 € mēnesī par 3000 pieprasījumiem. Skatiet cenu lapu.
Dubultieraksta grāmatvedības virsgrāmata, rēķini, bankas datu saskaņošana, PVN deklarācijas un atskaites ir pieejamas caur to pašu API, tāpēc integrācija aptver pašu grāmatvedību, nevis tās kopiju. Funkciju lapa uzskaita iekļautās iespējas, un sadaļa kas ir grāmatvedības API detalizētāk izskaidro šo modeli.
Klienti, kuru grāmatvedības dati jau atrodas citur
Divas iespējas aizstāj savienotājus katram pakalpojumu sniedzējam, ko platforma citādi veidotu šiem klientiem:
- Datu pārcelšana. Uzņēmuma kontu plāns, sadarbības partneri, sākuma atlikumi vai pilna žurnāla vēsture, atvērtie rēķini, pamatlīdzekļi un krājumi tiek importēti vienā izsaukumā. Skatiet migrāciju no citas sistēmas.
- Faili grāmatvedim. Situācijās, kad klienta grāmatvedis strādā savā programmatūrā, Nordlet eksportē virsgrāmatu formātos, ko šī programmatūra nolasa: DATEV grāmatojumu pakešu failu (
POST /v1/reports/datev) Vācijas grāmatvediem un SIE 4 failu (POST /v1/reports/sie) Zviedrijas grāmatvediem. Failu eksportam nav nepieciešama pieteikšanās, marķiera atjaunošana vai maksa par katru izsaukumu no grāmatvedības sistēmas izstrādātāja.
Kad savienotāji joprojām ir pareizā izvēle
Grāmatvedības kārtošana jūsu produktā nav piemērotākā izvēle katrai platformai:
- Ja jūsu klientu finanšu komandas pieprasa, lai viņu esošā grāmatvedības sistēma paliek pamatdodu sistēma (system of record), jums ir nepieciešami savienotāji ar šo sistēmu, kas izveidoti tieši vai caur vienotu API.
- Ja jums ir nepieciešams tikai nosūtīt dažus dokumentus klienta grāmatvedībā, piemēram, vienu rēķinu par pasūtījumu, var pietikt ar vienu tiešu savienotāju ar pakalpojumu sniedzēju, ko izmanto vairums jūsu klientu.
- Ja lielākā daļa jūsu klientu izmanto vienu pakalpojumu sniedzēju, viena tieša integrācija prasa vienu projektu, nevis sešus.
Arguments par integrēšanos vienu reizi attiecas uz gadījumiem, kad jūsu platformai ir jāpārvalda savu lietotāju grāmatvedība, nevis tā jāatspoguļo: tirgum (marketplaces), kas veic izmaksas pārdevējiem, platformām, kas izraksta rēķinus savu lietotāju vārdā, un SaaS produktiem, kuros grāmatvedība ir daļa no paša produkta. Pirms jebkura ceļa izvēles mūsu pirmsražošanas testa plāns grāmatvedības API norāda, kas ir jāpārbauda.
FAQ
Cik ilga ir QuickBooks integrācijas izstrāde?
Apideck lēš, ka pirmajai strādājošajai versijai, ko veic viens prasmīgs inženieris, nepieciešamas trīs līdz četras nedēļas. Kāds Rutter klients lēsa, ka nepieciešami divi inženieri uz pāris mēnešiem, bet reāli bija vajadzīgi vismaz trīs mēneši ar vairākām iterācijām. Darbs produkcijas vidē - marķieru atsvaidzināšana, atkārtoti mēģinājumi, pieprasījumu limiti, atkārtota savienojuma izveide un saskaņošana - ir tas, kas rada atšķirību starp šiem skaitļiem.
Cik ilga ir NetSuite integrācijas izstrāde?
Rutter norāda, ka NetSuite izstrāde aizņem no sešiem līdz divpadsmit mēnešiem. NetSuite papildus ietver konta līmeņa vienlaicīgo pieprasījumu limitus, septiņu dienu atsvaidzināšanas marķierus, SuiteQL kopā ar SOAP, kā arī izziņotās izmaiņas: jaunas uz marķieriem balstītās autentifikācijas integrācijas netiks pieņemtas sākot no 2027.1 laidiena, un SOAP galapunkti tiks deaktivizēti 2028.2 laidienā.
Vai vienots grāmatvedības API novērš darbu ar katru pakalpojumu sniedzēju atsevišķi?
Tas samazina izstrādes apjomu, jo viena saskarne aptver vairākus pakalpojumu sniedzējus. Tas nenovērš pakalpojumu sniedzēju atšķirības: datu ierakstīšana, pielāgotie lauki un nestandarta situācijas bieži tiek atbalstītas nevienmērīgi, un vienotā API cena tiek pieskaitīta pašu pakalpojumu sniedzēju API maksām. Šie kompromisi ir aplūkoti mūsu SaaS integrācijas ceļvedī.
Cik maksā API piekļuve QuickBooks un Xero?
Intuit partneru programmā ir bezmaksas izstrādātāja līmenis (Builder) un maksas līmeņi par 300, 1700 un 4500 ASV dolāriem mēnesī, un datu nolasīšana tiek mērīta, ja tiek pārsniegts iekļautais apjoms. Xero lietotņu plāni, kas stājās spēkā 2026. gada 2. martā, svārstās no bezmaksas plāna 5 savienojumiem līdz 1445 AUD mēnesī par 10 000 savienojumiem, savukārt lielākiem plāniem cena tiek noteikta pēc pieprasījuma.
Vai Nordlet var aizstāt integrācijas ar manu klientu grāmatvedības sistēmām?
Ja jūsu platforma kārto savu lietotāju grāmatvedību, jā: jūs izveidojat vienu integrāciju ar Nordlet API, nevis pa vienai katram grāmatvedības pakalpojumu sniedzējam. Esošie grāmatvedības dati tiek importēti vienā izsaukumā, un grāmatveži, kuri izmanto DATEV vai SIE saderīgu programmatūru, saņem eksporta failus. Nordlet neveic datu sinhronizāciju ar QuickBooks, Xero, NetSuite vai Business Central; ja šīm sistēmām ir jāpaliek par pamatdatu sistēmu, jums joprojām ir nepieciešami savienotāji ar tām.