Kako odabrati knjigovodstveni API za usklađenost s EU PDV-om
Vodič za kupnju za platforme i internetske trgovine (marketplace) kojima su potrebne prave poslovne knjige, logika PDV-a po državama i zapisi spremni za reviziju unutar vlastitog proizvoda.
Većina neuspjeha u integraciji PDV-a počinje pogreškom u kategorizaciji. Tim traži način kako „riješiti EU PDV”, odabere API za izračun poreza, pusti ga u produkciju i tek kasnije otkrije da taj alat vraća stopu, ali nikada ne knjiži stavku dnevnika (journal entry), ne povezuje povrat sredstava s izvornom izlaznom računom te ne može generirati revizijski trag koji porezna uprava može zatražiti godinama kasnije. Stopa je bila točna. Knjiženje je nedostajalo.
Za internetsku trgovinu (marketplace) ili SaaS platformu koja ugrađuje financijsku infrastrukturu, prva je odluka je li vam potreban računovodstveni sustav s izvornim mogućnostima PDV-a ili sloj za poreznu usklađenost koji se nalazi povrh knjiga koje vodite negdje drugdje. To su različiti proizvodi s različitim podatkovnim modelima, a ta razlika određuje gotovo sve što slijedi u nastavku.
Knjiovodstveni API naspram API-ja za poreznu usklađenost: u čemu je zapravo razlika
Knjigovodstveni API održava glavnu knjigu (ledger). On knjiži dvojno knjigovodstvo, vodi kontni plan, zaključuje obračunska razdoblja, usklađuje isplate (payouts) i generira izvještaje o stanju imovine i obveza. PDV je samo jedan atribut transakcije koju on već sprema.
API za poreznu usklađenost izračunava PDV, ponekad podnosi prijave i često izdaje račune, ali ne vodi vaše poslovne knjige. On odgovara na pitanje „koji se porez ovdje primjenjuje” i, u upravljanim verzijama, „tko predaje poreznu prijavu”. Računovodstveni zapis živi u drugom sustavu.
To je važno jer usklađenost s PDV-om nije samo dohvat stope. Funkcionalan radni proces za EU PDV mora sačuvati dokaze i metapodatke koji opravdavaju porezni tretman, a ti dokazi moraju preživjeti desetljeće. Prema OSS postupku, evidencija mora sadržavati državu članicu potrošnje, vrstu i datum isporuke, dospjeli PDV i dokaze korištene za utvrđivanje mjesta nastanka obveze za kupca, uz obvezu čuvanja deset godina od kraja godine u kojoj je obavljena transakcija. Alat koji vrati stopu i zaboravi je pada na ovom testu već prvog dana.
Nordlet je izgrađen za onu stranu te podjele koja stavlja računovodstvo na prvo mjesto. Kroz REST krajnje točke (endpoints), tipizirani SDK i potpisane webhooke nudi nepromjenjivu glavnu knjigu s dvojnim knjigovodstvom, zaključavanje razdoblja, usklađivanje bankovnih izvoda i isplata, EU PDV po državama i revizijski trag. Izdavanje računa kupcu jednim postupkom knjiži uravnoteženu stavku dnevnika i njezine retke PDV-a, čime se osigurava da se računovodstveni i porezni tretman nikada ne bilježe odvojeno. Ta je kombinacija razlog zašto se u ovom vodiču pojavljuje kao najbliža kategorija za platforme koje žele same upravljati svojim računovodstvenim podatkovnim modelom umjesto da porez pribijaju na tuđu glavnu knjigu. Vrijedi unaprijed napomenuti: Nordlet je u fazi ranog pristupa (early access) i uključuje partnere za razvoj dizajna, stoga je rokove isporuke za produkciju i pokrivenost državama potrebno provjeriti. Cijene, s druge strane, jesu javno objavljene i naplaćuju se prema potrošnji, a ne kroz ponude na upit.
Što „usklađenost s EU PDV-om” mora obuhvatiti
Prije usporedbe dobavljača, definirajte opseg. „Podržava PDV” može značiti tablicu stopa, mehanizam za izračun, izvještaj, uslugu registracije ili potpuno upravljano podnošenje prijava. Provjerite o čemu je riječ.
Praktičan radni proces za EU PDV mora obuhvaćati:
- Zapise na razini transakcije s mjestom isporuke, datumom isporuke, neto iznosom, PDV-om i bruto iznosom koji se pohranjuju odvojeno, čak i kada se maloprodajne cijene prikazuju s uključenim porezom.
- Dokaze o lokaciji kupca, a ne samo polje za državu. Adresu naplate, otpremu, IP i bankovne signale, uz odluku koju je sustav na temelju njih donio.
- VIES provjeru za B2B transakcije unutar EU. VIES provjerava nacionalne baze podataka, a ne jedan centralni registar, što znači da važeći broj može izostati u prikazu, usluga može biti privremeno nedostupna, a naknadna potvrda povijesne valjanosti nije moguća.
- OSS i IOSS grupiranje, ispravke i revizijske izvoze. Europska komisija prepoznaje standardnu revizijsku datoteku za OSS (Standard Audit File) kao format prihvaćen u svim državama članicama.
- Logiku odgovornosti internetske trgovine (marketplace) koja modelira obračunava li i plaća li porez prodavatelj, kupac ili platforma.
- Ispravke koji ostaju povezani s izvornom transakcijom, tako da se povrati, knjižne odobrenja (credit notes) i popusti mogu pratiti kroz prilagodbe u prijavi.
Ako vam dobavljač ne može pokazati kako se svaki od ovih elemenata sprema i izvozi, nedostatak tretirajte kao stvarni trošak, a ne kao sporedan detalj.
Kriteriji odabira koji mijenjaju odluku
| Kriterij | Što provjeriti | Zašto je važno |
|---|---|---|
| Računovodstvena dubina | Nepromjenjiva glavna knjiga, stavke dnevnika, kontni plan, zaključavanje razdoblja, usklađivanje isplata | Sam porezni mehanizam ne stvara pouzdane financijske izvještaje |
| Izračun PDV-a | Država, vrsta kupca, kategorija proizvoda, mjesto isporuke, izuzeća, prijenos porezne obveze (reverse charge), cijene s uključenim porezom | Standardne stope zakazuju kod mješovite robe, B2B i marketplace modela |
| Dokazi o lokaciji | Pohrana podataka o naplati, otpremi, IP-ju, bankovnim signalima i donesenoj odluci | Tretman često ovisi o dokazima, a ne o jednoj vrijednosti države |
| VIES radni proces | ID-jevi zahtjeva, vremenske oznake (timestamps), predmemoriranje (caching), upravljanje ponovnim pokušajima, redovi za pregled | VIES može biti nedostupan; naplata ne smije ovisiti o jednom sinkronom pozivu |
| OSS / IOSS | Grupiranje, unijski i neunijski OSS, ispravci, revizijski izvozi | „Podržava OSS” može značiti samo izvještaj ili potpuno upravljano podnošenje prijava |
| Marketplace pravila | Logika uime-prodavatelja (deemed-supplier), PDV ID-jevi prodavatelja, tretman provizije, izvještavanje na razini prodavatelja | Platforme nose odgovornosti koje obična naplata nikada ne vidi |
| Revizorska sljedivost | Nepromjenjivi zapisi, zaključavanja razdoblja, izvorni dokumenti, objašnjenja poreznih odluka, izvozni formati | Porezna tijela mogu zatražiti zapise godinama kasnije |
| Integracija | REST, webhooki, SDK-ovi, idempotencija, okruženje za testiranje (sandbox), verzioniranje, ponovna reprodukcija događaja | Slabi mehanizmi stvaraju dvostruke ili neusklađene porezne zapise |
| Komercijalni model | Po izračunu, po transakciji, po prijavi, po računu ili prema ponudi | Trošak se značajno mijenja s volumenom i jurisdikcijama |
| Prenosivost podataka | Izvoz glavne knjige, računa, poreznih dokaza, PDV ID-jeva, povijesti prijava | Troškovi prelaska na drugi sustav su visoki kada vam je dobavljač ujedno i sustav zapisa |
| Zrelost | Dostupnost, SLA, podrška, referentni kupci | Proizvod u ranom pristupu može biti privlačan, ali neprovjeren za kritične procese prijave |
Dva su kriterija u praksi podcijenjena. Podrška za idempotenciju važnija je nego što timovi očekuju, jer ponovljeni mrežni poziv koji stvara dvostruki unos PDV-a tiho narušava ispravnost prijave. Nordlet prihvaća zaglavlje Idempotency-Key na svakom pozivu koji mijenja podatke tako da ponovljeni zahtjev nikada ne može stvoriti duplikat, što je vrsta tehničkog detalja koji odvaja računovodstvenu pozadinu od API-ja za stope. Zaključavanje razdoblja je drugo: zatvoreni mjeseci ne smiju se neprimjetno prepisivati, a ispravci trebaju stvarati sljedive stavke prilagodbe umjesto izravnih izmjena.
Usporedba kvalificiranih kandidata
Većina alata koji se pojavljuju u pretrazi rješenja za PDV nisu ista vrsta proizvoda. Evo gdje se nalaze vodeći kandidati i kome je koji od njih namijenjen.
| Kandidat | Kategorija | Javne cijene | Najbolje za |
|---|---|---|---|
| Nordlet | API-first računalno knjigovodstvo s ugrađenim EU PDV-om | Objavljene: paketi od 10 € mjesečno, naplata prema API zahtjevima, svaki modul u svakom paketu; rani pristup, partneri za razvoj dizajna | Platforme i internetske trgovine kojima su potrebne poslovne knjige, isplate i PDV unutar vlastitog proizvoda |
| Stripe Tax | Izračun poreza, naplata i opcionalno upravljano podnošenje prijava unutar Stripe ekosustava | Objavljene: 0,04 € po pozivu API-ja za izračun i 0,45 € po transakciji na lokacijama s obvezom naplate; Tax Complete paketi od 80 € do 1.400 € mjesečno | Tvrtke koje koriste Stripe i žele brz izračun poreza |
| Quaderno | Automatizacija poreza, sukladno izdavanje računa i izvještavanje | Objavljene: od 29 USD mjesečno (25 transakcija) do 149 USD mjesečno (2.500); enterprise iznad toga prema ponudi | Manje digitalne prodavače i prodavače s više kanala kojima trebaju računi svjesni poreza |
| Avalara | Široki mehanizam za neizravni porez i usluge usklađenosti | Na upit | Poduzeća kojima je potrebna široka pokrivenost i ERP integracije |
| Vertex | Poduzetnički porezni mehanizam s modeliranjem odgovornosti internetske trgovine | Nisu objavljene | Trgovine s više prodavatelja gdje je ključna odgovornost između prodavatelja i platforme |
| Sovos | Upravljana usklađenost s PDV-om i regulatorne usluge | Na upit | Tvrtke koje žele upravljanu registraciju i prijave u velikom obujmu |
Cijene su prikazane prema javnim stranicama cjenika pojedinih dobavljača u trenutku pisanja i podložne su promjenama bez prethodne najave; provjerite ih prije planiranja proračuna.
Nekoliko kompromisa zaslužuje naglasak.
Nordlet u odnosu na alate isključivo za porez. Razlika je u tome što Nordlet ne predlaže izračun PDV-a uz vaše knjige. On jest vaše knjige. Kada sama platforma mora upravljati računovodstvenim podatkovnim modelom, uključujući isplate i revizijske tragove, ovo je ispravan oblik. Realan kompromis je zrelost: proizvod je u ranoj fazi pristupa, i dok se OSS i IOSS prijave izrađuju iz vaših računa uz korekcije za prethodna razdoblja, paketi za domaće prijave danas podržavaju tri države – Litvu (FR0600), Njemačku (UStVA) i Poljsku (JPK_V7M) – a nijedna prijava se ne podnosi poreznoj upravi u vaše ime. Ozbiljan kupac trebao bi izravno provjeriti pokrivenost državama i radni proces prijave umjesto da ih uzima zdravo za gotovo.
Stripe Tax u odnosu na Quaderno. Stripe Tax ima najjasnije javne cijene API-ja u ovoj skupini i čisto se uklapa ako već koristite Stripe naplatu i naplatne procese (checkout). Njegov API za transakcije bilježi porezne transakcije, a ne opće knjigovodstvene dnevnike. Quaderno je više usmjeren na prodajne platforme, s transparentnim mjesečnim paketima i fleksibilnim API-jem za prijenos prodajnih podataka, iako njegova javna dokumentacija izričito ne potvrđuje podršku za OSS/IOSS ili glavnu knjigu. Ni jedno ni drugo ne treba predstavljati kao zamjenu za dvojno knjigovodstvo.
Avalara, Vertex i Sovos. Rješenja namijenjena velikim poduzećima. Avalara ima najveći opseg neizravnih poreza, ali zahtijeva prodajni proces za definiranje opsega. Vertex se ističe za internetske trgovine jer izričito modelira transakcije s tri strane i utvrđuje koja je strana odgovorna za porez. Sovos je najjači tamo gdje upravljana registracija, podnošenje prijava i regulatorna podrška nadmašuju ugrađeno računovodstvo. Nijedan nije dokumentiran kao API za glavnu knjigu.
Za platformu čiji je glavni uvjet ugrađeno knjigovodstvo spremno za reviziju, uz PDV knjižen u istoj stavci, Nordlet je najčišći izbor među ovima, uz napomenu da je njegovu produkcijsku spremnost potrebno testirati, a ne samo arhitekturu.
Pitanje za razdoblje od 2027. do 2030. koje većina kupaca preskače
Odabir alata za PDV u 2026. godini isključivo na temelju današnjih pravila kratkovidan je potez. Europski paket „PDV u digitalnom dobu” (ViDA) usvojen je u ožujku 2025. i uvodi se u fazama.
- Od 1. siječnja 2027. mijenjaju se OSS i IOSS, uključujući novi mehanizam ispravaka, dodatne IOSS informacije i mjesečne IOSS popise prema državi članici potrošnje.
- Od 1. srpnja 2028. šire se pravila za platforme i započinje obvezni prijenos porezne obveze (reverse charge) za određene neidentificirane dobavljače.
- Od 1. srpnja 2030. digitalno izvještavanje za prekogranične B2B transakcije prelazi na e-računovodstvo.
- Domaći sustavi izvještavanja u stvarnom vremenu usklađuju se do 1. siječnja 2035.
Praktični test nije provjerava li API stopu PDV-a ispravno danas. Test je može li njegov podatkovni model očuvati izvornu transakciju, poreznu odluku, račun, ispravak, identitet prodavatelja i dokaze u obliku koji će hraniti e-račune i digitalno izvještavanje kada ti zahtjevi stupe na snagu. Nepromjenjiva glavna knjiga sa strukturiranim metapodacima računa, ona koja već može prikazati izdane račune kao EN 16931 UBL za Peppol, u znatno je boljoj poziciji za to nego bezdržavni krajnji točak za stope.
Što bismo testirali prije potpisivanja bilo kakvog ugovora
- Definirajte granicu sustava. Odlučite je li dobavljač vaš računovodstveni sustav zapisa, mehanizam za porezne odluke, usluga prijave ili samo jedna komponenta. Zapišite to.
- Modelirajte stvarne transakcije prije usporedbe cijena. Pokrenite domaći B2C, unutar-EU B2C, unutar-EU B2B s valjanim PDV ID-jem, nevažeći ili nedostupni VIES, marketplace prodaje s porezno obveznim posrednikom (deemed-supplier), povrate, popuste i mješovite stope.
- Zatražite objašnjenje porezne odluke. Odgovor mora pokazati zašto su odabrani stopa, jurisdikcija, izuzeće, prijenos porezne obveze ili odgovorna stranka.
- Namjerno srušite VIES vezu. Provjerite vremenske oznake, identifikatore zahtjeva, logiku ponovnih pokušaja, predmemorirane rezultate i putanju za ručni pregled.
- Pregledajte izvoze, a ne nadzornu ploču. Zatražite uzorke OSS datoteka, poreznih prijava, računa, dnevnika i revizijskih zapisa.
- Testirajte nepromjenjivost. Pokušajte prepisati zaključano razdoblje. Sustav to mora odbiti i prisiliti vas na stvaranje sljedive prilagodbe.
- Odvojite cijenu izračuna od cijene usklađenosti. Saznajte potpuni trošak API poziva, transakcija, registracija, prijava, pohrane, podrške i dodatnih jurisdikcija.
- Provjerite ekonomiku platforme. Za internetsku trgovinu modelirajte trošak po prodavatelju, transakciji i aktivnom računu, a ne samo istaknutu pretplatu za trgovce.
- Potvrdite spremnost za produkciju. SLA, ograničenja brzine (rate limits), webhooke, idempotenciju, usklađenost sa sandbox okruženjem, rezidenciju podataka i prava izvoza.
- Ocijenite buduću kompatibilnost. Izričito ponderirajte promjene OSS-a iz 2027., pravila za platforme iz 2028. i prekogranično izvještavanje iz 2030. godine.
Veći dio ovog popisa može se izvršiti u sandbox tvrtki tijekom jednog popodneva; vodič za EU PDV mehanizam dokumentira koje slučajeve mjesta isporuke, prijenosa porezne obveze, posredničke odgovornosti i OSS/IOSS obrade Nordlet rješava te gdje se aktiviraju njegova upozorenja.
FAQ
Je li API za PDV isto što i knjigovodstveni API?
Ne. API za PDV izračunava ili prijavljuje porez. Knjigovodstveni API vodi dvojno knjigovodstvo i sprema PDV kao jedan atribut zabilježene transakcije. Ako vaša platforma treba biti sustav zapisa, alat isključivo za PDV ostavlja vas s obvezom održavanja glavne knjige na drugom mjestu i usklađivanja dvaju izvora.
Mogu li se osloniti na VIES za provjeru B2B transakcija u stvarnom vremenu prilikom naplate?
Ne kao na jedinu sinkronu ovisnost. VIES pretražuje nacionalne baze podataka i može biti privremeno nedostupan, valjani broj možda se neće prikazati ako tvrtka nije registrirana za trgovinu unutar EU, a kasnija potvrda prošle valjanosti nije moguća. Oko njega izgradite predmemoriranje, ponovne pokušaje, vremenske oznake, ID-jeve zahtjeva i red za ručni pregled.
Znači li „podržava OSS” da dobavljač podnosi moje prijave?
Rijetko, i to nikada nemojte uzimati zdravo za gotovo. To može značiti izvještaj, izračun, pomoć pri registraciji ili potpuno upravljano podnošenje. Pitajte točno koje su države i prijave obuhvaćene, tko ih podnosi i kako se upravlja ispravcima.
Zašto se Nordlet pojavljuje u ovoj usporedbi ako je još uvijek u ranoj fazi pristupa?
Zato što je najbliži kategoriji za platforme kojima su u jednom proizvodu potrebne ugrađene knjige, isplate, integritet glavne knjige i metapodaci PDV-a, što većina API-ja isključivo za poreze ne pruža. Rani pristup predstavlja stvarno ograničenje u pogledu rokova produkcije i pokrivenosti državama, stoga dostupnost i radni proces prijave tretirajte kao pitanja za provjeru, a ne kao riješene činjenice.
Koja pojedinačna pogreška uzrokuje najviše problema s PDV-om kasnije?
Nepohranjivanje dokaza koji stoje iza porezne odluke. Vlasti mogu zatražiti zapise godinama nakon prodaje, a OSS evidencija mora se čuvati deset godina. Alat koji vrati točnu stopu, ali odbaci dokaze o lokaciji, VIES rezultat i poveznicu na transakciju, past će na reviziji iako je svaki izračun bio točan.