Factur-X vs ZUGFeRD vs UBL, een praktische gids voor Europese facturatie
De naamgeving rond Europese gestructureerde facturatie is een rommeltje. Factur-X, ZUGFeRD en UBL klinken als drie concurrerende formaten, en veel leverancierscommunicatie behandelt ze ook zo. Ze concurreren niet echt. Twee ervan zijn hetzelfde ding onder verschillende nationale merknamen, en de derde leeft op een totaal andere laag van de stack. Loopt jouw pipeline over grenzen, dan kom je ze alle drie tegen, en weten hoe ze samenhangen scheelt verrassend veel debuggen.
Hier de praktische versie.
Het korte antwoord
- ZUGFeRD is de Duitse hybride factuurstandaard. PDF/A-3 met ingebedde XML.
- Factur-X is de Franse naam voor hetzelfde ding. De XML-schema’s zijn op byteniveau gelijk aan ZUGFeRD 2.x voor de profielen die beide standaarden delen.
- UBL zit op een andere laag. Het is het pure XML-factuurformaat dat over Peppol reist. Geen pdf erbij.
De echte vraag is dus niet “Factur-X vs ZUGFeRD vs UBL”. Het is “hybride pdf (Factur-X / ZUGFeRD) vs pure XML (UBL)”.
ZUGFeRD en Factur-X: hetzelfde bestand, andere sticker
ZUGFeRD ontstond in Duitsland in 2014 (FeRD = Forum elektronische Rechnung Deutschland). Frankrijk nam in 2017 dezelfde architectuur over onder de naam Factur-X. Sinds ZUGFeRD 2.1 zijn de profielen MINIMUM, BASIC WL, BASIC, EN 16931 en EXTENDED byte-equivalent met de overeenkomstige Factur-X-profielen. Een correct opgebouwde ZUGFeRD 2.1 EN 16931-factuur is een geldige Factur-X EN 16931-factuur. Je converteert niet tussen de twee. Je labelt het bestand met het merk dat je afnemer verwacht.
De gedeelde profielen, oplopend in detail:
- MINIMUM: net genoeg voor boekhoudkundige referentie. Totaal, btw, leverancier, afnemer.
- BASIC WL (zonder regels): factuur op aggregaatniveau, geen regelitems.
- BASIC: regelitems, maar enkel de EN 16931-verplichte velden per regel.
- EN 16931: het volledige Europese semantische model uit EN 16931. Dit niveau mikken de meeste B2B-mandaten op.
- EXTENDED: leverancier-specifieke uitbreidingen bovenop EN 16931. Gebruik dit alleen als beide kanten van de pipeline de extra velden begrijpen.
Begin je vanaf nul en heb je geen specifieke afnemerseis, mik dan op EN 16931. Het is de kleinste gemene deler die voldoet aan de grote 2026-mandaten en levert hetzelfde bestand op, ongeacht welk nationaal label je erop plakt.
Waar UBL past
UBL (Universal Business Language, OASIS) is een ander beest. Het is geen pdf. Het is een XML-document op zichzelf, ontworpen om tussen machines te reizen. Het Peppol-netwerk draait op UBL. Het Belgische 1 januari 2026-mandaat, de overheidsfacturatie in Nederland en het grensoverschrijdende kanaal naar het Franse Chorus Pro gebruiken allemaal UBL over Peppol BIS Billing 3.0.
De verhouding ziet er dus zo uit:
- Factur-X / ZUGFeRD = PDF/A-3 met XML erin. Geoptimaliseerd voor “ik heb een menselijk leesbare kopie nodig én een machinaal leesbare kopie in hetzelfde bestand”.
- UBL = alleen XML. Geoptimaliseerd voor “machines aan beide kanten, het netwerk verzorgt het transport”.
In de praktijk hebben de meeste EU-pipelines beide nodig. Je verstuurt de factuur als UBL over Peppol omdat het mandaat dat voor het transport eist, en je archiveert een Factur-X / ZUGFeRD-kopie als menselijk leesbaar dossier omdat de fiscale archiefwet dat eist.
Let op één subtiliteit: ZUGFeRD 2.x en Factur-X 1.x kunnen ook UBL inbedden, niet alleen CII. Dezelfde hybride pdf kan binnenin CII (Cross Industry Invoice, het oorspronkelijke schema) of UBL dragen. De meeste Duitse pipelines gebruiken CII, de meeste Franse pipelines UBL. Beide zijn geldig. Krijg je een Factur-X-bestand binnen en je parser kent enkel CII, dan mis je geruisloos de helft van de inkomende facturen uit de Duitse markt.
Wanneer welke gebruiken
Gebruik UBL alleen als de factuur uitsluitend door machines verwerkt wordt en het netwerk de archivering aan beide kanten al regelt. Dit is de Peppol-case, government-to-business en de meeste publieke-sectorflows.
Gebruik Factur-X / ZUGFeRD wanneer:
- Je afnemer een privaat bedrijf is dat de factuur wil bekijken voordat hij betaalt.
- Je de menselijk leesbare pdf nodig hebt als wettelijke archiefkopie.
- Je de Duitse of Franse grens oversteekt, waar hybride het dominante private-sectorformaat is.
- Je één bestand wil dat je kunt mailen en één bestand dat je kunt inlezen.
Gebruik beide, parallel, wanneer het mandaat Peppol-levering eist (UBL) en de fiscale archiefplicht een menselijk leesbare kopie eist (PDF/A-3). Dat is de feitelijke realiteit voor B2B in België sinds januari 2026 en wordt vanaf september 2026 de realiteit in Frankrijk.
De grensoverschrijdende randgevallen
Een paar patronen die mensen verrassen:
- Afnemer eist Factur-X, leverancier stuurt ZUGFeRD. Geen conversie nodig als beide 2.1 EN 16931 zijn. Bevestig gewoon de versie. We zien pipelines zinloze XML-herschrijvingen doen op dit punt.
- Afnemer eist UBL over Peppol, leverancier heeft enkel Factur-X. Je moet de ingebedde XML extraheren, CII naar UBL transformeren en over Peppol verzenden. Dit is het meest voorkomende “hybride naar pure XML”-gat.
- Leverancier stuurt Factur-X met UBL erin, parser van afnemer verwacht CII. Parst geruisloos nul regels. Je hebt een parser nodig die beide probeert.
- PDF/A-3 geldig, ingebedde XML ongeldig. PDF/A-3-validatie kijkt niet in de bijlage. Je hebt een validator nodig die de XML apart tegen EN 16931 controleert.
Dit is precies wat onze publieke validator op /check doet: hij inspecteert de PDF/A-3-conformiteit, extraheert de bijlage ongeacht of die CII of UBL is, en valideert de XML tegen het EN 16931 semantische model. Je krijgt een verdict per laag, zodat je bij een fout meteen weet of het probleem in de container, het schema of de data zit.
De conclusie
Stop met Factur-X, ZUGFeRD en UBL als alternatieven te zien. Factur-X en ZUGFeRD zijn dezelfde hybride envelop onder twee nationale merken. UBL is het pure-XML-formaat over Peppol. Echte grensoverschrijdende pipelines in 2026 produceren beide, archiveren de hybride en verzenden de pure XML. Wie je vertelt dat je er één moet kiezen, heeft niet genoeg grenzen overgestoken.