XRechnung, ZUGFeRD und BIS Billing 3.0, welche E-Rechnungsformate Ihre Software unterstützen sollte

Die EN 16931 beschreibt ein semantisches Datenmodell. Sie legt fest, welche Angaben eine Rechnung enthält und wie sie zueinander stehen, etwa die Rechnungsnummer als BT-1 oder die Käuferreferenz als BT-10. Die Norm selbst ist kein Dateiformat.

Für die technische Abbildung erlaubt sie zwei Syntaxen: UBL und UN/CEFACT CII. Beide bilden dasselbe semantische Modell ab, unterscheiden sich aber in Elementnamen und Aufbau. Software, die nur UBL einliest, kann eine CII-Rechnung nicht automatisch verarbeiten, auch wenn diese normkonform ist.

Für die Implementierung entscheidet das über den Pflegeaufwand. Zwei parallele Mappings bedeuten, dass jede Regeländerung an zwei Stellen nachgezogen werden muss. Wer stattdessen einmal auf das semantische Modell der Norm abbildet und daraus beide Syntaxen erzeugt, fasst pro Änderung nur eine Stelle an.

Beim Empfang wird die eingehende Datei umgekehrt zuerst auf das semantische Modell abgebildet und von dort in Ihr Datenmodell übernommen.

Über der Norm liegen die nationalen und netzwerkspezifischen Ausprägungen, im Standard Core Invoice Usage Specification genannt, kurz CIUS. Eine CIUS engt die Norm ein. Sie macht optionale Felder verpflichtend, schließt andere aus und bringt eigene Schematron-Regeln mit. Ausprägungen, die über den Umfang der Norm hinausgehen, heißen Extension.

Unabhängig von Syntax und Ausprägung liegt eine E-Rechnung entweder als reine XML-Datei vor oder als PDF/A-3 mit eingebetteter XML-Datei. Für den zweiten Fall hat sich der Ausdruck hybrides Format eingebürgert.

XRechnung ist eine CIUS der EN 16931 und wird von der Koordinierungsstelle für IT-Standards gepflegt, kurz KoSIT. Es gibt sie in beiden Syntaxen. Eine Sichtkomponente hat sie nicht, die Datei ist reines XML.

XRechnung ist für Rechnungen an die Bundesverwaltung vorgegeben. Die Rechnung wird über die Leitweg-ID adressiert, die im Datensatz als Käuferreferenz angegeben wird.

Der Einreichungsweg hängt vom Empfänger ab. In Frage kommen die Portale ZRE und OZG-RE oder ein Peppol Access Point. Im B2B spielt die Leitweg-ID keine Rolle. Dort ist XRechnung nur eines von mehreren zulässigen Profilen.

Derzeit gilt Version 3.0.2. Für XRechnung 4.0, die Umsetzung der EN 16931 in der Fassung 2026, gibt es bereits eine Vorversion. Die finale Version der XRechnung 4.0 wird voraussichtlich im Frühjahr 2027 veröffentlicht werden.

ZUGFeRD verpackt eine XML-Datei nach CII in ein PDF/A-3. Der Mensch sieht das PDF, während die Software das XML liest.

Die Spezifikation kennt mehrere Profile mit unterschiedlichem Datenumfang, von MINIMUM bis EXTENDED.

MINIMUM und BASIC WL enthalten keine vollständige Rechnung und erfüllen die Norm nicht. Ab dem Profil EN 16931, in älteren Fassungen COMFORT genannt, ist der strukturierte Teil normkonform. Ihre Software sollte das Profil beim Import auslesen und Dateien mit MINIMUM oder BASIC WL gesondert behandeln, etwa über eine manuelle Prüfung.

Factur-X ist technisch weitgehend deckungsgleich mit ZUGFeRD.

ZUGFeRD ist vor allem dort sinnvoll, wo Ihre Kunden an Empfänger fakturieren, die Rechnungen weiterhin visuell prüfen. Dabei ist nur das eingebettete XML rechtlich maßgeblich. Weichen PDF und XML voneinander ab, gehen laut BMF-Schreiben vom 15. Oktober 2025 die Daten des strukturierten Teils vor.

Ein Freigabeprozess, der nur das PDF prüft, kann deshalb eine Rechnung freigeben, deren maßgeblicher Inhalt anders lautet.

Beim Versand sollte Ihre Software PDF und XML aus demselben Datensatz erzeugen, damit beide nicht auseinanderlaufen. Beim Empfang sollte sie für die Prüfung eine eigene Ansicht aus dem XML aufbauen, statt das mitgelieferte PDF anzuzeigen. Das Bundesfinanzministerium empfiehlt ebenfalls, den XML-Teil selbst zu visualisieren.

Peppol BIS Billing 3.0 ist ebenfalls eine CIUS der EN 16931, festgelegt auf UBL 2.1. OpenPeppol hat es als eigenes Format für den Austausch von Rechnungen und Gutschriften über das Netzwerk spezifiziert.

Es bringt zusätzlich zu den Regeln der Norm eigene Schematron-Regeln mit. Eine Datei kann die Prüfung gegen die EN 16931 bestehen und an einer Peppol-Regel scheitern. Häufig sind das Codelisten oder Felder, die das Netzwerk enger fasst als die Norm.

Die Spezifikation wird versioniert weiterentwickelt. Wer selbst validiert, sollte prüfen, ob seine Regelsätze dem aktuellen Stand entsprechen.

Längerfristig bewegt sich Peppol Richtung PINT, einer international abgestimmten Basis für Rechnungsprofile außerhalb Europas. Für die Umsetzung in Deutschland ändert das derzeit nichts.

Für diese Rechnungen muss Ihre Software XRechnung erzeugen können. Die Leitweg-ID des Empfängers gehört als Pflichtfeld in den Rechnungsdatensatz und wird in der XRechnung als Käuferreferenz (BT-10) ausgegeben. Fehlt sie oder steht sie im falschen Feld, weist das Empfangsportal die Rechnung ab.

Das Gesetz verlangt eine Rechnung nach EN 16931 und lässt das Format offen. XRechnung, ZUGFeRD ab dem Profil EN 16931 und auch Peppol BIS Billing sind zulässig. Das eingebettete XML bleibt dabei rechtlich maßgeblich. Weichen PDF und XML voneinander ab, prüft der Empfänger womöglich andere Angaben als die, die rechtlich gelten.

Unternehmen im Inland müssen seit dem 1. Januar 2025 E-Rechnungen nach EN 16931 empfangen können. Für eine normkonforme E-Rechnung braucht der Absender daher keine Zustimmung des Empfängers, auch wenn dieser ein bestimmtes Format bevorzugt.

Beide Seiten müssen sich nur über den Übertragungsweg und über Formate außerhalb der Norm absprechen. In der Praxis gehört der vereinbarte Weg deshalb in die Stammdaten des einzelnen Geschäftspartners.

Neben Peppol BIS Billing 3.0 lassen sich über das Peppol-Netzwerk auch XRechnung und seit März 2025 ZUGFeRD als hybride Datei übertragen. Die Dokumenttypen, die ein Empfänger im Verzeichnisdienst registriert hat, zeigen, welche Formate er annimmt. Vor dem Versand muss Ihre Software diese Registrierung abfragen und das passende Format wählen. Für einzelne Prüfungen zeigt die Peppol-ID-Suche das ohne Anmeldung an.

Im laufenden Betrieb sollte Ihre Software diese Abfrage vor dem Versand automatisch stellen, entweder direkt über die Verzeichnisdienste SML und SMP oder über die API Ihres Peppol Access Points. Basierend darauf wird ein gemeinsam unterstütztes Format festgestellt und dann die E-Rechnung in diesem Format generiert.

Eingehende Rechnungen kommen in dem Format an, das der Absender gewählt hat. Ihre Software sollte deshalb beide Syntaxen lesen können, UBL und CII, und damit auch XRechnung in beiden Varianten. Dazu kommen ZUGFeRD und Factur-X als hybride Dateien und, sobald Ihre Kunden Rechnungen aus dem Ausland erhalten, die dort üblichen Profile.

Jede eingehende Datei enthält eine Kennung dafür, welche Ausprägung sie verwendet. In UBL steht sie im Element cbc:CustomizationID, in CII im Kontextparameter der Richtlinie. Ihre Software sollte diese Kennung zuerst auslesen, denn davon hängt ab, welche Prüfregeln greifen und wie die Datei in Ihr Datenmodell übernommen wird.

Manche Peppol Access Points nehmen Ihnen diesen Schritt ab. Sie prüfen die eingehende Datei, lesen die Rechnungsdaten aus und übergeben sie zusammen mit der Originaldatei als einheitlichen Datensatz.

Ihre Software sollte den Empfang vor dem Versand vollständig abdecken, also beide Syntaxen und die hybriden Formate, denn Ihre Kunden müssen E-Rechnungen bereits heute empfangen können.

Der Versand wird für Ihre Kunden in zwei Stufen Pflicht. Ab dem 1. Januar 2027 bei mehr als 800.000 Euro Gesamtumsatz des Vorjahres und ab dem 1. Januar 2028 für alle übrigen inländischen B2B-Umsätze.

Wer mit der Syntax CII beginnt, kann damit XRechnung in der CII-Variante und ZUGFeRD erzeugen. UBL wird nötig, sobald Empfänger im Peppol-Netzwerk Peppol BIS Billing 3.0 erwarten, denn dieses Format setzt UBL voraus.

Alle umsatzsteuerlichen Pflichtangaben müssen maschinell auswertbar im strukturierten Teil der E-Rechnung stehen. Dazu gehört auch die Leistungsbeschreibung. Ein Verweis auf einen Anhang, einen Lieferschein oder einen Link ersetzt kein Pflichtfeld. Grundlage sind die FAQ des Bundesfinanzministeriums zur E-Rechnung und das BMF-Schreiben vom 15. Oktober 2025.

Der Grund liegt im Aufbau der E-Rechnung. Bei hybriden Formaten wie ZUGFeRD sind die Daten im XML führend, das PDF ist nur eine Ansicht. Eine Angabe, die nur im PDF sichtbar ist, zählt deshalb nicht.

Fehlt eine Pflichtangabe im strukturierten Teil, gilt die Rechnung als nicht ordnungsgemäß und der Vorsteuerabzug des Empfängers kann gefährdet sein. Ihre Kunden merken das spätestens, wenn Geschäftspartner Rechnungen deshalb zurückweisen.

Viele Rechnungsvorlagen transportieren Pflichtangaben als Textbausteine, die nur im PDF erscheinen. Häufig betrifft das die Leistungsbeschreibung, etwa “gemäß Angebot 2026-114”, den Leistungszeitraum im Fußbereich der Rechnung und den Hinweis auf die Steuerschuldnerschaft des Leistungsempfängers.

Im Datenmodell sollte jede dieser Angaben ein eigenes Feld haben, aus dem das XML befüllt wird. Der Leistungszeitraum gehört in die Felder für den Abrechnungszeitraum (BG-14), der Reverse-Charge-Hinweis in die Steuerkategorie mit Befreiungsgrund (BT-120 und BT-121).

Die technische Validierung prüft, ob die Pflichtfelder der Norm vorhanden und formal korrekt befüllt sind. Sie erkennt nicht, ob eine Leistungsbeschreibung umsatzsteuerlich ausreicht. Eine Rechnung kann die Prüfung also bestehen und eine Pflichtangabe trotzdem nur unzureichend enthalten.

Lieferscheine, Stundennachweise und andere rechnungsbegleitende Unterlagen lassen sich als Anhang in die E-Rechnung einbetten, in der EN 16931 über die Gruppe der zusätzlichen Belege (BG-24). Das ersetzt den separaten Versand und hält Rechnung und Nachweis in einer Datei zusammen.

Eine XRechnung wird gegen zwei Regelwerke geprüft, die Regeln der EN 16931 und die zusätzlichen Regeln der KoSIT. Für Peppol BIS Billing 3.0 gilt dasselbe mit den Regeln von OpenPeppol. Eine Prüfung allein gegen die Norm sagt deshalb nur begrenzt etwas darüber aus, ob der Empfänger die Datei annimmt. Ihre Software sollte gegen das Regelwerk der Ausprägung prüfen, die der Empfänger erwartet.

KoSIT und OpenPeppol veröffentlichen regelmäßig neue Versionen ihrer Regelwerke mit angepassten Codelisten und Schematron-Regeln. Hält Ihre Software die Regelsätze nicht aktuell, können Rechnungen abgelehnt werden, die bisher angenommen wurden. Die Ablehnung kommt dann vom Empfänger, die Ursache liegt aber im eigenen, veralteten Regelsatz.

Für Tests während der Entwicklung lassen sich einzelne Dateien mit dem kostenlosen E-Rechnungs-Validator gegen die EN 16931 und die Peppol-Regeln prüfen. Für die automatische Prüfung im Betrieb bietet InvoiceRails die Validierung auch über eine API an, gegen die EN 16931 und Profile wie XRechnung, ZUGFeRD und Peppol BIS Billing. Der Prüfbericht weist Fehler, Warnungen und Hinweise getrennt aus.

Ein Mapping wird einmal gebaut, die Prüfregeln dahinter können sich mehrmals im Jahr ändern. Der nächste größere Wechsel steht mit XRechnung 4.0 und der EN 16931 in der Fassung 2026 bereits an.

Die Fassung 2026 stützt sich auf UBL 2.5. In konformen Implementierungen lässt sich UBL 2.5 erst nutzen, wenn CEN ein aktualisiertes Syntax-Binding veröffentlicht hat. Bis dahin gelten die bestehenden Bindungen auf Basis von UBL 2.1. Anbieter können den Umstieg also vorbereiten, aber noch nicht umsetzen.

Wer die Anbindung selbst baut, übernimmt diese Pflege dauerhaft. Dazu gehört, die Mappings für beide Syntaxen, die Codelisten und die Schematron-Regeln aktuell zu halten und die Versionspläne von KoSIT, FeRD, OpenPeppol und CEN zu verfolgen. Das ist machbar, bindet aber Entwicklungszeit, die im eigenen Produkt fehlt.

Alternativ lässt sich die Formatpflege an einen Peppol Access Point auslagern. InvoiceRails, der OpenPeppol-zertifizierte Access Point von fino data services, deckt über eine API mehr als 60 Formate ab, darunter XRechnung, ZUGFeRD und Factur-X, und pflegt Validierungsregeln und Format-Updates laufend nach.

Anbieter binden Versand und Empfang einmal an und stellen die Funktion beliebig vielen ihrer Kunden zur Verfügung, auf Wunsch unter eigener Marke. Die Abbildung der eigenen Rechnungsdaten auf die Schnittstelle bleibt beim Anbieter, ebenso die Pflichtfelder im eigenen Datenmodell.

Wie Softwareanbieter E-Rechnung grundsätzlich in das eigene Produkt bringen, lesen Sie im Beitrag zu E-Rechnung für Softwareanbieter.