Automatizace dodržování předpisů pro DPH v EU pomocí cloudového účetního API

Praktický průvodce pro platformy a tržiště, které potřebují správné účetnictví, správnou DPH a auditní stopu, která obstojí i po letech.

DPH v EU už dávno není problém výpočtu. Je to problém dokládání. Sazby jsou zveřejněné, limity známé a přiznání v režimu OSS mají jasnou dokumentaci. To, co u auditů selhává a co na velkém měřítku boří platformy, je neschopnost rekonstruovat, jak se na konkrétní faktuře dospělo ke konkrétnímu rozhodnutí ohledně DPH, a to s použitím pravidel a vstupů, které platily v daném okamžiku. Cloudové účetní API to sice dokáže zautomatizovat od začátku do konce, ale pouze tehdy, pokud je navrženo kolem rozhodovacího grafu a nikoliv jen kolem samotné sazby.

Tento rozdíl ovlivňuje všechno, o čem píšeme níže.

Co „automatizace DPH v EU“ ve skutečnosti znamená

Pro platformu prodávající do několika zemí EU představuje automatizace DPH řetězec na sebe navazujících rozhodnutí:

Je zákazník plátcem DPH (B2B), nebo koncovým spotřebitelem (B2C) a kde se nachází?
Sazba které země se uplatňuje, v jaké daňové kategorii a k datu vystavení faktury?
Jedná se o přenesení daňové povinnosti (reverse-charge), režim OSS, režim IOSS, nebo o tuzemské plnění?
Byla plátcem považovaným za dodavatele (deemed supplier) online tržiště, nebo obchodník?
Jaké důkazy podkládají každou z těchto odpovědí a lze je později zpětně přehrát?

Zautomatizovat samotnou částku bez automatizace související úvahy vede ke klasickému selhání při auditu: správné součty, ale žádná obhajitelná stopa. Moderní daňové nástroje stále častěji prosazují důkazní stopu připravenou pro audit a vyhledávání historických sazeb právě proto, že daňová kontrola se dnes soustředí na to, jak se k rozhodnutí o DPH dospělo, a nejen na to, jaká byla jeho výsledná výše.

Cloudové účetní API je přirozeným místem pro uložení této stopu, protože už nyní uchovává fakturu, záznam v hlavní knize i protistranu. Platforma Nordlet je postavena na této myšlence: neměnná účetní kniha (immutable ledger) s podvojným zápisem, logika DPH pro jednotlivé země, ověřování v systému VIES a generování výkazů i.SAF – to vše dostupné přes jediné rozhraní REST s typovými SDK a webhooky. API nepředstavuje jen tenkou vrstvu nad vedením účetnictví, ale je primárním systémem záznamů pro samotné rozhodnutí.

Tři schopnosti API, které mají největší váhu

Většina práce na automatizaci DPH se omezuje na tři schopnosti, které musí účetní API čistě zpřístupnit.

1. Obsah sazeb a daňové kategorie vázané k datu. Sazby se mění. Kategorie se mění. Snižované sazby přibývají a ubývají. Schůdný postup, jak uvádí metodika společnosti Sage pro reformu DPH v EU a účetní API, spočívá v přiřazení položek k daňovým kategoriím a následném mapování těchto kategorií na kódy specifické pro danou zemi s platností od určitého data. Pevné zakódování sazby na položku a zemi je anti-pattern, který nenápadně bobtná, dokud změna sazby o rok později něco nerozbije.

2. Ověřování DIČ s elegantním selháním (graceful degradation). Systém VIES je kanonickým zdrojem pro přeshraniční ověřování B2B transakcí. Zároveň je občas nespolehlivý. Rozumná implementace ukládá ověření do mezipaměti s krátkou platností TTL (Time-To-Live), při selhání provádí opakované pokusy a nejednoznačné případy směruje do fronty ke kontrole namísto toho, aby blokovala prodej. Představa, že VIES musí synchronně uspět u každé transakce, je přesně to, čím si platformy samy způsobují výpadky.

3. Sběr důkazů a neměnnost dat. Každé rozhodnutí o DPH by mělo ukládat své vstupy: signály o umístění zákazníka, DIČ a časové razítko ověření, daňovou kategorii, verzi tabulky sazeb, příslušný režim (tuzemský, OSS, IOSS, přenesení daňové povinnosti) a roli tržiště. Tento záznam musí přežít změny sazeb a úpravy nastavení. Neměnná účetní kniha se zamykáním účetních období, kterou Nordlet vynucuje na úrovni API, znamená, že uzavřený měsíc nelze potichu přepsat, aby pozdější audit vypadal úhledněji.

Tyto tři schopnosti představují základ. Vše ostatní, včetně podávání přiznání OSS, generování souhrnných hlášení i.SAF a párování plateb, stojí na nich.

Modelování rozhodnutí o DPH, nejen samotné sazby

Nejčastějším chybovým stavem v zabudovaném účetnictví je vnímání daňového pole na faktuře jako výsledku pouhého vyhledání. Tak to ale není. Jde o výsledek malého rozhodovacího grafu a právě tento graf je potřeba uložit.

Funkční model:

Klasifikujte protistranu. B2B nebo B2C. V případě B2B ověřte DIČ v systému VIES a uložte odpověď včetně časového razítka a stavu. U B2C zachyťte alespoň dva signály o umístění: fakturační adresu, IP adresu nebo geolokaci a případně zemi vydání platebního prostředku.
Určete místo plnění. U digitálních služeb se DPH řídí podle umístění zákazníka, nikoli dodavatele. U zboží se pravidla liší podle místa odeslání a dodání. API by mělo u každého řádku faktury označit odvozené místo plnění a použité signály.
Zvolte režim. Tuzemský, OSS (přeshraniční B2C v rámci EU), IOSS (dovoz zboží nízké hodnoty), nebo přenesení daňové povinnosti. Logiku limitů, zejména limitu 10 000 EUR pro přeshraniční B2C prodej digitálních služeb, je nutné vyhodnocovat vůči klouzavému oknu, nikoli izolovaně pro aktuální fakturu.
Vyhledejte sazbu. Zjistěte sazbu dané země pro příslušnou daňovou kategorii k datu faktury. Uložte použitou verzi tabulky sazeb.
Zaúčtujte do hlavní knihy. Zapište záznam s podvojným zápisem, kde je DPH na výstupu rozdělena podle zemí a režimů, aby bylo možné sestavit přiznání OSS a tuzemská přiznání k DPH bez nutnosti zpětně odvozovat data.

Každý krok by měl být sledovatelný přes API. Webhooky jako sale_invoice.paid umožňují navazujícím systémům reagovat na změny stavu bez nutnosti neustálého dotazování (polling). Idempotentní klíče zabraňují vzniku duplicitních záznamů v hlavní knize, když síťový požadavek selže a odešle se znovu v nevhodný okamžik. Nic z toho není exotické, ale obojí je při provozu platformy ve velkém měřítku naprosto nezbytné.

OSS, IOSS a limit 10 000 EUR

Pro SaaS a digitální služby představuje praktický problém automatizace režim OSS. Dodavatel prodávající B2C zákazníkům přes hranice v rámci EU uplatňuje sazbu své domovské země, dokud v aktuálním nebo předchozím kalendářním roce nepřekročí limit 10 000 EUR. Poté uplatňuje sazbu členského státu zákazníka a podává čtvrtletní přiznání prostřednictvím OSS. Praktická příručka věnovaná dodržování předpisů pro DPH u SaaS a digitálních služeb popisuje tuto problematiku jako problém datového potrubí (data pipeline), nikoli jako problém registrace.

Datový tok, který musí účetní API podporovat:

Sledování přeshraničních B2C tržeb oproti limitu na klouzavém základě za kalendářní rok.
Automatické přepnutí zjišťování sazby z domovské na cílovou zemi při překročení limitu, a to bez zpětného datování předchozích faktur.
Seskupení transakcí podle členského státu, režimu a měny pro čtvrtletní přiznání OSS.
Normalizace částek na eura k správnému kurzu pro účely hlášení v OSS.
Export datasetu připraveného k podání ve formátu, který dokáže zpracovat příslušný systém nebo poskytovatel daňových služeb.

Nordlet toto řeší pomocí logiky DPH pro jednotlivé země přímo v účetní knize a sestavami, které seskupují data podle režimu a členského státu: přiznání OSS se počítají přímo z faktur, včetně oprav za předchozí období, a limit 10 000 EUR se sleduje automaticky. Přiznání se odvozuje z účetní knihy a nemusí se každý rok skládat znovu od začátku. To je smysl umístění rozhodovacího grafu do účetního systému namísto samostatné tabulky v Excelu.

Režim IOSS funguje u dovozu zboží nízké hodnoty obdobně, jen s jinými limity a jiným typem přiznání.

Toky na tržištích a platformách tvoří samostatnou kategorii

Považovat online tržiště za běžný B2C kanál je chybou, které se dopouští prekvapivé množství implementací. V mnoha scénářích v EU vystupuje platforma jako osoba povinná k dani považovaná za dodavatele (deemed supplier) a nese odpovědnost za výběr a odvod DPH. Vlastní účetnictví obchodníka musí odrážet, že pro tyto transakce je protistranou relevantní z hlediska DPH platforma, nikoli koncový zákazník.

Právě zde se projevuje hodnota integrovaného účetního API. Platforma v okamžiku prodeje ví, zda jednala v pozici dodavatele považovaného za plátce. Tuto skutečnost je nutné zapsat do záznamu faktury a přenést ji do účetní knihy, aby účetnictví obchodníka duplicitně nezapočítávalo DPH, kterou už platforma vyřešila. Předávání ukazatelů daňové role přes API a jejich promítnutí do přehledů představuje rozdíl mezi čistým účetnictvím a párováním, které nikdy úplně nesedí.

Pro platformy stavějící na Nordletu je to standardní funkce: faktury nesou atribut vatScheme (včetně hodnoty marketplace_deemed) a příznak deemedSupplier a modul pro určení daňového režimu vrací příslušný režim spolu s jeho právním základem podle směrnice 2006/112/ES. V kombinaci s podporou více společností (multi-company) tak účetnictví platformy i účetnictví obchodníka mohou žít pod stejným API, s různými společnostmi a různými rolemi, aniž by docházelo k prolínání účetních zápisů DPH mezi nimi.

Co ViDA mění a co nemění

Iniciativa DPH v digitálním věku (ViDA) mění podobu automatizace z modelu „vypočítej a zaúčtuj“ na model „vypočítej, zaúčtuj a ošli“. Součástí datového toku se stává elektronická fakturace a hlášení daňovým orgánům v reálném či téměř reálném čase. To však účetní API nenahrazuje. Naopak to činí ze strukturovaných fakturačních dat v účetním API zdroj, který se zrcadlí do vykazovací brány.

Dva praktické důsledky:

Metadata faktur musí být podrobnější, než umožňují starší schémata. Políčka podle standardu Peppol BIS 3.0, strukturovaný rozpis DPH na řádcích a identifikátory režimů by měly být v účetním API prvotřídními entitami, nikoli dodatečně připojenými poznámkami ve volném textu.
Účetní doklad a vykazovaný doklad musí zůstat synchronizované. Pokud je vystaven opravný daňový doklad (dobropis), vykazovací brána musí vidět opravu se stejnými identifikátory. Neměnná účetní kniha a jasná návaznost dokladů to značně zjednodušují. Volné vedení účetnictví to naopak komplikuje.

Příprava na ViDA spočívá méně v zavádění nových funkcí a více v utužení disciplíny ohledně toho, co již existuje.

Krátké srovnání přístupů k automatizaci

Přístup	Důkaz o rozhodnutí o DPH	Zpracování OSS/IOSS	Modelování role tržiště	Vhodnost pro integrované platformy
Ruční účetnictví v tabulkách	Slabé, rekonstruované zpětně	Ruční, náchylné k chybám	Obvykle se ignoruje	Nevhodné
Starší účetní software s doplňkovým daňovým modulem	Částečné, často mimo účetní knihu	Podporované, ale izolované	Omezené	Nevhodné až průměrné
Běžné účetní API (styl Xero, QuickBooks)	Závisí na disciplíně integrace	Liší se podle trhu a doplňků	Pro toky v roli deemed supplier v EU veřejně nepotvrzeno	Průměrné
Nordlet (API-first, se zaměřením na EU)	Neměnná účetní kniha, daňová metadata na faktuře, zamykání období	Nativní DPH pro jednotlivé země, i.SAF, VIES, skupinové OSS	Prvotřídní: `vatScheme`, `deemedSupplier` na faktuře	Silné

Tabulka odráží vstupy dostupné pro tento článek. V případech, kdy schopnost konkurence nebyla v podkladovém výzkumu zdokumentována, je uvedena jako veřejně nepotvrzená namísto domněnek.

Co vybudovat jako první, pokud začínáte teď

Pokud tým buduje integrovanou automatizaci DPH v EU nad cloudovým účetním API, doporučujeme následující pořadí kroků, které obvykle ušetří nejvíce práce s předěláváním:

Nejprve vymodelujte protistranu a její signály o umístění. Na tom závisí každé navazující rozhodnutí. Ukládejte signály, nikoli jen odvozenou zemi.
Vytvořte vrstvu daňových kategorií. Namapujte produkty a služby na kategorie. Kategorie namapujte na kódy zemí. Nikdy nemapujte produkty přímo na sazby.
Zapojte ověřování VIES s mezipamětí a frontou ke kontrole. Nedovolte, aby dostupnost služby VIES blokovala váš proces pokladny.
Odesílejte a zpracovávejte webhooky pro změny stavu faktur. U každého zápisu používejte idempotentní klíče.
Uzamykejte období ihned po jejich uzavření. Vynucujte to na úrovni API, nikoli interní směrnicí.
Odvozujte přiznání OSS z účetní knihy. Pokud přiznání vyžaduje samostatnou tabulku v Excelu, účetní kniha neobsahuje dostatek metadat.
Teprve poté přidejte e-fakturaci a integraci s vykazovací bránou. Vstupní data musí být v pořádku jako první.

Většina těchto kroků představuje jednorázovou investici, která se tiše vyplácí každé čtvrtletí. Neomezená sandboxová společnost je tím nejlevnějším místem, kde si tento postup můžete ověřit od začátku do konce.

FAQ

Stačí ověření v systému VIES k prokázání, že B2B prodej byl správně osvobozen od daně?

Samo o sobě nikoliv. Vies potvrzuje platnost DIČ v daném okamžiku. Auditovatelný záznam obsahuje také časové razítko kontroly, datovou odpověď, uvedenou zemi zákazníka a důkaz, že zboží nebo služby byly dodány danému subjektu registrovanému k DPH. Uložte všechno toto ke konkrétní faktuře.

Může se platforma spolehnout, že DPH vyřeší tržiště, a vynechat vlastní logiku?

Pouze u konkrétních transakcí, kde tržiště vystupuje jako osoba povinná k dani považovaná za dodavatele (deemed supplier) podle pravidel EU. Účetnictví obchodníka musí tyto transakce stále správně odrážet a veškerý prodej mimo tento rozsah, včetně přímých prodejů a B2B toků, zůstává odpovědností obchodníka. Bezpečnější výchozí možností je modelovat roli explicitně pro každou transakci.

Jak často se sazby DPH v EU skutečně mění tak, že na tom záleží?

Dost často na to, aby pevně zakódované sazby způsobovaly reálné problémy. Kategorie snižovaných sazeb se mění, zavádějí se dočasné sazby, které vyprší, a objevují se nová pravidla členských států. Vrstva obsahu sazeb s daty platnosti nepředstavuje zbytečné nadprojektování, ale nutný základ.

Jaký je v praxi rozdíl mezi OSS a IOSS?

Režim OSS pokrývá přeshraniční B2C prodej zboží a digitálních služeb v rámci EU, který se vykazuje čtvrtletně prostřednictvím jednoho členského státu. Režim IOSS pokrývá dovoz zboží nízké hodnoty do EU, typicky spotřební zboží do hodnoty 150 EUR. Oba režimy vycházejí ze stejných účetních dat, pokud účetní kniha označuje každou transakci příslušným režimem.

Znamená neměnná účetní kniha, že opravy jsou nemožné?

Ne. Opravy se provádějí pomocí nových záznamů, nikoli úpravou těch starých. Dobropis stornuje fakturu, stornovací zápis opraví chybné zaúčtování. Neměnnost zabraňuje tichému přepisování historie, což je přesně to chování, které auditoři vyhledávají.