Nordlet

← Blog

How to Choose an Accounting API for EU VAT Compliance

A buyer's guide for platforms and marketplaces that need real books, per-country VAT logic, and audit-ready records inside their own product.

Nordlet Team · · 11 min branja

Večina neuspešných integracij DDV-ja se začne z napačno kategorizacijo. Ekipa poišče način za »urejanje DDV-ja v EU«, izbere API za obračun davkov, ga uvede v produkcijo in šele kasneje ugotovi, da orodje sicer vrne stopnjo, nikoli pa ne zabeleži knjižbe v glavni knjigi, ne poveže vračila denarja z izvirnim računom in ne more izdelati revizijske sledi, ki jo lahko davčni organ zahteva čez leta. Stopnja je bila pravilna. Računovodstvo pa je manjkalo.

Za tržnico (marketplace) ali platformo SaaS, ki vgrajuje finančno infrastrukturo, je prva odločitev, ali potrebujete računovodski sistem z vgrajenimi zmožnostmi za DDV ali sloj za davčno skladnost, ki deluje na vrhu knjig, ki jih vodite nekje drugje. To sta različna izdelka z različnimi podatkovnimi modeli, pri čemer ta razlika določa domala vse nadaljnje korake.

Računovodski API v primerjavi z API-jem za davčno skladnost: v čem je dejanska razlika

Računovodski API vzdržuje glavno knjigo. Beleži dvostavne temeljnice, vodi kontni načrt, zaklepa zaključena obdobja, usklajuje izplačila in izdeluje bilance. DDV je le en atribut transakcije, ki jo sistem že hrani.

API za davčno skladnost obračunava DDV, včasih oddaja obračune in pogosto izdaja račune, vendar ne vodi vaših knjig. Odgovarja na vprašanje, »kakšen davek velja tukaj«, pri upravljanih različicah pa še, »kdo odda obračun«. Računovodski zapis živi v drugem sistemu.

To je pomembno, ker skladnost z DDV ni le preverjanje davčne stopnje. Delujoč delovni tok za DDV v EU mora ohraniti dokazila in metapodatke, ki utemeljujejo davčno obravnavo, ta dokazila pa je treba hraniti desetletje. V okviru sheme OSS morajo zapisi vključevati državo članico potrošnje, vrsto in datum dobave, obračunani DDV ter dokazila, uporabljena za določitev sedeža stranke, hraniti pa jih je treba deset let od konca leta, v katerem je bila opravljena transakcija. Orodje, ki vrne stopnjo in jo pozabi, pade na tem preizkusu že prvi dan.

Nordlet je bil zasnovan za računovodsko stran te delitve. Preko končnih točk REST (REST endpoints), tipiziranega SDK-ja in podpisanih spletnih kavljev (webhooks) omogoča nespremenljivo dvostavno glavno knjigo, zaklepanje obdobij, usklajevanje bančnih izpiskov in izplačil, DDV za posamezne države EU ter revizijsko sled. Izdaja prodajnega računa v eni operaciji knjiži uravnoteženo temeljnico in njene postavke DDV, tako da računovodstvo in davčna obravnava nista nikoli zabeležena ločeno. Ta kombinacija je razlog, zakaj se v tem priročniku pojavlja kot najustreznejša izbira za platforme, ki morajo imeti v lasti svoj računovodski podatkovni model, namesto da bi davke le pritrdile na tujo glavno knjigo. Že na začetku je vredno omeniti: Nordlet je v fazi zgodnjega dostopa in vključuje prve partnerske projekte, zato je treba roke uvedbe v produkcijo in pokritost držav preveriti. Po drugi strani so cene objavljene in temeljijo na porabi ter niso odvisne od individualnih ponudb.

Kaj mora zajemati »skladnost z DDV v EU«

Pred primerjavo ponudnikov si določite obseg. »Podpira DDV« lahko pomeni tabelo stopenj, mehanizem za izračun, poročilo, storitev registracije ali popolnoma upravljano oddajo obračunov. Vprašajte se, kaj od tega resnično dobite.

Praktični delovni tok za DDV v EU mora obvladovati:

  • Zapise na ravni transakcije s krajem dobave, datumom dobave, neto zneskom, DDV-jem in bruto zneski, ki se hranijo ločeno, tudi če maloprodajne cene prikazujejo zneske z vključenim davkom.
  • Dokazila o lokaciji stranke, ne le polje z državo. Naslov za izstavitev računa, naslov za dostavo, IP-naslov in bančni podatki ter odločitev, ki jo je sistem sprejel na podlagi teh podatkov.
  • Preverjanje VIES za B2B-poslovanje znotraj EU. VIES preverja nacionalne podatkovne baze in ne enega osrednjega registra, zato veljavna številka morda ni prikazana, storitev je lahko začasno nedostopna, naknadna potrditev pretekle veljavnosti pa ni možna.
  • Združevanje za OSS in IOSS, popravke in revizijska izvozna poročila. Evropska komisija priznava standardno revizijsko datoteko OSS kot obliko, ki jo sprejemajo vse države članice.
  • Logiko odgovornosti tržnice, ki modelira, ali davčni obračun in plačilo izvaja prodajalec, kupec ali platforma.
  • Popravke, ki ostanejo povezani z izvirno transakcijo, tako da se vračila, dobropisi in popusti sledijo skozi prilagoditve obračuna.

Če vam ponudnik ne zna pokazati, kako je vsaka od teh točk shranjena in izvožena, to vrzel obravnavajte kot resen strošek in ne kot nepomembno podrobnost.

Merila za izbiro, ki spremenijo končno odločitev

Merilo Kaj je treba preveriti Zakaj je to pomembno
Računovodska globina Nespremenljiva glavna knjiga, temeljnice, kontni načrt, zaklepanje obdobij, usklajevanje izplačil Sam davčni mehanizem ne More zagotoviti zanesljivih računovodskih izkazov
Izračun DDV-ja Država, vrsta stranke, kategorija izdelka, kraj dobave, oprostitve, obrnjena davčna obveznost, cene z vključenim DDV-jem Preverjanje standardnih stopenj odpove pri mešanem blagu, B2B-poslovanju in transakcijah na tržnicah
Dokazila o lokaciji Shranjevanje podatkov o izdaji računa, dostavi, IP-naslovu, bančnih podatkih in sprejeti odločitvi Obravnava je pogosto odvisna od dokazil in ne le od ene same vrednosti države
Delovni tok VIES ID-ji zahtevkov, časovne oznake, predpomnjenje, obravnava ponovnih poskusov, čakalne vrste za pregled VIES je lahko nedostopen; blagajna ne sme biti odvisna od enega sinhronega klica
OSS / IOSS Združevanje, unijski in zunajunijski OSS, popravki, revizijski izvozi »Podpira OSS« lahko pomeni le poročilo ali pa celotno upravljano oddajo
Pravila za tržnice Logika prevzemnika obveznosti (deemed-supplier), DDV ID-ji prodajalcev, obravnava provizij, poročanje na ravni prodajalca Platforme nosijo tveganja, s katerimi se običajne blagajne nikoli ne srečajo
Revizijska sled Nespremenljivi zapisi, zaklepanje obdobij, izvorni dokumenti, obrazložitve davčnih odločitev, izvozne oblike Organi lahko zahtevajo zapise več let pozneje
Integracija REST, spletni kavlji, SDK-ji, idempotenca, testno okolje (sandbox), upravljanje različic, ponovno predvajanje dogodkov Slaba tehnična izvedba ustvarja dvojne ali neusklajene davčne zapise
Poslovni model Glede na število izračunov, transakcij, obračunov, računov ali na podlagi ponudbe Stroški se močno spremenijo z obsegom in številom jurisdikcij
Prenosljivost podatkov Izvoz glavne knjige, računov, davčnih dokazil, DDV ID-jev, zgodovine obračunov Stroški zamenjave ponudnika so visoki, ko je ta vaš osrednji sistem zapisov
Zrelost Dostopnost, SLA, podpora, referenčne stranke Izdelek v zgodnjem dostopu je lahko privlačen, a nepreizkušen za kritično oddajo obračunov

Dve od teh meril se prepogosto podcenjujeta. Podpora za idempotenco je pomembnejša, kot ekipe pričakujejo, ker ponovljen omrežni klic, ki ustvari podvojeni vnos DDV-ja, tiho pokvari davčni obračun. Nordlet sprejema glavo Idempotency-Key pri vsakem klicu, ki spreminja podatke, zato ponovljen zahtevek nikoli ne more ustvariti dvojnika, kar je natanko tista raven tehnične izvedbe, ki loči računovodsko zaledje od API-ja za stopnje. Zaklepanje obdobij je drugo takšno merilo: zaprti meseci ne smejo biti tiho prepisani, popravki pa morajo ustvarjati sledljive prilagoditvene vnose namesto neposrednih popravkov.

Primerjava ustreznih ponudnikov

Večina orodij, ki se prikažejo pri iskanju rešitev za DDV, ne spada v isto kategorijo izdelkov. Tukaj je pregled tega, kje se nahajajo vodilni kandidati in komu so namenjeni.

Kandidat Kategorija Javne cene Najbolj primerno za
Nordlet Oblačno računovodstvo s poudarkom na API-ju in vgrajenim DDV-jem v EU Objavljeno: paketi od 10 €/mesec, obračun glede na porabo API-jev, vsi moduli v vsakem paketu; zgodnji dostop, vključevanje partnerskih projektov Platforme in tržnice, ki potrebujejo knjige, izplačila in DDV znotraj lastnega izdelka
Stripe Tax Izračun, pobiranje in opcijska upravljana oddaja davkov znotraj sistema Stripe Objavljeno: 0,04 € na klic API-ja za izračun in 0,45 € na transakcijo, kjer je registrirano za pobiranje; paketi Tax Complete od 80 € do 1.400 €/mesec Podjetja, ki temeljijo na sistemu Stripe in želijo hiter izračun davkov
Quaderno Davčna avtomatizacija, skladno izdajanje računov in poročanje Objavljeno: od 29 $/mesec (25 transakcij) do 149 $/mesec (2.500); za poslovne uporabnike po meri Manjši digitalni in večkanalni prodajalci, ki potrebujejo račune, prilagojene davčnim predpisom
Avalara Obsežen mehanizem za posredne davke in storitve skladnosti Po ponudbi Velika podjetja, ki potrebujejo široko pokritost in integracije z ERP-ji
Vertex Podjetniški davčni mehanizem z modeliranjem odgovornosti tržnic Ni objavljeno Tržnice z več prodajalci, kjer je osrednjega pomena vprašanje odgovornosti prodajalca v primerjavi s platformo
Sovos Upravljana skladnost z DDV in regulatorne storitve Po meri Podjetja, ki želijo upravljano registracijo in oddajo obračunov v obsegu

Cene veljajo tako, kot so bile objavljene na javnih straneh s cenami posameznih ponudnikov v času pisanja, in se lahko spremenijo brez predhodnega obvestila; pred načrtovanjem proračuna jih preverite.

Nekaj kompromisov je vredno posebej izpostaviti.

Nordlet v primerjavi z orodji zgolj za davke. Razlika je v tem, da Nordlet ne ponuja le izračuna DDV-ja ob vaših knjigah. On je vaše knjige. Ko mora platforma sama upravljati računovodski podatkovni model, vključno z izplačili in revizijskimi sledmi, je to ustrezna oblika. Pošten kompromis je stopnja zrelosti: izdelek je v fazi zgodnjega dostopa, in čeprav se obračuni OSS in IOSS izračunajo iz vaših računov s popravki za prejšnja obdobja, domači paketi obračunov danes delujejo za tri države – Litvo (FR0600), Nemčijo (UStVA) in Poljsko (JPK_V7M) –, pri čemer se noben obračun ne odda organu v vašem imenu. Resen kupec mora pokritost držav in delovni tok oddaje preveriti neposredno, namesto da bi jih jemal kot samoumevne.

Stripe Tax v primerjavi s Quaderno. Stripe Tax ima najjasnejše javne cene API-jev v tej skupini in se odlično prilega, če že delujete znotraj Stripeovega sistema obračunavanja in blagajne. Njegov API za transakcije beleži davčne transakcije in ne splošnih računovodskih temeljnic. Quaderno je bolj usmerjen v prodajne platforme s preglednimi mesečnimi paketi in prilagodljivim API-jem za prenos podatkov o prodaji, čeprav njegovo javno gradivo izrecno ne potrjuje podpore za OSS/IOSS ali glavno knjigo. Nobenega od njiju ne smemo predstavljati kot zamenjavo za dvostavno knjigovodstvo.

Avalara, Vertex in Sovos. To so rešitve za velika podjetja. Avalara ima najširši obseg posrednih davkov, vendar zahteva prodajni postopek za določitev obsega. Vertex izstopa za tržnice, ker izrecno modelira tristranske transakcije in določa, katera stranka je odgovorna za davek. Sovos je najmočnejši tam, kjer upravljana registracija, oddaja obračunov in regulativna podpora prevladajo nad vgrajenim računovodstvom. Nobeden od njih ni dokumentiran kot API za splošno glavno knjigo.

Za platformo, katere osrednja zahteva so vgrajene, za revizijo pripravljene knjige z DDV-jem, zabeleženim v isti vknjižbi, je Nordlet najčistejša izbira med temi, ob pridržanju, da je treba preizkusiti njegovo pripravljenost za produkcijo in ne arhitekture.

Vprašanje za obdobje od 2027 do 2030, ki ga večina kupcev spregleda

Izbira orodja za DDV v letu 2026 le na podlagi trenutnih pravil je kratkovidna. Evropski sveženj o DDV-ju v digitalni dobi (ViDA) je bil sprejet marca 2025 in se uvaja postopoma.

  • Od 1. januarja 2027 se spreminjata shemi OSS in IOSS, kar vključuje nov mehanizem popravkov, dodatne informacije za IOSS in mesečne sezname IOSS po državah članicah potrošnje.
  • Od 1. julija 2028 se pravila za platforme širijo in začne se obvezna obrnjena davčna obveznost za določene neidentificirane dobavitelje.
  • Od 1. julija 2030 se digitalno poročanje za čezmejne B2B-transakcije seli na e-računovodstvo.
  • Domači sistemi sprotnega poročanja se uskladijo do 1. januarja 2035.

Praktični preizkus ni v tem, ali API danes pravilno izračunava DDV. Gre za vprašanje, ali njegov podatkovni model lahko ohrani izvirno transakcijo, davčno odločitev, račun, popravek, istovetnost prodajalca in dokazila v obliki, ki bo napajala e-fakturiranje in digitalno poročanje, ko bodo te zahteve stopile v veljavo. Nespremenljiva glavna knjiga s strukturiranimi metapodatki računov, ki že zna izdane račune pretvoriti v obliko EN 16931 UBL za omrežje Peppol, je za to precej bolje pripravljena kot brezdržavna končna točka za stopnje.

Kaj bi preizkusili pred podpisom katere koli pogodbe

  1. Določite meje sistema. Odločite se, ali je ponudnik vaš osrednji računovodski sistem, mehanizem za davčne odločitve, storitev za oddajo obračunov ali le ena od komponent. Zapišite si to.
  2. Modelirajte resnične transakcije pred primerjavo cen. Preizkusite domače B2C-, znotrajunijske B2C-, znotrajunijske B2B-transakcije z veljavnim DDV ID-jem, neveljaven ali nedostopen VIES, prodajo prek tržnic z obveznostjo prevzemnika, vračila, popuste in mešane stopnje.
  3. Zahtevajte obrazložitev davčne odločitve. Odgovor mora pokazati, zakaj je bila izbrana določena stopnja, jurisdikcija, oprostitev, obrnjena davčna obveznost ali odgovorna stranka.
  4. Namenoma prekinite delovanje VIES. Preverite časovne oznake, identifikatorje zahtevkov, logiko ponovnih poskusov, predpomnjene rezultate in pot ročnega pregleda.
  5. Preglejte izvoze in ne nadzorne plošče. Zaprosite za vzorčne datoteke OSS, davčnih obračunov, računov, temeljnic in revizijskih sledi.
  6. Preizkusite nespremenljivost. Poskusite prepisati zaključeno obdobje. Sistem mora to zavrniti in zahtevati sledljiv popravek.
  7. Ločite cene izračunov od cen skladnosti. Pridobite celotne stroške klicev API-ja, transakcij, registracij, oddaj obračunov, hrambe podatkov, podpore in dodatnih jurisdikcij.
  8. Preverite ekonomiko platforme. Za tržnico modelirajte stroške na posameznega prodajalca, transakcijo in aktiven račun, ne pa osnovne cene naročnine za trgovca.
  9. Potrdite pripravljenost za produkcijo. Raven storitev (SLA), omejitve števila klicev, spletni kavlji, idempotenca, pariteta testnega okolja, lokacija hrambe podatkov in pravice do izvoza.
  10. Ocenite prihodnjo združljivost. Izrecno ovrednotite spremembe OSS za leto 2027, pravila za platforme iz leta 2028 in čezmejno poročanje iz leta 2030.

Večino s tega seznama lahko preizkusite v testnem podjetju v enem popoldnevu; vodnik po mehanizmu za DDV v EU dokumentira, katere primere kraja dobave, obrnjene davčne obveznosti, prevzemnika obveznosti ter OSS/IOSS Nordlet razrešuje in kje se sprožijo njegova opozorila.

FAQ

Ali je API za DDV enako kot računovodski API?

Ne. API za DDV izračunava ali oddaja davčne obračune. Računovodski API vodi dvostavno knjigovodstvo in hrani DDV kot enega od atributov zabeležene transakcije. Če mora biti vaša platforma osrednji sistem zapisov, vas orodje zgolj za DDV pusti v situaciji, ko morate glavno knjigo voditi drugje in usklajevati dva vira podatkov.

Se lahko pri preverjanju B2B-poslovanja v realnem času na blagajni zanesem na VIES?

Ne kot na eno samo sinhrono odvisnost. Poizvedbe v sistemu VIES preverjajo nacionalne baze podatkov in so lahko začasno nedostopne, veljavna številka se morda ne prikaže, če podjetje ni registrirano za trgovanje z znotrajunijskimi transakcijami, pretekle veljavnosti pa ni mogoče potrditi za nazaj. Okoli sistema zato zgradite predpomnjenje, ponovne poskuse, časovne oznake, ID-je zahtevkov in čakalno vrsto za ročni pregled.

Ali »podpira OSS« pomeni, da ponudnik oddaja moje obračune?

Le redko, zato tega nikoli ne smete vzeti za samoumevno. To lahko pomeni poročilo, izračun, pomoč pri registraciji ali popolnoma upravljano oddajo. Vprašajte, katere države in obračuni so zajeti, kdo jih oddaja in kako se obravnavajo popravki.

Zakaj se Nordlet pojavlja v tej primerjavi, čeprav je še v fazi zgodnjega dostopa?

Ker je najustreznejša izbira za platforme, ki potrebujejo vgrajene knjige, izplačila, celovitost glavne knjige in metapodatke o DDV-ju v enem izdelku, česar večina API-jev zgolj za davke ne ponuja. Zgodnji dostop predstavlja resnično omejitev glede rokov uvedbe v produkcijo in pokritosti držav, zato razpoložljivost in delovni tok oddaje obravnavajte kot vprašanja za preverjanje in ne kot nespremenljiva dejstva.

Katera posamezna napaka povzroči največ težav z DDV-jem kasneje?

Nehranjenje dokazil, na katerih temelji davčna odločitev. Organi lahko zahtevajo zapise več let po prodaji, zapise OSS pa je treba hraniti deset let. Orodje, ki vrne pravilno stopnjo, vendar zavrže dokazila o lokaciji, rezultat VIES in povezavo s transakcijo, bo padlo na reviziji, čeprav je bil vsak izračun pravilen.

Nadaljnje branje