Automatizácia súladu s DPH v EÚ pomocou cloudového účtovného API
Praktická príručka pre platformy a trhoviská, ktoré potrebujú reálne účtovníctvo, správnu DPH a auditovateľnú stopu, ktorá obstojí aj o niekoľko rokov.
DPH v EÚ už nie je problémom výpočtu, ale problémom dokazovania. Sadzby sú zverejnené, limity sú známe a priznania OSS sú dobre zdokumentované. To, čo pri auditoch zlyháva a čo v neskorších fázach rozširovania platformy spôsobuje problémy, je neschopnosť zrekonštruovať, ako sa konkrétne rozhodnutie o DPH na určitej faktúre prijalo na základe pravidiel a vstupov platných v danom momente. Cloudové účtovné API to dokáže automatizovať od začiatku do konca, ale iba vtedy, ak je navrhnuté okolo rozhodovacieho grafu, a nie iba okolo samotnej sadzby.
Tento rozdiel ovplyvňuje všetko, o čom píšeme nižšie.
Čo v skutočnosti znamená „automatizovať DPH v EÚ“
Pre platformu predávajúcu do viacerých krajín EÚ predstavuje automatizácia DPH reťazec na sebe závisiacich rozhodnutí:
- Je zákazník subjektom B2B alebo B2C a kde sa nachádza?
- Sadzba ktorej krajiny sa uplatňuje, v akej daňovej kategórii a k dátumu vystavenia faktúry?
- Ide o samozdanenie (reverse charge), režim OSS, režim IOSS alebo tuzemské plnenie?
- Je povinnou osobou (deemed supplier) trhovisko, alebo obchodník?
- Aké dôkazy podporujú každú z týchto odpovedí a dá sa to neskôr prehrať?
Automatizácia čistej sumy bez automatizácie logiky za ňou vytvára klasický auditný nedostatok: správne súčty, ale žiadna obhájiteľná stopa. Moderné daňové enginy čoraz častejšie presadzujú dôkazové stopy pripravené na audit a vyhľadávanie historických sadzieb práve preto, že kontrolné orgány sa dnes zameriavajú na to, ako sa k rozhodnutiu o DPH dospelo, a nielen na to, aká bola jeho výsledná podoba.
Cloudové účtovné API je na uchovanie tejto stopy prirodzeným miestom, pretože už v sebe uchováva faktúru, položku v hlavnej knihe (ledger) aj obchodného partnera. Nordlet je postavený na tejto myšlienke: nezmeniteľná (immutable) podvojná účtovná kniha, logika DPH pre jednotlivé krajiny, overovanie VIES a generovanie výkazov i.SAF, pričom všetko je prístupné cez jediné rozhranie REST s typovanými SDK a webhookmi. API nie je len tenkou vrstvou nad klasickým účtovníctvom, ale je systémom záznamov pre samotné rozhodnutie.
Tri kľúčové schopnosti API, ktoré majú najväčšiu váhu
Väčšina úloh spojených s automatizáciou DPH sa zužuje na tri schopnosti, ktoré musí účtovné API čisto sprístupniť.
1. Obsah sadzieb a daňové kategórie naviazané na dátum. Sadzby sa menia. Kategórie sa menia. Znížené sadzby pribúdajú a ubúdajú. Fungujúcim vzorom, ako uvádza príručka pre vývojárov od spoločnosti Sage o reformách DPH v EÚ a účtovných API, je priradiť položky k daňovým kategóriám a tie následne prepojiť s kódmi pre konkrétne krajiny vrátane platnosti od/do. Pevné zakódovanie sadzby na jednu položku a krajinu je protipólom správneho postupu, ktorý sa potichu nabaľuje dovtedy, kým zmena sadzby po roku niečo nepokazí.
2. Overovanie IČ DPH s elegantným zlyhaním (graceful degradation). VIES je hlavným zdrojom na cezhraničné overovanie subjektov v režime B2B. Zároveň býva občasne nespôsobilý prevádzky. Rozumné implementácie si výsledky overení ukladajú do vyrovnávacej pamäte skrátenej doby platnosti (TTL), pri zlyhaní skúšajú operáciu zopakovať a nejednoznačné prípady smerujú do fronty na manuálnu kontrolu namiesto toho, aby blokovali predaj. Predstava, že VIES musí synchrónne fungovať pri každej jednej transakcii, je presne tou chybou, ktorou si platformy spôsobujú výpadky samy.
3. Zaznamenávanie dôkazov a nezmeniteľnosť. Každé rozhodnutie o DPH by malo obsahovať svoje vstupy: signály o polohe zákazníka, IČ DPH a časovú pečiatku jeho overenia, daňovú kategóriu, verziu tabuľky sadzieb, príslušný režim (tuzemský, OSS, IOSS, samozdanenie) a úlohu trhoviska. Tento záznam musí prežiť zmeny sadzieb aj úpravy konfigurácie. Nezmeniteľná účtovná kniha so zámkami účtovných období, ktorú Nordlet vynucuje na úrovni API, znamená, že uzavretý mesiac nemožno potichu prepísať s cieľom urobiť neskorší audit prehľadnejším.
Tieto tri schopnosti predstavujú základ. Všetko ostatné vrátane podávania daňových priznaní OSS, generovania i.SAF a odsúhlasovania stojí na nich.
Modelovanie rozhodnutia o DPH, nielen samotnej sadzby
Najčastejším problémom v integrovanom účtovníctve je prístup, kedy sa daňové pole na faktúre považuje za výsledok jednoduchého vyhľadania. To nie je pravda. Je to výsledok malého rozhodovacieho grafu a práve tento graf je potrebné uložiť.
Fungujúci model:
- Klasifikujte obchodného partnera. B2B alebo B2C. Ak ide o B2B, overte IČ DPH prostredníctvom VIES a uložte odpoveď vrátane časovej pečiatky a stavu. Ak ide o B2C, získajte aspoň dva signály o polohe: fakturačnú adresu, IP adresu alebo geolokáciu a krajinu platobného prostriedku, ak je k dispozícii.
- Určite miesto dodania. Pri digitálnych službách sa DPH riadi polohou zákazníka, nie dodávateľa. Pri tovare sa pravidlá líšia podľa miesta odoslania a miesta určenia. API by malo označiť každý riadok faktúry odvodeným miestom dodania a použitými signálmi.
- Zvoľte režim. Tuzemský, OSS (cezhraničný B2C predaj v rámci EÚ), IOSS (dovoz tovaru nízkej hodnoty) alebo samozdanenie. Logiku limitov, najmä hranicu 10 000 EUR pre cezhraničné B2C služby, je nutné vyhodnocovať voči skĺzavajúcemu časovému oknu (rolling window), a nie len pre aktuálnu faktúru izolovane.
- Vyriešte sadzbu. Vyhľadajte sadzbu dane pre danú krajinu a daňovú kategóriu k dátumu vystavenia faktúry. Uložte použitú verziu tabuľky sadzieb.
- Zaúčtujte do hlavnej knihy. Vytvorte zápis podvojného účtovníctva s DPH na úhradu rozdelenou podľa krajín a režimov, aby bolo možné vytvárať priznania OSS a tuzemské priznania k DPH bez opätovného odvodzovania údajov.
Každý krok by mal byť cez API pozorovateľný. Webhooky ako sale_invoice.paid umožňujú nadväzujúcim systémom reagovať na zmeny stavov bez nutnosti neustáleho dopytovania (polling). Kľúče na zaistenie idempotencie (idempotency keys) zabraňujú vzniku duplicitných účtovných zápisov v prípade, že sa sieťová požiadavka v nevhodnej chvíli zopakuje. Ani jedno z toho nie je exotická funkcia, ale pri rozširovaní platformy sú obe nevyhnutné.
OSS, IOSS a limit 10 000 EUR
Pre SaaS a digitálne služby predstavuje praktický problém automatizácie režim OSS. Dodávateľ predávajúci cezhranične v rámci B2C segmentu v EÚ uplatňuje sadzbu svojej domovskej krajiny dovtedy, kým v prebiehajúcom alebo predchádzajúcom kalendárnom roku neprekročí limit 10 000 EUR. Následne uplatňuje sadzbu členského štátu zákazníka a podáva štvrťročné priznania cez OSS. Praktická príručka o súlade s DPH pre SaaS a digitálne služby vníma túto problematiku ako problém dátovej pipeline, nie ako problém registrácie.
Potrubie (pipeline), ktoré musí účtovné API podporovať:
- Sledovať cezhraničné výnosy B2C vzhľadom na limit na priebežnom základe za kalendárny rok.
- Automaticky prepnúť výpočet sadzby z domovskej krajiny na cieľovú krajinu pri prekročení limitu bez spätného datovania predchádzajúcich faktúr.
- Zoskupiť transakcie podľa členského štátu, režimu a meny pre štvrťročné priznanie OSS.
- Priradiť sumám kurz EUR platný v deň vzniku kurzovej povinnosti pre účely vykazovania v OSS.
- Exportovať súbor údajov pripravený na podanie v takom formáte, ktorý dokáže spracovať podávajúci softvér alebo služba.
Nordlet to rieši pomocou logiky DPH pre jednotlivé krajiny priamo v hlavnej knihe a prostredníctvom reportov zoskupujúcich dáta podľa režimov a členských štátov: priznania OSS sa počítajú zo samotných faktúr vrátane opráv predchádzajúcich období a limit 10 000 EUR sa sleduje automaticky. Priznanie sa odvodzuje priamo z hlavnej knihy a rekonštruuje sa bez nutnosti vytvárať ho každý štvrťrok od nuly. To je hlavný zmysel umiestnenia rozhodovacieho grafu priamo do účtovného systému namiesto samostatného tabuľkového procesora.
Režim IOSS funguje pre dovoz tovaru nízkej hodnoty rovnako, avšak s inými limitmi a iným priznaním.
Toky pre trhoviská a platformy predstavujú samostatnú kategóriu
Považovať trhovisko za bežný B2C kanál je presne ten bod, kde zlyháva prekvapivo veľa implementácií. V mnohých scenároch v EÚ je platforma považovaná za osobu povinnú dodávať tovar (deemed supplier) a zodpovedá za výber a odvod DPH. Vlastné účtovníctvo obchodníka by malo odrážať skutočnosť, že partnerom relevantným z hľadiska DPH pre tieto transakcie je platforma, a nie koncový zákazník.
Tu sa prejavuje skutočná hodnota integrovaného účtovného API. Platforma v momente predaja presne vie, či vystupovala ako povinná osoba. Túto skutočnosť je nutné zaznamenať na faktúre a preniesť ju do účtovnej knihy, aby účtovníctvo obchodníka duplicitne nezapočítavalo DPH, ktorú už platforma vyriešila. Prenos indikátorov daňovej úlohy cez API a ich zobrazenie v reportoch predstavuje rozdiel medzi čistým účtovníctvom a nekončiacim odsúhlasovaním stavov.
Pre platformy postavené na systéme Nordlet je to štandardná funkcia: faktúry obsahujú atribút vatScheme (vrátane hodnoty marketplace_deemed) a príznak deemedSupplier. Modul na určenie režimu (treatment resolver) navyše vracia príslušný režim spolu s jeho právnym základom podľa Smernice 2006/112/ES. V kombinácii s podporou viacerých spoločností (multi-company) môžu účtovníctvo platformy a účtovníctvo obchodníka fungovať pod rovnakým API pre rôzne firmy a s rôznymi úlohami bez toho, aby medzi nimi dochádzalo k únikom účtovných zápisov DPH.
Čo ViDA mení a čo nemení
Smernica o DPH v digitálnom veku (ViDA) posúva tvar automatizácie z roviny „vypočítaj a zaúčtuj“ do roviny „vypočítaj, zaúčtuj a odošli“. Elektronická fakturácia a vykazovanie daňovým úradom v takmer reálnom čase sa stávajú súčasťou procesného reťazca. To však účtovné API nenahrádza. Naopak, štruktúrované údaje o faktúrach z účtovného API robia zdroj, ktorý sa zrkadlí do vykazovacej brány.
Dva praktické dôsledky:
- Metadátová štruktúra faktúr musí byť bohatšia, než dovoľujú staršie schémy. Polia Peppol BIS 3.0, štruktúrovaný rozpis DPH na úrovni položiek a identifikátory schém by mali byť priamo súčasťou účtovného API, a nie len dopĺňanými poznámkami vo forme voľného textu.
- Účtovný dokument a vykazovaný dokument musia byť v zhode. Ak sa vystaví dobropis, vykazovacia brána musí vidieť opravu s rovnakými identifikátormi. Nezmeniteľné účtovné knihy a jasná nadväznosť dokumentov to uľahčujú, zatiaľ čo voľné vedenie účtovníctva to komplikuje.
Príprava na ViDA je menej o zavádzaní nových funkcií a viac o sprísnení disciplíny v tom, čo už existuje.
Krátke porovnanie prístupov k automatizácii
| Prístup | Dôkazy o rozhodnutí o DPH | Spracovanie OSS / IOSS | Modelovanie úlohy trhoviska | Vhodnosť pre integrované platformy |
|---|---|---|---|---|
| Manuálne účtovníctvo s tabuľkovými procesormi | Slabé, rekonštruované dodatočne | Manuálne, náchylné k chybám | Väčšinou ignorované | Slabá |
| Starší účtovný softvér s doplnkovým daňovým modulom | Čiastočné, často mimo hlavnú knihu | Podporované, ale v izolovaných silách | Obmedzená | Slabá až stredná |
| Všeobecné účtovné API (štýl Xero, QuickBooks) | Závisí od disciplíny integrácie | Líši sa podľa trhu a doplnkov | V kontexte EÚ pre režimy zastupujúcich dodávateľov nepotvrdené | Stredná |
| Nordlet (API-first, zameraný na EÚ) | Nezmeniteľná kniha, daňové metadáta na faktúru, zámky období | Natívna DPH pre krajiny, i.SAF, VIES, zoskupenie pre OSS | Špičková: vatScheme, deemedSupplier na každej faktúre |
Silná |
Tabuľka odráža vstupy dostupné pre tento článok. V prípadoch, keď schopnosť konkurenta nie je v prieskume zdokumentovaná, sa uvádza ako verejne nepotvrdená namiesto predpokladanej.
Čo vybudovať najskôr, ak začínate teraz
Ak tím zavádza integrovanú automatizáciu DPH v EÚ pomocou cloudového účtovného API, postupnosť, ktorá zvyčajne ušetrí najviac prerábania:
- Predovšetkým namodelujte obchodného partnera a signály jeho krajiny. Každé nadväzujúce rozhodnutie na tom závisí. Ukladajte surové signály, nielen odvodenú krajinu.
- Vybudujte vrstvu daňových kategórií. Priraďte produkty a služby ku kategóriám. Kategórie prepojte s kódmi krajín. Nikdy nepriraďujte produkty priamo k sadzbám.
- Zaintegrujte overovanie VIES s vyrovnávacou pamäťou a frontou na kontrolu. Nedovoľte, aby nedostupnosť služby VIES blokovala proces nákupu (checkout).
- Odosielajte a prijímajte webhooky pre zmeny stavu faktúr. Pri každom zápise používajte idempotenčné kľúče.
- Uzamykajte obdobia hneď po ich skončení. Vynucujte to priamo v API, nie iba v interných predpisoch.
- Odvodzujte priznania OSS priamo z hlavnej knihy. Ak priznanie potrebuje samostatnú tabuľku, hlavná kniha neobsahuje dostatok metadát.
- Až potom pridajte elektronickú fakturáciu a integráciu s vykazovacou bránou. Vstupné dáta musia byť v poriadku ako prvé.
Väčšina z týchto krokov predstavuje jednorazové investície, ktoré sa potichu vyplácajú každý štvrťrok. Neobmedzená testovacia spoločnosť (sandbox) je tým najlacnejším miestom na overenie celého procesu od začiatku do konca.
FAQ
Stačí overenie cez VIES na preukázanie toho, že B2B predaj bol správne oslobodený od dane?
Samo osebe nie. VIES potvrdzuje platnosť IČ DPH v určitom časovom bode. Záznam obhájiteľný pri audite obsahuje aj časovú pečiatku overenia, odpoveď zo systému, uvádzanú krajinu zákazníka a dôkaz o tom, že tovar alebo služby boli dodané danému subjektu registrovanému pre DPH. Uložte všetky tieto údaje k faktúre.
Môže sa platforma spoliehať na to, že DPH vyrieši trhovisko, a vynechať svoju vlastnú logiku?
Iba pri konkrétnych transakciách, kde je trhovisko považované za osobu povinnú dodávať tovar (deemed supplier) podľa pravidiel EÚ. Účtovníctvo obchodníka musí tieto transakcie stále správne odrážať a akýkoľvek predaj mimo tohto rozsahu, vrátane priamych predajov a B2B tokov, zostáva zodpovednosťou obchodníka. Bezpečnejším prístupom je explicitne modelovať úlohu pre každú transakciu zvlášť.
Ako často sa sadzby DPH v EÚ menia natoľko, aby to malo význam?
Dostatočne často na to, aby pevne zakódujované sadzby spôsobovali reálne problémy. Kategórie so zníženou sadzbou sa menia, zavádzajú sa a vypršiavajú dočasné sadzby a objavujú sa nové pravidlá členských štátov. Vrstva obsahu sadzieb s dátumami platnosti nie je prehnané inžinierstvo, ale základný štandard.
Aký je v praxi rozdiel medzi OSS a IOSS?
Režim OSS pokrýva cezhraničný predaj tovaru a digitálnych služieb v rámci B2C segmentu v EÚ a vykazuje sa štvrťročne prostredníctvom jedného členského štátu. Režim IOSS pokrýva dovoz tovaru nízkej hodnoty do EÚ, zvyčajne spotrebného tovaru do hodnoty 150 EUR. Oba režimy vychádzajú z tých istých účtovných údajov, ak hlavná kniha označí každú transakciu príslušným schémovým kódom.
Znamená nezmeniteľná účtovná kniha, že opravy nie sú možné?
Nie. Opravy sa robia prostredníctvom nových zápisov, nie úpravou starých. Dobropis stornuje faktúru, stornovací zápis opraví chybné zaúčtovanie. Nezmeniteľnosť zabraňuje tichému prepisovaniu histórie, čo je presne to správanie, ktoré audítori vyhľadávajú.