Automatizacija usklađenosti s PDV-om u EU-u pomoću API-ja za računalovodstvo u oblaku

Praktičan vodič za platforme i internetske trgovine kojima su potrebne uredne poslovne knjige, ispravan PDV i revizijski trag koji je valjan i godinama kasnije.

PDV u EU-u više nije problem izračuna. To je problem dokazivanja. Stope su javno objavljene, pragovi su poznati, a OSS obrasci su dobro dokumentirani. Ono što dovodi do pada u revizijama i što narušava rad platformi u velikom obujmu jest nemogućnost rekonstrukcije načina na koji je donesena određena odluka o PDV-u na konkretnom računu, uz primjenu pravila i ulaznih podataka koji su postojali u tom trenutku. API za računalovodstvo u oblaku može ovo automatizirati od početka do kraja, ali samo ako je dizajniran oko grafa odlučivanja, a ne samo oko same stope.

Ta razlika definira sve što je navedeno u nastavku.

Što zapravo znači „automatizacija PDV-a u EU-u”

Za platformu koja vrši prodaju u više država članica EU-a, automatizacija PDV-a predstavlja niz međusobno povezanih odluka:

Je li kupac poslovni subjekt (B2B) ili krajnji potrošač (B2C) i gdje se nalazi?
Koja se stopa i koja porezna kategorija primjenjuje prema državi kupca na datum izdavanja računa?
Je li riječ o prijenosu porezne obveze (reverse charge), prijavi kroz OSS, prijavi kroz IOSS ili tuzemnoj isporuci?
Je li internetska trgovina (marketplace) smatrana isporučiteljem (deemed supplier) ili je to bio trgovac?
Koji dokazi potkrepljuju svaki od tih odgovora i mogu li se oni naknadno ponoviti?

Automatizacija iznosa bez automatizacije same argumentacije dovodi do klasičnog revizorskog propusta: iznosi su točni, ali nema obranjivog traga. Suvremeni porezni sustavi sve se više fokusiraju na dokazne tragove spremne za reviziju i povijesni pregled stopa upravo zato što se inspekcijski nadzor danas usredotočuje na način na koji je donesena odluka o PDV-u, a ne samo na njezin rezultat.

API za računalovodstvo u oblaku prirodno je mjesto za pohranu tog traga jer već pohranjuje račun, knjižni stavak i poslovnog partnera. Nordlet je izgrađen oko ove ideje: nepromjenjiva (immutable) dvojna knjigovodstvena evidencija, logika PDV-a prilagođena pojedinim državama, VIES provjera i generiranje i.SAF obrazaca, a sve to dostupno je putem jedinstvenog REST sučelja s tipiziranim SDK-ovima i webhookovima. API nije tek tanka ovojnica iznad klasičnog knjigovodstva. On je sustav zapisa za samu odluku.

Tri mogućnosti API-ja koje nose najveći teret

Većina posla oko automatizacije PDV-a svodi se na tri mogućnosti koje računalovodstveni API mora besprijekorno podržavati.

1. Sadržaj stopa i porezne kategorije povezane s datumom. Stope se mijenjaju. Kategorije se mijenjaju. Snižene stope se uvode i ukidaju. Održiv pristup, kako navodi Sage u svojim uputama za razvojne inženjere o reformi EU PDV-a i računovodstvenim API-jevima, jest mapiranje artikala u porezne kategorije, a zatim mapiranje poreznih kategorija na šifre specifične za pojedinu državu s definiranim datumima primjene. Hardkodiranje stope po artiklu za svaku pojedinu državu jest pogrešan obrazac ponašanja koji se tiho gomila sve dok promjena stope ne sruši sustav godinu dana kasnije.

2. Provjera PDV ID broja uz prilagođeno rješavanje pogrešaka (graceful degradation). VIES je mjerodavan izvor za prekograničnu B2B provjeru. Istodobno, povremeno zna biti nestabilan. Razumne implementacije predmemoriraju (cache) provjere s kratkim TTL-ovima, ponavljaju upite u slučaju kvara i usmjeravaju dvosmislene slučajeve u red za ručnu provjeru umjesto da blokiraju prodaju. Pretpostavka da VIES mora sinkrono uspjeti za svaku pojedinu transakciju uzrokuje situacije u kojima si platforme same stvaraju prekide u radu.

3. Prikupljanje dokaza i nepromjenjivost podataka. Svaka odluka o PDV-u trebala bi pohraniti svoje ulazne podatke: signale o lokaciji kupca, PDV ID broj i vremensku oznaku (timestamp) provjere, poreznu kategoriju, verziju tablice stopa, primjenjivi postupak (tuzemni, OSS, IOSS, prijenos porezne obveze) i ulogu internetske trgovine. Taj zapis mora preživjeti promjene stopa i izmjene postavki. Nepromjenjiva glavna knjiga sa zaključavanjem razdoblja, koju Nordlet nameće na razini API-ja, znači da se zaključeni mjesec ne može tiho naknadno prepraviti kako bi kasnija revizija izgledala urednije.

Te tri mogućnosti čine osnovu. Sve ostalo, uključujući OSS prijave, generiranje i.SAF datoteka i usklađivanje, nalazi se povrh toga.

Modeliranje odluke o PDV-u, a ne samo stope

Najčešći uzrok pogreške u ugrađenom računovodstvu jest tretiranje polja za porez na računu kao pukog rezultata pretraživanja. To ono nije. To je rezultat malog grafa odlučivanja, i upravo taj graf treba pohraniti.

Održiv model izgleda ovako:

Klasificirajte poslovnog partnera. B2B ili B2C. Ako je B2B, provjerite PDV ID broj putem VIES sustava i pohranite odgovor, uključujući vremensku oznaku i status. Ako je B2C, prikupite najmanje dva signala o lokaciji: adresu za naplatu, IP adresu ili geolokaciju te državu iz koje dolazi sredstvo plaćanja, ako je dostupna.
Utvrdite mjesto isporuke. Kod digitalnih usluga PDV prati lokaciju kupca, a ne isporučitelja. Kod robe se pravila razlikuju ovisno o polazištu i odredištu pošiljke. API bi svaku stavku računa trebao označiti izvedenim mjestom isporuke i korištenim signalima.
Odaberite porezni postupak. Tuzemni, OSS (prekogranični B2C unutar EU-a), IOSS (uvoz male vrijednosti) ili prijenos porezne obveze. Logiku praga, osobito prekogranični B2C prag od 10.000 EUR za digitalne usluge, potrebno je izračunavati na temelju pokretnog vremenskog okvira (rolling window), a ne promatrajući samo trenutni račun izolirano.
Odredite stopu. Pronađite stopu određene države za traženu poreznu kategoriju na datum izdavanja računa. Pohranite verziju korištene tablice stopa.
Proknjižite u glavnu knjigu. Zabilježite stavku dvojnog knjigovodstva s PDV-om koji se duguje razdvojenim po državama i postupcima, kako bi se OSS obrasci i domaće prijave PDV-a mogli generirati bez ponovnog izračunavanja podataka.

Svaki korak trebao bi biti vidljiv putem API-ja. Webhookovi kao što je sale_invoice.paid omogućuju nizvodnim sustavima da reagiraju na promjene stanja bez potrebe za stalnim slanjem upita (polling). Ključevi za idempotentnost (idempotency keys) sprečavaju dupliranje knjiženja u glavnoj knjizi ako se ponovni pokušaj slanja putem mreže dogodi u krivom trenutku. Nijedno od ovoga nije egzotično, ali su oboje neophodni u razmjerima poslovanja jedne platforme.

OSS, IOSS i prag od 10.000 EUR

Za SaaS i digitalne usluge, praktičan problem automatizacije jest OSS. Isporučitelj koji obavlja prekograničnu B2C prodaju unutar EU-a primjenjuje stopu svoje matične države sve dok ne prijeđe prag od 10.000 EUR u tekućoj ili prethodnoj kalendarskoj godini, nakon čega primjenjuje stopu države članice kupca i izvještava tromjesečno putem OSS-a. Praktične upute o usklađenosti s PDV-om za SaaS i digitalne usluge definiraju ovo kao problem podatkovnog cjevovoda (data pipeline), a ne kao problem registracije.

Cjevovod koji računalovodstveni API mora podržavati:

Praćenje prekograničnog B2C prihoda u odnosu na prag na temelju klizećeg razdoblja, po kalendarskoj godini.
Automatsko prebacivanje utvrđivanja stope s matične države na državu odredišta kada se prag prijeđe, bez retroaktivnog mijenjanja prethodnih računa.
Grupiranje transakcija po državi članici, postupku i valuti za tromjesečnu OSS prijavu.
Normalizaciju iznosa u EUR prema odgovarajućem tečaju na datum utvrđivanja tečajnih razlika za OSS izvještavanje.
Izvoz skupa podataka spremnog za prijavu u formatu koji sustav za predaju obrazaca ili servis za izvještavanje može prihvatiti.

Nordlet rješava ovaj izazov putem logike PDV-a specifične za svaku državu unutar glavne knjige i izvještavanja koje grupira podatke po postupcima i državama članicama: OSS obrasci se izrađuju izravno iz računa, uz korekcije za prethodna razdoblja, a prag od 10.000 EUR prati se automatski. Obrazac se izvodi iz glavne knjige, umjesto da se iznova rekonstruira svako tromjesečje. To je i poanta postavljanja grafa odlučivanja unutar računovodstvenog sustava umjesto u zasebnoj proračunskoj tablici (spreadsheet).

IOSS slijedi isti obrazac za uvoz male vrijednosti, uz drugačiji skup pragova i drukčiju prijavu.

Tokovi na platformama i u internetskim trgovinama posebna su kategorija

Tretiranje internetske trgovine (marketplace) kao običnog B2C kanala pogreška je koju čini iznenađujući broj implementacija. U mnogim scenarijima unutar EU-a, platforma se smatra isporučiteljem (deemed supplier) te je odgovorna za obračun i naplatu PDV-a. Vlastito računovodstvo trgovca mora odražavati činjenicu da je platforma, a ne krajnji kupac, suprotna strana relevantna za PDV kod tih transakcija.

Ovdje ugrađeni računalovodstveni API u potpunosti opravdava svoju vrijednost. Platforma u trenutku prodaje zna je li djelovala u svojstvu isporučitelja koji se smatra obveznikom. Tu činjenicu treba upisati u zapis računa i prenijeti je u glavnu knjigu kako poslovne knjige trgovca ne bi dvaput obračunale PDV koji je platforma već podmirila. Prosljeđivanje pokazatelja porezne uloge kroz API i njihovo prikazivanje u izvještajima čini razliku između urednih poslovnih knjiga i usklađivanja koje se nikako ne može svesti na nulu.

Za platforme koje se grade na Nordletu, ovo je podržano kao temeljna mogućnost: računi nose atribut vatScheme (uključujući marketplace_deemed) i zastavicu deemedSupplier, a rješavač postupaka (treatment resolver) vraća primjenjivi postupak zajedno s njegovom pravnom osnovom prema Direktivi 2006/112/EZ. U kombinaciji s podrškom za više kompanija (multi-company support), računovodstvo platforme i računovodstvo trgovca mogu postojati unutar istog API-ja, s različitim tvrtkama i različitim ulogama, bez curenja knjiženja PDV-a između njih.

Što ViDA mijenja, a što ne mijenja

Direktiva o PDV-u u digitalnom dobu (ViDA) mijenja oblik automatizacije s modela „izračunaj i proknjiži” na model „izračunaj, proknjiži i pošalji”. Elektroničko izdavanje računa i izvještavanje poreznih tijela u gotovo stvarnom vremenu postaju dio cjevovoda. To ne zamjenjuje računalovodstveni API. To čini strukturirane podatke o računima iz računalovodstvenog API-ja izvorom koji se zrcali u pristupniku za izvještavanje (reporting gateway).

Dvije su praktične posljedice:

Metadaci računa moraju biti bogatiji nego što to dopušta većina naslijeđenih shema (legacy schemas). Polja Peppol BIS 3.0 standarda, strukturirana razrada PDV-a po stavkama i identifikatori postupaka trebaju biti sastavni dio računalovodstvenog API-ja, a ne naknadno dodane bilješke u slobodnom tekstu.
Računovodstveni dokument i prijavljeni dokument moraju ostati usklađeni. Ako se izda odobrenje (credit note), pristupnik za izvještavanje mora vidjeti ispravak s istim identifikatorima. Nepromjenjive glavne knjige i jasan slijed dokumenata čine ovo jednostavnim. Opušteno knjigovodstvo čini ovo nornim mukotrpnim.

Priprema za ViDA manje se tiče novih značajki, a više pooštravanja discipline u onome što već postoji.

Kratka usporedba pristupa automatizaciji

Pristup	Dokazi o odluci o PDV-u	Upravljanje OSS-om / IOSS-om	Modeliranje uloge internetske trgovine	Prikladnost za ugrađene platforme
Ručno knjigovodstvo s proračunskim tablicama	Slabo, rekonstruira se naknadno	Ručno, podložno pogreškama	Obično se zanemaruje	Slabo
Stariji računovodstveni softver s naknadno dodanim poreznim modulom	Djelomično, često izvan glavne knjige	Podržano, ali izolirano	Ograničeno	Slabo do umjereno
Generički računalovodstveni API (u stilu Xero ili QuickBooks)	Ovisi o disciplini integracije	Razlikuje se ovisno o tržištu i dodatcima	Nije javno potvrđeno za tokove u kojima se platforma smatra isporučiteljem u kontekstu EU-a	Umjereno
Nordlet (orijentiran na API, fokusiran na EU)	Nepromjenjiva glavna knjiga, porezni metadaci po računu, zaključavanje razdoblja	Izvorni PDV po državama, i.SAF, VIES, OSS-spremno grupiranje	Prvoklasno: `vatScheme`, `deemedSupplier` po računu	Snažno

Tablica odražava ulazne podatke dostupne za ovaj članak. U slučajevima kada mogućnost konkurencije nije dokumentirana u istraživačkom sažetku, označena je kao javno neutvrđena umjesto da se donose pretpostavke.

Što prvo izgraditi ako tek počinjete

Ako neki tim postavlja ugrađenu automatizaciju EU PDV-a na API-ju za računalovodstvo u oblaku, slijed koji obično štedi najviše ponovnog rada izgleda ovako:

Prije svega modelirajte poslovnog partnera i njegove signale o državi. Svaka nizvodna odluka ovisi o tome. Pohranite signale, a ne samo izvedenu državu.
Izgradite sloj poreznih kategorija. Mapirajte proizvode i usluge u kategorije. Mapirajte kategorije na šifre država. Nikada nemojte mapirati proizvode izravno na stope.
Povežite VIES provjeru s predmemoriranjem (caching) i redom za pregled. Nemojte dopustiti da dostupnost VIES-a blokira vaš proces naplate (checkout).
Šaljite i primajte webhookove za promjene stanja računa. Koristite ključeve za idempotentnost pri svakom upisu.
Zaključajte razdoblja čim se zatvore. Nametnite to na razini API-ja, a ne kroz interne politike.
Izvedite OSS prijave iz glavne knjige. Ako za prijavu trebate zasebnu proračunsku tablicu, glavna knjiga ne nosi dovoljno metadataka.
Tek tada dodajte e-fakturiranje i integraciju s pristupnikom za izvještavanje. Ulazni podaci moraju najprije biti ispravni.

Većina ovih koraka predstavlja jednokratna ulaganja koja se višekratno isplaćuju svako tromjesečje. Neograničena sandbox tvrtka najjeftinije je mjesto za dokazivanje ovog slijeda od početka do kraja.

FAQ

Je li VIES provjera dovoljna da se dokaže da je B2B prodaja ispravno oslobođena PDV-a (zero-rated)?

Ne sama po sebi. VIES potvrđuje da je PDV ID valjan u određenom trenutku. Zapis otporan na reviziju također uključuje vremensku oznaku provjere, sadržaj odgovora, deklariranu državu kupca te dokaze da su roba ili usluge isporučene tom subjektu registriranom za PDV. Pohranite sve to uz račun.

Može li se platforma osloniti na internetsku trgovinu (marketplace) za obradu PDV-a i preskočiti vlastitu logiku?

Samo za specifične transakcije kod kojih se internetska trgovina smatra isporučiteljem prema pravilima EU-a. Računovodstvo trgovca i dalje mora ispravno odražavati te transakcije, dok sve prodaje izvan tog opsega, uključujući izravnu prodaju i B2B tokove, ostaju odgovornost trgovca. Sigurniji pristup jest izričito modeliranje uloge za svaku transakciju pojedinačno.

Koliko se često stope PDV-a u EU-u zapinski mijenjaju da bi to bilo važno?

Dovoljno često da hardkodirane stope uzrokuju stvarne probleme. Kategorije sniženih stopa se mijenjaju, uvode se privremene stope koje kasnije istječu, a pojavljuju se i nova pravila država članica. Sloj sadržaja stopa s definiranim datumima primjene nije pretjerano inženjerstvo. To je osnovni standard.

Koja je razlika između OSS-a i IOSS-a u praksi?

OSS pokriva prekograničnu B2C prodaju robe i digitalnih usluga unutar EU-a, koja se prijavljuje tromjesečno putem jedinstvene države članice. IOSS pokriva uvoz robe male vrijednosti u EU, obično potrošačku robu vrijednosti do 150 EUR. Oba sustava proizlaze iz istih računovodstvenih podataka ako glavna knjiga svaku transakciju označava pripadajućim postupkom.

Znači li nepromjenjiva glavna knjiga (immutable ledger) da su ispravci nemogući?

Ne. Ispravci se provode putem novih knjiženja, a ne uređivanjem starih. Odobrenje poništava račun, a storno knjiženje ispravlja pogrešan unos. Ono što nepromjenjivost sprječava jest tiho prepravljanje povijesti, što je upravo ono ponašanje koje revizori traže.