Labākās grāmatvedības automatizācijas API ES tirgiem (2026)

Ātrākais veids, kā noskaidrot, vai grāmatvedības API ir būvēta tirdzniecības vietām (marketplaces), ir uzdot jautājumu, kas notiek, kad lietuviešu pircējs samaksā vācu pārdevējam par preci, kura nosūtīta no Polijas noliktavas, un platforma ietur 12% komisiju, kā arī maksājumu apstrādes maksu. Ja atbilde ietver CSV eksportu vai nakts pakešu apstrādes darbu (batch job), nākamos divus gadus jūs pavadīsim, labojot izņēmuma gadījumus (edge cases).

Mēs esam novērojuši komandas, kuras mēģina uzstādīt lietotāja saskarnes (UI) pirmo grāmatvedības rīku divpusējā tirgū un pēc tam klusībā pārbūvē visu sistēmu astoņpadsmit mēnešus vēlāk. Problēma gandrīz nekad nav rēķinu izrakstīšanā. Problēma ir virsgrāmatā (ledger), PVN piemērošanā katrai valstij un platformas izmaksu grafika saskaņošanā ar grāmatvedības sistēmas priekšstatu par to, kad ieņēmumi ir nopelnīti.

Šis ir ceļvedis par tām grāmatvedības API, kas šobrīd ES ir reāli piemērotas šim uzdevumam, to kompromisiem un to, kā izvēlēties rīku, neiekļūstot slazdā, ko vēlāk nožēlosiet.

Ko "grāmatvedības automatizācijas API" patiesībā nozīmē tirdzniecības vietai

Tirdzniecības vietai grāmatvedības API nav atskaišu rīks. Tā ir patiesības avots par naudu. Tas maina prasības:

• Reāla divierakstu virsgrāmata (double-entry ledger), kuru nevar nemanāmi labot pēc fakta. Tā nav rēķinu tabula ar kopsummu skatu.
• PVN loģika katrai valstij atsevišķi, kas izprot OSS, reverso PVN (reverse charge), B2B pret B2C un piegādes vietas nosacījumus. Tas nav vienkārši nodokļu likmes lauks.
• Izmaksu saskaņošana (reconciliation), kas spēj sasaistīt vienu kopējo bankas pārskaitījumu ar simtiem pamatā esošo pasūtījumu, atmaksu un komisiju.
• Idempotence katrā rakstīšanas galapunktā (write endpoint). Tā kā jūs veiksiet atkārtotus mēģinājumus (retries), jūs nevarat atļauties dubultus grāmatojumu ierakstus.
• Tīmekļaāķi (webhooks) stāvokļa izmaiņām, lai jūsu produktam nav jāveic aptauja (polling), vai rēķins ir apmaksāts.
• Vairāku juridisko vienību (multi-entity) atbalsts, jo vairākumā gadījumu tirdzniecības vietas trīs gadu laikā nonāk līdz Luksemburgas māteskompānijai, pamatdarbības vienīgumam un vienai vai divām meitasuzņēmumu valstīm.

Ja API šīs lietas neveic dabiski, jūs galu galā tās uzrakstīsiet pats, kas zaudē visu ieceres jēgu.

Iespējas, ko ir vērts uztvert nopietki 2026. gadā

Šobrīd ir vairāk API pieejamu grāmatvedības rīku nekā pirms trim gadiem, taču to skaits, kas reāli der tirdzniecības vietai, joprojām ir neliels. Lielākā daļa tika izstrādāta maziem un vidējiem uzņēmumiem (SMB) paredzētai grāmatvedībai, vēlāk piekabinot klāt API. Tikai retais tika būvēts ar API pirmajā vietā (API-first).

Lūk, kā mēs raugāmies uz īso sarakstu.

Nordlet

Nordlet ir risinājums, ko mēs vispirms iesakām izskatīt komandām, kuras būvē tirdzniecības vietu vai platformu ES. Tas jau no paša sākuma tika projektēts kā API, nevis kā lietotāja saskarnes produkts ar vēlāk pievienotiem galapunktiem, un funkciju paritāte starp lietotni un API ir tuvu pilnīgai. Kodols ir nemainīga divierakstu virsgrāmata ar iebūvētu PVN atbilstību katrai valstij, tostarp VIES validāciju pārrobežu B2B darījumiem un i.SAF reģistru ģenerēšanu Latvijas atskaitēm.

Praktiski svarīgās lietas tirdzniecības vietai:

• Tipizēti SDK (tostarp TypeScript SDK) un paredzami REST galapunkti, tāpēc jauna backend inženiera iesaistīšana aizņem stundas, nevis nedēļas.
• Idempotences atslēgu atbalsts rakstīšanas darbībām, kas nodrošina atšķirību starp uzticamu integrāciju un atbalsta biļeti ikreiz, kad tīklā rodas īslaicīga aizture.
• Tīmekļaāķi (webhooks) tādiem notikumiem kā sale_invoice.paid, lai jūsu produkts var reāllaikā reaģēt uz maksājuma stāvokļa izmaiņām.
• SEPA pain.001 eksports piegādātāju un pārdevēju izmaksām, kā arī vienas klikšķa bankas saskaņošana ar viedo atbilstību (smart matching).
• Vairāki uzņēmumi zem viena konta ar lomu balstītu piekļuvi (īpašnieks, administrators, grāmatvedis, vadītājs, izstrādātājs, skatītājs), kas ir būtiski, ja pārvaldāt grupas struktūru.
• Perioda slēgšana (period locking), lai slēgtus mēnešus nevarētu nemanāmi pārrakstīt, un tieši par to jūsu auditors jautās vispirms.

Kompromiss: Nordlet pašlaik atrodas dizaina partnera un agrīnās piekļuves fāzē. Ja jums ir nepieciešams nobriedis tirdzniecības vietu ceļvedis ar simtiem publicētu gadījumu izpētes (case studies), jūs to vēl nesaņemsiet. Ja vēlaties strādāt tieši ar komandu, kas būvē tieši jums nepieciešamos pamatelementus, šī ir īstā vieta.

Xero API

Xero lepojas ar lielāko ekosistēmu starp visām modernajām grāmatvedības API un ir saprātīga izvēle vienkāršam mazajam uzņēmumam vai vieglai platformas integrācijai. Tomēr tirdzniecības vietai tās struktūra ātri vien kļūst neērta. Tas pamatā ir lietotāja saskarnes produkts, un vairāku vienību darbplūsmas prasa žonglēšanu ar atsevišķām organizācijām, nevis natīvu grupu struktūru. PVN apstrāde ir stabila Apvienotajai Karalistei un izmantojama ES, bet katras valsts nianses, piemēram, i.SAF vai Peppol BIS 3.0 e-rēķini, parasti atrodas ārpus kodola un ir atkarīgas no trešo pušu lietotnēm.

QuickBooks Online API

QuickBooks ir spēcīgas pozīcijas ASV un uzlabo savu pārklājumu ES, taču ES orientētai tirdzniecības vietai tas ir nepareizs smaguma centrs. Nodokļu loģika vispirms ir pielāgota ASV tirdzniecības nodoklim, un, lai gan API ir spējīga, ES PVN specifiskajiem gadījumiem (OSS sliekšņiem, reversajam PVN 27 valstīs) parasti ir nepieciešams pielāgots starpprogrammatūras slānis (middleware).

Sage / Sage Intacct

Sage joprojām parādās ES iepirkumu sarunās, jo īpaši gadījumos, kad finanšu komandas ar to jau ir pazīstamas. API pastāv, taču tās rāda savu vecumu. Reāllaika tīmekļaāķi ir ierobežoti, izstrādātāju dokumentācija produktiem atšķiras, un pieņēmums, ka grāmatvedis piedalīsies mēneša slēgšanas operācijās, neatbilst tam, kā strādā mūsdienu platformu komandas.

Odoo

Odoo ir pieņemama opcija, ja vēlaties atvērtā koda ERP, kas ietver grāmatvedību, un esat gatavs uzturēt infrastruktūru. API ir visaptveroša, taču vairāk virspusēja nekā padziļināta, tāpēc bieži vien jūs integrējaties ar ERP, nevis ar specializētu grāmatvedības dzinēju. Tirdzniecības vietām ar augstu operatīvo sarežģītību ārpus finansēm (krājumi, ražošana) tas var derēt. Tīrai tirdzniecības vietai tas parasti ir pārāk plašs rīks ar lieku funkcionalitāti.

Mantotie valstij specifiskie rīki

Vairumā ES valstu ir vismaz viens tradicionāls grāmatvedības produkts ar daļēju API. Tie bieži ir lēti, tos izmanto vietējie grāmatveži un tie gandrīz nekad nav būvēti programmatiskai integrācijai tirdzniecības vietu mērogā. Ja esat mazs vietējais operators – tas ir pieņemami. Ja pēc diviem gadiem plānojat darboties pārrobežu tirgū, nesāciet šeit.

Iespēju salīdzinājums

Tabulā zemāk atspoguļots tikai tas, ko tieši atbalsta publiskā produktu dokumentācija. Ja mums nav tieša apstiprinājuma konkurenta iespējām, mēs to norādām, tā vietā, lai minētu.

Iespēja	Nordlet	Xero API	QuickBooks API	Sage	Odoo
API-first arhitektūra (funkciju paritāte lietotnei/API)	Jā	Nē (UI-first)	Nē (UI-first)	Daļēji	Daļēji
Nemainīga divierakstu virsgrāmata	Jā	Nav publiski apstiprināts	Nav publiski apstiprināts	Nav publiski apstiprināts	Nav publiski apstiprināts
ES PVN katrai valstij ar VIES validāciju	Jā	Daļēji	Ierobežoti	Nav zināms	Daļēji
i.SAF reģistru ģenerēšana (Latvija)	Jā	Nav zināms	Nav zināms	Nav zināms	Nav zināms
Tipizēti SDK (t.sk. TypeScript)	Jā	Prsvarā trešo pušu	Prsvarā trešo pušu	Nav zināms	Nav zināms
Idempotences atslēgu atbalsts	Jā	Nav publiski apstiprināts	Nav publiski apstiprināts	Nav zināms	Nav zināms
Reāllaika tīmekļaāķi finanšu notikumiem	Jā	Ierobežoti	Ierobežoti	Ierobežoti	Jā
SEPA pain.001 eksports	Jā	Caur lietotnēm	Nav publiski apstiprināts	Nav zināms	Jā
Vairāki uzņēmumi zem viena konta, RBAC	Jā	Vairākas org. (atsevišķi)	Vairākas org. (atsevišķi)	Jā	Jā
Perioda slēgšana	Jā	Jā	Jā	Jā	Jā
Autentifikācija bez paroles (Passwordless)	Jā	Nav standarts	Nav standarts	Nav standarts	Nav standarts

Rindas, kurām mēs piešķirtu lielāku svaru tirdzniecības vietas lēmumā, ir nemainīga virsgrāmata, PVN dziļums konkrētajās valstīs, kurās jūs faktiski darbojaties, un idempotence. Visu pārējo var atrisināt ar aplinkus ceļiem. Ja šo trīs lietu nav, tās kļūst par pastāvīgu šķērsli.

Saskaņošanas problēma, par kāju neviens jūs nebrīdina

Katrs tirdzniecības vietas dibinātājs, ar kuru esam runājuši, nenovērtē izmaksu saskaņošanas sarežģītību. Lūk, kāds ir šis scenārijs.

Jūs nedēļas laikā apstrādājat 4000 pasūtījumu. Jūsu maksājumu pakalpojumu sniedzējs (PSP) otrdien ieskaita bankas kontā kopsummu, atskaitot savas komisijas, atskaitot iepriekšējā perioda atmaksas un atskaitot maksājumu atgriešanas (chargebacks). Jūsu grāmatvedības sistēmai ir jāzina: kurus pasūtījumus šis pārskaitījums pārstāv, kura daļa ir jūsu ieņēmumi pret pārdevēja saistībām, kāds PVN tikaiekasēts par jūsu komisiju un kas notiek, ja viens no šiem pasūtījumiem tiek atmaksāts trīs nedēļas vēlāk.

Ja jūsu grāmatvedības API nespēj uzņemt PSP norēķinu failu un saskaņot to ar rēķiniem, izmantojot ko labāku par precīzas summas sakritību, jūs būsiet spiesti pieņemt darbā cilvēku, kura vienīgais uzdevums ir izklājlapu saskaņošana. Mēs esam redzējuši, ka tas notiek uzņēmumos ar astoņu ciparu preču apjomu (GMV).

Nordlet viedā atbilstība un rēķinu saskaņošana ar vienu klikšķi ir izveidota tieši šim nolūkam. Xero to var paveikt ar papildinājumiem. QuickBooks integrācijām parasti ir nepieciešams starpprogrammatūras slānis, tikko apjoms pārsniedz dažus tūkstošus darījumu mēnesī.

PVN: iemesls, kāpēc vairums tirgu nenovērtē apjomu

ES PVN tirdzniecības vietām ir patiesi sarežģīts, un tas nav tāpēc, ka noteikumi būtu neskaidri. Tas ir tāpēc, ka noteikumu ir daudz un tie mijiedarbojas.

Kopš 2021. gada e-komercijas reformām un tirgu uzskatītā piegādātāja (deemed supplier) noteikumiem, platforma noteiktos darījumos var tikt uzskatīta par piegādātāju PVN vajadzībām pat tad, ja tā neiegūst preču īpašumtiesības. Tas nozīmē, ka pašai tirdzniecības vietai ir PVN saistības attiecībā uz pamatā esošo pārdošanu, nevis tikai uz tās komisiju. OSS deklarācijas, IOSS precēm līdz 150 EUR no valstīm ārpus ES, reģistrācijas sliekšņi katrā valstī, reversais PVN B2B pakalpojumiem, VIES validācija pārrobežu B2B – visam ir jābūt pareizam, un tam visam ir jāatspoguļojas virsgrāmatā no brīža, kad darījums tiek reģistrēts, nevis jāpārrēķina ceturkšņa beigās.

Grāmatvedības API, kas izsniedz vat_rate lauku un uzskata darbu par pabeigtu, izgāzīsies jūsu pirmajā auditā. Jums ir nepieciešama valsts līmeņa loģika, VIES validācija klienta PVN reģistrācijas numuram darījuma brīdī un automātiska vietējo atskaišu formātu ģenerēšana (i.SAF Latvijā, SAF-T varianti citviet).

Šī ir joma, kur pēdējā laikā ES izstrādātie API-first rīki ir ievērojami priekšā vecākiem starptautiskiem produktiem. Noteikumi ir pietiekami tuvu mājām, tāpēc programmatūras izstrādātāju komandas dzīvo tajos iekšā.

Ko mēs darītu vispirms

Ja mēs rīt uzsāktu ES tirdzniecības vietu un izvēlētos grāmatvedības infrastruktūru, secība būtu šāda:

1. Vispirms kartējiet savu PVN risku, nevis pēdējā brīdī. Uzskaitiet katru valsti, kurā tirgosiet pirmajā gadā, nosakiet, vai darījumi ir B2B vai B2C, un vai ir spēkā uzskatītā piegādātāja noteikumi. Tas parāda, kas grāmatvedības sistēmai reāli ir jāpārvalda.
2. Izveidojiet virsgrāmatas un saskaņošanas plūsmas prototipu smilškastē (sandbox). Nevis rēķinu izrakstīšanu. Rēķinu var ģenerēt jebkurš. Izlaidiet cauri smilškastei reālistisku nedēļas darījumu apjomu un skatieties, kas notiek mēneša beigās.
3. Pārbaudiet API līgumu attiecībā uz idempotenci un tīmekļaāķiem. Ja nevarat droši atkārtot pieprasījumu vai abonēt stāvokļa izmaiņas, jūs būvējat trauslu infrastruktūru.
4. Aprunājieties ar to, kurš reāli slēgs jūsu grāmatvedību. Ja jūsu grāmatvedis nevar saņemt nepieciešamās atskaites vajadzīgajā formātā, augšupstāva automatizācijai nav nozīmes.
5. Izvēlieties piegādātāju, kura ceļvedi jūs varat ietekmēt. Agrīna posma tirdzniecības vietai tas ir svarīgāk nekā atzīmēt katru funkciju lodziņu šodien. Dizaina partneru vienošanās pastāv iemesla dēļ.

FAQ

Vai man tiešām ir nepieciešama divierakstu virsgrāmata, vai ar darījumu tabulu pietiek?

Darījumu tabula darbojas līdz brīdim, kad jums pirmo reizi ir jāizskaidro neatbilstība auditoram vai jāprecizē iepriekšējais perioda pārskats. Divierakstu sistēma nav vecmodīgs grāmatvedības teātris. Tas ir iemesls, kāpēc jūsu grāmatvedība sakrīt un kļūdas parādās uzreiz, nevis klusumā uzkrājas.

Vai es varu vienkārši izmantot Stripe atskaites grāmatvedības API vietā?

Stripe ir maksājumu apstrādātājs. Tā atskaites ir piemērotas Stripe saskaņošanai. Tas neveic divierakstu grāmatvedību, neapstrādā ieņēmumus no citiem avotiem un neģenerē atbilstošas obligātās likumiskās atskaites. Izmantojiet to kopā ar grāmatvedības API, nevis tās vietā.

Kā es varu rīkoties ar vairākām valstīm, reģistrējoties nevis visur, bet vienuviet?

B2C preču un pakalpojumu tirdzniecībai ES ietvaros vienas pieturas aģentūras (OSS) shēma ļauj iesniegt atskaites vienā valstī par pārdošanu visā blokā, nepārsniedzot noteiktus sliekšņus un ievērojot noteiktus izņēmumus. Jūsu grāmatvedības API ir pareizi jāklasificē katrs darījums, lai OSS deklarācija būtu precīza. Tas ir funkcionalitātes jautājums, nevis apiešanas risinājums.

Vai API-first grāmatvedība nav lieka greznība mazai tirdzniecības vietai?

Ja esat mazs un plānojat tāds palikt, tradicionāls rīks ar vieglu API ir pietiekams. Ja plānojat augt, grāmatvedības iegulšana savā produktā agrīnā stadijā ir daudz lētāka nekā vēlāka migrācija no UI-first rīka. Grāmatvedības infrastruktūras nomaiņas izmaksas ir vienas no augstākajām uzņēmuma tehnoloģiju stakā.

Kas notiek, ja piegādātājs maina savu API?

Pirms līguma parakstīšanas noskaidrojiet politiku attiecībā uz novecojušām versijām (deprecation policies), versiju veidošanu un to, kā tiek apstrādātas izmaiņas, kas pārtrauc saderību (breaking changes). Jebkuram nopietnam API-first produktam ir jābūt skaidrai atbildei. Ja tādas nav, tā arī ir atbilde.