Nordlet

← Blog

Automating Per-Country VAT Reporting and VIES Validation

A practical guide for developers embedding EU VAT compliance into marketplaces and platforms using a cloud accounting API.

Nordlet Team · · 12 min čitanja

Većina pogrešaka vezanih uz PDV u programskom kodu platformi svodi se na jednu pretpostavku: da valjani ishod provjere preko sustava VIES znači da primjenjujete stopu od 0 % na prodaju. To nije slučaj, a gradnja rješenja na temelju tog prečaca proizvodi obrasce koji izgledaju uredno sve dok revizor ne zatraži objašnjenje zašto je primijenjeno oslobođenje unutar EU-a bez dokaza o prijevozu ili usklađenog zapisa o mjestu isporuke. Jaz između stanja „PDV broj je u redu” i „ova se isporuka ispravno tretira” jest mjesto gdje većina integracija tiho krene u krivom smjeru.

Ovaj vodič opisuje kako automatizirati izvještavanje o PDV-u po državama i VIES provjeru pomoću API-ja za računovodstvo u oblaku, koristeći Nordletov API za računovodstvo kao kontekst implementacije. Cilj je sustav koji prikuplja ispravne dokaze u trenutku prodaje, knjiži nepromjenjive stavke glavne knjige i proizvodi podatke spremne za obrasce grupirane prema shemi i državi članici, bez naknadnog rekonstruiranja zbrojeva u proračunskim tablicama.

Što VIES zapravo pokazuje, a što ne

VIES je sustav Europske komisije za razmjenu informacija o PDV-u (EU VAT Information Exchange System). Kada unesete šifru države i PDV broj, sustav u stvarnom vremenu pretražuje relevantnu nacionalnu bazu podataka i vraća informaciju je li taj PDV podatak valjan ili nevaljan. To je cijeli opseg. Sustav potvrđuje da je broj registriran i, u onim državama članicama koje to podržavaju, aktiviran za trgovinu unutar EU-a.

VIES ne utvrđuje pravo na oslobođenje od plaćanja PDV-a za isporuku unutar Zajednice. Europska komisija o tome govori posve jasno. Valjani odgovor sustava VIES samo je jedan dokaz među mnogima. I dalje morate potvrditi da je kupac stvarni primatelj, da isporuka ispunjava uvjete za isporuku unutar EU-a, da postoje dokazi o prijevozu ili otpremi te da račun sadrži propisanu napomenu o prijenosu porezne obveze (reverse-charge).

Stoga je prva odluka pri dizajnu strukturne prirode: držite status u sustavu VIES i tretman PDV-a u odvojenim poljima. Nikada nemojte povezivati vrijednost viesStatus: valid izravno s zeroRated: true. Onog trenutka kada spojite te dvoje u jedno, gubite mogućnost obrane određenog tretmana kada se postavi pitanje dokaza.

Preduvjeti prije pisanja integracijskog koda

Prije pozivanja bilo koje krajnje točke (endpoint), definirajte opseg onoga o čemu izvještavate. Ovaj je dio dosadan, a preskakanje tog koraka skupo.

  • U kojim je državama tvrtka poslovno nastanjena ili ima stalne poslovne jedinice
  • U kojim državama posjeduje registracije za PDV
  • Prodaje li dobra, usluge, digitalne usluge ili njihovu kombinaciju
  • Jesu li transakcije B2B, B2C ili oboje
  • Koristi li domaće registracije, OSS, IOSS, prijenos porezne obveze (reverse-charge) ili pravila prema kojima se tržnica (marketplace) smatra isporučiteljem
  • Koje izlaze API mora proizvesti: podatke za domaće obrasce, OSS/IOSS podatke, registre računa poput litavskog i.SAF-a, samo knjiženja u glavnoj knjizi ili pakete podataka za zasebnog davatelja usluga predaje obrazaca

To je važno jer sustav OSS ne obuhvaća svaku transakciju. Usluge isporučene u državi u kojoj tvrtka ima poslovni nastan općenito spadaju u domaći obrazac te države, a ne u OSS obrazac. Poslovne nastane modelirajte zasebno od samog početka jer ćete inače pogrešno usmjeriti te isporuke u trenutku agregacije.

Nemojte fiksno upisivati ni jednu stopu PDV-a po državi. EU poznaje standardne, snižene, super-snižene, prijelazne (parking), nulte i specifične stope prema vrsti proizvoda, a one se mijenjaju. Pouzdan izvor za određeni proizvod u određenoj državi članici jest porezna uprava te zemlje, dok TEDB Europske komisije nudi pregled za više država. Zabilježite izvor i verziju svake odluke o stopi kako naknadno ažuriranje tablice stopa ne bi tiho promijenilo izgled stare transakcije.

Modeliranje porezne odluke, a ne samo stope

Srž dugovječne integracije jest sloj poreznih kategorija koji se nalazi između proizvoda i stopa. Povežite proizvode s kategorijama, kategorije s poreznim šiframa specifičnima za pojedinu državu, a zatim sa stopama koje imaju važeći vremenski rok primjene:

proizvod/usluga
    → porezna kategorija
    → porezna šifra specifična za državu
    → stopa i tretman s definiranim datumom važenja

Nesigurna verzija koja dovodi do odstupanja u izvještavanju jest SKU proizvoda → PDV od 21 %. Isti proizvod nosi različite stope u različitim državama, a stopa se može promijeniti usred razdoblja. Nordletove vlastite smjernice za usklađenost s PDV-om preporučuju upravo ovakvo mapiranje temeljeno na kategorijama umjesto izravnog vezivanja proizvoda uz postotke.

Vaša taksonomija poreznih kategorija treba biti stabilna i interna: dobra po standardnoj stopi, dobra po sniženoj stopi, usluge elektroničkim putem, obične usluge, oslobođena isporuka, isporuka sa stopom od 0 %, B2B prijenos porezne obveze unutar EU-a, prodaja na daljinu unutar EU-a, uvoz putem sustava IOSS, transakcija u kojoj se tržnica smatra isporučiteljem. Sve što se nalazi dalje u lancu oslanja se na ovu taksonomiju.

VIES provjera kao asinkroni radni proces za prikupljanje dokaza

Službena VIES usluga nudi SOAP/WSDL sučelje koje prihvaća dvoslovnu oznaku države i PDV broj. Njezine dokumentirane pogreške važne su za obradu iznimaka: nevaljani unosi, globalna ograničenja istovremenih upita i ograničenja po državama članicama, nedostupnost usluge, nedostupnost sustava pojedine države članice te isteci vremena (timeouts). Promatrajte ih kao zasebne ishode, a ne kao jednu zajedničku skupinu "neuspjelih" upita.

Radni proces koji pouzdano funkcionira pod opterećenjem i tijekom revizije izgleda ovako:

  1. Normalizirajte PDV ID: pretvorite prefiks u velika slova, uklonite dozvoljene razmake ili znakove interpunkcije te zasebno sačuvajte izvornu vrijednost koju je unio korisnik.
  2. Lokalno provjerite šifru države i strukturu broja prije slanja mrežnog poziva.
  3. Pošaljite normalizirani broj u sustav VIES.
  4. Pohranite normalizirani ID, vremenske oznake zahtjeva i odgovora, status valjanosti (valjan/nevaljan/nije obrađeno), izvorni odgovor, svaku pogrešku usluge, ID-jeve kupca i računa te odluku aplikacije.
  5. Predmemorirajte (cache) uspješne rezultate za definirano, dokumentirano razdoblje.
  6. Ponovite prolazne tehničke pogreške uz postupno povećanje razmaka između pokušaja (backoff).
  7. Neriješene ili proturječne slučajeve usmjerite na ručnu provjeru.
  8. Ponovno provjerite kada je predmemorirani rezultat zastario ili prije transakcije u kojoj je taj dokaz ključan.

Nordlet provjerava EU PDV broj kada se kupac dodaje te ga ponovno provjerava prije fakturiranja ako je prethodni rezultat zastario, što je ponašanje koje želite ponoviti bez obzira na to provodi li se provjera unutar platforme ili u vašem vlastitom kodu.

Ključno pravilo: nemojte postupak naplate (checkout) činiti sinkronim sa sustavom VIES. Prekid rada usluge nije isto što i nevaljani broj. Ako VIES istekne tijekom prodaje, zadržite transakciju na provjeri ili joj dodijelite privremeni status. Blokiranje naplate zbog nedostupnosti sustava Europske komisije stvara upite korisničkoj podršci, a pogrešno označavanje dobrog kupca nevažećim još je gore.

Odvajanje statusa provjere od poreznog tretmana

Kada dobijete rezultat iz sustava VIES, mehanizam za donošenje odluka ima još posla. Pohranite sljedeće podatke u obliku zasebnih polja:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

Prije primjene prijenosa porezne obveze ili oslobođenja, mehanizam treba provjeriti je li kupac doista primatelj, jesu li država kupca i PDV prefiks usklađeni, ispunjava li isporuka uvjete za transakciju unutar EU-a, primjenjuju li se posebna pravila o mjestu isporuke, postoje li dokazi o prijevozu, djeluje li prodavatelj kao isporučitelj za kojeg se smatra da je obavio isporuku (deemed supplier) te sadrži li račun potrebnu napomenu. Valjani VIES status koji ne prolazi nijedan od ovih drugih testova nije zeleno svjetlo.

Stvaranje nepromjenjive porezne odluke u trenutku izdavanja računa

Kada se račun kreira, uz njega pohranite cjelovitu odluku, a ne samo konačnu stopu:

račun
  ├─ porezna kategorija stavke
  ├─ mjesto isporuke
  ├─ shema PDV-a
  ├─ stopa specifična za državu
  ├─ verzija tablice stopa
  ├─ referenca na VIES dokaz
  ├─ reference na dokaze o lokaciji
  ├─ referenca na pravnu osnovom
  └─ oznake uloge tržnice

Pravila EU-a o računima zahtijevaju podatke o isporučitelju i kupcu, broj računa, opis, oporezivi iznos, stopu PDV-a, iznos PDV-a te sve informacije o prijenosu porezne obveze ili oslobođenju. Odobrenja (credit notes) i ispravci trebaju imati jasnu i nedvosmislenu referencu na izvorni račun.

Nordletova glavna knjiga je nepromjenjiva (immutable), stoga se ispravci provode kroz nove stavke poput odobrenja ili storno knjiženja, umjesto uređivanja zaključanih zapisa. Svoj sustav prilagodite tom modelu, čak i ako vam pohrana tehnički omogućuje prepisivanje. Uređivanje zaključanog računa uništava poveznicu između izvorne prijave i ispravka, što je upravo onaj slijed koji revizor prati.

Knjiženje, webhookovi i idempotencija

Prodaja generira dvostruka knjigovodstvena knjiženja koja čuvaju i komercijalnu transakciju i obvezu za PDV raspodijeljenu po državama i shemama. Domaća prodaja može se knjižiti ovako:

Duguje: Potraživanja od kupaca / klring plaćanja
    Potražuje: Prihodi
    Potražuje: Obveze za PDV - DE - domaći

Prodaja unutar EU-a s B2B prijenosom porezne obveze knjiži prihod bez izlaznog PDV-a i s referencom na dokaz o prijenosu porezne obveze. Točan kontni plan ovisi o vama; važno je da dimenzije izvještavanja ostanu pridružene svakom knjiženju: država članica, shema, porezna kategorija, stopa, razdoblje, izvorni račun i slijed ispravaka.

Promjene stanja pokrećite putem webhookova umjesto periodičnog ispitivanja (polling). Nordlet emitira događaje poput sale_invoice.paid, potpisuje isporuke i ponovite slanje uz postupno povećanje razmaka (backoff). Svakom pisanju dodijelite deterministički ključ idempotencije:

sale:{platform_order_id}:invoice:{invoice_version}

Vaš potrošač (consumer) također mora biti idempotentan. Webhook može stići dvaput, zakasniti ili se aktivirati nakon što je izvorni zahtjev već uspješno izvršen. Provjerite potpise, zabilježite ID-jeve događaja, izdvojite nepravilno oblikovane događaje u karantenu, obradite ih kroz trajnu redoslijednu strukturu (durable queue) i redovito usklađujte stanje webhookova s API-jem. Ako niste prije radili s potpisanim webhookovima i ključevima idempotencije, ovdje se nalaze najsuptilnije pogreške s dvostrukim knjiženjima.

Grupiranje za OSS i izrada podataka spremnih za obrasce

Za prihvatljive OSS transakcije, grupirajte podatke iz glavne knjige prema shemi, državi članici potrošnje, vrsti isporuke, kategoriji stope, stopi, oporezivom iznosu, iznosu PDV-a, državi članici otpreme ili poslovnog nastana, valuti i razdoblju ispravka.

Obrazac unije za OSS odvaja isporuke po državama članicama potrošnje i razlikuje usluge iz države članice identifikacije, usluge iz drugih stalnih poslovnih jedinica te dobra otpremljena iz različitih država članica. Oporezive iznose i iznose PDV-a izvještava odvojeno za standardne i snižene stope. Oslobođene isporuke i isporuke sa stopom od 0 % u potpunosti izbivaju iz OSS obrasca.

Nekoliko operativnih detalja na koje ljudi često naiđu:

  • Razdoblja za OSS Unije i izvan Unije su tromjesečna; za IOSS razdoblje je mjesečno. Obrasci i plaćanje dospijevaju do kraja sljedećeg mjeseca.
  • Obrazac s nultim iznosom obvezan je za svako razdoblje, čak i ako nisu obavljene relevantne isporuke. Generirajte kontrolni popis razdoblja i automatski kreirajte obrazac s nultom vrijednošću.
  • OSS obrasci podnose se u eurima, primjenjujući referentni tečaj ESB-a na posljednji dan poreznog razdoblja kada je potrebna konverzija. Pohranite izvornu valutu, tečaj, datum tečaja, konvertirani iznos i metodu.

Izvozi bi trebali dolaziti iz zaključane glavne knjige, nikada iz pomoćne proračunske tablice. Zbrojevi u proračunskim tablicama gube ispravke, države otpreme, stope i dokaze. Izvoz sadrži razdoblje izvještavanja, shemu, državu članicu potrošnje, državu otpreme, kategoriju isporuke, stopu, oporezive iznose i iznose PDV-a, valutu i primijenjeni tečaj, iznose ispravaka za tekuće i prethodno razdoblje, ID-jeve izvornih računa, reference na odobrenja i zbrojeve za usklađivanje.

Budite precizni u pogledu toga što API ovdje isporučuje. Nordlet računa OSS i IOSS obrasce na temelju računa i glavne knjige, uključujući ispravke za prethodna razdoblja, šalje pakete domaćih obrazaca za Litvu (FR0600), Njemačku (UStVA) i Poljsku (JPK_V7M), te generira i.SAF registre spremne za VMI u Litvi. To su podatci spremni za obrasce. Jedan API poziv ne predaje PDV obrazac svake države kroz svaki nacionalni pristupnik (gateway), niti se ijedan obrazac predaje nadležnom tijelu u vaše ime. Računovodstvo, generiranje obrazaca, izvoz, predaju preko pristupnika i potvrdu plaćanja držite kao odvojena stanja u svom sustavu. Vodič kroz EU PDV mehanizam dokumentira koje slučajeve mehanizam rješava i gdje se aktiviraju njegova upozorenja.

Zaključavanje razdoblja

Nakon pregleda i odobrenja, uskladite račune sa stavkama glavne knjige, uskladite stanja PDV-a u glavnoj knjizi sa skupom podataka za obrazac, izvezite obrazac, zabilježite reference prijave i plaćanja, a zatim zaključajte razdoblje. Nordlet blokira knjiženja u zaključani mjesec, uključujući ona putem API-ja. Ispravci nakon zaključavanja ulaze u kasniji razdoblje s izričitim poveznicama na izvorni dokument i pogođeno razdoblje izvještavanja.

Uobičajeni načini neuspjeha i kako ih izbjeći

Način neuspjeha Zašto se događa Mjera ublažavanja
Smatranje valjanog VIES rezultata dovoljnim za primjenu stope 0 % VIES ne utvrđuje prava na oslobođenje Pohranite dokaze o kupcu, isporuci, prijevozu i računu uz sam rezultat
Smatranje nevaljanog rezultata dokazom nepostojanja registracije Broj možda nije aktiviran za trgovinu unutar EU-a ili baza podataka kasni Razlikujte nevaljani status, status "nije obrađeno" i tehnički kvar; sporove usmjerite na pregled
Učiniti naplatu sinkronom sa sustavom VIES Ograničenja istovremenih upita, isteci vremena, prekidi rada Asinkrona provjera, kratkotrajno predmemoriranje, ponovni pokušaji s odgodom, privremena stanja
Zauvijek predmemorirati rezultate Status registracije i aktivacije se mijenja Pohranite vremenske oznake i rok valjanosti; ponovno provjerite prije fakturiranja ako je zastarjelo
Izravno mapiranje proizvoda na postotke PDV-a Stope i oslobođenja ovise o državi i datumu Proizvod u kategoriju, kategorija u šifru države, šifra države u važeću stopu
Rekonstruiranje OSS-a iz proračunskih tablica Zbrojevi ispuštaju ispravke, države otpreme, dokaze Izvedite iz nepromjenjive glavne knjige s dimenzijama na svakom knjiženju
Uključivanje usluga domaćih poslovnih jedinica u OSS Određene usluge spadaju u domaći obrazac Modelirajte poslovne nastane odvojeno, usmjerite prema shemi prije agregacije
Izostavljanje obrazaca s nultim iznosom OSS zahtijeva obrazac u svakom razdoblju Generirajte kontrolni popis i automatski kreirajte obrasce s nultom vrijednošću
Uređivanje zatvorenih računa radi ispravka Uništava poveznicu između prijave i ispravka Koristite odobrenja i storno knjiženja u kasnijem razdoblju

Što bismo učinili najprije

Kada bismo sutra započinjali ovu integraciju, prvo bismo izgradili sloj poreznih kategorija i zapis o poreznoj odluci prije nego što dotaknemo ijednu krajnju točku za izvještavanje. Učinite taksonomiju stabilnom, povežite proizvode s kategorijama i osigurajte da zapis o odluci bilježi izvorne signale države uz razlog odabira mjesta isporuke. Sve ostalo - VIES, knjiženje, OSS grupiranje, izvoz - ovisi o tome je li taj model ispravan.

Zatim bismo povezali VIES kao asinkroni korak provjere s četiri odvojena stanja i pokrenuli ga nad testnom tvrtkom (sandbox company) uz pripremljene slučajeve za nezgodne situacije (isteci vremena, neobrađeni rezultati, nepodudarni prefiksi) prije nego što ga pustimo u proizvodnu okolinu. Gore navedeni načini neuspjeha gotovo su u potpunosti izbivi ako podatkovni model prenosi dokaze i dimenzije izvještavanja od prvog knjiženja.

FAQ

Znači li valjani VIES odgovor da mogu primijeniti stopu od 0 % na B2B prodaju unutar EU-a?

Ne. VIES potvrđuje da je PDV broj registriran i, gdje je to podržano, aktiviran za trgovinu unutar EU-a. Pravo na oslobođenje od plaćanja PDV-a za isporuku unutar Zajednice ovisi o dodatnim dokazima: činjenici da je kupac stvarni primatelj, dokazima o prijevozu ili otpremi, ispravnom mjestu isporuke i obveznoj napomeni na računu. Pohranite rezultat sustava VIES kao jedan od ulaznih podataka, a ne kao samu odluku.

Treba li VIES provjera blokirati naplatu (checkout)?

Ne bi trebala. VIES može isteći ili dosegnuti ograničenja istovremenih upita, a prekid rada nije isto što i nevaljani broj. Provjerite asinkrono, predmemorirajte uspješne rezultate za dokumentirano razdoblje, ponovite prolazne pogreške i zadržite dvosmislene slučajeve na provjeri s privremenim stanjem umjesto da rušite prodaju.

Može li API za računovodstvo u oblaku automatski predati moje PDV obrasce?

On može generirati podatke spremne za obrasce, grupirane prema shemi i državi članici, izračunate iz nepromjenjive glavne knjige s uračunatim ispravcima. Hoće li ti podaci biti predani kroz svaki nacionalni pristupnik za predaju ovisi o proizvodu i državi. Nordlet računa OSS i IOSS obrasce, šalje pakete domaćih obrazaca za Litvu, Njemačku i Poljsku te generira i.SAF registre spremne za VMI u Litvi, ali ne predaje ništa poreznoj upravi u vaše ime. Računovodstvo, generiranje obrazaca, izvoz, predaju preko pristupnika i plaćanje tretirajte kao odvojena stanja umjesto da pretpostavljate kako jedan poziv predaje obrazac svugdje.

Kako da obradim ispravke nakon što je razdoblje zaključano?

Knjižite ih u naknadnom razdoblju s izričitim poveznicama na izvorni dokument i pogođeno razdoblje izvještavanja. Nordlet blokira nova knjiženja u zaključani mjesec, uključujući ona putem API-ja, stoga ispravci prolaze kroz odobrenja ili storno knjiženja umjesto izravnog uređivanja. Time se čuva slijed između izvorne prijave i naknadnog prilagođavanja.

Dodatna literatura