← Back to all articles

UBL vs CII: welke factuur-XML-syntaxis kies je?

SealDoc Team · · 5 min read

Twee XML-syntaxen kunnen een EN16931-conforme elektronische factuur weergeven: UBL 2.1 en UN/CEFACT Cross Industry Invoice (CII). Beide zijn correct. Beide worden geaccepteerd door EN16931. En beide zijn structureel voldoende anders dat code geschreven voor het ene formaat het andere niet zonder een afzonderlijke implementatie kan parsen.

Als je in 2026 een factuurpijplijn in Europa bouwt, kom je waarschijnlijk beide tegen. Hier is wat je moet weten om het juiste te kiezen en het andere te kunnen verwerken.

Wat ze gemeen hebben

Zowel UBL als CII zijn serialisaties van hetzelfde semantische model: EN16931. Een naam van de verkoper is een naam van de verkoper. Een btw-bedrag is een btw-bedrag. De business terms (BT) en business groups (BG) zijn identiek voor beide syntaxen.

EN 16931-2 definieert de officiele koppeling van elke BT aan zijn XML-pad in beide syntaxen. Het document is gratis beschikbaar via CEN/TC 434 en is de gezaghebbende naslag wanneer je beide moet implementeren.

Beide formaten zijn gebaseerd op internationale standaarden en worden geaccepteerd door EN16931-validators. Beide produceren machine-leesbare gestructureerde facturen.

Hoe ze structureel verschillen

De verschillen zijn significant en alomtegenwoordig. Elementnamen, naamruimteprefixes, neststructuren en attribuutconventies zijn allemaal anders.

Naam verkoper (BT-27)

UBL 2.1:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

CII:

<rsm:SupplyChainTradeTransaction>
  <ram:SellerTradeParty>
    <ram:Name>Acme GmbH</ram:Name>
  </ram:SellerTradeParty>
</rsm:SupplyChainTradeTransaction>

UBL gebruikt diepe nesting met naamruimten voor aggregaatcomponenten (cac:) en basiscomponenten (cbc:). CII is vlakker, met ram: (Reusable Aggregate Module) en rsm: (Reusable Schema Module) naamruimten.

Nettobedrag factuurregel (BT-131)

UBL 2.1:

<cac:InvoiceLine>
  <cbc:LineExtensionAmount currencyID="EUR">250.00</cbc:LineExtensionAmount>
</cac:InvoiceLine>

CII:

<ram:IncludedSupplyChainTradeLineItem>
  <ram:SpecifiedLineTradeSettlement>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>250.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>

Valutacodes in CII zijn op sommige plaatsen elementattributen en op andere afwezig (met de valuta gedeclareerd op headerniveau). UBL is consistenter: currencyID verschijnt op elk monetair bedragselement.

Rootelement en naamruimten

UBL 2.1 gebruikt drie naamruimten:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

CII gebruikt drie andere naamruimten:

<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

Er is geen overlap tussen de twee naamruimtesets. Een parser gericht op het ene formaat kan het andere niet verwerken.

Welk formaat waar verplicht is

De keuze is zelden de jouwe. Het formaat wordt bepaald door het doelland, het leverkanaal en het compliancekader.

FormaatVerplicht door
UBL 2.1Peppol BIS Billing 3.0 (netwerktransport)
CIIFactur-X, ZUGFeRD, XRechnung (beide CII en UBL geaccepteerd)
CII of UBLFrankrijk (Portail Public de Facturation: beide geaccepteerd)

Peppol BIS Billing 3.0 is uitsluitend UBL. Als je via het Peppol-netwerk verzendt, moet je UBL produceren.

Factur-X en ZUGFeRD zijn CII. De factur-x.xml-bijlage in een PDF/A-3 is altijd CII.

XRechnung accepteert zowel CII als UBL, maar CII (CrossIndustryInvoice) wordt vaker getest door validators van Duitse overheidsportalen.

Conversie tussen formaten

Er is geen verliesvrije automatische conversie tussen UBL en CII. De semantische inhoud is identiek, maar:

  • Sommige velden zijn attributen in het ene formaat en elementen in het andere
  • De nestdiepte verschilt, wat invloed heeft op hoe je opeenvolgende items zoals factuurregels uitleest
  • Valutacodeplacement verschilt tussen formaten (sommige CII-implementaties gaan ervan uit dat de headervaluta van toepassing is op alle regels)
  • Datumformaten verschillen: UBL gebruikt JJJJ-MM-DD, CII gebruikt JJJJMMDD met een format="102"-attribuut

Conversie is mogelijk maar vereist een speciale koppelingslaag. XSLT wordt vaak gebruikt; de OpenPEPPOL-gemeenschap biedt referentiekoppelingen.

Prestaties en tooling

UBL wordt breder ondersteund in .NET- en Java-bibliotheken. OASIS UBL bestaat al sinds 2006 en de meeste enterprise-XML-tooling heeft er expliciete ondersteuning voor.

CII is minder gangbaar in Europese developertooling buiten Frankrijk en Duitsland. Er bestaan parserbiblotheken maar die zijn doorgaans meer gespecialiseerd.

Saxon HE verwerkt Schematron-validatie voor beide. De voorgecompileerde XSLT-bestanden van de Peppol BIS GitHub releases bevatten afzonderlijke XSLT-bestanden:

peppol-en16931-ubl.xsl    (voor UBL-facturen)
peppol-en16931-cii.xsl    (voor CII-facturen)

Voer elk uit op het juiste invoerformaat.

Welk formaat eerst te implementeren

Voor de meeste developers die in 2026 een nieuwe Europese factuurintegratie starten, is UBL het betere startpunt:

  • Peppol-netwerktransport vereist UBL
  • De meeste EU-landen accepteren UBL op nationale portalen
  • .NET- en Java-tooling is volwassener
  • De UBL-specificatie is consistenter in attribuutplacement

Als je specifiek in Frankrijk of Duitsland opereert, wordt CII noodzakelijk voor Factur-X en ZUGFeRD. Dat is een tweede implementatielaag, geen vervanging.

Voor archiveringsdoeleinden is PDF/A-3 met ingebedde CII de standaard. De meeste pijplijnen die Peppol UBL over het netwerk verzenden, genereren ook een Factur-X CII-pdf voor het archief van de koper. De twee dienen verschillende functies en bestaan naast elkaar.

Een noot over validatie

Ongeacht welke syntaxis je gebruikt, valideer tegen de Schematron-regels van het juiste profiel. Een factuur die geldige UBL is, kan Peppol BIS 3.0-regels overtreden als verplichte Peppol-specifieke elementen ontbreken. Een factuur die geldige CII is, kan mislukken voor het Factur-X EN 16931-profiel als optionele velden die dat profiel vereist, ontbreken.

Het diepere probleem is dat de meeste pijplijnen beide nodig hebben. Een Peppol-aflevering vereist UBL. Het archief van de koper vereist een Factur-X-pdf met ingebedde CII. Het onderhouden van twee onafhankelijke XML-generatiepaden, twee validatiepassen en twee sets Schematron-regelbestanden verdubbelt het oppervlak voor correctheidsfouten.

SealDoc genereert beide uit dezelfde invoer. Een enkele API-aanroep met je factuurgegevens produceert het UBL-document voor Peppol-transmissie en de PDF/A-3 met ingebedde CII voor het archief van de koper. Schematron-validatie wordt uitgevoerd op beide uitvoerbestanden voordat een van beiden wordt teruggegeven. Je hoeft geen van beide XML-generatiepaden te onderhouden of Peppol BIS-releases bij te houden.

Voor het controleren van bestaande bestanden accepteert de SealDoc publieke validator zowel UBL als CII en rapporteert fouten per BT-nummer en business rule-code. Nuttig voor het diagnosticeren van documenten die zijn ontvangen van handelspartners of voor het kalibreren van een externe factuurexport aan EN16931-vereisten.

← Back to all articles