Nordlet

← Blog

Avtomatizacija skladnosti z DDV v EU s pomočjo API-ja za v oblaku podprto računovodstvo

Uporaben vodnik za platforme in tržnice, ki potrebujejo prave poslovne knjige, pravilen DDV in revizijsko sled, ki vzdrži preizkus časa še leta kasneje.

Nordlet Team · · 10 min branja

DDV v EU ni več problem izračuna. Je problem dokazovanja. Stopnje so objavljene, pragovi so znani, obračuni OSS pa so dobro dokumentirani. Tisto, kar pade na revizijah in kar v obsegu ruši platforme, je nezmožnost rekonstrukcije, kako je bila sprejeta določena odločitev o DDV na določenem računu z uporabo pravil in vnosov, ki so obstajali v tistem trenutku. API za v oblaku podprto računovodstvo lahko to avtomatizira od začetka do konca, vendar le, če je zasnovan okoli grafikona odločanja in ne le okoli stopnje davka.

Ta razlika opredeljuje vse, kar sledi v nadaljevanju.

Kaj v resnici pomeni »avtomatizacija DDV v EU«

Za platformo, ki prodaja v več državah EU, je avtomatizacija DDV veriga odvisnih odločitev:

  • Ali je stranka poslovni subjekti (B2B) ali končni potrošnik (B2C) in kje se nahaja?
  • Stopnja katere države se uporablja, v kateri davčni kategoriji in na datum izdaje računa?
  • Ali je dobava obdavčena z obrnjeno davčno obveznostjo (reverse charge), prijavljena prek sistema OSS, sistema IOSS ali domača dobava?
  • Ali je bila tržnica šteje kot dobavitelj (deemed supplier) ali je bil to trgovec?
  • Kakšni dokazi podpirajo vsakega od teh odgovorov in jih je mogoče pozneje poustvariti?

Avtomatizacija zneska brez avtomatizacije utemeljitve je tisto, kar povzroča klasični revizijski neuspeh: pravšnja vsaka vsota, a nobene obranljive sledi. Sodobni davčni pogoni se vse bolj osredotočajo na dokazne sledi, primerne za revizijo, in zgodovinske poizvedbe stopenj davka, ravno zato, ker se inšpekcijski nadzor danes osredotoča na to, kako je bila sprejeta odločitev o DDV, in ne le na to, kolikšna je bila.

API za v oblaku podprto računovodstvo je naravno mesto za shranjevanje te sledi, saj že hrani račun, vknjižbo v glavni knjigi in poslovnega partnerja. Nordlet je zasnovan okoli te ideje: nespremenljiva dvostavna glavna knjiga, logika DDV po posameznih državah, preverjanje VIES in generiranje poročil i.SAF, pri čemer je vse dostopno prek enotnega vmesnika REST s tipiziranimi kompleti SDK in spletnimi kavlji (webhooks). API ni zgolj tanek ovoj okoli knjigovodstva. Je evidenca same odločitve.

Tri zmogljivosti API-ja, ki nosijo glavno breme

Večina dela na področju avtomatizacije DDV se zreducira na tri zmožnosti, ki jih mora računovodski API jasno izpostaviti.

1. Vsebina stopenj in davčne kategorije, vezane na datum. Stopnje se spreminjajo. Kategorije se spreminjajo. Znižane stopnje se dodajajo in ukinjajo. Izvedljiv vzorec, kot ga zagovarja Sage v svojem smernicah za razvijalce o reformi DDV v EU in računovodskih API-jih, je kartiranje artiklov v davčne kategorije, nato pa kartiranje davčnih kategorij v kode, specifične za posamezno državo, z veljavnimi datumi. Trdo kodiranje stopnje na artikel in državo je protiporaba, ki se tiho kopiči, dokler sprememba stopnje čez leto dni ne povzroči napake.

2. Preverjanje ID-ja za DDV z elegantnim zmanjšanjem zmogljivosti (graceful degradation). VIES je kanonični vir za preverjanje B2B transakcij z mednarodnim elementom. Hkrati pa je občasno zanesljiv. Smiselne izvedbe predpomnijo preverjanja s kratkim časom veljavnosti (TTL), ponovijo poskus ob napaki in dvoumne primere preusmerijo v čakalno vrsto za pregled, namesto da bi blokirale prodajo. Predpostavka, da mora VIES sinhrono uspeti za vsako transakcijo, je način, s katerim si platforme same gradijo izpade.

3. Zajem dokazil in nespremenljivost (immutability). Vsaka odločitev o DDV mora shranjevati svoje vnose: signale o lokaciji stranke, ID za DDV in časovni žig preverjanja, davčno kategorijo, različico razpredelnice stopenj, veljavno ureditev (domača, OSS, IOSS, obrnjena davčna obveznost) in vlogo tržnice. Ta zapis mora preživeti spremembe stopenj in konfiguracijske popravke. Nespremenljiva glavna knjiga z zaklepanjem obdobij, kar Nordlet uveljavlja na ravni API-ja, pomeni, da zaključenega meseca ni mogoče potihoma prepisati, da bi bila kasnejša revizija videti lepša.

Te tri zmožnosti predstavljajo osnovo. Vse ostalo, vključno z oddajo obračunov OSS, generiranjem i.SAF in usklajevanjem, sloni na tem.

Modeliranje odločitve o DDV, ne le stopnje

Najpogostejši vzorec napake pri vgrajenem računovodstvu je obravnavanje polja za davek na računu kot rezultata poizvedbe. To ni to. Je rezultat majhnega grafikona odločanja in ta grafikon je tisto, kar je treba shraniti.

Učinkovit model:

  1. Razvrstitev poslovnega partnerja. B2B ali B2C. V primeru B2B preverite ID za DDV prek sistema VIES in shranite odziv, vključno s časovnim žigom in statusom. V primeru B2C zajemite vsaj dva signala o lokaciji: naslov za izstavitev računa, IP ali geolokacijo in državo plačilnega sredstva, kjer je to na voljo.
  2. Določitev kraja obdavčitve. Pri digitalnih storitvah DDV sledi lokaciji stranke in ne dobavitelja. Pri blagu se pravila razlikujejo glede na izvor in cilj pošiljke. API mora označiti vsako postavko računa z izpeljanim krajem obdavčitve in uporabljenimi signali.
  3. Izbira ureditve. Domača, OSS (mednarodna B2C znotraj EU), IOSS (uvoz blaga manjše vrednosti) ali obrnjena davčna obveznost. Logiko pragov, zlasti prag mednarodne B2C prodaje digitalnih storitev v višini 10.000 EUR, je treba izračunati glede na tekoče okno (rolling window) in ne glede na posamezen račun izolirano.
  4. Določitev stopnje. Poiščite stopnjo države za davčno kategorijo na datum računa. Shranite uporabljeno različico razpredelnice stopenj.
  5. Knjiženje v glavno knjigo. Zapišite dvostavno transakcijo z DDV-jem za plačilo, razdeljenim po državah in ureditvah, tako da je mogoče pripraviti obračune OSS in domače obračune DDV brez ponovnega izpeljevanja podatkov.

Vsak korak mora biti opazljiv prek API-ja. Spletni kavlji, kot je sale_invoice.paid, omogočajo nadaljnjim sistemom odzivanje na spremembe stanj brez poizvedovanja (polling). Ključi za enkratnost (idempotency keys) preprečujejo podvojene vknjižbe v glavno knjigo, ko omrežni poskus zaporedja spodleti ob nepravem času. Nobeno od tega ni eksotično, vendar sta oboje nujno pri obsegu poslovanja platforme.

OSS, IOSS in prag 10.000 EUR

Za SaaS in digitalne storitve je praktični problem avtomatizacije OSS. Dobavitelj, ki prodaja mednarodno B2C znotraj EU, uporablja stopnjo svoje matične države, dokler v tekočem ali prejšnjem koledarskem letu ne preseže praga 10.000 EUR, nato pa uporablja stopnjo države članice prejemnice in četrtletno poroča prek sistema OSS. Praktični napotki o skladnosti z DDV za SaaS in digitalne storitve to opredeljujejo kot problem podatkovnega cevovoda in ne kot problem registracije.

Cevovod, ki ga mora računovodski API podpirati:

  • Spremljanje mednarodnih B2C prihodkov glede na prag na tekoči osnovi za vsako koledarsko leto.
  • Samodejni preklop določanja stopnje z matične države na ciljno državo ob preseganju praga, brez retroaktivnega popravljanja prejšnjih računov.
  • Združevanje transakcij po državah članicah, ureditvah in valutah za četrtletni obračun OSS.
  • Normalizacija zneskov v EUR na ustrezen tečajni datum za poročanje v OSS.
  • Izvoz niza podatkov, pripravljenega za obračun, v obliki, ki jo lahko poročevalec ali storitev za oddajo poročil obdela.

Nordlet to rešuje prek logike DDV po posameznih državah v glavni knjigi in poročanja, ki združuje podatke po ureditvah in državah članicah: obračuni OSS se izračunajo iz samih računov s popravki prejšnjih obdobij, prag 10.000 EUR pa se spremlja samodejno. Obračun se izpelje iz glavne knjige in se ne rekonstruira iz nič vsako četrtletje. To je bistvo postavitve grafikona odločanja znotraj računovodskega sistema namesto v ločeni preglednici.

IOSS sledi enakemu vzorcu za uvoz blaga manjše vrednosti, le z drugačnim naborom pragov in drugačnim obračunom.

Tržnice in tokovi platform predstavljajo svojo kategorijo

Obravnava tržnice kot običajnega kanala B2C je točka, kjer se zatakne pri presenetljivo velikem številu implementacij. V številnih scenarijih v EU je platforma tista, ki šteje kot dobavitelj (deemed supplier), in je odgovorna za obračun ter plačilo DDV. Lastno računovodstvo trgovca mora odražati, da je platforma in ne končni kupec tista stranka, ki je relevantna za DDV pri teh transakcijah.

Tu se vgrajeni računovodski API izkaže za nepogrešljivega. Platforma v trenutku prodaje ve, ali je delovala kot šteje kot dobavitelj. To dejstvo je treba zapisati v evidenco računa in ga prenesti v glavno knjigo, da knjige trgovca ne bi podvajale DDV-ja, ki ga je platforma že obdelala. Posredovanje kazalnikov davčne vloge prek API-ja in njihovo odražanje v poročilih je tista razlika med čistimi knjigami in usklajevanjem, ki se nikoli zares ne izide.

Za platforme, ki temeljijo na Nordletu, je to prvovrstna funkcija: računi nosijo vatScheme (vključno z marketplace_deemed) in zastavico deemedSupplier, razreševalnik obravnave pa vrne veljavno ureditev skupaj s pravno podlago po Direktivi 2006/112/ES. V kombinaciji s podporo za več podjetij lahko računovodstvo platforme in računovodstvo trgovca bivata pod istim API-jem z različnimi podjetji in vlogami, ne da bi prihajalo do uhajanja knjižb DDV med njima.

Kaj ViDA spreminja in česa ne

DDV v digitalni dobi (ViDA) spreminja obliko avtomatizacije iz »izračunaj in knjiži« v »izračunaj, knjiži in posreduj«. E-fakturiranje in poročanje davčnim organom v skoraj realnem času postaneta del cevovoda. To ne nadomešča računovodskega API-ja. Zaradi tega so strukturirani podatki o računu v računovodskem API-ju vir, ki se zrcali v prehodu za poročanje.

Dve praktični posledici:

  • Metapodatki računa morajo biti bogatejši, kot dovoljuje večina starejših shem. Polja Peppol BIS 3.0, strukturirana razčlenitev DDV na postavko in identifikatorji ureditev morajo biti prvovrstni elementi v računovodskem API-ju, ne pa dodani kot opombe v prostem besedilu.
  • Računovodski dokument in poročani dokument morata ostati usklajena. Če je izdani dobropis, mora prehod za poročanje videti popravek z istimi identifikatorji. Nespremenljive glavne knjige in jasen izvor dokumentov to naredijo preprosto. Ohlapno knjigovodstvo pa to otežuje.

Priprava na ViDA je manj v novem funkcionalnostih in bolj v zaostritvi discipline tistega, kar že obstaja.

Kratek primerjalni pregled pristopov avtomatizacije

Pristop Dokazilo o odločitvi o DDV Obravnava OSS/IOSS Modeliranje vloge tržnice Primernost za vgrajene platforme
Ročno knjigovodstvo s preglednicami Šibko, rekonstruirano za nazaj Ročno, nagnjeno k napakam Običajno prezrto Slabo
Stara računovodska programska oprema z dodatki Delno, pogosto zunaj glavne knjige Podprto, vendar osamljeno v silosih Omejeno Slaba do zmerna
Generični računovodski API (tipa Xero, QuickBooks) Odvisno od discipline integracije Razlikuje se glede na trg in dodatke Ni javno potrjeno za tokove s šteje kot dobavitelj v EU Zmerna
Nordlet (prvi API, osredotočen na EU) Nespremenljiva glavna knjiga, metapodatki DDV, zaklepanje Izvorno po državah, i.SAF, VIES, združevanje za OSS Prvovrstno: vatScheme, deemedSupplier na račun Močna

Tabela odraža vnose, ki so na voljo za ta članek. Kjer zmogljivost tekmeca ni dokumentirana v raziskovalnem poročilu, je ostala kot javno nepotrjena, namesto da bi bila privzeta.

Kaj najprej zgraditi, če šele začetka

Če ekipa postavlja vgrajeno avtomatizacijo DDV v EU na računovodskem API-ju, je zaporedje, ki običajno prihrani največ ponovnega dela, naslednje:

  1. Preden karkoli drugega modelirajte partnerja in njegove signale o državi. Vsaka nadaljnja odločitev je odvisna od tega. Shranite signale, ne le izpeljane države.
  2. Zgradite sloj davčnih kategorij. Povežite izdelke in storitve s kategorijami. Povežite kategorije s kodami držav. Nikoli ne povezujte izdelkov neposredno s stopnjami.
  3. Povežite preverjanje VIES s predpomnjenjem in čakalno vrsto za pregled. Ne dovolite, da bi dostopnost storitve VIES blokirala vaš nakupni postopek.
  4. Oddajajte in prejemajte spletne kavlje za spremembe stanja računa. Uporabite ključe za enkratnost pri vsakem pisanju.
  5. Zaklenite obdobja takoj, ko se zaključijo. Uveljavite to v API-ju, ne v pravilniku.
  6. Izpeljite obračune OSS iz glavne knjige. Če obračun potrebuje ločeno preglednico, glavna knjiga ne nosi dovolj metapodatkov.
  7. Šele nato dodajte integracijo z e-fakturiranjem in prehodom za poročanje. Vstopni podatki morajo biti najprej pravilni.

Večina teh korakov je enkratna naložba, ki se tiho povrne vsako četrtletje. Neomejeno razvijalsko okolje (sandbox) je najcenejše mesto za dokazovanje tega zaporedja od začetka do konca.

FAQ

Ali je preverjanje VIES dovolj, da se dokaže, da je bila B2B prodaja pravilno obdavčena z ničelno stopnjo?

Samo po sebi ne. VIES potrjuje, da je ID za DDV veljaven v določenem trenutku. Revizijsko obranljiv zapis vključuje tudi časovni žig preverjanja, vsebino odziva, navedeno državo stranke ter dokaz, da je bilo blago ali storitev dobavljena temu zavezancu za DDV. Vse to shranite skupaj z računom.

Lahko se platforma zanese na tržnico glede obravnave DDV in preskoči svojo lastno logiko?

Samo za tiste specifične transakcije, kjer tržnica nastopa kot šteje kot dobavitelj v skladu s pravili EU. Računovodstvo trgovca mora še vedno pravilno odražati te transakcije, vsa prodaja zunaj tega obsega, vključno z neposredno prodajo in B2B tokovi, pa ostaja odgovornost trgovca. Varneje je, da vlogo eksplicitno modelirate za vsako transakcijo posebej.

Kako pogosto se stopnje DDV v EU dejansko spremenijo, da bi to sploh štelo?

Dovolj pogosto, da trdo kodirane stopnje povzročajo resne težave. Kategorije znižanih stopenj se premikajo, uvajajo se začasne stopnje, ki potečejo, pojavljajo pa se tudi nova pravila držav članic. Vsebinski sloj stopenj z veljavnimi datumi ni pretirano inženirstvo. Je osnovni standard.

Kakšna je razlika med OSS in IOSS v praksi?

OSS pokriva čezmejno B2C prodajo blaga in digitalnih storitev znotraj EU, o čemer se poroča četrtletno prek ene države članice. IOSS pokriva uvoz blaga manjše vrednosti v EU, običajno blago za potrošnike pod 150 EUR. Oboje izhaja iz istih računovodskih podatkov, če glavna knjiga označuje vsako transakcijo z ustrezno ureditvijo.

Ali nespremenljiva glavna knjiga pomeni, da so popravki nemogoči?

Ne. Popravki se izvajajo prek novih vknjižb in ne z urejanjem starih. Dobropis stornira račun, stornirna vknjižba pa popravi napačen zapis. Tisto, kar nespremenljivost preprečuje, je tiho prepisovanje zgodovine, kar je natanko tisto vedenje, ki ga revizorji iščejo.

Nadaljnje branje