UBL oder CII? Dieselbe XRechnung in zwei XML-Syntaxen

UBL und CII können dieselbe XRechnung ausdrücken. Rechnungsnummer, Käufer, Leistung und Zahlbetrag bleiben gleich; die XML-Struktur unterscheidet sich. Welche Syntax Sie ausgeben sollten, hängt vom vereinbarten Rechnungsprofil, dem Empfangssystem und dem Übertragungsweg ab. Die Dateiendung .xml beantwortet diese Frage nicht.

Hier vergleichen Sie eine konkrete Rechnung in beiden Syntaxen. Sie erhalten vollständige Dateien, ausgewählte XML-Pfade und die tatsächlich erzeugten KoSIT-Berichte. So können Sie ein Mapping prüfen, einen Export beurteilen oder mit Ihrem Softwareanbieter eine belastbare Formatentscheidung treffen.

Die gemeinsame Ausgangsrechnung

Die synthetische Muster GmbH berechnet der Beispiel AG zehn Stunden Beratungsleistung zu jeweils 100,00 Euro netto. Die Rechnung enthält eine Position, 19 Prozent Umsatzsteuer und keine Zu- oder Abschläge. Es gibt weder eine Vorauszahlung noch einen bereits abgezogenen Skontobetrag. Beide Dateien bilden genau diesen Geschäftsvorfall ab.

Namen, Adressen, E-Mail-Adressen und Bankverbindung dienen ausschließlich dem technischen Beispiel. Die Dateien sind nicht zur Zahlung bestimmt. Übernehmen Sie insbesondere die Käuferreferenz und Kontodaten nicht in eine echte Rechnung. Eine syntaktisch zulässige Angabe wird dadurch nicht zur richtigen Angabe Ihres Auftraggebers.

Für die erste Kontrolle öffnen Sie beide Dateien nacheinander im XRechnung Viewer. Prüfen Sie, ob die fachlichen Werte übereinstimmen. Eine identische Darstellung ist hilfreich, ersetzt aber weder den Feldvergleich noch die Validierung: Ein Viewer kann bestimmte Angaben ausblenden oder fehlerhafte Dateien trotzdem lesbar darstellen.

Downloads mit echten Prüfberichten

Beide Dateien wurden am 7. September 2026 lokal mit KoSIT Validator 1.6.2 und der XRechnung-Konfiguration v2026-01-31 geprüft. Für beide Läufe lautet die Annahmeempfehlung ACCEPTABLE; Schema und Schematron sind gültig. Es wurden keine Fehler und keine Warnungen ausgegeben. Diese Aussage gilt für die verlinkten Dateien und diesen Regelstand.

Das Prüfmanifest mit SHA-256-Prüfsummen ordnet die Dateien den Prüfläufen zu. Auch die Originalberichte enthalten einen Hash des geprüften Eingangs. Wenn Sie nur ein Zeichen der Rechnung ändern, beschreibt der alte Bericht bereits eine andere Datei. Prüfen Sie bearbeitete Beispiele deshalb erneut.

Die verwendete Konfiguration und ihre Veröffentlichung sind bei KoSIT dokumentiert. Ein späteres Regelpaket kann andere Meldungen erzeugen. Speichern Sie bei eigenen Tests immer Eingangsdatei, Bericht, Validatorversion und Konfigurationsstand zusammen.

Die Anleitung zum Wiederholen der Prüfung enthält Werkzeugstand, Befehle und erwartete Ergebnisse als herunterladbare Textdatei.

UBL und CII zuverlässig erkennen

In der UBL-Datei heißt das Wurzelelement ubl:Invoice. Sein Namensraum ist urn:oasis:names:specification:ubl:schema:xsd:Invoice-2. In der CII-Datei steht rsm:CrossIndustryInvoice mit dem Namensraum urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100.

Die Präfixe ubl und rsm sind Abkürzungen innerhalb des Dokuments. Ein Exportprogramm darf andere Präfixe vergeben oder einen Standardnamensraum verwenden. Entscheidend sind der lokale Elementname und die zugehörige Namensraum-URI. Eine Erkennung über die Zeichenfolge <ubl:Invoice scheitert deshalb an zulässigen Varianten.

Praktisch bedeutet das: Lesen Sie das Dokument mit einem XML-Parser, der Namensräume berücksichtigt. Vergleichen Sie zuerst den qualifizierten Wurzelnamen. Ermitteln Sie danach Profil und Spezifikationskennung. Eine beliebige UBL-Rechnung ist noch keine XRechnung; dasselbe gilt für eine beliebige CII-Datei.

UBL kennt außerdem ein separates Wurzelelement CreditNote. Unser Beispiel behandelt eine Rechnung mit Typcode 380, keine Gutschrift. Übertragen Sie die hier gezeigten Rechnungspfade deshalb nicht ungeprüft auf andere Belegarten. Die Grundlagen finden Sie im UBL-Glossar und im CII-Glossar.

Spezifikationskennung und Prozesskennung auseinanderhalten

Die Spezifikationskennung BT-24 erklärt, welche fachlichen Anforderungen die Rechnung erfüllen soll. Im Beispiel lautet sie in beiden Syntaxen:

urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

In UBL steht diese Kennung in cbc:CustomizationID. In CII befindet sie sich unter rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. Der Wert enthält xrechnung_3.0; daraus lässt sich nicht allein der genaue technische Konfigurationsstand eines späteren Prüflaufs ableiten.

Daneben enthalten beide Dateien die Geschäftsprozesskennung BT-23. UBL verwendet dafür cbc:ProfileID, CII den Kontext ram:BusinessProcessSpecifiedDocumentContextParameter. Unser Beispiel nutzt urn:fdc:peppol.eu:2017:poacc:billing:01:1.0. Diese Angabe ersetzt weder BT-24 noch den Nachweis, dass ein bestimmter Empfänger genau diesen Dokumenttyp annimmt.

Die EN 16931 beschreibt die fachliche Bedeutung der Rechnungselemente. Die Syntaxbindung ordnet sie konkreten XML-Pfaden zu. XRechnung konkretisiert die Anforderungen zusätzlich. Diese Ebenen erklärt KoSIT im Abschnitt zu EN 16931 und Konformität. Im Alltag hilft die Reihenfolge: Geschäftsvorfall verstehen, passendes Profil wählen, korrekt abbilden und mit dem passenden Regelwerk prüfen.

Ausgewählte XML-Pfade direkt vergleichen

Die folgenden Pfade beginnen jeweils unter dem Wurzelelement. Sie beziehen sich auf die herunterladbare Rechnung, nicht auf sämtliche möglichen Belegarten oder Erweiterungen. Bei CII liegen die Rechnungsdaten in mehreren fachlichen Kontexten; ein kurzer Elementname allein reicht daher selten für eine eindeutige Zuordnung.

Datumswerte: gleicher Tag, andere Darstellung

UBL schreibt das Rechnungsdatum als 2026-09-07. Die CII-Datei enthält 20260907 in einem udt:DateTimeString mit format="102". Beide Werte bezeichnen denselben Kalendertag. Bei einem Textvergleich sehen sie unterschiedlich aus; bei einem fachlichen Vergleich müssen sie gleich sein.

Eine robuste Übernahme wandelt beide Darstellungen zunächst in ein gemeinsames Datumsmodell um. Prüfen Sie dabei echte Kalenderdaten statt nur die Anzahl der Ziffern. Behalten Sie Rechnungsdatum, Leistungsdatum und Fälligkeit getrennt. Dass sie in einer einfachen Testrechnung zufällig zusammenfallen könnten, wäre kein Grund, dieselbe Datenbankspalte für alle drei Angaben zu verwenden.

Beträge: Zahlwert und Kontext zusammen lesen

Der UBL-Zahlbetrag steht als 1190.00 mit currencyID="EUR" im Element cbc:PayableAmount. CII verwendet ram:DuePayableAmount; die Rechnungswährung wird im übergeordneten Abrechnungskontext mit ram:InvoiceCurrencyCode angegeben. Ein Mapping muss den Wert mit dem richtigen Währungskontext verbinden.

Verwechseln Sie den Zahlbetrag nicht mit der Bruttosumme. In unserer Rechnung sind beide 1.190,00 Euro, weil keine Vorauszahlung vorliegt. Bei einer Schlussrechnung können diese Beträge auseinanderfallen. Vergleichen Sie daher die Bedeutung von BT-112, bereits gezahlten Beträgen und BT-115 statt nur gleich aussehende Zahlen zu übernehmen.

Positionen: Menge, Einheit und Preis gehören zusammen

Die Position enthält zehn Stunden zum Nettopreis von 100,00 Euro. UBL bildet die Menge über cbc:InvoicedQuantity ab, CII über ram:BilledQuantity im Lieferkontext der Position. Der Einheitencode ist in beiden Dateien HUR. Die Positionsnettosumme beträgt 1.000,00 Euro.

Beim Testen sollten Sie zusätzlich einen Fall mit mehreren Positionen und einen mit einer abweichenden Preisbasismenge aufnehmen. Ein Mapper, der nur den ersten Mengenwert im Dokument liest, kann die einfache Rechnung bestehen und bei realen Aufträgen falsche Summen erzeugen. Die BT-Feldreferenz hilft bei Pfaden, Kardinalitäten und zugehörigen Regeln.

Welche Syntax verlangt der Empfänger?

Fragen Sie nicht nur „Können Sie XML empfangen?“. Klären Sie den konkreten Dokumenttyp, das Profil, die Version, die Käuferreferenz und den Übertragungsweg. Ein Portal, eine E-Mail-Verarbeitung und ein Peppol-Zugang können unterschiedliche technische Anforderungen haben. Eine gültige Datei ist noch keine erfolgreiche Zustellung.

Für eine belastbare Abstimmung genügen zunächst fünf präzise Fragen:

1. Wird XRechnung in UBL, CII oder beiden Syntaxen angenommen?
2. Welcher Profil- und Versionsstand wird erwartet?
3. Welche Käuferreferenz und welche elektronischen Adressen sind erforderlich?
4. Über welchen Kanal und mit welchen Dateigrenzen erfolgt die Einreichung?
5. Gibt es eine Testmöglichkeit und eine eindeutige Empfangsbestätigung?

Peppol BIS Billing 3.0 beschreibt UBL-Rechnungen und UBL-Gutschriften. Die offizielle Peppol-Dokumentation enthält dafür Syntaxen, Regeln und Codelisten. Daraus folgt keine pauschale Aussage, dass jede CII-Datei über jeden Peppol-Zugang versendet werden kann. Lassen Sie den tatsächlich unterstützten Dokumenttyp durch Ihren Zugangsanbieter und den Empfänger bestätigen.

Auch CII und ZUGFeRD sind nicht austauschbare Begriffe. Unsere CII-Datei ist eigenständiges XRechnung-XML. Sie ist kein hybrides PDF mit eingebetteter Rechnung. Wenn ein Empfänger ausdrücklich ein solches PDF verlangt, sehen Sie sich die ZUGFeRD-Beispiele und deren Profilinformationen an.

Ein sinnvoller Test für Ihre eigene Schnittstelle

Beginnen Sie mit den unveränderten Downloads. Lassen Sie Ihr System beide Dateien einlesen und vergleichen Sie die gemeinsamen Fachwerte. Erzeugen Sie anschließend aus Ihrem internen Rechnungsmodell beide Ausgaben erneut. Validieren Sie diese neu erzeugten Dateien separat; die hier verlinkten Berichte gelten nicht für Ihren Export.

Bewerten Sie drei Ergebnisse getrennt: Sind die Daten fachlich gleich? Sind beide Ausgaben technisch gültig? Nimmt der vorgesehene Empfänger sie an? Ein grüner Validatorbericht beantwortet nur den zweiten Teil innerhalb seines Prüfumfangs. Die Leistung, der richtige Auftrag und die tatsächliche Bankverbindung benötigen zusätzliche fachliche Kontrollen.

Nehmen Sie danach einen gezielten Fehlerfall hinzu, etwa eine fehlende Käuferreferenz. Ihr System sollte die zugehörige Meldung einer verständlichen Eingabestelle zuordnen können. Wie Regel-ID, Fundstelle und Annahmeempfehlung verarbeitet werden, zeigt der Beitrag KoSIT-Prüfberichte maschinell auswerten.

Häufige Fragen zur Formatentscheidung

Ist UBL grundsätzlich besser als CII?

Nein. Für diesen Beleg liefern beide Syntaxen ein vollständig geprüftes Ergebnis. Ein vorhandener UBL-Export, ein CII-basierter Prozess oder ein fest vereinbartes Empfangsprofil kann die Entscheidung vereinfachen. Entscheidend ist, welche Variante Ihren konkreten Ablauf mit möglichst wenig fehleranfälliger Umwandlung unterstützt.

Reicht es, die XML-Tags umzubenennen?

Nein. Die Strukturen, Datumsformate, Währungskontexte und Gruppierungen unterscheiden sich. Eine verlässliche Umwandlung führt über die fachlichen Rechnungselemente und berücksichtigt optionale Angaben. Zwei Dateien können technisch gültig sein und trotzdem unterschiedliche Geschäftsangaben enthalten.

Kann ich die Beispiele für einen Produktionstest verwenden?

Für lokale Tests und vereinbarte Testumgebungen ja. Sie enthalten synthetische Daten und sind keine echten Forderungen. Senden Sie sie nicht ungefragt an einen produktiven Rechnungseingang. Stimmen Sie Testkennungen und Testempfänger vorher ab und ersetzen Sie bei eigenen Rechnungen sämtliche Musterwerte.