XRechnung, ZUGFeRD en BIS Billing 3.0: welke e-factuurformaten uw software zou moeten ondersteunen

De EN 16931 beschrijft een semantisch datamodel. Ze legt vast welke gegevens een factuur bevat en hoe ze zich tot elkaar verhouden, bijvoorbeeld het factuurnummer als BT-1 of de referentie van de koper als BT-10. De norm zelf is geen bestandsformaat.

Voor de technische weergave staat ze twee syntaxen toe: UBL en UN/CEFACT CII. Beide geven hetzelfde semantische model weer, maar verschillen in elementnamen en opbouw. Software die alleen UBL inleest, kan een CII-factuur niet automatisch verwerken, ook al is die normconform.

Voor de implementatie bepaalt dat de onderhoudslast. Twee parallelle mappings betekenen dat elke regelwijziging op twee plaatsen moet worden doorgevoerd. Wie in plaats daarvan eenmaal naar het semantische model van de norm mapt en daaruit beide syntaxen aanmaakt, past per wijziging slechts één plaats aan.

Bij ontvangst wordt het binnenkomende bestand omgekeerd eerst naar het semantische model gemapt en van daaruit in uw datamodel overgenomen.

Boven de norm liggen de nationale en netwerkspecifieke uitwerkingen, in de standaard Core Invoice Usage Specification genoemd, kortweg CIUS. Een CIUS perkt de norm in. Ze maakt optionele velden verplicht, sluit andere uit en brengt eigen Schematron-regels mee. Uitwerkingen die verder gaan dan de reikwijdte van de norm, heten extension.

Ongeacht syntaxis en uitwerking is een e-factuur ofwel een zuiver XML-bestand ofwel een PDF/A-3 met een ingebed XML-bestand. Voor het tweede geval is de term hybride formaat gangbaar geworden.

XRechnung is een CIUS van de EN 16931 en wordt beheerd door de Duitse coördinatiedienst voor IT-standaarden (Koordinierungsstelle für IT-Standards), kortweg KoSIT. Ze bestaat in beide syntaxen. Een weergavecomponent heeft ze niet; het bestand is zuiver XML.

XRechnung is voorgeschreven voor facturen aan de Duitse federale overheid. De factuur wordt geadresseerd via de Leitweg-ID, die in de gegevensset als referentie van de koper wordt vermeld.

De indieningsroute hangt af van de ontvanger. In aanmerking komen de portalen ZRE en OZG-RE of een Peppol Access Point. In B2B speelt de Leitweg-ID geen rol. Daar is XRechnung slechts een van meerdere toegestane profielen.

Momenteel geldt versie 3.0.2. Voor XRechnung 4.0, de implementatie van de EN 16931 in de versie 2026, is er al een voorversie. De definitieve versie van XRechnung 4.0 wordt naar verwachting in het voorjaar van 2027 gepubliceerd.

ZUGFeRD verpakt een XML-bestand volgens CII in een PDF/A-3. De mens ziet de pdf, terwijl de software de XML leest.

De specificatie kent meerdere profielen met een verschillende gegevensomvang, van MINIMUM tot EXTENDED.

MINIMUM en BASIC WL bevatten geen volledige factuur en voldoen niet aan de norm. Vanaf het profiel EN 16931, in oudere versies COMFORT genoemd, is het gestructureerde deel normconform. Uw software zou het profiel bij de import moeten uitlezen en bestanden met MINIMUM of BASIC WL apart moeten behandelen, bijvoorbeeld via een handmatige controle.

Factur-X is technisch grotendeels gelijk aan ZUGFeRD.

ZUGFeRD is vooral zinvol waar uw klanten factureren aan ontvangers die facturen nog steeds visueel controleren. Daarbij is alleen de ingebedde XML juridisch doorslaggevend. Wijken pdf en XML van elkaar af, dan gaan volgens de BMF-circulaire van 15 oktober 2025 de gegevens van het gestructureerde deel voor.

Een goedkeuringsproces dat alleen de pdf controleert, kan daarom een factuur goedkeuren waarvan de doorslaggevende inhoud anders luidt.

Bij verzending zou uw software pdf en XML uit dezelfde gegevensset moeten aanmaken, zodat ze niet uit elkaar lopen. Bij ontvangst zou ze voor de controle een eigen weergave uit de XML moeten opbouwen, in plaats van de meegeleverde pdf te tonen. Het Duitse federale ministerie van Financiën raadt eveneens aan het XML-deel zelf te visualiseren.

Peppol BIS Billing 3.0 is eveneens een CIUS van de EN 16931, vastgelegd op UBL 2.1. OpenPeppol heeft het gespecificeerd als eigen formaat voor de uitwisseling van facturen en creditnota’s via het netwerk.

Het brengt naast de regels van de norm eigen Schematron-regels mee. Een bestand kan de controle aan de hand van de EN 16931 doorstaan en op een Peppol-regel stranden. Vaak gaat het om codelijsten of velden die het netwerk strikter definieert dan de norm.

De specificatie wordt in versies verder ontwikkeld. Wie zelf valideert, zou moeten nagaan of zijn regelsets actueel zijn.

Op langere termijn beweegt Peppol zich richting PINT, een internationaal afgestemde basis voor factuurprofielen buiten Europa. Voor de implementatie in Duitsland verandert dat momenteel niets.

Voor deze facturen moet uw software XRechnung kunnen aanmaken. De Leitweg-ID van de ontvanger hoort als verplicht veld in de factuurgegevens en wordt in de XRechnung als referentie van de koper (BT-10) uitgevoerd. Ontbreekt ze of staat ze in het verkeerde veld, dan wijst het ontvangstportaal de factuur af.

De wet eist een factuur volgens EN 16931 en laat het formaat open. XRechnung, ZUGFeRD vanaf het profiel EN 16931 en ook Peppol BIS Billing zijn toegestaan. De ingebedde XML blijft daarbij juridisch doorslaggevend. Wijken pdf en XML van elkaar af, dan controleert de ontvanger mogelijk andere gegevens dan de gegevens die juridisch gelden.

Binnenlandse bedrijven moeten sinds 1 januari 2025 e-facturen volgens EN 16931 kunnen ontvangen. Voor een normconforme e-factuur heeft de afzender daarom geen instemming van de ontvanger nodig, ook als deze een bepaald formaat verkiest.

Beide partijen hoeven alleen afspraken te maken over de verzendroute en over formaten buiten de norm. In de praktijk hoort de afgesproken route daarom in de stamgegevens van de afzonderlijke zakenpartner.

Naast Peppol BIS Billing 3.0 kunnen via het Peppol-netwerk ook XRechnung en sinds maart 2025 ZUGFeRD als hybride bestand worden verzonden. De documenttypen die een ontvanger in de directorydienst heeft geregistreerd, laten zien welke formaten hij accepteert. Vóór verzending moet uw software deze registratie opvragen en het passende formaat kiezen. Voor afzonderlijke controles toont Peppol-ID opzoeken dat zonder aanmelding.

In de dagelijkse werking zou uw software deze opvraging vóór verzending automatisch moeten uitvoeren, ofwel rechtstreeks via de directorydiensten SML en SMP, ofwel via de API van uw Peppol Access Point. Op basis daarvan wordt een gemeenschappelijk ondersteund formaat vastgesteld en vervolgens de e-factuur in dat formaat gegenereerd.

Inkomende facturen komen binnen in het formaat dat de afzender heeft gekozen. Uw software zou daarom beide syntaxen moeten kunnen lezen, UBL en CII, en daarmee ook XRechnung in beide varianten. Daarbij komen ZUGFeRD en Factur-X als hybride bestanden en, zodra uw klanten facturen uit het buitenland ontvangen, de daar gangbare profielen.

Elk binnenkomend bestand bevat een identificatie van de uitwerking die het gebruikt. In UBL staat die in het element cbc:CustomizationID, in CII in de contextparameter van de richtlijn. Uw software zou deze identificatie eerst moeten uitlezen, want daarvan hangt af welke controleregels gelden en hoe het bestand in uw datamodel wordt overgenomen.

Sommige Peppol Access Points nemen u deze stap uit handen. Ze controleren het binnenkomende bestand, lezen de factuurgegevens uit en geven ze samen met het originele bestand door als uniforme gegevensset.

Uw software zou de ontvangst volledig moeten afdekken vóór de verzending, dus beide syntaxen en de hybride formaten, want uw klanten moeten nu al e-facturen kunnen ontvangen.

De verzending wordt voor uw klanten in twee fasen verplicht. Vanaf 1 januari 2027 bij meer dan 800.000 euro totale omzet in het voorgaande jaar en vanaf 1 januari 2028 voor alle overige binnenlandse B2B-transacties.

Wie met de syntaxis CII begint, kan daarmee XRechnung in de CII-variant en ZUGFeRD aanmaken. UBL wordt nodig zodra ontvangers in het Peppol-netwerk Peppol BIS Billing 3.0 verwachten, want dat formaat vereist UBL.

Alle verplichte btw-gegevens moeten machinaal verwerkbaar in het gestructureerde deel van de e-factuur staan. Daartoe behoort ook de omschrijving van de prestatie. Een verwijzing naar een bijlage, een leveringsbon of een link vervangt geen verplicht veld. De grondslag vormen de FAQ van het Duitse federale ministerie van Financiën over e-facturering en de BMF-circulaire van 15 oktober 2025.

De reden ligt in de opbouw van de e-factuur. Bij hybride formaten zoals ZUGFeRD zijn de gegevens in de XML leidend; de pdf is slechts een weergave. Een gegeven dat alleen in de pdf zichtbaar is, telt daarom niet.

Ontbreekt een verplicht gegeven in het gestructureerde deel, dan geldt de factuur als niet correct en kan het recht op aftrek van voorbelasting van de ontvanger in gevaar komen. Uw klanten merken dat uiterlijk wanneer zakenpartners facturen om die reden afwijzen.

Veel factuursjablonen bevatten verplichte gegevens als tekstblokken die alleen in de pdf verschijnen. Vaak betreft dat de omschrijving van de prestatie, bijvoorbeeld “volgens offerte 2026-114”, de prestatieperiode in de voettekst van de factuur en de vermelding van de verleggingsregeling (btw verlegd naar de afnemer).

In het datamodel zou elk van deze gegevens een eigen veld moeten hebben, waaruit de XML wordt gevuld. De prestatieperiode hoort in de velden voor de factuurperiode (BG-14), de vermelding van de verleggingsregeling in de btw-categorie met vrijstellingsgrond (BT-120 en BT-121).

De technische validatie controleert of de verplichte velden van de norm aanwezig en formeel correct ingevuld zijn. Ze herkent niet of een omschrijving van de prestatie voor de btw volstaat. Een factuur kan de controle dus doorstaan en een verplicht gegeven toch slechts onvoldoende bevatten.

Leveringsbonnen, urenstaten en andere begeleidende documenten bij de factuur kunnen als bijlage in de e-factuur worden ingebed, in de EN 16931 via de groep aanvullende bewijsstukken (BG-24). Dat vervangt de afzonderlijke verzending en houdt factuur en bewijsstuk samen in één bestand.

Een XRechnung wordt gecontroleerd aan de hand van twee regelsets: de regels van de EN 16931 en de aanvullende regels van de KoSIT. Voor Peppol BIS Billing 3.0 geldt hetzelfde met de regels van OpenPeppol. Een controle alleen aan de hand van de norm zegt daarom maar beperkt iets over de vraag of de ontvanger het bestand accepteert. Uw software zou moeten controleren aan de hand van de regelset van de uitwerking die de ontvanger verwacht.

KoSIT en OpenPeppol publiceren regelmatig nieuwe versies van hun regelsets met aangepaste codelijsten en Schematron-regels. Houdt uw software de regelsets niet actueel, dan kunnen facturen worden afgewezen die tot nu toe werden geaccepteerd. De afwijzing komt dan van de ontvanger, maar de oorzaak ligt in de eigen, verouderde regelset.

Voor tests tijdens de ontwikkeling kunnen afzonderlijke bestanden met de gratis e-factuurvalidator worden gecontroleerd aan de hand van de EN 16931 en de Peppol-regels. Voor de automatische controle tijdens de werking biedt InvoiceRails de validatie ook via een API aan, aan de hand van de EN 16931 en profielen zoals XRechnung, ZUGFeRD en Peppol BIS Billing. Het controlerapport vermeldt fouten, waarschuwingen en aanwijzingen afzonderlijk.

Een mapping wordt eenmaal gebouwd; de controleregels erachter kunnen meerdere keren per jaar veranderen. De volgende grote overstap staat met XRechnung 4.0 en de EN 16931 in de versie 2026 al op stapel.

De versie 2026 steunt op UBL 2.5. In conforme implementaties kan UBL 2.5 pas worden gebruikt wanneer CEN een geactualiseerde syntax binding heeft gepubliceerd. Tot dan gelden de bestaande bindings op basis van UBL 2.1. Leveranciers kunnen de overstap dus voorbereiden, maar nog niet uitvoeren.

Wie de koppeling zelf bouwt, neemt dit beheer blijvend op zich. Daartoe behoort het actueel houden van de mappings voor beide syntaxen, de codelijsten en de Schematron-regels en het volgen van de versieplanningen van KoSIT, FeRD, OpenPeppol en CEN. Dat is haalbaar, maar kost ontwikkeltijd die in het eigen product ontbreekt.

Als alternatief kan het formaatbeheer worden uitbesteed aan een Peppol Access Point. InvoiceRails, het door OpenPeppol gecertificeerde Access Point van fino data services, dekt via een API meer dan 60 formaten af, waaronder XRechnung, ZUGFeRD en Factur-X, en houdt validatieregels en formaatupdates doorlopend bij.

Leveranciers koppelen verzending en ontvangst eenmaal en stellen de functie beschikbaar aan een onbeperkt aantal van hun klanten, desgewenst onder eigen merk. Het mappen van de eigen factuurgegevens naar de interface blijft bij de leverancier, net als de verplichte velden in het eigen datamodel.

Hoe softwareleveranciers e-facturering in principe in hun eigen product brengen, leest u in het artikel over e-facturering voor softwareleveranciers.