XRechnung-Beispiel: annotierte XML-Datei zum Download (UBL & CII)

Wer eine XRechnung zum ersten Mal umsetzt, sucht meist genau eine Sache: eine echte, vollständige Beispieldatei, die man öffnen, lesen und Feld für Feld nachvollziehen kann. Genau die liefert dieser Artikel — als Download in beiden zulässigen XML-Syntaxen und Block für Block erklärt.

Das ist ein Referenzartikel, keine Anleitung. Wer die Struktur selbst erzeugen, validieren und automatisieren will, findet den Weg in XRechnung implementieren. Hier geht es allein um die fertige Datei: ansehen, verstehen, mit der eigenen Ausgabe vergleichen.

Die Beispieldatei herunterladen

Dieselbe Rechnung liegt in beiden XML-Syntaxen bereit, die XRechnung 3.0 erlaubt. Beide sind gleichwertig gültig — welche Sie brauchen, hängt vom Empfänger ab (mehr dazu unten).

• xrechnung-beispiel-ubl.xml — UBL 2.1 (Universal Business Language), 5,4 KB
• xrechnung-beispiel-cii.xml — UN/CEFACT CII (Cross-Industry Invoice), 7,2 KB

Beide Dateien wurden mit der e-invoice-API erzeugt und gegen deren Geschäftsregeln (BR-DE-*) sowie die Rechenkonsistenz geprüft. Danach haben wir zwei Kennungen von Hand korrigiert: die CustomizationID auf XRechnung 3.0 umgestellt und die fehlende Prozesskennung ergänzt. Seitdem bewertet der offizielle KoSIT-Validator beide Dateien als ACCEPTABLE. Wie Sie das selbst nachprüfen, steht im Abschnitt Selbst gegenprüfen am Ende.

Inhaltlich ist es die Rechnung RE-2026-0042 der fiktiven Muster GmbH (Berlin) an die Kunde AG (Hamburg): zwei Positionen, 19 % Umsatzsteuer, Zahlung per Überweisung, 30 Tage netto. Alle folgenden Ausschnitte stammen wörtlich aus der UBL-Datei, sofern nicht anders angegeben.

1. Kopfdaten: CustomizationID, ProfileID, Nummer, Datum, TypeCode, Währung

Der Kopf einer XRechnung legt fest, nach welcher Spezifikation gelesen werden muss und identifiziert die Rechnung. In UBL stehen diese Felder direkt unter dem Wurzelelement:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>RE-2026-0042</cbc:ID>
<cbc:IssueDate>2026-07-29</cbc:IssueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>

• CustomizationID (BT-24): Der Kennzeichner der Spezifikation. Dieser Wert sagt dem Empfänger, dass es sich um eine XRechnung nach EN 16931 handelt. Er muss zeichengenau stimmen.
• ProfileID (BT-23): Die Prozesskennung. Die Regel PEPPOL-EN16931-R001 verlangt sie; ohne sie lehnt der KoSIT-Validator ab. Üblich ist urn:fdc:peppol.eu:2017:poacc:billing:01:1.0.
• ID (BT-1): Die Rechnungsnummer, hier RE-2026-0042 — eindeutig im System des Ausstellers.
• IssueDate (BT-2): Das Ausstellungsdatum im ISO-Format JJJJ-MM-TT.
• InvoiceTypeCode (BT-3): 380 steht für „Handelsrechnung" (Code aus UNTDID 1001). Eine Gutschrift wäre 381.
• DocumentCurrencyCode (BT-5): Die Rechnungswährung EUR nach ISO 4217.

2. BuyerReference (BT-10): wann Pflicht, wann Formsache

Direkt im Kopf steht ein Feld, das viele stolpern lässt:

<cbc:BuyerReference>991-00000-19</cbc:BuyerReference>

Die BuyerReference (BT-10) ist ein Käufer-Referenzfeld. In der Rechnung an öffentliche Auftraggeber (B2G) erwarten Bund, Länder und Kommunen hier die Leitweg-ID — die Adresse, über die das Rechnungsportal die Rechnung zustellt. Das Beispiel zeigt eine solche ID im typischen Format.

Der Haken: Die deutsche Geschäftsregel BR-DE-15 macht BT-10 in jeder XRechnung zur Pflicht — auch im B2B, wo es gar keine Leitweg-ID gibt. Dort trägt man stattdessen die Referenz ein, die der Kunde vorgibt, etwa eine Bestellnummer. Weglassen führt zur Ablehnung. Die Abgrenzung Leitweg-ID gegen generische Referenz vertieft XRechnung implementieren.

3. Verkäufer und Käufer: EndpointID mit schemeID

Beide Parteien stehen in eigenen Blöcken — der Verkäufer in AccountingSupplierParty, der Käufer in AccountingCustomerParty. Auffällig ist das erste Feld jeder Partei:

<cbc:EndpointID schemeID="EM">rechnungen@muster-gmbh.de</cbc:EndpointID>

Die EndpointID (BT-34 beim Verkäufer, BT-49 beim Käufer) ist die elektronische Adresse der Partei. Das Attribut schemeID sagt, welcher Art diese Adresse ist: EM steht für E-Mail. Andere gebräuchliche Werte sind 0204 (deutsche Leitweg-ID) oder 9930 (deutsche USt-IdNr.). Ohne schemeID weiß der Empfänger nicht, wie er die Adresse interpretieren soll — das Attribut ist Pflicht.

Darunter folgen Name, Anschrift und Steuerregistrierung. Der Verkäufer trägt zusätzlich eine Kontakt-E-Mail (BT-43), die die Regel BR-DE-7 verlangt:

<cac:PartyTaxScheme>
  <cbc:CompanyID>DE123456789</cbc:CompanyID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:PartyTaxScheme>

Die CompanyID unter PartyTaxScheme mit TaxScheme-ID VAT ist die Umsatzsteuer-Identifikationsnummer (BT-31) des Verkäufers.

4. Positionen: die Einheitencodes HUR und C62

Die Rechnung hat zwei Positionen. Sie zeigen absichtlich zwei verschiedene Mengeneinheiten, weil genau hier oft Verwirrung entsteht.

Position 1 — zehn Beratungsstunden:

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="EUR">1200.00</cbc:LineExtensionAmount>
  <cac:Item>
    <cbc:Name>Beratungsleistung Senior Consultant</cbc:Name>

Position 2 — eine pauschale Leistung:

  <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="EUR">450.00</cbc:LineExtensionAmount>

Das Attribut unitCode trägt die Einheiten aus der UN/ECE-Empfehlung 20 (Codeliste UNECERec20). Die beiden häufigsten:

Der häufigste Fehler: für eine Pauschale oder einen einzelnen Vorgang keine passende Einheit finden. Die Antwort ist fast immer C62 — die dimensionslose Zähl-Einheit „eins". Ein leeres oder ausgedachtes unitCode führt zur Ablehnung, weil nur Codes aus der Codeliste zulässig sind.

5. Steuerblock und Summen

Der Steuerblock fasst die Umsatzsteuer je Steuersatz zusammen. Beide Positionen laufen mit 19 %, also gibt es genau eine Steuergruppe:

<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">313.50</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="EUR">1650.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="EUR">313.50</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19.00</cbc:Percent>

Die Kategorie S („Standard rate") mit 19.00 Prozent gilt für den vollen Regelsteuersatz. Darunter zieht der Summenblock alles zusammen:

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="EUR">1650.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="EUR">1650.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="EUR">1963.50</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount currencyID="EUR">1963.50</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Die Rechnung ist damit vollständig durchgerechnet:

Diese Summen müssen zusammenpassen (Regeln BR-CO-*), sonst lehnt der Empfänger ab: netto 1.650,00 + Steuer 313,50 = brutto 1.963,50.

6. Zahlungsdaten: Code 58, IBAN, Zahlungsziel

Die Zahlungsanweisung sagt dem Käufer, wie und wohin er zahlt:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE89370400440532013000</cbc:ID>
    <cbc:Name>Muster GmbH</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentTerms>
  <cbc:Note>Zahlung innerhalb von 30 Tagen netto.</cbc:Note>
</cac:PaymentTerms>

• PaymentMeansCode (BT-81): 58 steht für „SEPA-Überweisung". Bei Lastschrift stünde hier 59, bei Karte 48.
• PayeeFinancialAccount/ID (BT-84): die IBAN des Zahlungsempfängers. Ein BIC (BT-86) ist bei einer deutschen IBAN nicht erforderlich und hier bewusst weggelassen.
• PaymentTerms/Note (BT-20): das Zahlungsziel als Freitext — hier 30 Tage netto.

Zusätzlich nennt das Beispiel im Block cac:Delivery das Lieferdatum (BT-72) 2026-07-24.

7. UBL gegen CII: dieselbe Rechnung, zwei Syntaxen

Der eigentliche Mehrwert dieser Beispiele: Es ist genau dieselbe Rechnung — einmal in UBL, einmal in CII. So sehen Sie unmittelbar, wie sich die beiden Syntaxen unterscheiden, ohne zwei verschiedene Rechnungen vergleichen zu müssen.

UBL ist flach und selbsterklärend benannt (cbc:ID, cbc:IssueDate). CII (rsm:CrossIndustryInvoice) ist tiefer verschachtelt und in Handelsblöcke gegliedert. Spezifikations- und Prozesskennung stehen in CII nicht als CustomizationID und ProfileID, sondern hier:

<ram:BusinessProcessSpecifiedDocumentContextParameter>
  <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
</ram:BusinessProcessSpecifiedDocumentContextParameter>
<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

Auch das Datum ist anders kodiert. UBL nutzt ISO 2026-07-29, CII das kompakte Format 102:

<ram:IssueDateTime>
  <udt:DateTimeString format="102">20260729</udt:DateTimeString>
</ram:IssueDateTime>

Die Beträge dagegen stimmen zeichengenau überein. Der Bruttobetrag in CII:

<ram:GrandTotalAmount>1963.50</ram:GrandTotalAmount>
<ram:DuePayableAmount>1963.50</ram:DuePayableAmount>

Welche Syntax soll ich nehmen? UBL, wenn Sie international arbeiten oder Peppol nutzen. CII, wenn Sie auch ZUGFeRD unterstützen wollen — das Hybridformat verwendet ausschließlich CII. Die vollständige Gegenüberstellung liefert XRechnung vs. ZUGFeRD.

8. Selbst gegenprüfen: der offizielle KoSIT-Validator

Diese Dateien wurden mit der e-invoice-API erzeugt und gegen deren Geschäftsregeln (BR-DE-*) und die Rechenkonsistenz geprüft. Der Generator schrieb die CustomizationID (BT-24) noch mit dem alten Namensraum xoev-de. Diese Kennung kennt der amtliche Validator nicht und lehnt die Datei ab, bevor er eine einzige Regel prüft. Die Prozesskennung (BT-23) fehlte ganz. Wir haben beide Kennungen von Hand korrigiert und die Dateien danach durch den KoSIT-Validator 1.6.3 mit der XRechnung-Konfiguration vom 31.08.2026 geschickt. Ergebnis: ACCEPTABLE, ohne Fehler und ohne Warnung. Das gilt für diese beiden Dateien, nicht für jede Rechnung, die Ihre Software erzeugt.

Prüfen Sie Ihre eigene Ausgabe genauso, bevor Sie sie produktiv verschicken. Der KoSIT-Validator ist dasselbe Werkzeug, das auch die Rechnungsportale der öffentlichen Verwaltung einsetzen:

1. Laden Sie den KoSIT-Validator (validator.jar) und das aktuelle Konfigurationspaket „XRechnung" von den offiziellen Veröffentlichungen der KoSIT herunter.
2. Entpacken Sie das Konfigurationspaket; es enthält die Schema- und Schematron-Artefakte für XRechnung 3.0.
3. Prüfen Sie eine der Beispieldateien:

   java -jar validator.jar -s scenarios.xml xrechnung-beispiel-ubl.xml

4. Der Validator meldet in der Konsole ACCEPTABLE oder REJECTED und schreibt einen Report. Darin heißt accept bestanden, reject listet die verletzten Regeln mit BT-/BR-Nummer.

Genau so prüfen Empfänger im Zweifel Ihre eingehende Rechnung. Was der KoSIT-Validator ablehnt, lehnt auch das Portal ab — deshalb ist er die verbindliche Referenz, nicht irgendein Online-Checker.

Wie es weitergeht

Sie haben eine vollständige XRechnung Block für Block gelesen. Zwei Anschlusspunkte:

• Selbst erzeugen und automatisieren: Wie Sie diese Struktur programmatisch aufbauen, validieren und in die Pipeline hängen, zeigt XRechnung implementieren. Dieser Artikel hier ist die Referenzdatei zum Anschauen — dort steht der Weg zur eigenen Erzeugung.
• ZUGFeRD statt oder neben XRechnung: Viele B2B-Empfänger bevorzugen das Hybridformat. Unterschiede, Gemeinsamkeiten und Auswahlkriterien klärt XRechnung vs. ZUGFeRD.