← Back to all articles

UBL vs. CII: Welche Rechnungs-XML-Syntax sollte man wählen?

SealDoc Team · · 4 min read

Zwei XML-Syntaxen können eine EN16931-konforme elektronische Rechnung darstellen: UBL 2.1 und UN/CEFACT Cross Industry Invoice (CII). Beide sind korrekt. Beide werden von EN16931 akzeptiert. Und beide sind strukturell so unterschiedlich, dass Code, der für eine Syntax geschrieben wurde, die andere ohne eine separate Implementierung nicht parsen kann.

Wenn Sie 2026 in Europa eine Rechnungspipeline aufbauen, werden Sie wahrscheinlich auf beide stoßen. Hier ist, was Sie wissen müssen, um die richtige zu wählen und mit der anderen umzugehen.

Was sie gemeinsam haben

Sowohl UBL als auch CII sind Serialisierungen desselben semantischen Modells: EN16931. Ein Lieferantenname ist ein Lieferantenname. Ein USt.-Betrag ist ein USt.-Betrag. Die Business Terms (BT) und Business Groups (BG) sind in beiden Syntaxen identisch.

EN 16931-2 definiert die offizielle Abbildung von jedem BT auf seinen XML-Pfad in beiden Syntaxen. Das Dokument ist kostenlos von CEN/TC 434 erhältlich und ist die maßgebliche Referenz, wenn beide implementiert werden müssen.

Beide Formate basieren auf internationalen Standards und werden von EN16931-Validatoren akzeptiert. Beide erzeugen maschinenlesbare strukturierte Rechnungen.

Wie sie sich strukturell unterscheiden

Die Unterschiede sind erheblich und durchgängig. Elementnamen, Namespace-Präfixe, Verschachtelungsstrukturen und Attributkonventionen sind alle unterschiedlich.

Lieferantenname (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 verwendet tiefe Verschachtelung mit Aggregat-(cac:) und Basis-(cbc:) Komponenten-Namespaces. CII ist flacher, mit ram: (Reusable Aggregate Module) und rsm: (Reusable Schema Module) Namespaces.

Positionsnettobetrag (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>

Währungscodes sind in CII an manchen Stellen Elementattribute und an anderen nicht vorhanden (bei auf Kopfzeilenebene deklarierter Währung). UBL ist konsistenter: currencyID erscheint auf jedem Geldbetragelement.

Wurzelelement und Namespaces

UBL 2.1 verwendet drei Namespaces:

<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 verwendet drei andere Namespaces:

<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">

Zwischen den beiden Namespace-Mengen gibt es keine Überschneidung. Ein Parser, der auf ein Format abzielt, kann das andere nicht verarbeiten.

Welches Format wo vorgeschrieben ist

Die Wahl liegt selten bei Ihnen. Das Format wird durch das Zielland, den Zustellkanal und den Compliance-Rahmen bestimmt.

FormatVorgeschrieben von
UBL 2.1Peppol BIS Billing 3.0 (Netzwerktransport)
CIIFactur-X, ZUGFeRD, XRechnung (sowohl CII als auch UBL akzeptiert)
CII oder UBLFrankreich (Portail Public de Facturation: beide akzeptiert)

Peppol BIS Billing 3.0 ist ausschließlich UBL. Bei der Übertragung über das Peppol-Netzwerk muss UBL erzeugt werden.

Factur-X und ZUGFeRD sind CII. Der factur-x.xml-Anhang in einer PDF/A-3 ist immer CII.

XRechnung akzeptiert sowohl CII als auch UBL, aber CII (CrossIndustryInvoice) wird häufiger von deutschen Behördenportal-Validatoren getestet.

Konvertierung zwischen Formaten

Eine verlustfreie automatische Konvertierung zwischen UBL und CII gibt es nicht. Der semantische Inhalt ist identisch, aber:

  • Manche Felder sind in einem Format Attribute und im anderen Elemente
  • Die Verschachtelungstiefe unterscheidet sich, was das Lesen von sequenziellen Elementen wie Rechnungspositionen beeinflusst
  • Die Währungscode-Platzierung unterscheidet sich zwischen Formaten (manche CII-Implementierungen nehmen an, dass die Kopfzeilenwährung für alle Positionen gilt)
  • Datumsformate unterscheiden sich: UBL verwendet JJJJ-MM-TT, CII verwendet JJJJMMTT mit einem format="102"-Attribut

Konvertierung ist möglich, erfordert aber eine dedizierte Abbildungsschicht. XSLT ist gängig; die OpenPEPPOL-Community stellt Referenzabbildungen bereit.

Performance und Tooling

UBL wird in .NET- und Java-Bibliotheken breiter unterstützt. OASIS UBL gibt es seit 2006, und die meisten Enterprise-XML-Tools haben explizite Unterstützung dafür.

CII ist in europäischem Entwickler-Tooling außerhalb von Frankreich und Deutschland weniger verbreitet. Parser-Bibliotheken existieren, sind aber tendenziell spezialisierter.

Saxon HE behandelt Schematron-Validierung für beide. Die vorkompilierten XSLT-Dateien aus den Peppol-BIS-GitHub-Releases enthalten separate XSLT-Dateien:

peppol-en16931-ubl.xsl    (for UBL invoices)
peppol-en16931-cii.xsl    (for CII invoices)

Jede gegen das passende Eingabeformat ausführen.

Welches zuerst implementiert werden sollte

Für die meisten Entwickler, die 2026 eine neue europäische Rechnungsintegration starten, ist UBL der bessere Ausgangspunkt:

  • Peppol-Netzwerktransport erfordert UBL
  • Die meisten EU-Länder akzeptieren UBL auf nationalen Portalen
  • .NET- und Java-Tooling ist ausgereifter
  • Die UBL-Spezifikation ist bei der Attributplatzierung konsistenter

Wer speziell in Frankreich oder Deutschland tätig ist, für den wird CII für Factur-X und ZUGFeRD notwendig. Das ist eine zweite Implementierungsschicht, kein Ersatz.

Für Archivierungszwecke ist PDF/A-3 mit eingebettetem CII der Standard. Die meisten Pipelines, die Peppol UBL über das Netzwerk übertragen, generieren auch eine Factur-X-CII-PDF für das Archiv des Käufers. Beide dienen verschiedenen Zwecken und koexistieren.

Ein Hinweis zur Validierung

Unabhängig von der verwendeten Syntax sollte gegen die Schematron-Regeln des richtigen Profils validiert werden. Eine Rechnung, die gültiges UBL ist, kann Peppol-BIS-3.0-Regeln verletzen, wenn Peppol-spezifische Pflichtelemente fehlen. Eine Rechnung, die gültiges CII ist, kann das Factur-X-EN-16931-Profil verletzen, wenn für dieses Profil erforderliche optionale Felder fehlen.

Das tiefere Problem ist, dass die meisten Pipelines beides benötigen. Eine Peppol-Zustellung erfordert UBL. Das Archiv des Käufers erfordert eine Factur-X-PDF mit eingebettetem CII. Zwei unabhängige XML-Generierungswege, zwei Validierungsdurchläufe und zwei Sätze von Schematron-Regeldateien zu pflegen verdoppelt die Fehleranfälligkeit.

SealDoc generiert beides aus demselben Input. Ein einziger API-Aufruf mit Ihren Rechnungsdaten erzeugt das UBL-Dokument für die Peppol-Übertragung und die PDF/A-3 mit eingebettetem CII für das Archiv des Käufers. Die Schematron-Validierung läuft gegen beide Outputs, bevor einer davon zurückgegeben wird. Sie müssen weder XML-Generierungswege pflegen noch Peppol-BIS-Releases verfolgen.

Für die Prüfung bestehender Dateien akzeptiert der öffentliche SealDoc-Validator sowohl UBL als auch CII und meldet Fehler nach BT-Nummer und Business-Rule-Code. Nützlich für die Diagnose von Dokumenten, die von Handelspartnern empfangen wurden, oder für die Kalibrierung eines Drittanbieter-Rechnungsexports gegen EN16931-Anforderungen.

← Back to all articles