UBL gegen CII: die zwei XML-Syntaxen von EN 16931
EN 16931 definiert ein semantisches Datenmodell für Rechnungen und erkennt zwei XML-Syntaxen für dessen Übertragung an: UBL 2.1 (Universal Business Language) und UN/CEFACT CII (Cross Industry Invoice). Beide drücken dieselben fachlichen Inhalte aus, beide sind gültig, beide werden gegen dieselben Geschäftsregeln geprüft. Die Entscheidung zwischen ihnen ist, von wenigen Ausnahmen abgesehen, keine technische, sondern eine Frage des Ökosystems.
Diese Seite erklärt, woher die beiden kommen, wo sie heute jeweils dominieren und worin sich die sichtbaren Unterschiede für jemanden zeigen, der sie lesen oder erzeugen muss.
Ein verbreitetes Missverständnis
Zuerst ist zu klären, worin die beiden Formate sich nicht unterscheiden. Sie kodieren keine unterschiedlichen Rechnungen. Sie tragen keine unterschiedlichen Informationen. Sie liefern bei gleichem fachlichen Inhalt keine unterschiedlichen Validierungsergebnisse. Das EN-16931-Schematron existiert in zwei parallelen Umsetzungen — eine für UBL, eine für CII —, und beide Umsetzungen erzwingen dieselben Regeln über demselben semantischen Modell. Eine korrekt erzeugte UBL-Rechnung und eine korrekt erzeugte CII-Rechnung über denselben Vorgang bestehen dieselben Prüfungen und werden von jedem konformen nachgelagerten System gleich verarbeitet.
Die beiden Formate sind nicht »kompatibel« in dem Sinne, dass sich eines stillschweigend in das andere überführen ließe — sie haben unterschiedliche Elementnamen, unterschiedliche Verschachtelungsregeln und unterschiedliche Attribut-Konventionen —, doch sie sind äquivalent in dem Sinne, dass jede wohlgeformte Rechnung in einem Format bei korrekter Abbildung verlustfrei in eine wohlgeformte Rechnung im anderen Format überführt werden kann.
Woher die beiden kommen
UBL (Universal Business Language) wird von OASIS gepflegt, einem offenen Normungskonsortium. Es entstand in den frühen 2000er Jahren als allgemeines XML-Vokabular für Geschäftsdokumente — Rechnungen, Bestellungen, Lieferavisen, Kataloge. Seine Entwurfsphilosophie ist elementreich und selbsterklärend: die meisten Daten leben in benannten Elementen statt in Attributen, und die Elementnamen tragen die Bedeutung selbst (cbc:InvoicedQuantity, cac:AccountingSupplierParty, cbc:PayableAmount).
CII (Cross Industry Invoice) ist Teil der UN/CEFACT-Arbeit zur Handelsvereinfachung. Sie geht auf die UN/EDIFACT-Tradition zurück — einen viel älteren Versuch strukturierter Geschäftsdokumente — und wurde in den 2010er Jahren als XML neu formuliert. Ihr Entwurf trägt mehr EDIFACT-Erbe: tiefere Verschachtelung, knappere Elementnamen, stärkere Bindung an Type-Codes und Attribute. Elementnamen wie ram:SpecifiedTradeProduct und ram:ApplicableHeaderTradeAgreement sind typisch.
Beide gab es Jahre vor EN 16931. Als CEN 2015 bis 2017 nach XML-Syntaxen suchte, die seine neue Norm tragen sollten, waren UBL und CII bereits etabliert und hatten ihre eigenen Anwender. Die Anerkennung beider war die einzig diplomatisch tragfähige Lösung.
Sichtbare Unterschiede für die Leserin
Derselbe fachliche Inhalt sieht in den beiden Formaten recht unterschiedlich aus:
UBL ist in der äußeren Struktur ausführlicher, aber flacher in der Verschachtelung. Eine Rechnungsposition liegt typischerweise direkt im Rechnungselement, mit Positionsnummer, Artikelnamen, Menge und Preis als unmittelbaren Kindern.
CII ist in den Elementnamen kompakter, aber tiefer verschachtelt. Dieselbe Rechnungsposition ist in ram:IncludedSupplyChainTradeLineItem eingebettet, dann in ram:SpecifiedLineTradeAgreement, ram:SpecifiedLineTradeDelivery und ram:SpecifiedLineTradeSettlement, von denen jeder einen Teil der Positionsattribute trägt. Die Struktur spiegelt die zugrunde liegende EDIFACT-Logik aus Segmenten und Gruppen wider.
Für einen Entwickler ohne Vorkenntnisse ist UBL meistens leichter zu lesen: die Elementnamen sagen, was sie enthalten, und die Verschachtelung folgt der Anschauung. CII belohnt eine Leserin, die das semantische Modell schon im Kopf hat — sobald die Abbildung sitzt, ergibt die Tiefenstruktur Sinn —, ist beim ersten Kontakt aber undurchsichtig.
Wo welche dominiert
Die geographische Aufteilung ist recht sauber:
UBL-Gebiet — Dänemark, Norwegen, Niederlande, Belgien, Schweden, Island, weite Teile des öffentlichen Sektors in Skandinavien sowie das gesamte PEPPOL-Netz. PEPPOL BIS Billing 3.0 ist UBL-only, und PEPPOL ist das de facto Rückgrat des grenzüberschreitenden europäischen E-Invoicings.
CII-Gebiet — Deutschland (XRechnung unterstützt beide, doch die Wirtschaft bevorzugt CII), Frankreich (das nationale Format und die in Factur-X eingebettete XML basieren auf CII), Schweiz.
XRechnung akzeptiert beide Syntaxen gleichberechtigt. PEPPOL akzeptiert nur UBL. Das französische B2B akzeptiert auf Format-Ebene beide, wobei Factur-X konstruktionsbedingt nur CII führt. In der Praxis bedeutet das: eine Organisation, die grenzüberschreitend in Europa fakturiert, wird beide produzieren müssen, auch wenn intern eine Vorliebe besteht.
Werkzeuge
Werkzeuge für beide Formate sind reif. Die großen XML-Bibliotheken (lxml, Xerces, .NET XmlReader und so weiter) verarbeiten beide gleich gut. Schematron-Validatoren prüfen dieselben EN-16931-Regeln gegen beide. Code-Generatoren für UBL und CII aus XSD-Definitionen existieren in jeder größeren Programmiersprache. Eine bedeutsame Werkzeug-Lücke gibt es nicht.
Ein Bereich, in dem die Werkzeuge auseinandergehen, sind die Validierungsberichte selbst: ein Schematron-Bericht nennt die Regel-ID, doch der Pfad zum fehlerhaften Element ist zwischen den beiden Formaten naturgemäß unterschiedlich. Eine Meldung »Stadt des Käufers fehlt« zeigt in UBL auf cac:BuyerCustomerParty/cac:Party/cac:PostalAddress/cbc:CityName und in CII auf ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CityName. Werkzeuge, die Validierungsfehler nutzbar darstellen wollen, müssen wissen, mit welcher Syntax sie es zu tun haben.
Das Fazit
Es gibt keinen allgemeinen technischen Grund, eine Syntax der anderen vorzuziehen. Die Entscheidung in der Praxis bestimmt sich danach, wohin die Rechnung geht:
- Versand an einen PEPPOL-Endpunkt? UBL.
- Versand an einen deutschen Empfänger, der XRechnung-CII verlangt hat? CII.
- Erstellung von Factur-X? Sie verwenden CII, eingebettet in ein PDF.
- Bau eines Systems, das beides erzeugen soll? Das semantische Modell zuerst bauen und UBL und CII aus derselben Quelle als Ausgaben erzeugen. Versuchen Sie nicht, zwischen den beiden als Hauptweg zu konvertieren; die Abbildungen existieren, sind aber mühsam zu pflegen und verlieren an den Rändern still Informationen.
Die historische Ironie liegt darin, dass EN 16931 die Format-Zersplitterung im europäischen Rechnungswesen beenden sollte — und durch die Anerkennung zweier Syntaxen ihr sichtbarstes Symptom konserviert hat. Die Wette war, dass ein stabiles semantisches Modell die syntaktische Spaltung auf Dauer bedeutungslos machen würde. Ob diese Wette aufgeht, hängt davon ab, wessen Werkzeuge man verwendet.