Auf dieser Seite

Dieser Artikel richtet sich an ERP-Berater, IT-Verantwortliche und Steuerberater, die verstehen wollen, wie eine XRechnung intern aufgebaut ist, wie aus dem Roh-XML ein lesbares Dokument wird und was GoBD konkret für die Archivierung bedeutet. Der kaufmännische Einstieg steht auf der Übersichtsseite XRechnung öffnen & lesen.

Die zwei Syntaxen: UBL 2.1 und UN/CEFACT CII

XRechnung ist keine Dateiformat-Eigenerfindung, sondern die deutsche CIUS (Core Invoice Usage Specification) zur europäischen Norm EN 16931-1. Die Norm definiert ein semantisches Datenmodell – sie schreibt aber nicht vor, in welcher XML-Syntax es serialisiert wird. Erlaubt sind zwei Syntaxen:

Merkmal UBL 2.1 (OASIS) UN/CEFACT CII
Root-Element <Invoice> (UBL-Namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2) <CrossIndustryInvoice> (Namespace urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100)
Namespace-Präfixe cbc, cac ram, rsm, udt
Rechnungsnummer direkt in cbc:ID unter dem Root in rsm:ExchangedDocument/ram:ID (eine Ebene tiefer)
Erweiterungs­mechanismus Extension Point im Core vorhanden nicht im Core, nur außerhalb
Peppol-Pflicht ja – Peppol BIS Billing 3.0 verlangt UBL nein
ZUGFeRD/Factur-X nein ausschließlich CII

Faustregel: Bundesbehörden akzeptieren beide Syntaxen gleichwertig. Wer international über Peppol sendet, braucht UBL. Wer ZUGFeRD in das PDF einbettet, bekommt automatisch CII. Beide Syntaxen sind inhaltlich äquivalent – ein validierender Parser muss beide beherrschen.

Warum die Norm kein Sichtformat vorschreibt

EN 16931-1 beschreibt ausschließlich das semantische Modell: welche Felder es gibt (z. B. BT-1 Invoice number, BT-9 Payment due date, BG-25 Invoice line), welche davon Pflicht sind und welche Codierungen zulässig sind. Ein Layout – Schriftart, Spaltenbreite, Logo-Position – ist bewusst außerhalb des Normumfangs.

Gründe dafür:

  • Die Rechnung soll maschinenlesbar sein, nicht druckbar. Der Empfänger importiert die Daten in sein ERP; ein vorgeschriebenes Layout wäre für die Buchung nutzlos.
  • Unterschiedliche Empfangssysteme (Portale, ERPs, Marktplätze) brauchen unterschiedliche Darstellungen. Eine zentrale Visualisierungsvorschrift würde diese Flexibilität aufheben.
  • Das Original-Dokument ist das XML – jede visuelle Darstellung ist eine abgeleitete, nicht normative Kopie.

Die Konsequenz: Wer die Datei öffnet und „lesen" möchte, bekommt ohne Viewer ausschließlich den XML-Quelltext zu sehen (verfügbare XRechnung-Lösungen im Überblick).

Sichtdokument erzeugen: KoSIT-XSLT

Die Koordinierungsstelle für IT-Standards (KoSIT) stellt ein Open-Source-XSLT-Paket (Apache 2.0) bereit, das XRechnung-XML in lesbare HTML- oder PDF-Dokumente transformiert.

Technischer Ablauf (zweistufig)

  1. Normalisierung: Das Eingabe-XML (UBL oder CII) wird in ein syntax-neutrales Zwischen-XML überführt. Dieser Schritt gleicht die strukturellen Unterschiede zwischen den beiden Syntaxen aus.
  2. Rendering: Das Zwischen-XML wird per xrechnung-html.xsl in HTML oder per xr-pdf.xsl in ein druckbares PDF transformiert.

Das aktuelle Release (2026-01-31) ist kompatibel mit XRechnung 3.0.x.

Einbindung in eigene Systeme

<!-- Beispiel: Saxon-HE-Aufruf auf der Kommandozeile -->
java -jar saxon-he.jar \
  -s:eingangsrechnung.xml \
  -xsl:xrechnung-html.xsl \
  -o:sichtdokument.html

In Java- und .NET-Umgebungen ist der Aufruf entsprechend über die JAXP- bzw. System.Xml.Xsl-API möglich. Viele DMS- und ECM-Plattformen integrieren XSLT-Transformationen nativ; das KoSIT-Stylesheet lässt sich dort direkt einbinden.

Wichtig: Das erzeugte HTML oder PDF ist kein gültiges XRechnung-Dokument und darf nicht anstelle der Original-XML archiviert werden (siehe GoBD-Abschnitt unten).

Einbindung in den Rechnungseingang

Für eine vollständige Verarbeitungskette im Eingangsbereich sind mindestens drei Schritte nötig:

  1. Empfang & Validierung: Die eingehende XML gegen das offizielle KoSIT-Schematron validieren (Pflichtfelder, Codelisten, Rechenregeln). Fehlerhafte Rechnungen sollten vor der Weiterleitung zurückgewiesen werden.
  2. Sichtdokument erzeugen: KoSIT-XSLT oder ein gleichwertiger Renderer erzeugt das HTML/PDF für die manuelle Sichtprüfung und Freigabe.
  3. Daten extrahieren & buchen: XPath-Abfragen oder eine dedizierte Parser-Bibliothek (z. B. mustang-project für Java) extrahieren Betrag, Fälligkeitsdatum, Steuersatz und Positionszeilen für den ERP-Import.

Portale (Peppol-AP, OZG-RE, ZRE) liefern die Datei meist bereits validiert aus – der Validierungsschritt kann dann entfallen oder wird auf Plausibilität reduziert.

GoBD: Original-XML ist das Aufbewahrungsobjekt

Das BMF-Schreiben zu den GoBD (28.11.2019) konkretisiert § 147 AO für elektronische Unterlagen: Werden aufzeichnungs- und aufbewahrungspflichtige Daten, Datensätze und elektronische Dokumente im Unternehmen erzeugt oder empfangen, müssen sie auch in dieser Form aufbewahrt werden – und dürfen vor Ablauf der Frist nicht gelöscht werden.

Für den XRechnung-Eingang bedeutet das:

  • Aufbewahrungsobjekt ist die Original-XML-Datei, so wie sie empfangen wurde – unveränderlich, mit Zeitstempel des Empfangs.
  • Das gerenderte PDF oder das erzeugte HTML ist eine Arbeitskopie, kein Ersatz für die XML.
  • Aufbewahrungsfrist für Eingangsrechnungen: 8 Jahre (§ 147 Abs. 1 Nr. 4 i.V.m. Abs. 3 AO; § 14b Abs. 1 UStG n.F.; § 257 Abs. 1 Nr. 4 HGB – geändert durch BEG IV, in Kraft ab 01.01.2025). Die 10-Jahresfrist gilt weiterhin für Handelsbücher, Inventare und Jahresabschlüsse (§ 147 Abs. 1 Nr. 1 AO). Quellen: § 14b UStG · Hetkamp-Kanzlei: BEG IV
  • Die XML muss indexiert und maschinell auswertbar bleiben; eine Ablage in einem nicht lesbaren Archiv-Format genügt nicht (GoBD-Grundsatz der maschinellen Auswertbarkeit).

Praxis-Empfehlung: Original-XML und Sichtdokument parallel ablegen, XML als primäres Aufbewahrungsobjekt kennzeichnen, Sichtdokument als Referenz verknüpfen.

Im Zweifel stimmen Sie die Archivierungsorganisation mit Ihrem Steuerberater ab – die vorstehenden Angaben geben den Stand der GoBD (Stand: 2019, ergänzt 2025) wieder und ersetzen keine steuerliche Einzelberatung.

Häufige Encoding- und Öffnen-Fehler

UTF-8 BOM

Das KoSIT-Schematron verlangt encoding="UTF-8" ohne Byte Order Mark (BOM). Einige Windows-Editoren (Notepad, ältere Excel-XML-Exporte) setzen ein UTF-8-BOM (EF BB BF) vor die XML-Deklaration. Das macht das Dokument für strikte XML-Parser ungültig. Lösung: Export ohne BOM konfigurieren oder das BOM beim Empfang programmatisch entfernen.

Whitespace vor der XML-Deklaration

Leerzeichen oder Zeilenumbrüche vor <?xml version="1.0" encoding="UTF-8"?> sind nach XML-Spezifikation nicht erlaubt. ERP-Middleware-Zwischenstufen fügen solche Zeichen gelegentlich ein. Symptom: Parser wirft content is not allowed in prolog.

Namespace-Mismatch

Wird eine CII-Datei mit einem UBL-spezifischen Parser verarbeitet (oder umgekehrt), schlägt die Deserialisierung fehl, weil Root-Element und Namespaces nicht übereinstimmen. Robuste Implementierungen erkennen die Syntax anhand des Root-Elements automatisch.

Zeichensatz-Probleme in Positionstexten

Sonderzeichen in Positionsbeschreibungen (z. B. typografische Anführungszeichen, Streckendash) müssen als XML-Entities oder in korrektem UTF-8 kodiert sein. Werden sie aus einem Legacy-System in ISO-8859-1 geliefert und als UTF-8 deklariert, entstehen Mojibake-Artefakte.

Versionspfad: XRechnung 3.0.2 → 4.0

Version Veröffentlicht Wesentliches
XRechnung 3.0 01.08.2023 Umsetzung EN 16931-1:2017, obligatorischer Einsatz ab 01.01.2025
XRechnung 3.0.2 03.07.2024 Bugfix-Release: Kardinalitätsfehler in BG-27/BG-28 behoben
XRechnung 4.0 geplant Mitte–Ende 2026 Umsetzung EN 16931-1:2026; neue Erweiterungsarchitektur, XML-Attachments im Kernmodell, gelockerte 1:1:1-Beziehung Bestellung–Lieferung–Rechnung

Quellen: xeinkauf.de – XRechnung 4.0 · The Invoicing Hub – XRechnung 3.0.2

Was das für Implementierungen bedeutet: Version 3.0.x und 4.0 werden strukturell verschieden sein – Schematron-Sets, XSLT-Stylesheets und XPath-Abfragen müssen bei der Migration auf 4.0 aktualisiert werden. KoSIT wird ein neues Visualisierungs-Release veröffentlichen; das Timing ist noch offen. Wer heute Systeme aufbaut, sollte die Syntax-Version beim Empfang auslesen und versioniert verarbeiten.

Weiterführende Ressourcen

Systemische Einbindung statt Einzel-Viewer

Einzelne Viewer lösen das Sichtbarkeitsproblem manuell – Rechnung für Rechnung. Wer Eingangsrechnungen in die Liquiditätsplanung überführen will, braucht eine systemische Lösung: XRechnung öffnen & lesen – Übersicht zeigt, wie der Dienst die XML automatisch verarbeitet, validiert und direkt in die 13-Wochen-Liquiditätsvorschau einbucht – ohne manuellen XSLT-Aufruf, ohne separate Ablage.

Weiterführend: E-Rechnungspflicht 2025–2028 – was gilt wann und ZUGFeRD & Factur-X erklärt.