Najboljši API-ji za avtomatizacijo računovodstva za tržnice v EU (2026)

Najhitrejši način, da ugotovite, ali je bil računovodski API zasnovan za tržnice (marketplaces), je vprašanje, kaj se zgodi, ko litovski kupec plača nemškemu prodajalcu za izdelek, poslan iz poljskega skladišča, platforma pa si vzame 12-odstotni provizijo ter provizijo za obdelavo plačila. Če odgovor vključuje izvoze CSV ali nočne paketne opravke, boste naslednji dve leti porabili za odpravljanje robnih primerov.

Opazovali smo ekipe, ki so poskušale računovodsko orodje, osredotočeno na uporabniški vmesnik, nasaditi na dvostransko tržnico in so nato osemnajst mesecev kasneje vse skupaj na tiho zgradile na novo. Težava skoraj nikoli ni v izdajanju računov. Težava so glavna knjiga, obravnava DDV-ja po državah in usklajevanje med urnikom izplačil platforme ter predstavo računovodskega sistema o tem, kdaj je bil prihodek ustvarjen.

To je vodnik po računovodskih API-jih, ki so trenutno v EU dejansko prilagojeni tej nalogi, kakšne so njihove kompromisne rešitve in kako izbrati ter se ne ujeti v sistem, ki ga boste kasneje obžalovali.

Kaj za tržnico zares pomeni „API za avtomatizacijo računovodstva“

Za tržnico računovodski API ni poročevalsko orodje. Je vir resnice za denar. To spremeni zahteve:

• Prava dvostavna glavna knjiga (double-entry ledger), ki je ni mogoče tiho urejati za nazaj. Ne le tabela računov s pregledom vsot.
• Logika DDV-ja po posameznih državah, ki razume OSS, obratno davčno obveznost (reverse charge), razmerja B2B in B2C ter pravila o kraju obdavčitve. Ne le polje za davčno stopnjo.
• Usklajevanje izplačil, ki lahko poveže pavšalno bančno nakazilo s stotinami ustreznih naročil, vračil in provizij.
• Idempotenca pri vsaki končni točki (endpoint) za zapisovanje. Ker boste zahteve ponavljali in si ne morete privoščiti dvojnih temeljnih knjižb.
• Spletni kljuke (webhooks) za spremembe stanja, tako da vaš izdelek ni treba nenehno preverjati (polling), ali je bil račun plačan.
• Podpora za več subjektov (multi-entity), saj večina tržnic v treh letih konča z luksemburško holding družbo, operativnim subjektom ter enim ali dvema hčerinskimi podjetji v posameznih državah.

Če API teh stvari ne podpira v osnovi, jih boste morali napasti sami, s čimer pa odpade ves smisel uporabe.

Možnosti, ki jih je vredno resno upoštevati v letu 2026

Računovodskih orodij z dostopom prek API-ja je več kot pred tremi leti, vendar je število tistih, ki so resnično primerna za tržnico, še vedno majhno. Večina jih je bila zgrajena za knjigovodstvo malih in srednjih podjetij (SMB), API pa je bil dodan naknadno. Nekaj jih je bilo zasnovanih z mislijo na API (API-first).

Takole gledamo na ožji izbor.

Nordlet

Nordlet je tista rešitev, ki jo ekipam priporočamo na prvem mestu, če gradijo tržnico ali platformo v EU. Zasnovan je bil kot API že od vsega začetka in ne kot izdelek z uporabniškim vmesnikom, ki bi mu pozneje dodali končne točke, pri čemer je funkcionalna skladnost med aplikacijo in API-jem skoraj popolna. Jedro predstavlja nespremenljiva dvostavna glavna knjiga z vgrajeno skladnostjo z DDV-jem po posameznih državah, vključno s preverjanjem VIES za čezmejne posle B2B in generiranjem registra i.SAF za litovske davčne obračune.

Kar je praktično pomembno za tržnico:

• Tipizirani kompleti SDK (vključno s kompletom SDK za TypeScript) in predvidljive končne točke REST, zato vključitev novega inženirja v ozadju traja ure in ne tedne.
• Podpora za ključe idempotence (idempotency-key) pri zapisovanju, kar loči zanesljivo integracijo od klicanja podpore ob vsakem motenju omrežja.
• Spletne kljuke (webhooks) za dogodke, kot je sale_invoice.paid, tako da se lahko vaš izdelek v realnem času odzove na spremembe stanja plačila.
• Izvoz v formatu SEPA pain.001 za izplačila dobaviteljem in prodajalcem ter enostavno usklajevanje bank z inteligentnim ujemanjem z enim klikom.
• Več podjetij pod enim računom z dostopom, ki temelji na vlogah (lastnik, skrbnik, računovodja, vodja, razvijalec, opazovalec), kar je ključno pri vodenju skupinske strukture.
• Zaklepanje obračunskih obdobij, kar preprečuje tiho spreminjanje zaprtih mesecev – to pa je točno tisto, o čemer vas bo revizor vprašal najprej.

Kompromis: Nordlet je trenutno v fazi partnerskega oblikovanja in zgodnjega dostopa. Če potrebujete zrel priročnik za tržnico s stotinami objavljenih študij primerov, tega še ne boste dobili. Če pa želite neposredno sodelovati z ekipo, ki gradi prvine, ki jih dejansko potrebujete, je to pravi naslov.

Xero API

Xero ima največji ekosistem med vsemi sodobnimi računovodskimi API-ji in je smiselna izbira za preprosto malo podjetje ali lažjo integracijo s platformo. Za tržnico pa postane oblika precej nerodna. V osnovi je to izdelek, osredotočen na uporabniški vmesnik, delovni procesi za več subjektov pa vključujejo preklapljanje med ločenimi organizacijami in ne lastne skupinske strukture. Obravnava DDV-ja je zanesljiva za Združeno kraljestvo in uporabna za EU, vendar pa nianse posameznih držav, kot sta i.SAF ali e-fakturiranje Peppol BIS 3.0, običajno ostajajo zunaj jedra in so odvisne od aplikacij tretjih oseb.

QuickBooks Online API

QuickBooks je močno prisoten v ZDA in izboljšuje svojo pokritost v EU, vendar je za tržnico s sedežem v EU to napačno težišče. Davčna logika je najprej prilagojena prometnemu davku v ZDA, in čeprav je API zmogljiv, robni primeri DDV-ja v EU (pragi OSS, obratna davčna obveznost v 27 državah) običajno zahtevajo posredniško programsko opremo (middleware) po meri.

Sage / Sage Intacct

Sage se še vedno pojavlja v pogovorih o nabavi v EU, zlasti tam, kjer so finance že navajene nanj. API-ji obstajajo, vendar kažejo svoja leta. Spletne kljuke v realnem času so omejene, dokumentacija za razvijalce je med izdelki neenakomerna, domneva pa, da bo računovodja vključen v operacije ob koncu meseca, pa se ne ujema z delom sodobnih ekip za platforme.

Odoo

Odoo je primerna možnost, če želite odprtokodni ERP, ki vključuje računovodstvo, in vam ustreza upravljanje infrastrukture. API je obsežen, vendar bolj širok kot globok, zato se pogosteje povezujete z ERP-jem kot pa s specializiranim računovodskim pogonom. Za tržnice z veliko operativno kompleksnostjo zunaj financ (zaloge, proizvodnja) je to lahko ustrezno. Za čisto tržnico pa je običajno preobsežen.

Legacy lokalna orodja

V večini držav EU obstaja vsaj en uveljavljen računovodski izdelek z delnim API-jem. Pogosto so poceni, uporabljajo jih lokalni računovodje in skoraj nikoli niso bili zgrajeni za programsko integracijo v obsegu tržnice. Če ste majhen lokalni ponvajalec, je v redu. Če pa nameravate čez dve leti poslovati čez mejo, ne začnite tukaj.

Primerjava zmožnosti

Spodnja tabela odraža le tisto, kar je neposredno podprto v javni dokumentaciji izdelkov. Kjer za zmožnost konkurenta nimamo neposredne potrditve, to raje povemo, namesto da bi ugibali.

Zmožnost	Nordlet	Xero API	QuickBooks API	Sage	Odoo
Arhitektura z API-jem na prvem mestu (funkcionalna skladnost aplikacije in API-ja)	Da	Ne (UI-first)	Ne (UI-first)	Delno	Delno
Nespremenljiva dvostavna glavna knjiga	Da	Ni javno potrjeno	Ni javno potrjeno	Ni javno potrjeno	Ni javno potrjeno
DDV v EU po državah s preverjanjem VIES	Da	Delno	Omejeno	Neznano	Delno
Generiranje registra i.SAF (Litva)	Da	Neznano	Neznano	Neznano	Neznano
Tipizirani kompleti SDK (vklj. TypeScript)	Da	Večinoma tretje osebe	Večinoma tretje osebe	Neznano	Neznano
Podpora za ključe idempotence	Da	Ni javno potrjeno	Ni javno potrjeno	Neznano	Neznano
Spletne kljuke za finančne dogodke v realnem času	Da	Omejeno	Omejeno	Omejeno	Da
Izvoz SEPA pain.001	Da	Preko aplikacij	Ni javno potrjeno	Neznano	Da
Več podjetij pod enim računom, RBAC	Da	Več organizacij (ločeno)	Več organizacij (ločeno)	Da	Da
Zaklepanje obdobja	Da	Da	Da	Da	Da
Prijava brez gesla (passwordless)	Da	Ni standardno	Ni standardno	Ni standardno	Ni standardno

Vrstice, ki bi jim pri odločitvi o tržnici dali največjo težo, so nespremenljivost glavne knjige, globina obravnave DDV-ja v specifičnih državah, kjer dejansko poslujete, in idempotenca. Vse ostalo se da rešiti z obvodom. Te tri pa, če manjšajo, predstavljajo trajno oviro.

Težava usklajevanja, na katero vas nihče ne opozori

Vsak ustanovitelj tržnice, s katerim smo govorili, podcenjuje usklajevanje izplačil. Vzorec je sledeč.

V enem tednu obdelate 4.000 naročil. Vaš ponudnik plačilnih storitev (PSP) vam v torek na bančni račun nakaže pavšalni znesek, zmanjšan za njihove provizije, vračila iz prejšnjega obdobja in zavrnitve plačil (chargebacks). Vaš računovodski sistem mora vedeti: katerim naročilom predstavlja ta prenos, kolikšen del je vaš prihodek v primerjavi z obveznostjo do prodajalca, kolikšen DDV je bil obračunan na vašo provizijo in kaj se zgodi, ko je eno od teh naročil tri tedne pozneje vrnjeno.

Če vaš računovodski API ne more vnesti datoteke poravnave PSP in je primerjati z računi s čim boljšim mehanizmom kot le ujemanjem točnih zneskov, boste morali zaposliti nekoga, čigar celotno delo bo usklajevanje preglednic. Videli smo, da se to dogaja v podjetjih z desetmilijonskim prometom (GMV).

Nordletovo inteligentno ujemanje in usklajevanje računov z enim klikom je zasnovano točno za to obliko. Xero to zmore z dodatki. Integracije s QuickBooks pa običajno potrebujejo posredniško programsko opremo, ko obseg preseže nekaj tisoč transakcij na mesec.

DDV: razlog, zakaj večina tržnic podcenjuje obseg

DDV za tržnice v EU je resnično zahteven in to ne zato, ker bi bila pravila nejasna. Pač pa zato, ker jih je veliko in med seboj delujejo.

Od e-trgovinskih reform iz leta 2021 in pravil o navideznem dobavitelju (deemed supplier) za tržnice se lahko platforma za namene DDV-ja obravnava kot dobavitelj pri določenih transakcijah, tudi če nima lastništva nad blom. To pomeni, da ima tržnica sama obveznosti glede DDV-ja pri osnovni prodaji, in ne le pri svoji proviziji. Obračuni OSS, IOSS za blago pod 150 EUR iz držav zunaj EU, pragi registracije po državah, obratna davčna obveznost za storitve B2B, preverjanje VIES za čezmejni B2B: vse to mora biti pravilno in vse to se mora odražati v glavni knjigi od trenutka, ko je transakcija zabeležena, ne pa da se rekonstruira ob koncu četrtletja.

Računovodski API, ki vam ponudi polje vat_rate in zaključi delo, bo padel na vaši prvi reviziji. Kar potrebujete, je logika po posameznih državah, preverjanje VIES kupčeve davčne številke v trenutku transakcije in samodejno ustvarjanje lokalnih davčnih formatov (i.SAF v Litvi, različice SAF-T drugod).

To je področje, kjer so orodja z arhitekturo API-first, ki so bila nedavno razvita v EU, bistveno pred starejšimi mednarodnimi izdelki. Predpisi so dovolj blizu domačemu okolju, da ekipe, ki gradijo programsko opremo, živijo z njimi.

Kaj bi storili najprej

Če bi jutri začeli z gradnjo tržnice v EU in izbirali računovodsko infrastrukturo, bi bil vrstni red naslednji:

1. Najprej, in ne na koncu, ocenite svojo izpostavljenost DDV-ju. Navedite vsako državo, v kateri boste prodajali v prvem letu, ali so transakcije B2B ali B2C in ali veljajo pravila o navideznem dobavitelju. To vam pove, kaj mora računovodski sistem dejansko obvladati.
2. V peskovniku (sandbox) izdelajte prototip glavne knjige in poteka usklajevanja. Ne izdajanja računov. Račun zna ustvariti vsak. Skozi peskovnik požene en teden realnega obsega transakcij in preverite, kaj se zgodi ob koncu meseca.
3. Preverite pogodbo API glede idempotence in spletnih kljuk. Če zahteve ne morete varno ponoviti ali se naročiti na spremembe stanja, gradite krhko infrastrukturo.
4. Pogovorite se s tistim, ki bo dejansko zaključil vaše poslovne knjige. Če vaš računovodja ne more dobiti poročil, ki jih potrebuje, v obliki, ki jo zahteva, avtomatizacija v zgornjem delu verige nima pomena.
5. Izberite ponudnika, na katerega načrt delovanja lahko vplivate. Za tržnico v zgodnji fazi je to pomembneje kot odkljukanje vsake posamezne funkcije danes. Partnerski dogovori o načrtovanju obstajajo z določenim razlogom.

FAQ

Ali res potrebujem dvostavno glavno knjigo ali zadostuje tabela transakcij?

Tabela transakcij deluje vse do tistega trenutka, ko morate revizorju razložiti neskladje ali ponovno izkazati preteklo obdobje. Dvostavno knjiženje ni zastarelo računovodsko gledališče. Je razlog, da se vaše knjige ujemajo in da se napake pokažejo takoj, namesto da se potiho kopičijo.

Ali lahko za računovodski API uporabljam poročanje Stripe?

Stripe je ponudnik plačil. Njegovo poročanje je primerno za usklajevanje storitve Stripe. Ne izvaja dvostavnega knjiženja, ne obravnava prihodkov zunaj Stripe-a in ne ustvarja predpisanih zakonskih obračunov. Uporabljajte ga poleg računovodskega API-ja, ne namesto njega.

Kako naj obvladujem več držav brez registracije povsod?

Za prodajo blaga in storitev končnim potrošnikom (B2C) znotraj EU shema za vse na enem mestu (OSS) omogoča oddajo obračunov v eni državi za prodajo v celotnem bloku, do določenih pragov in z določenimi izjemami. Vaš računovodski API mora pravilno kategorizirati vsako transakcijo, da je obračun OSS točen. To je vprašanje zmožnosti in ne obvoda.

Ali je računovodstvo, ki temelji izključno na API-ju, preveč za majhno tržnico?

Če ste majhni in nameravate to tudi ostati, je tradicionalno orodje z lahkim API-jem povsem v redu. Če pa pričakujete rast, je vdelava računovodstva v vaš izdelek zgodaj precej cenejša kot kasnejša migracija z orodja, osredotočenega na uporabniški vmesnik. Strošek zamenjave računovodske infrastrukture je eden najvišjih v tehnološkem skladu podjetja.

Kaj se zgodi, če ponudnik spremeni svoj API?

Pred podpisom pogodbe povprašajte o politikah opuščanja (deprecation policies), upravljanju različic in načinu obravnave prelomnih sprememb (breaking changes). Vsak resen izdelek API-first mora imeti jasen odgovor. Če ga nimajo, je to že sam po sebi odgovor.