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 — nicht von Hand geschrieben. Sie tragen die CustomizationID von XRechnung 3.0. Was das an Prüfung genau bedeutet und wie Sie es 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, 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:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>
<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.
• 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 9930 (deutsche Leitweg-ID) oder 0204 (Peppol). 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. Der Spezifikations-Kennzeichner steht in CII nicht als CustomizationID, sondern hier:

<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard: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

Ehrlichkeit an dieser Stelle ist wichtiger als ein starkes Wort. Diese Dateien wurden mit der e-invoice-API erzeugt und gegen deren Geschäftsregeln (BR-DE-*) und die Rechenkonsistenz geprüft. Das ist die Ebene, auf der die meisten Fehler entstehen — aber es ist kein Lauf gegen das XSD-Schema, kein Schematron gegen den EN-16931-Kern und kein Durchlauf durch den amtlichen Validator. Deshalb behaupten wir hier bewusst weder eine Schema-Validierung noch eine amtliche Bestätigung — beides müssen Sie selbst herstellen, wenn Sie es brauchen.

Wer eine amtliche Bestätigung will — und das sollten Sie, bevor Sie eigene Ausgabe produktiv verschicken —, jagt die Datei durch den KoSIT-Validator, 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 Szenario-Paket; 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 schreibt einen Report. accept heißt 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.