Znalosti · E-faktura
Validace e-faktury a správné čtení protokolu o kontrole
Když je e-faktura z vašeho softwaru odmítnuta, musí váš tým podle protokolu o kontrole zjistit, které pole hlášení vyvolalo a kdo ho může opravit.
Ukazujeme, jak číst protokol o kontrole a na kterých místech patří validace do vašeho softwaru.
Co se při validaci e-faktury kontroluje
Validátor kontroluje e-fakturu postupně podle tří sad pravidel a každou odchylku zaznamená do protokolu o kontrole.
Schéma XML dané syntaxe
E-faktura podle EN 16931 existuje v jedné ze dvou syntaxí, UBL nebo UN/CEFACT CII. Všechny běžné aplikační specifikace vycházejí z těchto dvou syntaxí, například XRechnung, ZUGFeRD a Peppol BIS Billing 3.0.
Schéma XML dané syntaxe určuje, které prvky jsou povoleny, v jakém pořadí stojí a jaký mají datový typ.
Chyby schématu nemají ID pravidla. Parser XML je hlásí vlastními kódy, například cvc-complex-type.2.4.a pro prvek na místě, kde jej schéma neočekává.
U ZUGFeRD je soubor CII vložen do PDF. Validátor kontroluje část XML. Tato část je při odchylkách od obrazové části rozhodující, jak uvádí dopis německého spolkového ministerstva financí (BMF) ze dne 15. října 2025 k zavedení povinné e-faktury.
Obchodní pravidla EN 16931
Obchodní pravidla kontrolují údaje e-faktury na logické chyby, například zda jsou vyplněna povinná pole a zda si součty odpovídají. Evropský výbor pro normalizaci (CEN) tato pravidla zveřejňuje jako soubory Schematron na GitHubu, vždy pro UBL a pro CII.
Podle prefixu ID pravidla poznáte druh kontroly. Pravidla s BR a číslem kontrolují povinná pole a jejich počet, BR-CO kontroluje výpočty a závislosti mezi poli, BR-CL kontroluje číselníky a BR-DEC desetinná místa částek. Pravidla jako BR-S, BR-AE nebo BR-IC kontrolují údaje k jednotlivým kategoriím DPH.
Soubory CEN obsahují také pravidla specifická pro syntaxi. Pravidla s prefixem UBL-CR hlásí například varování, když soubor UBL obsahuje prvky, které nepatří do datového modelu EN 16931.
Pravidla XRechnung a Peppol BIS Billing 3.0
XRechnung a Peppol BIS Billing 3.0 jsou aplikační specifikace EN 16931, odborně nazývané CIUS (Core Invoice Usage Specification). Předepisují další pole a doplňují EN 16931 o vlastní pravidla. Nová datová pole CIUS zavádět nesmí.
Pravidla XRechnung začínají na BR-DE a pocházejí od německého Koordinačního úřadu pro IT standardy (KoSIT). Peppol BIS Billing 3.0 doplňuje pravidla s prefixy PEPPOL-EN16931 a PEPPOL-COMMON a také pravidla specifická pro jednotlivé země.
Identifikátor specifikace v BT-24 určuje, která aplikační specifikace pro soubor platí. Validátor KoSIT podle tohoto identifikátoru vybere odpovídající scénář kontroly. Chybný nebo zastaralý identifikátor proto může vést k tomu, že soubor bude zkontrolován podle jiných pravidel nebo odmítnut.
Co validace nekontroluje
Validátor nerozpozná, zda sazba daně odpovídá plnění nebo zda je popis plnění dostatečný.
Podle německého spolkového ministerstva financí musí všechny povinné údaje pro účely DPH stát ve strukturované části e-faktury. Pouhý odkaz na přílohu s popisem plnění nestačí. Název položky jako „viz příloha“ v BT-153 přesto validací projde, protože obsah tohoto pole žádné pravidlo nehodnotí.
KoSIT a Fórum elektronické faktury Německo (FeRD) zveřejnily tabulku, která povinným údajům podle německého zákona o DPH přiřazuje odpovídající pole BT. Podle této tabulky můžete určit, které povinné údaje by měl váš software zajistit vlastními kontrolami věrohodnosti.
Struktura protokolu o kontrole
Každá položka v protokolu o kontrole obsahuje zpravidla čtyři údaje.
ID pravidla
ID pravidla jako BR-CO-15 nebo BR-DE-2 odkazuje na pravidlo v dokumentaci příslušné sady pravidel.
Závažnost
Validátor označí každé hlášení jako chybu, nebo jako varování. V pravidlech Peppol se chyby označují jako fatal. Samotné varování zpravidla k odmítnutí nevede. Některé validátory navíc vydávají upozornění, tedy doporučení pro čistou implementaci bez vlivu na výsledek. Validátor KoSIT na konci svého protokolu doporučí dokument přijmout, nebo odmítnout.
Peppol často zavádí nová pravidla nejprve jako varování a v pozdějším vydání je povýší na chybu. Ve verzi 3.0.21 se například pravidla PEPPOL-COMMON-R052 a PEPPOL-COMMON-R053 změnila z varování na chyby, jak uvádějí poznámky k vydání Peppol BIS Billing 3.0.
Umístění
Umístění je výraz XPath, který ukazuje na dotčený prvek v XML. Stejné číslo BT leží v UBL a CII na různých místech. Celková částka faktury s DPH (BT-112) stojí v UBL v prvku cbc:TaxInclusiveAmount pod cac:LegalMonetaryTotal, v CII v prvku ram:GrandTotalAmount pod ram:SpecifiedTradeSettlementHeaderMonetarySummation.
U pravidel, která porovnávají více polí, ukazuje umístění často na nadřazený prvek. Hodnotu, která hlášení vyvolala, pak najdete podle textu hlášení.
Text hlášení
Text hlášení popisuje pravidlo a většinou uvádí dotčená čísla BT. Hlášení k BR-CO-15 například říká, že celková částka faktury s DPH (BT-112) musí odpovídat součtu celkové částky faktury bez DPH (BT-109) a částky DPH (BT-110).
Od verze 3.0.21 začínají texty pravidel Peppol ID pravidla.
Vyhodnocení protokolu o kontrole ve správném pořadí
Dlouhý protokol o kontrole má často jen několik málo příčin.
-
Odstraňte chyby schématu
Dokud soubor nesplňuje schéma, jsou výsledky obchodních pravidel málo vypovídající nebo zcela chybějí. Proto nejprve odstraňte chyby schématu v exportu a poté soubor znovu validujte.
-
Seskupte položky podle ID pravidla
Chyba v mapování se může objevit v každé položce faktury. Faktura se 40 položkami pak vytvoří 40 záznamů k témuž pravidlu, které mají jedinou příčinu. Protokol proto vyhodnocujte podle ID pravidel.
-
Rozpoznejte navazující chyby
Jeden chybějící prvek může porušit několik pravidel současně. Pokud chybí rozpis DPH (BG-23), hlásí validátor například BR-CO-18 a navíc pravidla dotčené kategorie DPH, jako je BR-S-01. Nejprve odstraňte příčinu a znovu validujte, než začnete zbývající hlášení řešit jednotlivě.
-
Přes číslo BT do vlastního datového modelu
Číslo BT propojuje protokol o kontrole s vaším softwarem. Udržujte přiřazení každého čísla BT k databázovému poli, k poli formuláře ve vašem rozhraní a k odpovědnosti. Odpovědnost určuje, zda chybu opraví váš tým, nebo váš zákazník, například když chybějí kmenová data.
-
Varování vyhodnoťte a zaznamenejte
U každého varování rozhodněte, zda ho odstraníte, nebo vědomě akceptujete, a rozhodnutí zaznamenejte. U každého nového vydání zkontrolujte, zda akceptované varování nebylo povýšeno na chybu.
Typické příčiny chyb podle skupin pravidel
Skupina pravidel často již ukazuje, ve které části vašeho softwaru je třeba opravu provést.
Chyby schématu bez ID pravidla
Příčinou je pořadí prvků, jmenný prostor nebo chybný datový typ v exportu. Oprava se provádí ve funkci exportu, jednou pro všechny zákazníky.
BR s číslem
Příčinou je povinné pole, které není namapováno nebo je v kmenových datech prázdné. Oprava se provádí v mapování nebo u povinného pole v rozhraní.
BR-CO a BR-DEC
Příčinou jsou součty, zaokrouhlování, slevy a přirážky na úrovni dokladu. Oprava se provádí ve výpočetní logice tvorby faktur.
BR-CL
Příčinou je zastaralý nebo vlastní kód, například pro měrné jednotky nebo země. Oprava se provádí v číselnících vašeho softwaru.
BR-S, BR-AE, BR-IC a další kategorie
Kategorie DPH, sazba daně a důvod osvobození si neodpovídají. Oprava se provádí v daňové logice a v kmenových datech položek.
UBL-CR
Export obsahuje prvky UBL mimo datový model EN 16931. Oprava se provádí ve funkci exportu.
BR-DE
Chybějí kontaktní údaje prodávajícího, platební údaje nebo reference kupujícího. Oprava se většinou provádí v kmenových datech vašich zákazníků.
PEPPOL-EN16931 a PEPPOL-COMMON
Chybí elektronická adresa nebo má identifikátor chybný formát. Oprava se provádí v kmenových datech a ve správě Peppol ID.
Chybějící reference kupujícího u XRechnung (BR-DE-15)
Pravidlo BR-DE-15 hlásí chybějící referenci kupujícího v BT-10. U faktur pro veřejnou správu se tam uvádí Leitweg-ID úřadu. Pro faktury B2B podle německého spolkového ministerstva financí z hlediska DPH stačí zástupný znak jako „-“, pokud příjemce faktury nestanoví vlastní identifikátor. Váš software proto může pole u faktur B2B předvyplnit zástupným znakem, který mohou vaši zákazníci přepsat.
Rozdíly ze zaokrouhlení u DPH (BR-S-09)
Pravidlo BR-S-09 porovnává částku DPH kategorie základní sazby se součinem základu daně a sazby daně. Pokud váš software zaokrouhluje DPH po položkách a částky sčítá, může se součet lišit. U mnoha položek může být odchylka větší než tolerance, kterou pravidlo připouští. Částku daně proto počítejte pro každou kategorii ze základu daně a sazby daně, jak pravidlo předepisuje.
Začlenění validace do vašeho softwaru
Validace patří na pět míst ve vašem softwaru a ve vašem vývojovém procesu.
Před odesláním
Váš software by měl každou e-fakturu validovat ihned po vytvoření a při chybách odeslání zastavit. Vaši zákazníci si s ID pravidla nebo výrazem XPath příliš neporadí. Pravidla, která mohou vaši zákazníci opravit sami, proto převeďte na upozornění u dotčeného pole formuláře. Upozornění k BR-DE-6, tedy k telefonnímu číslu kontaktu prodávajícího v BT-42, může znít například „Zadejte prosím telefonní číslo pro případné dotazy“.
Chyby, které vznikají ve vašem mapování nebo ve vaší výpočetní logice, váš zákazník opravit nemůže. Takové chyby by měly jít jako interní upozornění vašemu týmu.
Při přijetí
Váš software by měl validovat i příchozí e-faktury a výsledek zobrazit u dokladu. Původní soubor ukládejte beze změny a protokol o kontrole jako samostatný dokument vedle něj. Německé spolkové ministerstvo financí vyžaduje, aby byla alespoň strukturovaná část e-faktury uchována neporušená v původní podobě.
Pokud přijatá faktura obsahuje chyby, může váš zákazník požádat odesílatele o opravenou fakturu. Váš software může tento krok podpořit, například připraveným dotazem odesílateli, který obsahuje protokol o kontrole.
V automatizovaných testech
Založte si sadu testovacích faktur, která pokrývá vaše druhy faktur s jejich kódy, například 380 pro fakturu a 384 pro opravnou fakturu. Pokryjte také každou kategorii DPH, kterou vaši zákazníci používají. K tomu patří slevy a přirážky a také každá syntaxe, kterou váš software vytváří. Zařaďte i záměrně chybné soubory a ověřte, že je validátor odmítne.
Validátor KoSIT je open-source program pro příkazový řádek a lze jej zapojit do build pipeline. KoSIT navíc poskytuje testovací sadu s ukázkovými fakturami, která se hodí jako výchozí bod pro vaši vlastní sadu.
Po každé aktualizaci sad pravidel
Sady pravidel se mění i bez nového čísla verze. KoSIT pro XRechnung 3.0.2 pravidelně zveřejňuje balíčky s opravami chyb, naposledy ve verzi ze dne 31. srpna 2026. XRechnung 3.0 zůstává v platnosti nejméně do 31. července 2027.
Předběžná verze specifikace XRechnung 4.0 vyšla 15. září 2026. Výslovně není určena pro produktivní nasazení, ale poskytuje vám včasný přehled o nových a změněných funkcích. Finální verze vyjde pravděpodobně na jaře 2027 společně s technickými komponentami.
OpenPeppol pro Peppol BIS Billing 3.0 pravidelně zveřejňuje nová vydání, v posledních letech vždy v květnu a v listopadu. Verze 3.0.21 byla zveřejněna 20. května 2026 a je závazná od 17. srpna 2026.
Pro každé vydání si naplánujte pevný termín, kdy svou testovací sadu validujete podle nových pravidel. V každém protokolu o kontrole zaznamenejte, s jakou verzí validátoru a sady pravidel vznikl. Výsledek tak dokážete dohledat i tehdy, když se pravidla mezitím změnila. Pro přechod na XRechnung 4.0 by vaše testovací prostředí mělo umět kontrolovat obě verze souběžně.
Vyhodnocení protokolů o kontrole napříč všemi zákazníky
Pokud váš software vytváří e-faktury pro mnoho zákazníků, vyplatí se vyhodnocovat protokoly o kontrole napříč všemi zákazníky. Objeví-li se stejné ID pravidla náhle u mnoha zákazníků, leží příčina pravděpodobně v mapování nebo v nové sadě pravidel. Vyskytuje-li se jen u jednoho zákazníka, leží příčina spíše v jeho kmenových datech.
Validace s InvoiceRails
Kroky z tohoto článku můžete zcela implementovat sami. Jednorázová náročnost je přiměřená, trvalá však nikoli: sady pravidel, číselníky a konfigurace kontrol se mění několikrát ročně a každá změna se musí promítnout do vašich testů, vašeho odesílání a vašeho plánování vydání.
Validaci, odesílání a správu sad pravidel proto lze předat i certifikovanému Peppol Access Pointu, jako je InvoiceRails.
Validátor e-faktur pro jednotlivé kontroly
Bezplatný validátor e-faktur od InvoiceRails kontroluje soubory XML v UBL a CII i hybridní faktury PDF, bez přihlášení. Automaticky rozpozná syntaxi, verzi a profil, mimo jiné XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X a další profily EN 16931. Poté soubor validuje podle schématu XML a také podle pravidel Schematron a obchodních pravidel rozpoznaného profilu. Protokol o kontrole si můžete stáhnout jako PDF nebo sdílet odkazem, například když vaše podpora probírá odmítnutou fakturu se zákazníkem.
API InvoiceRails ve vašem softwaru
InvoiceRails je Peppol Access Point od fino data services certifikovaný OpenPeppol. Váš software napojí InvoiceRails přes REST API a jeho prostřednictvím odesílá a přijímá e-faktury pro libovolný počet zákazníků, na přání jako white-label.
API nabízí validaci jako samostatný endpoint, rovněž s automatickým rozpoznáním profilu. Váš software tak může e-faktury kontrolovat ihned po vytvoření. Každé hlášení v odpovědi obsahuje ID pravidla, závažnost, text hlášení a umístění jako XPath. Váš software může ID validace uložit k faktuře a výsledek znovu načíst po dobu nejméně 90 dnů.
InvoiceRails validuje každý soubor, který váš software odesílá přes Peppol, i bez tohoto volání. Váš software musí předem ověřit, které formáty příjemce podporuje.
InvoiceRails kontroluje i příchozí e-faktury a předává vašemu softwaru původní soubor spolu s načtenými údaji z faktury. Webhook oznamuje vašemu softwaru každou změnu stavu doručení.
Váš software nadále zajišťuje přiřazení polí z vašeho datového modelu, srozumitelná upozornění ve vašem rozhraní a kontroly věrohodnosti povinných údajů, které žádné pravidlo nepokrývá.