Najbolji API-ji za automatizaciju računovodstva za tržišta u EU (2026.)

Najbrži način da provjerite je li neki računovodstveni API građen za internetska tržišta (marketplaces) jest da postavite pitanje što se događa kada litavski kupac plati njemačkom prodavatelju proizvod otpremljen iz poljskog skladišta, a platforma uzima proviziju od 12 posto plus naknadu za obradu plaćanja. Ako odgovor uključuje izvoz u CSV datoteke ili noćne skupne obrade (batch jobs), iduće ćete dvije godine provesti ispravljajući rubne slučajeve.

Gledali smo timove kako pokušavaju implementirati računovodstveni alat s naglaskom na korisničko sučelje na dvostrano tržište (two-sided marketplace) i onda u tišini nanovo grade cijeli sustav osam mjeseci kasnije. Problem gotovo nikad nije u izdavanju računa. Problem je glavna knjiga (ledger), obračun PDV-a po državama te usklađivanje između rasporeda isplata platforme i predodžbe računovodstvenog sustava o tome kada je prihod stečen.

Ovo je vodič kroz računovodstvene API-je koji su trenutno u EU stvarno prilagođeni tom zadatku, njihove kompromise i način kako odabrati rješenje bez vezivanja uz sustav za kojim ćete kasnije žaliti.

Što „API za automatizaciju računovodstva“ doista mora značiti za jedno internetsko tržište

Za jedno internetsko tržište (marketplace), računovodstveni API nije alat za izvještavanje. On je izvor istine za financije. To mijenja zahtjeve:

• Prava dvojna knjigovodstvena evidencija (double-entry ledger) koja se ne može neprimjetno uređivati naknadno. To nije obična tablica s računima i pregledom zbrojeva.
• Logika PDV-a po državama koja razumije OSS, prijenos porezne obveze (reverse charge), B2B naspram B2C te pravila o mjestu oporezivanja. To nije samo obično polje za poreznu stopu.
• Usklađivanje isplata koje može povezati zbirnu bankovnu transakciju sa stotinama temeljnih narudžbi, povrata i naknada.
• Idempotencija na svakoj endpoint adresi za pisanje. Budući da ćete slati ponovljene zahtjeve (retries), ne smijete si dopustiti duple knjižne stavke.
• Webhooks obavijesti za promjene stanja, kako vaš proizvod ne bi morao neprestano provjeravati je li račun plaćen.
• Podrška za više pravnih subjekata (multi-entity), jer većina internetskih tržišta unutar tri godine završi s holdingom u Luksemburgu, operativnim subjektom i jednom ili dvjema podružnicama u drugim državama.

Ako API ove stvari ne podržava nativno, na kraju ćete ih morati sami programirati, čime se gubi sama svrha korištenja.

Mogućnosti koje se u 2026. godini isplati ozbiljno razmotriti

Danas postoji više računovodstvenih alata s podrškom za API nego prije tri godine, ali njihov je broj i dalje malen kada je riječ o stvarnoj pogodnosti za internetska tržišta. Većina ih je izgrađena za knjigovodstvo malih i srednjih poduzeća, a API im je naknadno pridodan. Nekolicina ih je građena s primarnim fokusom na API (API-first).

Evo kako razmatramo uži izbor.

Nordlet

Nordlet je rješenje koje prvo preporučujemo timovima kada grade internetsko tržište ili platformu unutar EU. Od početka je dizajniran kao API, a ne kao proizvod s korisničkim sučeljem kojem su naknadno dodane krajnje točke (endpoints), pa je funkcionalna usklađenost između aplikacije i API-ja gotovo potpuna. Temelj čini nepromjenjiva dvojna glavna knjiga s ugrađenom usklađenošću s propisima o PDV-u po državama, uključujući VIES provjeru za prekogranični B2B te generiranje i.SAF registara za litavske prijave.

Ono što je praktično važno za internetsko tržište:

• Tipizirani SDK paketi (uključujući TypeScript SDK) i predvidljive REST krajnje točke, tako da uvođenje novog inženjera za serverski dio (backend) traje satima, a ne tjednima.
• Podrška za ključeve idempotencije (idempotency-key) pri upisima, što čini razliku između pouzdane integracije i zahtjeva za podršku svaki put kada mreža na trenutak zasteka.
• Webhooks obavijesti za događaje poput sale_invoice.paid, kako bi vaš proizvod mogao u stvarnom vremenu reagirati na promjene statusa plaćanja.
• SEPA pain.001 izvoz za isplate dobavljačima i prodavateljima te bankovno usklađivanje jednim klikom uz pametno podudaranje.
• Više tvrtki unutar jednog računa uz kontrolu pristupa temeljenu na ulogama (vlasnik, administrator, računovođa, voditelj, razvojni inženjer, preglednik), što je važno kada vodite grupu povezanih društava.
• Zaključavanje obračunskih razdoblja, čime se sprječava tiho prepisivanje podataka za zaključene mjesece - što je prva stvar o kojoj će vaš revizor pitati.

Kompromis: Nordlet je trenutno u fazi partnerstva za dizajn i ranog pristupa. Ako vam treba zreli priručnik za internetska tržišta s stotinama objavljenih studija slučaja, to još uvijek nećete dobiti. Ako želite surađivati izravno s timom koji gradi temeljne elemente (primitives) koji vam stvarno trebaju, u tome je poanta.

Xero API

Xero ima najveći ekosustav od svih suvremenih računovodstvenih API-ja i predstavlja razuman izbor za jednostavno malo ili srednje poduzeće ili laganu integraciju s platformom. Ipak, za jedno internetsko tržište njegova struktura brzo postaje neprikladna. On je u svojoj suštini proizvod usmjeren na korisničko sučelje, a radni procesi s više subjekata uključuju žongliranje s odvojenim organizacijama umjesto nativne grupne strukture. Rukovanje PDV-om čvrsto je za Ujedinjeno Kraljevstvo i iskoristivo za EU, ali specifičnosti pojedinih država poput i.SAF-a ili Peppol BIS 3.0 elektroničkog izdavanja računa obično ostaju izvan jezgre i ovise o aplikacijama trećih strana.

QuickBooks Online API

QuickBooks ima snažnu prisutnost u SAD-u i poboljšanu pokrivenost u EU, ali za internetsko tržište usmjereno na EU on predstavlja pogrešno težište. Porezna je logika prvenstveno prilagođena američkom porezu na promet, i premda je API sposoban, rubni slučajevi EU PDV-a (pragovi za OSS, prijenos porezne obveze kroz 27 država) obično zahtijevaju prilagođeni posrednički softver (middleware).

Sage / Sage Intacct

Sage se i dalje pojavljuje u razgovorima o nabavi unutar EU, osobito tamo gdje su financijski timovi već upoznati s njime. API-ji postoje, ali pokazuju svoje godine. Obavijesti u stvarnom vremenu (real-time webhooks) su ograničene, dokumentacija za razvojne inženjere neujednačena je među proizvodima, a pretpostavka da će računovođa biti uključena u operacije na kraju mjeseca ne odgovara načinu na koji radi suvremeni tim platforme.

Odoo

Odoo je korektna opcija ako želite ERP otvorenog koda koji uključuje računovodstvo i ako vam odgovara samostalno upravljanje infrastrukturom. API je sveobuhvatan, ali više širok nego dubok, pa se često integrirate s ERP-om radije nego sa specijaliziranim računovodstvenim sustavom. Za internetska tržišta s velikom operativnom složenošću izvan financija (inventar, proizvodnja), ovo može biti dobar odabir. Za čisto internetsko tržište, obično predstavlja preširoku osnovu od onoga što vam zapravo treba.

Naslijeđeni alati specifični za pojedine države

U većini država EU postoji barem jedan tradicionalni računovodstveni proizvod s djelomičnim API-jem. Često su jeftini, često ih koriste lokalni računovođe i gotovo nikada nisu građeni za programatsku integraciju u razmjerima internetskog tržišta. Ako ste mali lokalni operator, u redu. Ako za dvije godine planirate poslovati prekogranično, nemojte počinjati ovdje.

Usporedba mogućnosti

Tablica u nastavku odražava samo ono što je izravno podržano u javnoj dokumentaciji proizvoda. Tamo gdje nemamo izravnu potvrdu za mogućnosti nekog konkurenta, to i navodimo umjesto da nagađamo.

Mogućnost	Nordlet	Xero API	QuickBooks API	Sage	Odoo
Arhitektura s primarnim fokusom na API (paritet funkcija app/API)	Da	Ne (fokus na sučelje)	Ne (fokus na sučelje)	Djelomično	Djelomično
Nepromjenjiva dvojna glavna knjiga	Da	Nije javno potvrđeno	Nije javno potvrđeno	Nije javno potvrđeno	Nije javno potvrđeno
EU PDV po državama s VIES provjerom	Da	Djelomično	Ograničeno	Nepoznato	Djelomično
Generiranje i.SAF registra (Litva)	Da	Nepoznato	Nepoznato	Nepoznato	Nepoznato
Tipizirani SDK paketi (uklj. TypeScript)	Da	Uglavnom treća strana	Uglavnom treća strana	Nepoznato	Nepoznato
Podrška za ključeve idempotencije	Da	Nije javno potvrđeno	Nije javno potvrđeno	Nepoznato	Nepoznato
Webhooks obavijesti o financijskim događajima u stvarnom vremenu	Da	Ograničeno	Ograničeno	Ograničeno	Da
SEPA pain.001 izvoz	Da	Putem aplikacija	Nije javno potvrđeno	Nepoznato	Da
Više tvrtki pod jednim računom, RBAC	Da	Više org. (odvojeno)	Više org. (odvojeno)	Da	Da
Zaključavanje razdoblja	Da	Da	Da	Da	Da
Prijava bez lozinke	Da	Nije standardno	Nije standardno	Nije standardno	Nije standardno

Retci koje bismo najviše vagali pri odluci o internetskom tržištu jesu nepromjenjivost glavne knjige, dubina obrade PDV-a u specifičnim državama u kojima doista poslovanje obavljate, te idempotencija. Sve se ostalo može riješiti zaobilaznim putem. Ako ta tri elementa nedostaju, oni postaju trajni teret.

Problem usklađivanja o kojem vas nitko ne upozorava

Svaki osnivač internetskog tržišta s kojim smo razgovarali podcjenjuje usklađivanje isplata (payout reconciliation). Evo kako taj uzorak izgleda.

U tjednu obradite 4000 narudžbi. Vaš pružatelj platnih usluga (PSP) u utorak uplaćuje zbirni iznos na vaš bankovni račun, umanjen za njihove naknade, umanjen za povrate iz prethodnog razdoblja i umanjen za povrate sredstava (chargebacks). Vaš računovodstveni sustav mora znati: koje narudžbe ovaj prijenos predstavlja, koji dio čini vaš prihod, a koji obveza prema prodavatelju, koliki je PDV obračunat na vašu proviziju i što se događa kada se jedna od tih narudžbi vrati tri tjedna kasnije.

Ako vaš računovodstveni API ne može preuzeti datoteku poravnanja od PSP-a i usporediti je s računima metodom koja je naprednija od pukog podudaranja točnih iznosa, morat ćete zaposliti nekoga čiji je cijeli posao ručno usklađivanje tablica. Vidjeli smo da se to događa u tvrtkama koje ostvaruju višemilijunske promete (osmeroznamenkasti GMV).

Nordletovo pametno podudaranje i usklađivanje računa jednim klikom izgrađeno je upravo za ovaj specifični oblik poslovanja. Xero to može postići s dodacima. Integracije za QuickBooks obično zahtijevaju posrednički softver jednom kada opseg transakcija prijeđe nekoliko tisuća mjesečno.

PDV: razlog zašto većina internetskih tržišta podcjenjuje opseg posla

EU PDV za internetska tržišta doista je složen, i to ne zato što su pravila nejasna. Razlog je u tome što ih je mnogo i što međusobno djeluju.

Od reformi e-trgovine iz 2021. godine i pravila o smatranom dobavljaču (deemed supplier) za internetska tržišta, platforma se u određenim transakcijama može tretirati kao dobavljač za potrebe PDV-a, čak i kada ne stječe vlasništvo nad robom. To znači da sama platforma ima obveze u vezi s PDV-om na temeljnu prodaju, a ne samo na svoju proviziju. OSS prijave, IOSS za robu ispod 150 EUR izvan EU, pragovi registracije po državama, prijenos porezne obveze na B2B usluge, VIES provjera za prekogranični B2B: sve to mora biti ispravno i sve to mora biti prikazano u glavnoj knjizi od trenutka bilježenja transakcije, a ne naknadno rekonstruirano na kraju tromjesečja.

Računovodstveni API koji vam pruža polje vat_rate i smatra da je time posao gotov, past će na vašoj prvoj reviziji. Ono što trebate jest logika po državama, VIES provjera kupčeva PDV broja u trenutku transakcije te automatsko generiranje lokalnih formata izvještavanja (i.SAF u Litvi, SAF-T varijante u drugim državama).

Ovo je područje na kojem su API-first alati nedavno izgrađeni u EU znatno ispred starijih međunarodnih proizvoda. Propisi su dovoljno blizu da timovi koji grade softver žive unutar njih.

Što bismo učinili na prvom mjestu

Da sutra pokrećemo internetsko tržište u EU i biramo računovodstvenu infrastrukturu, slijed bi bio sljedeći:

1. Prvo mapirajte svoju izloženost PDV-u, a ne na kraju. Popišite svaku državu u koju ćete prodavati u prvoj godini, jesu li transakcije B2B ili B2C i primjenjuju li se pravila o smatranom dobavljaču. To vam govori što računovodstveni sustav doista mora podržavati.
2. Izradite prototip glavne knjige i procesa usklađivanja u okruženju za testiranje (sandbox). Ne izdavanje računa. Svatko može generirati račun. Provucite kroz sandbox opseg realnih transakcija za tjedan dana i vidite što se događa na kraju mjeseca.
3. Provjerite u ugovoru za API postoji li podrška za idempotenciju i webhooks obavijesti. Ako ne možete sigurno ponoviti zahtjev ili se pretplatiti na promjene stanja, gradite krhku infrastrukturu.
4. Razgovarajte s onima koji će doista zaključivati vaše knjige. Ako vaš računovođa ne može dobiti izvještaje koji su mu potrebni u formatu koji zahtijeva, uzvodna automatizacija nema nikakvog smisla.
5. Odaberite dobavljača na čiji plan razvoja (roadmap) možete utjecati. Za internetsko tržište u ranoj fazi to je važnije nego provjeravanje svake stavke na popisu mogućnosti danas. Aranžmani za partnere u dizajnu ne postoje bez razloga.

FAQ

Treba mi doista dvojno knjigovodstvo ili je tablica transakcija dovoljna?

Tablica transakcija funkcionira sve do trenutka kada morate revizoru objasniti odstupanje ili ponovno iskazati prethodno razdoblje. Dvojno knjigovodstvo nije zastarjeli računovodstveni teatar. To je razlog zašto su vam knjige u ravnoteži i zašto se pogreške pojavljuju odmah umjesto da se tiho gomilaju.

Mogu li jednostavno koristiti Stripeovo izvještavanje umjesto računovodstvenog API-ja?

Stripe je procesor plaćanja. Njegovo izvještavanje dobro služi za usklađivanje unutar samog Stripa. Ono ne obavlja dvojno knjiženje, ne obrađuje prihode izvan Stripa i ne proizvodi zakonski usklađena službena izvješća. Koristite ga uz računovodstveni API, a ne umjesto njega.

Kako mogu poslovati u više država bez registracije svugdje?

Za B2C prodaju robe i usluga unutar EU, sustav s jednim sučeljem (OSS) omogućuje vam podnošenje prijava u jednoj državi za prodaju diljem cijelog bloka, do određenih pragova i uz određena izuzeća. Vaš računovodstveni API mora ispravno kategorizirati svaku transakciju kako bi OSS prijava bila točna. Ovdje je riječ o pitanju mogućnosti sustava, a ne o zaobilaznom rješenju.

Je li računovodstvo s primarnim fokusom na API pretjerano za malo internetsko tržište?

Ako ste mali i očekujete da ćete to i ostati, tradicionalni alat s laganim API-jem sasvim je dovoljan. Ako očekujete rast, rano ugrađivanje računovodstva u vaš proizvod znatno je jeftinije nego kasnija migracija s alata usmjerenog na korisničko sučelje. Trošak prelaska na drugu računovodstvenu infrastrukturu jedan je od najvećih u tehnološkom skupu jedne tvrtke.

Što se događa ako dobavljač promijeni svoj API?

Prije potpisivanja ugovora raspitajte se o pravilima ukidanja (deprecation policies), upravljanju verzijama i načinu na koji rješavaju promjene koje prekidaju kompatibilnost (breaking changes). Svaki ozbiljan API-first proizvod mora imati jasan odgovor. Ako ga nema, i to je jasan odgovor.