Zwei Sprachen für denselben Satz
EN 16931 beschreibt, welche Angaben eine Rechnung enthält und was sie bedeuten — nicht, wie sie im XML angeordnet sind. Für die Anordnung lässt die Norm zwei Syntaxen zu:
- CII (Cross Industry Invoice) von UN/CEFACT
- UBL (Universal Business Language) von OASIS
Beide sind vollwertig. Ein Dokument in CII und dasselbe Dokument in UBL enthalten exakt dieselben Felder mit denselben BT-Nummern. Sie sehen nur völlig anders aus.
Dieselbe Rechnungsnummer, zweimal
BT-1, die Rechnungsnummer, in UBL:
1<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"2 xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">3 <cbc:ID>RE-2026-0042</cbc:ID>4</ubl:Invoice>Und in CII:
1<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"2 xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">3 <rsm:ExchangedDocument>4 <ram:ID>RE-2026-0042</ram:ID>5 </rsm:ExchangedDocument>6</rsm:CrossIndustryInvoice>Gleiche Aussage, gleiche BT-Nummer, anderer Pfad. Genau deshalb nennen Fehlermeldungen die BT-Nummer und nicht den XPath: Die BT-Nummer gilt in beiden Syntaxen, der Pfad nicht.
Die Unterschiede, die in der Praxis auffallen
| CII | UBL | |
|---|---|---|
| Herausgeber | UN/CEFACT | OASIS |
| Wurzelelement | rsm:CrossIndustryInvoice | ubl:Invoice / ubl:CreditNote |
| Typische Präfixe | rsm, ram, udt | cbc, cac |
| Aufbau | tiefer verschachtelt, drei Kopfbereiche | flacher, gruppiert nach Geschäftsobjekt |
| Verbreitung | Industrie, Hybridformate | öffentliche Beschaffung, Peppol |
Der auffälligste strukturelle Unterschied: CII teilt das Dokument in drei große
Blöcke — ExchangedDocument (Kopf), SupplyChainTradeTransaction mit den
Positionen, und darin wiederum Vereinbarung, Lieferung und Abrechnung. UBL legt
die Gruppen flacher nebeneinander.
Für einen Menschen, der zum ersten Mal hineinsieht, ist UBL meist leichter zu lesen. Für einen Parser ist das gleichgültig.
Wer verlangt was
Diese Zuordnung ist die eigentlich nützliche Information:
| Zielformat | Syntax | Wahlfreiheit? |
|---|---|---|
| ZUGFeRD | CII | nein |
| Factur-X | CII | nein |
| Peppol BIS Billing 3.0 | UBL | nein |
| XRechnung | CII oder UBL | ja |
| FatturaPA | eigene Syntax | — |
| Facturae | eigene Syntax | — |
Die einzige Stelle mit echter Wahlfreiheit ist die XRechnung. Und selbst dort gilt: Wenn der Empfänger eine Präferenz nennt, folgen Sie ihr — beide Varianten sind konform, aber nicht jede Eingangsverarbeitung ist gleich gut auf beide vorbereitet.
Der Sonderfall XRechnung
Die XRechnung ist eine CIUS von EN 16931 und erbt damit die Zweigleisigkeit der Norm. Es gibt sie als UBL-Datei und als CII-Datei; beide tragen dieselbe Spezifikationskennung in BT-24 und werden vom selben Regelwerk geprüft.
Praktisch überwiegt UBL, weil die deutschen Eingangsplattformen aus der Peppol-Welt kommen. Wer keine Vorgabe hat, fährt mit UBL erfahrungsgemäß konfliktärmer.
Was das für die Implementierung heißt
Die verbreitete Fehlannahme ist, man müsse sich für eine Syntax entscheiden. Muss man beim Erzeugen meistens nicht — man entscheidet sich für ein Zielformat, und das bringt seine Syntax mit. Wer ZUGFeRD erzeugt, erzeugt CII, ohne je eine Wahl getroffen zu haben.
Beim Empfangen ist es umgekehrt. Sobald Rechnungen aus mehreren Quellen eintreffen, kommen beide Syntaxen an, und zwar unangekündigt: Der eine Lieferant schickt ein ZUGFeRD-PDF, der nächste eine UBL-XRechnung, der dritte eine CII-XRechnung. Eine Eingangsverarbeitung, die nur eine Syntax kennt, fällt beim zweiten Lieferanten aus.
💡 Der praktische Rat: Behandeln Sie die Syntax als Detail des Transports, nicht als Teil Ihres Datenmodells. Intern arbeiten Sie mit den BT-Feldern; die Syntax existiert nur an der Grenze nach außen. Dann ist der Wechsel von CII auf UBL eine Konfigurationsfrage und kein Umbau.