Auf dieser Seite

Wer E-Rechnungsformate in ERP- oder Buchhaltungssysteme integriert, kommt an der Normhierarchie nicht vorbei: EN 16931 als europäischer Kern, XRechnung als deutsche CIUS-Ausprägung, ZUGFeRD als Hybrid-Format mit sechs Profilen. Dieser Artikel legt die Architektur offen: mit Syntaxvergleich, vollständiger Profilmatrix, lauffähigen Validator-Kommandos und einem klaren Ausblick auf XRechnung 4.0.

Wer die Entscheidungsfrage ohne technischen Unterbau sucht, findet sie auf der Übersichtsseite ZUGFeRD oder XRechnung; der Lösungsüberblick fasst alle verwandten E-Rechnungsthemen zusammen.

EN 16931: das semantische Rechnungsmodell der EU

Die europäische Norm EN 16931, mandatiert durch die EU-Richtlinie 2014/55/EU, definiert ein semantisches Datenmodell für elektronische Rechnungen: rund 120 Datenelemente, gegliedert in Business Terms (BT) und Business Groups (BG). Das Modell beschreibt was in einer E-Rechnung stehen muss, nicht wie es kodiert wird.

Für das „Wie" legt CEN zwei Syntaxbindungen fest:

  • CEN/TS 16931-3-2: Bindung an UBL 2.1 (OASIS-Standard)
  • CEN/TS 16931-3-3: Bindung an UN/CEFACT CII D16B (Cross Industry Invoice)

Beide Syntaxen sind inhaltlich gleichwertig. Welche ein System verwendet, ist eine Integrationsentscheidung, keine Konformitätsfrage gegenüber EN 16931.

Nationale Standardisierungsgremien dürfen die EN 16931 durch eine CIUS (Core Invoice Usage Specification) einschränken: Sie können Pflichtfelder verschärfen, optionale Felder verbindlich machen und nationale Pflichtergänzungen hinzufügen. Erweitern dürfen sie nicht; das bleibt Extensions vorbehalten.

XRechnung 3.0.2 als CIUS der EN 16931

XRechnung ist die deutsche CIUS zu EN 16931, herausgegeben von KoSIT (Koordinierungsstelle für IT-Standards im Auftrag des IT-Planungsrats). Die aktuell produktive Version ist XRechnung 3.0.2 (Stand: Juni 2026).

Was XRechnung gegenüber der reinen EN 16931 einschränkt und ergänzt:

Merkmal EN 16931 XRechnung 3.0.2
Format semantisches Modell reines XML (kein PDF-Container)
Syntax UBL 2.1 oder CII D16B beide unterstützt
Leitweg-ID (BT-10) optional Pflicht für B2G
Zahlungsart optional eingeschränkte Wertemenge
Lieferdatum optional Pflicht (soweit anwendbar)
Mengeneinheiten freie Codes Pflicht-Codeliste (UNTDID 6411)

XRechnung ist kein lesbares Dokument: Die XML-Datei enthält ausschließlich maschinenlesbare Daten. Ein Viewer (z. B. das kostenlose XRechnung-Viewer-Tool) oder ein ERP-Modul rendert die Darstellung. Für die B2G-Übermittlung an Bundesbehörden über PEPPOL oder das OZG-RE-Portal (Nachfolger der ZRE, konsolidiert September 2025) ist XRechnung verpflichtend.

ZUGFeRD 2.4: sechs Profile, eine vollständige Matrix

ZUGFeRD ist kein eigenes Datenmodell, sondern eine Implementierung der EN 16931 in einem PDF/A-3-Container. In die PDF-Datei ist ein CII-XML eingebettet, das sogenannte Hybrid-Format. Seit Version 2.2 ist ZUGFeRD technisch identisch mit dem französischen Standard Factur-X: eine ZUGFeRD-2.x-Rechnung kann ohne Anpassung an französische Geschäftspartner versendet werden.

ZUGFeRD 2.4 ist seit dem 15. Januar 2026 in Kraft (FeRD-Spezifikation) und rückwärtskompatibel zu 2.x. Das BMF-Schreiben vom 15. Oktober 2025 erkennt ZUGFeRD ab Version 2.0.1 als E-Rechnung im Sinne des § 14 UStG an, mit einer wichtigen Klarstellung: Der XML-Teil ist führend. Weicht das PDF-Rendering vom eingebetteten XML ab, gilt der XML-Inhalt. Falsche PDF-Darstellungen gefährden den Vorsteuerabzug. Typische Fehlerszenarien bei dieser Hybrid-Regel zeigt ZUGFeRD Hybrid-Falle.

ZUGFeRD 2.4 definiert sechs Profile:

Profil Rechnungspositionen Steuerdaten B2B §14 UStG Typischer Einsatz
MINIMUM nein nur Gesamtbetrag nein Zahlungsreferenz, Prepayment
BASIC WL nein ja nein Kreditnotiz ohne Positionsdaten
BASIC ja ja bedingt¹ Einfache Massenbelege
EN 16931 ja vollständig ja Standard-B2B Deutschland
EXTENDED ja vollständig + Erweiterungen ja Komplexe Branchenszenarien
XRECHNUNG ja vollständig B2G² Behörden-Hybrid (ZUGFeRD-Container, XRechnung-CIUS)

¹ BASIC enthält formal alle Pflichtfelder nach § 14 UStG; das BMF-Schreiben schließt explizit nur MINIMUM und BASIC WL aus. Für sichere B2B-Integration ist EN 16931 der empfohlene Mindeststandard.

² Das XRECHNUNG-Profil von ZUGFeRD wird in einzelnen B2G-Kontexten akzeptiert (hybrides Dokument mit XRechnung-konformem XML-Teil), ist jedoch nicht universell einsetzbar und sollte mit dem Empfänger abgestimmt werden.

Für B2B-Integration in deutschen ERP-Systemen gilt: Mindestens EN 16931, im Zweifelsfall EXTENDED, wenn branchenspezifische Felder (z. B. Branchenreferenzen, Projektcodes) benötigt werden.

Syntaxwahl: UBL 2.1 oder CII D16B?

Beide Syntaxen bilden das gleiche semantische Modell ab; die Wahl ist eine Integrationsentscheidung:

Kriterium UBL 2.1 CII D16B
Root-Element <ubl:Invoice> <rsm:CrossIndustryInvoice>
Namespace-Präfixe cbc: / cac: ram: / udt:
Standard-Gremium OASIS UN/CEFACT
PEPPOL BIS 3.0 Standard nicht verwendet
ZUGFeRD / Factur-X nicht unterstützt Pflicht
XRechnung 3.0.2 unterstützt unterstützt
Lesbarkeit ausführlich, gut lesbar kompakt, tief verschachtelt

Faustregel für ERP-Integratoren:

  • Bestehende PEPPOL-Anbindung vorhanden → UBL 2.1 für XRechnung
  • ZUGFeRD-Ausgang gewünscht → CII D16B ist zwingend (PDF/A-3-Einbettung)
  • Beide Ausgangsformate geplant → zwei Serialisierungen aus demselben semantischen Objekt; die meisten Open-Source-Bibliotheken (Mustang, Konik) unterstützen beide

Validierung: KoSIT, Mustang, Online-Tools

Jede E-Rechnung sollte vor dem Versand gegen drei Schichten validiert werden:

  1. XML-Schema (strukturelle Wohlgeformtheit)
  2. EN 16931 Schematron-Regeln (semantische Geschäftsregeln, z. B. BR-CO-15)
  3. BR-DE-Regeln (deutsche XRechnung-spezifische Einschränkungen)

KoSIT-Validator (offiziell, kostenlos)

Der offizielle Validator des IT-Planungsrats ist Java-basiert und über GitHub (itplr-kosit/validator) als Standalone-JAR verfügbar. Für XRechnung wird zusätzlich das Konfigurationspaket (itplr-kosit/validator-configuration-xrechnung) benötigt.

java -jar validator-1.6.2-standalone.jar \
  -s scenarios.xml \
  -r /pfad/zum/konfigurationspaket \
  eingangsrechnung.xml

Der Validator erkennt UBL- und CII-Syntax automatisch, extrahiert eingebettetes XML aus ZUGFeRD-PDFs und gibt einen strukturierten XML-Bericht aus.

Mustang-Bibliothek

Mustang ist eine Open-Source-Java-Bibliothek (Apache 2.0) für das Lesen, Schreiben und Validieren von ZUGFeRD- und XRechnung-Dokumenten. Sie eignet sich für die direkte ERP-Integration ohne Abhängigkeit vom KoSIT-Standalone-JAR. Mustang umfasst einen eigenen Validator-Layer und einen Online-Dienst unter mustangproject.org/validator.

Online-Validierung ohne Installation

Für Ad-hoc-Prüfungen ohne lokale Infrastruktur stehen browserbasierte Dienste bereit:

Hinweis: Online-Dienste sind für die Entwicklung geeignet. Vor Produktionsbetrieb empfiehlt sich die lokale KoSIT-Integration oder eine Bibliothek wie Mustang, damit keine Rechnungsdaten Dritte passieren.

XRechnung 4.0: Roadmap für ERP-Berater

XRechnung 4.0 wird die Umsetzung der revidierten EU-Norm EN 16931-1:2026 sein. KoSIT erwartet die Veröffentlichung Mitte bis Ende 2026; eine Vorabversion (Preview) liegt vor, ist aber ausdrücklich nicht für den Produktivbetrieb freigegeben (xeinkauf.de/aktuelles/xrechnung/xrechnung-4-umsetzung/).

Was ERP-Integratoren für die Migrationsplanung kennen müssen:

Mehrfachbestellungen pro Rechnung: Das bisherige 1:1-Modell (eine Rechnung, eine Bestellung) fällt. Ein Beleg kann künftig mehrere Bestellungen und Lieferungen referenzieren. Bestandssysteme, die auf dieses Modell aufgebaut sind, brauchen ein Datenmodell-Update.

Neue Extension-Methodik: Branchenspezifische Erweiterungen werden über eine zentrale „Extension Component Library" standardisiert. Proprietäre Extension-Ansätze aus XRechnung 3.x verlieren ihre Basis.

XML-Anhänge im Kernmodell: Bisher waren eingebettete XML-Anhänge nur in Extensions möglich. XRechnung 4.0 integriert sie in das Kernmodell, was z. B. für Steuermeldungsszenarien relevant ist.

Erheblicher Aufwand für Übergangsphase: KoSIT und FeRD sprechen explizit von „erheblichem Aufwand" für Softwarehersteller, Behörden und Unternehmen. Eine parallele Unterstützung von 3.0.2 und 4.0 während der Übergangsphase ist wahrscheinlich.

Empfehlung: Systeme, die jetzt neu entwickelt oder grundlegend modernisiert werden, sollten 4.0-Kompatibilität als Architekturziel nennen, aber erst auf Basis der finalen Spezifikation implementieren.

Was der Dienst für die Integration übernimmt

Die automatisierte Verarbeitung eingehender E-Rechnungen, unabhängig davon, ob sie als XRechnung-XML oder ZUGFeRD-Hybrid eintreffen, ist ein Kernproblem für Buchhaltung und ERP-Anbindung. Der Dienst normalisiert beide Formate auf ein einheitliches internes Modell, validiert das eingebettete XML (nicht das PDF-Rendering) und macht Abweichungen sichtbar, bevor sie in Buchen und Vorsteuerabzug einfließen.

Mehr zu den technischen Fähigkeiten im Bereich Belegverarbeitung: Cashflow aus Belegen.

Die rechtlichen Grundlagen zur gestaffelten Versandpflicht (2027/2028) erklärt E-Rechnungspflicht 2025 bis 2028.

Format-Sicherheit für den Produktivbetrieb

Wer die Profilmatrix und die XML-Führungsregel in der Integrationsspezifikation verankert, schützt den Vorsteuerabzug von vornherein. Das ist die Glaubwürdigkeit, die Finanzamt und Steuerberater im Ernstfall einfordern.

Im Navigator das Passende finden Live-Demo ansehen
Christopher Helm, Maximilian Geissinger, Uwe Martens - die Gründer von liqui.de

Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.

Navigator: Alle Inhalte entlang der Financial Supply Chain auf einen Blick
Navigator: der visuelle Index entlang der Financial Supply Chain
Was ist der Unterschied zwischen EN 16931 und XRechnung?

EN 16931 ist die europäische Norm, die ein semantisches Datenmodell für E-Rechnungen definiert. XRechnung ist die deutsche CIUS (Core Invoice Usage Specification) zu dieser Norm: Sie schränkt optionale Felder ein, macht zusätzliche Felder (z. B. die Leitweg-ID) verbindlich und benennt zugelassene Codelisten. XRechnung ist ein strenges nationales Profil der EN 16931, keine eigenständige Norm.

Welche ZUGFeRD-Profile sind für B2B-Rechnungen in Deutschland zulässig?

Für die B2B-Rechnungspflicht nach § 14 UStG sind MINIMUM und BASIC WL ausdrücklich ausgeschlossen (BMF-Schreiben vom 15. Oktober 2025 (PDF)). Empfehlenswert und rechtssicher sind die Profile **EN 16931** und **EXTENDED**. Das BASIC-Profil enthält formal alle Pflichtfelder nach § 14 UStG, sollte aber mit dem ERP-Berater und dem Steuerberater abgestimmt werden.

Muss ich mich zwischen UBL 2.1 und CII D16B entscheiden?

Für XRechnung sind beide Syntaxen gleichwertig; die Wahl hängt von der bestehenden Systemlandschaft ab. Für ZUGFeRD ist CII D16B verpflichtend, da das Format auf UN/CEFACT aufbaut. Systeme mit PEPPOL-Anbindung setzen typischerweise auf UBL 2.1.

Wann ist XRechnung 4.0 produktiv einsetzbar?

Stand Juni 2026 liegt XRechnung 4.0 als Vorabversion vor. KoSIT erwartet die finale Spezifikation Mitte bis Ende 2026, nach Veröffentlichung der revidierten EN 16931-1:2026 durch CEN. Eine produktive Implementierung ist erst nach Erscheinen der finalen Spezifikation und der zugehörigen Validierungsartefakte sinnvoll.

Wie validiere ich eine ZUGFeRD-Rechnung lokal ohne Online-Dienst?

Der offizielle KoSIT-Validator (GitHub: itplr-kosit/validator) läuft als Java-Standalone-JAR. Zusätzlich wird das XRechnung-Konfigurationspaket (itplr-kosit/validator-configuration-xrechnung) benötigt. Der Validator extrahiert automatisch den XML-Teil aus einer ZUGFeRD-PDF und prüft ihn gegen Schema, EN-16931-Regeln und BR-DE-Regeln.

Was bedeutet „XML-Teil ist führend" beim ZUGFeRD-Format?

Laut BMF-Schreiben vom 15. Oktober 2025 gilt bei ZUGFeRD der eingebettete XML-Datenteil als rechtsverbindlich, nicht die PDF-Darstellung. Weichen Betrag, Steuersatz oder Bankverbindung im PDF vom XML ab, ist der XML-Inhalt maßgeblich. ERP-Systeme müssen daher den XML-Teil auslesen und verarbeiten, nicht das gerenderte PDF.