Zum Inhalt springen

UBL oder CII – zwei Syntaxen für dieselbe Rechnung

Die EN 16931 erlaubt zwei XML-Syntaxen: OASIS UBL 2.1 und UN/CEFACT CII D16B. Beide transportieren dieselben Rechnungsangaben, nur mit anderen Elementnamen und anderer Struktur. Wer XRechnungen empfängt, muss beide verarbeiten können.

Stand:

Datenmodell und Syntax

Die EN 16931 beschreibt zuerst ein syntaxneutrales Datenmodell: Geschäftsbegriffe wie „Invoice number“ (BT-1) oder „Buyer reference“ (BT-10). Teil 2 der Norm legt fest, in welchen XML-Formaten diese Begriffe übertragen werden dürfen. Das sind laut XRechnung-Spezifikation ISO/IEC 19845 Universal Business Language 2.1 (UBL) und UN/CEFACT Cross Industry Invoice, XML-Schemas 16B (CII).

UBL kennt getrennte Nachrichten für Rechnung und Gutschrift. In CII gibt es nur das Dokument CrossIndustryInvoice; eine Gutschrift erkennen Sie dort am Rechnungstyp (BT-3), etwa am Code 381. ZUGFeRD und Factur-X nutzen ausschließlich CII, XRechnung beide Syntaxen.

So erkennen Sie die Syntax

Entscheidend ist der Namespace des Wurzelelements, nicht das Präfix. Präfixe wie ubl: oder rsm: sind frei wählbar, der Namespace nicht.

Wurzelelement einer UBL-Rechnung
<ubl:Invoice xmlns:ubl="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">

Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei standard/01.01a-INVOICE_ubl.xml (Apache 2.0)

Wurzelelement derselben Rechnung in CII
<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
                          xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
                          xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100"
                          xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei standard/01.01a-INVOICE_uncefact.xml (Apache 2.0)

Erkennungsmerkmale, beobachtet an den Testdateien 01.01a der KoSIT-Testsuite
MerkmalUBLCII
WurzelelementInvoice (bei Gutschriften CreditNote)CrossIndustryInvoice
Namespaceurn:oasis:names:specification:ubl:schema:xsd:Invoice-2urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100
Übliche Präfixecbc: (einfache Werte), cac: (Gruppen)rsm:, ram:, udt:
Datum2016-04-0420160404 mit format="102"
ReihenfolgeKopf, Summen, dann PositionenPositionen, dann Vereinbarung, Lieferung, Abrechnung
Währung bei BeträgenAttribut currencyID an jedem Betragin der Testdatei nur am Steuergesamtbetrag

Dasselbe Feld in beiden Syntaxen

Werte aus der Rechnung 01.01a, die in beiden Syntaxen vorliegt
GeschäftsbegriffUBLCIIWert
BT-1 Rechnungsnummercbc:IDram:ID in rsm:ExchangedDocument123456XX
BT-10 Käuferreferenzcbc:BuyerReferenceram:BuyerReference04011000-12345-03
BT-24 Spezifikationskennungcbc:CustomizationIDram:GuidelineSpecifiedDocumentContextParameter/ram:ID…xrechnung_3.0
BT-84 IBANcac:PayeeFinancialAccount/cbc:IDram:PayeePartyCreditorFinancialAccount/ram:IBANIDDE79000000001234567890
BT-109 Summe ohne UStcbc:TaxExclusiveAmountram:TaxBasisTotalAmount314.86
BT-112 Summe mit UStcbc:TaxInclusiveAmountram:GrandTotalAmount336.9

Die Summenblöcke derselben Rechnung zeigen, wie verschieden die Namen sind, obwohl die Zahlen übereinstimmen:

Summen in UBL (BT-106, BT-109, BT-112, BT-115)
<cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">314.86</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">314.86</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">336.9</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">336.9</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei standard/01.01a-INVOICE_ubl.xml (Apache 2.0)

Dieselben Summen in CII, ergänzt um den Steuergesamtbetrag (BT-110)
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    <ram:LineTotalAmount>314.86</ram:LineTotalAmount>
    <ram:TaxBasisTotalAmount>314.86</ram:TaxBasisTotalAmount>
    <ram:TaxTotalAmount currencyID="EUR">22.04</ram:TaxTotalAmount>
    <ram:GrandTotalAmount>336.9</ram:GrandTotalAmount>
    <ram:DuePayableAmount>336.9</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei standard/01.01a-INVOICE_uncefact.xml (Apache 2.0)

Worauf Sie beim Lesen achten sollten

Wer XML-Dateien selbst auswertet, etwa für einen Import in die Buchhaltung, stolpert meist über drei Stellen. Das Rechnungsdatum steht in UBL als 2016-04-04, in CII als 20160404 mit dem Attribut format="102". Die Positionsnummer (BT-126) liegt in UBL direkt in cac:InvoiceLine/cbc:ID, in CII eine Ebene tiefer in ram:AssociatedDocumentLineDocument/ram:LineID. Und die Positionen stehen in CII am Anfang von rsm:SupplyChainTradeTransaction, noch vor den Angaben zu den Vertragsparteien und den Summen. Ein Import, der nur eine Syntax kennt, liest die andere deshalb nicht einfach mit.

Peppol

Peppol ist eine europäische Infrastruktur für den Austausch strukturierter Einkaufsdokumente; nationale Peppol Authority für Deutschland ist die KoSIT. Das Rechnungsformat im Netz, Peppol BIS Billing 3.0, setzt UBL voraus. CII ist dort nur optional: Empfänger können sich im Verzeichnis (SMP) zusätzlich für CII-Rechnungen registrieren. Die Testdateien der KoSIT tragen in BT-23 die Peppol-Prozesskennung urn:fdc:peppol.eu:2017:poacc:billing:01:1.0.

Was Empfänger annehmen müssen

Die XRechnung-Spezifikation ist hier eindeutig: Rechnungsstellende können sich für eine der beiden Syntaxen entscheiden, Rechnungsempfangende müssen beide empfangen können. Öffentliche Auftraggeber müssen alle von der EU benannten Syntaxen verarbeiten. Zwischen Unternehmen ist das Format eine Sache der Vertragsparteien. Eine Software, die nur eine Syntax liest, wird aber früher oder später an einer Lieferantenrechnung scheitern.

Umwandeln zwischen UBL und CII

Eine Umwandlung ist möglich und für Empfänger oft praktisch. Die Spezifikation warnt jedoch vor sogenannten Mismatches: Einzelne Angaben lassen sich in der anderen Syntax nicht immer gleich abbilden. Das Open-Source-Werkzeug Mustangproject kann CII in UBL umwandeln. Unser Anzeigeprogramm liest beide Syntaxen direkt: XRechnung anzeigen.

Welche Syntax soll ich für meine Rechnungen wählen?

Versenden Sie über Peppol, nehmen Sie UBL. Erstellen Sie ZUGFeRD, ist CII vorgegeben. Für Rechnungen an den Bund sind beide zulässig.

Ist eine XRechnung in CII dasselbe wie ZUGFeRD?

Nein. ZUGFeRD ist ein PDF mit eingebettetem XML. Im Profil XRECHNUNG steckt in diesem PDF allerdings eine XRechnung in CII-Syntax.

Kann ich beide Syntaxen mit demselben Werkzeug prüfen?

Ja. Die Validator-Konfiguration der KoSIT enthält Regeln für UBL und CII. Mit XRechnung prüfen laden Sie Dateien in beiden Syntaxen hoch.

Quellen

  1. Spezifikation Standard XRechnung 3.0.2 – CIUS und ExtensionKoSIT, 20. Juni 2024 · geprüft am 7. November 2026
  2. Peppol BIS Billing 3.0 (Version 3.0.21)OpenPeppol · geprüft am 7. November 2026
  3. PeppolKoSIT (XStandards Einkauf) · geprüft am 7. November 2026
  4. XRechnung-Testsuite, Release 2026-08-31KoSIT (GitHub itplr-kosit), 31. August 2026 · geprüft am 7. November 2026
  5. Mustangproject – Bibliothek und Kommandozeilenwerkzeug für ZUGFeRD, Factur-X und XRechnungMustangproject · geprüft am 7. November 2026

Weiterlesen

Grundlage: XRechnung 3.0.2. Stand .