E-Rechnung XML: So ist das Format aufgebaut und strukturiert

Hinter jeder XRechnung und jedem ZUGFeRD steckt eine XML-Datei. Wer einmal verstanden hat, wie sie aufgebaut ist, verliert die Scheu vor dem Format – und kann Fehler in Sekunden lokalisieren, statt blind im Validator zu suchen.

Warum überhaupt XML?

Das Datenmodell der EN 16931 ist abstrakt formuliert. Damit Software es austauschen kann, braucht es eine Syntax – also eine konkrete Schreibweise. Die EN erlaubt zwei davon:

• UBL 2.1 (OASIS Universal Business Language)
• UN/CEFACT CII (Cross Industry Invoice)

Beide sind XML. Sie beschreiben dieselben Geschäftsfelder, nur mit unterschiedlichen Tag-Namen und unterschiedlicher Verschachtelung. Hintergrund in UBL und CII.

XML ist deshalb der Standard, weil es:

• maschinenlesbar und gleichzeitig per Texteditor öffenbar ist,
• über Schemas (XSD) und Schematron-Regeln automatisch validierbar ist,
• in praktisch jeder Programmiersprache verarbeitet werden kann.

Grundgerüst einer XRechnung (UBL)

Eine XRechnung im UBL-Format beginnt mit einem Wurzelelement <Invoice>. Stark vereinfacht sieht das so aus:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>
  <cbc:ID>2026-0815</cbc:ID>
  <cbc:IssueDate>2026-08-15</cbc:IssueDate>
  <cbc:DueDate>2026-09-15</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>04011000-12345-12</cbc:BuyerReference>
  ...
</Invoice>

Drei Dinge fallen sofort auf:

1. Namespaces trennen Tags aus unterschiedlichen Vokabularen (cbc, cac).
2. Die CustomizationID legt fest, dass es sich um eine XRechnung 3.0 nach EN 16931 handelt.
3. Pflichtfelder wie Rechnungsnummer, Datum, Währung und Leitweg-ID stehen weit oben.

Die wichtigsten Blöcke

Eine vollständige Rechnung gliedert sich in immer wiederkehrende Abschnitte:

Diese Blöcke entsprechen den BG-Gruppen aus dem semantischen Modell. Wer das Modell kennt, findet sich in jedem Tool wieder.

CII statt UBL

ZUGFeRD und Factur-X verwenden CII. Hier sieht das Wurzelelement so aus:

<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">
  <rsm:ExchangedDocument>
    <ram:ID>2026-0815</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260815</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  ...
</rsm:CrossIndustryInvoice>

Andere Tag-Namen, gleicher Inhalt. Wer beide einmal nebeneinander sieht, erkennt das Muster sofort.

Wie liest man die Felder?

Ein einzelner Wert in der EN 16931 hat einen Code, z. B. BT-1 für die Rechnungsnummer. In UBL steht er in <cbc:ID> direkt unter <Invoice>, in CII in <ram:ID> unter <rsm:ExchangedDocument>. Eine Übersicht aller Felder mit Mapping in BT-1 Rechnungsnummer und in der Liste der Pflichtfelder.

XML öffnen und lesen

Drei Wege funktionieren immer:

1. Texteditor (Notepad++, VS Code) – schnell für einen Blick auf die Struktur.
2. Browser – Chrome und Firefox stellen XML mit Einrückung dar.
3. Visualisierung – Tools wie unser XRechnung-Validator zeigen die Daten lesbar in Tabellen.

Bei ZUGFeRD muss die XML zuerst aus dem PDF extrahiert werden. Sie liegt als Anhang factur-x.xml (oder zugferd-invoice.xml bei alten Versionen) im Dokument.

Validierung statt Vermutung

Eine XML-Datei kann wohlgeformt sein (gültiges XML) und trotzdem keine gültige E-Rechnung – wenn z. B. ein Pflichtfeld fehlt oder ein Code nicht zur EN 16931 passt. Es gibt zwei Prüfebenen:

• XSD-Schema – prüft Struktur und Datentypen.
• Schematron-Regeln – prüfen die Geschäftslogik (z. B. Summen, IBAN-Format, Codelisten).

Erst wenn beide Ebenen sauber sind, akzeptiert ein Empfänger die Rechnung. Mehr in E-Rechnung validieren.

Häufige Fehlerquellen im XML

In der Praxis tauchen immer wieder dieselben Probleme auf:

• Falsche CustomizationID – z. B. eine alte XRechnung-Version.
• Fehlende Leitweg-ID bei Behördenrechnungen.
• Summenrundungsfehler – Cent-Differenz zwischen Positionen und Gesamtsumme.
• Falsche Steuerkategoriecodes – S (Standard) statt Z (Zero) bei steuerfreien Umsätzen.
• Encoding-Probleme – Umlaute kippen, weil die XML nicht in UTF-8 vorliegt.

Die Top-Fallen mit Lösungen in E-Rechnung Fehler vermeiden.

Häufige Fragen

Brauche ich XML-Kenntnisse, um E-Rechnungen zu erstellen?

Nein. Tools wie unser E-Rechnung-Generator erzeugen die XML automatisch. Kenntnisse helfen aber bei der Fehlersuche.

Kann ich die XML manuell bearbeiten?

Technisch ja, aber riskant – jede manuelle Änderung kann Schematron-Regeln verletzen. Lieber im erzeugenden Tool korrigieren und neu exportieren.

Wie groß ist eine typische XML-Rechnung?

Eine Standardrechnung mit fünf bis zehn Positionen liegt zwischen 5 und 30 KB. Komplexe Belege mit vielen Zuschlägen und Anhangsverweisen können 100 KB überschreiten.

Warum stehen Beträge oft mit zwei Nachkommastellen, manchmal aber mit vier?

Stückpreise (BT-146) erlauben bis zu vier Nachkommastellen, alle Summen sind auf zwei zu runden. Das ist eine Vorgabe der EN 16931 und wird vom Validator geprüft.

Wo finde ich das offizielle XSD-Schema?

Das CEN veröffentlicht es; KoSIT stellt für die XRechnung die anwendungsspezifischen Schemata und Schematron-Regeln auf seiner Website bereit.