XRechnung, ZUGFeRD a BIS Billing 3.0: které formáty e-faktur by měl váš software podporovat

EN 16931 popisuje sémantický datový model. Určuje, jaké údaje faktura obsahuje a jak spolu souvisejí, například číslo faktury jako BT-1 nebo referenci kupujícího jako BT-10. Norma sama o sobě není formátem souboru.

Pro technické vyjádření připouští dvě syntaxe: UBL a UN/CEFACT CII. Obě vyjadřují stejný sémantický model, liší se však názvy prvků a strukturou. Software, který načítá pouze UBL, nedokáže fakturu v CII automaticky zpracovat, i když odpovídá normě.

Pro implementaci to rozhoduje o náročnosti údržby. Dvě paralelní mapování znamenají, že každou změnu pravidel je nutné promítnout na dvou místech. Kdo místo toho mapuje jednou na sémantický model normy a z něj vytváří obě syntaxe, upravuje při každé změně jen jedno místo.

Při příjmu se naopak příchozí soubor nejprve namapuje na sémantický model a odtud se převezme do vašeho datového modelu.

Nad normou leží národní a síťové varianty, ve standardu nazývané Core Invoice Usage Specification, zkráceně CIUS. CIUS normu zužuje. Činí volitelná pole povinnými, jiná vylučuje a přináší vlastní pravidla Schematron. Varianty, které jdou nad rámec normy, se nazývají Extension.

Nezávisle na syntaxi a variantě existuje e-faktura buď jako čistý soubor XML, nebo jako PDF/A-3 s vloženým souborem XML. Pro druhý případ se vžil výraz hybridní formát.

XRechnung je CIUS normy EN 16931 a spravuje ji německý Koordinační úřad pro IT standardy, zkráceně KoSIT. Existuje v obou syntaxích. Vizuální složku nemá, soubor je čisté XML.

XRechnung je předepsán pro faktury německé spolkové správě. Faktura se adresuje přes Leitweg-ID, které se v datovém záznamu uvádí jako reference kupujícího.

Cesta podání závisí na příjemci. V úvahu přicházejí portály ZRE a OZG-RE nebo Peppol Access Point. V B2B nehraje Leitweg-ID žádnou roli. Tam je XRechnung jen jedním z několika přípustných profilů.

V současnosti platí verze 3.0.2. Pro XRechnung 4.0, implementaci EN 16931 ve verzi 2026, již existuje předběžná verze. Finální verze XRechnung 4.0 bude zveřejněna pravděpodobně na jaře 2027.

ZUGFeRD vkládá soubor XML v syntaxi CII do PDF/A-3. Člověk vidí PDF, zatímco software čte XML.

Specifikace zná několik profilů s různým rozsahem dat, od MINIMUM po EXTENDED.

MINIMUM a BASIC WL neobsahují úplnou fakturu a normu nesplňují. Od profilu EN 16931, ve starších verzích nazývaného COMFORT, odpovídá strukturovaná část normě. Váš software by měl profil při importu načíst a soubory s MINIMUM nebo BASIC WL zpracovávat odděleně, například prostřednictvím ruční kontroly.

Factur-X je technicky z velké části totožný se ZUGFeRD.

ZUGFeRD má smysl především tam, kde vaši zákazníci fakturují příjemcům, kteří faktury i nadále kontrolují vizuálně. Právně rozhodující je přitom pouze vložené XML. Pokud se PDF a XML liší, mají podle dopisu německého spolkového ministerstva financí (BMF) ze dne 15. října 2025 přednost data strukturované části.

Schvalovací proces, který kontroluje pouze PDF, proto může schválit fakturu, jejíž rozhodující obsah zní jinak.

Při odesílání by měl váš software vytvářet PDF i XML ze stejného datového záznamu, aby se od sebe nevzdálily. Při příjmu by měl pro kontrolu sestavit vlastní zobrazení z XML, místo aby zobrazoval dodané PDF. Německé spolkové ministerstvo financí rovněž doporučuje část XML vizualizovat samostatně.

Peppol BIS Billing 3.0 je rovněž CIUS normy EN 16931, vázaná na UBL 2.1. OpenPeppol jej specifikoval jako vlastní formát pro výměnu faktur a dobropisů přes síť.

Kromě pravidel normy přináší vlastní pravidla Schematron. Soubor může projít kontrolou podle EN 16931 a neuspět u pravidla Peppol. Často jde o číselníky nebo pole, která síť vymezuje úžeji než norma.

Specifikace se vyvíjí ve verzích. Kdo validuje sám, měl by ověřit, zda jeho sady pravidel odpovídají aktuálnímu stavu.

Dlouhodobě se Peppol posouvá směrem k PINT, mezinárodně sladěnému základu pro fakturační profily mimo Evropu. Pro implementaci v Německu to v současnosti nic nemění.

Pro tyto faktury musí váš software umět vytvářet XRechnung. Leitweg-ID příjemce patří jako povinné pole do datového záznamu faktury a v XRechnung se uvádí jako reference kupujícího (BT-10). Pokud chybí nebo je ve špatném poli, přijímací portál fakturu odmítne.

Zákon vyžaduje fakturu podle EN 16931 a formát nechává otevřený. Přípustné jsou XRechnung, ZUGFeRD od profilu EN 16931 i Peppol BIS Billing. Vložené XML přitom zůstává právně rozhodující. Pokud se PDF a XML liší, kontroluje příjemce možná jiné údaje než ty, které právně platí.

Tuzemské firmy musí být od 1. ledna 2025 schopny přijímat e-faktury podle EN 16931. Pro e-fakturu odpovídající normě proto odesílatel nepotřebuje souhlas příjemce, i když ten preferuje určitý formát.

Obě strany se musí dohodnout pouze na cestě přenosu a na formátech mimo normu. V praxi proto dohodnutá cesta patří do kmenových dat jednotlivého obchodního partnera.

Kromě Peppol BIS Billing 3.0 lze přes síť Peppol přenášet také XRechnung a od března 2025 i ZUGFeRD jako hybridní soubor. Typy dokumentů, které má příjemce zaregistrované v adresářové službě, ukazují, které formáty přijímá. Před odesláním musí váš software tuto registraci zjistit a zvolit vhodný formát. Pro jednotlivé kontroly to bez přihlášení zobrazí vyhledávání Peppol ID.

V běžném provozu by měl váš software tento dotaz před odesláním pokládat automaticky, buď přímo přes adresářové služby SML a SMP, nebo přes API vašeho Peppol Access Pointu. Na tomto základě se určí společně podporovaný formát a e-faktura se poté vygeneruje v tomto formátu.

Příchozí faktury přicházejí ve formátu, který zvolil odesílatel. Váš software by proto měl umět číst obě syntaxe, UBL i CII, a tím i XRechnung v obou variantách. K tomu přistupují ZUGFeRD a Factur-X jako hybridní soubory a jakmile vaši zákazníci dostávají faktury ze zahraničí, také tam obvyklé profily.

Každý příchozí soubor obsahuje identifikátor, kterou variantu používá. V UBL je v prvku cbc:CustomizationID, v CII v kontextovém parametru směrnice (guideline). Váš software by měl tento identifikátor načíst jako první, protože na něm závisí, která kontrolní pravidla se uplatní a jak se soubor převezme do vašeho datového modelu.

Některé Peppol Access Pointy vám tento krok usnadní. Zkontrolují příchozí soubor, načtou údaje z faktury a předají je spolu s původním souborem jako jednotný datový záznam.

Váš software by měl plně pokrýt příjem dříve než odesílání, tedy obě syntaxe a hybridní formáty, protože vaši zákazníci musí být schopni přijímat e-faktury již dnes.

Odesílání se pro vaše zákazníky stává povinným ve dvou fázích. Od 1. ledna 2027 při celkovém obratu za předchozí rok vyšším než 800 000 eur a od 1. ledna 2028 pro všechna ostatní tuzemská plnění B2B.

Kdo začne se syntaxí CII, může s ní vytvářet XRechnung ve variantě CII i ZUGFeRD. UBL je nutné, jakmile příjemci v síti Peppol očekávají Peppol BIS Billing 3.0, protože tento formát UBL vyžaduje.

Všechny povinné údaje pro účely DPH musí stát strojově vyhodnotitelně ve strukturované části e-faktury. Patří k nim i popis plnění. Odkaz na přílohu, dodací list nebo odkaz na web povinné pole nenahrazuje. Základem jsou časté dotazy (FAQ) německého spolkového ministerstva financí k e-fakturaci a dopis BMF ze dne 15. října 2025.

Důvod spočívá ve struktuře e-faktury. U hybridních formátů, jako je ZUGFeRD, jsou určující data v XML, PDF je pouze zobrazení. Údaj, který je viditelný jen v PDF, se proto nepočítá.

Pokud povinný údaj ve strukturované části chybí, považuje se faktura za nesprávnou a nárok příjemce na odpočet DPH může být ohrožen. Vaši zákazníci to zjistí nejpozději ve chvíli, kdy jim obchodní partneři faktury z tohoto důvodu vrátí.

Mnoho šablon faktur přenáší povinné údaje jako textové bloky, které se objevují pouze v PDF. Často se to týká popisu plnění, například „podle nabídky 2026-114“, období plnění v zápatí faktury a upozornění na přenesení daňové povinnosti na příjemce plnění.

V datovém modelu by měl mít každý z těchto údajů vlastní pole, ze kterého se plní XML. Období plnění patří do polí pro zúčtovací období (BG-14), upozornění na reverse charge do kategorie daně s důvodem osvobození (BT-120 a BT-121).

Technická validace kontroluje, zda jsou povinná pole normy přítomna a formálně správně vyplněna. Nerozpozná, zda je popis plnění z hlediska DPH dostatečný. Faktura tedy může kontrolou projít, a přesto obsahovat povinný údaj jen nedostatečně.

Dodací listy, výkazy hodin a další podklady doprovázející fakturu lze vložit do e-faktury jako přílohu, v EN 16931 přes skupinu dodatečných podkladů (BG-24). To nahrazuje samostatné zasílání a drží fakturu i doklad pohromadě v jednom souboru.

XRechnung se kontroluje podle dvou sad pravidel, pravidel EN 16931 a doplňujících pravidel KoSIT. Pro Peppol BIS Billing 3.0 platí totéž s pravidly OpenPeppol. Kontrola pouze podle normy proto jen omezeně vypovídá o tom, zda příjemce soubor přijme. Váš software by měl kontrolovat podle sady pravidel té varianty, kterou příjemce očekává.

KoSIT a OpenPeppol pravidelně zveřejňují nové verze svých sad pravidel s upravenými číselníky a pravidly Schematron. Pokud váš software sady pravidel neudržuje aktuální, mohou být odmítnuty faktury, které byly dosud přijímány. Odmítnutí pak přichází od příjemce, příčina však leží ve vlastní zastaralé sadě pravidel.

Pro testy během vývoje lze jednotlivé soubory zkontrolovat bezplatným validátorem e-faktur podle EN 16931 a pravidel Peppol. Pro automatickou kontrolu v provozu nabízí InvoiceRails validaci i přes API, podle EN 16931 a profilů jako XRechnung, ZUGFeRD a Peppol BIS Billing. Protokol o kontrole uvádí chyby, varování a upozornění odděleně.

Mapování se vytvoří jednou, kontrolní pravidla za ním se však mohou měnit několikrát ročně. Další větší změna již čeká s XRechnung 4.0 a EN 16931 ve verzi 2026.

Verze 2026 se opírá o UBL 2.5. V implementacích odpovídajících normě lze UBL 2.5 použít až poté, co CEN zveřejní aktualizované syntaktické vazby (syntax binding). Do té doby platí stávající vazby na bázi UBL 2.1. Poskytovatelé tedy mohou přechod připravovat, ale zatím ne realizovat.

Kdo si připojení buduje sám, přebírá tuto údržbu trvale. Patří k ní udržovat aktuální mapování pro obě syntaxe, číselníky a pravidla Schematron a sledovat plány verzí KoSIT, FeRD, OpenPeppol a CEN. Je to proveditelné, váže to však vývojový čas, který ve vlastním produktu chybí.

Alternativně lze správu formátů svěřit Peppol Access Pointu. InvoiceRails, Access Point od fino data services certifikovaný OpenPeppol, pokrývá přes API více než 60 formátů, mimo jiné XRechnung, ZUGFeRD a Factur-X, a validační pravidla i aktualizace formátů průběžně udržuje.

Poskytovatelé napojí odesílání a příjem jednou a funkci zpřístupní libovolnému počtu svých zákazníků, na přání pod vlastní značkou. Mapování vlastních fakturačních dat na rozhraní zůstává na poskytovateli, stejně jako povinná pole ve vlastním datovém modelu.

Jak poskytovatelé softwaru obecně přinášejí e-fakturaci do vlastního produktu, si přečtěte v článku o e-fakturaci pro poskytovatele softwaru.