E-Rechnung validieren und den Prüfbericht richtig lesen

Ein Validator prüft eine E-Rechnung nacheinander gegen drei Regelwerke und hält jede Abweichung in einem Prüfbericht fest.

XML-Schema der Syntax

Eine E-Rechnung nach EN 16931 liegt in einer von zwei Syntaxen vor, UBL oder UN/CEFACT CII. Alle gängigen Anwendungsspezifikationen bauen auf diesen beiden Syntaxen auf, etwa XRechnung, ZUGFeRD und Peppol BIS Billing 3.0.

Das XML-Schema der Syntax legt fest, welche Elemente erlaubt sind, in welcher Reihenfolge stehen und welchen Datentyp sie haben.

Schemafehler haben keine Regel-ID. Der XML-Parser meldet sie mit eigenen Codes, zum Beispiel cvc-complex-type.2.4.a für ein Element an einer Stelle, an der das Schema es nicht erwartet.

Bei ZUGFeRD ist eine CII-Datei in ein PDF eingebettet. Der Validator prüft den XML-Teil. Dieser Teil ist bei Abweichungen vom Bildteil maßgebend, so das BMF-Schreiben vom 15. Oktober 2025 zur Einführung der obligatorischen E-Rechnung.

Geschäftsregeln der EN 16931

Die Geschäftsregeln kontrollieren die Angaben einer E-Rechnung auf logische Fehler, etwa ob Pflichtfelder gefüllt sind und ob die Summen zueinander passen. Das Europäische Komitee für Normung (CEN) veröffentlicht diese Regeln als Schematron-Dateien auf GitHub, jeweils für UBL und für CII.

Am Präfix der Regel-ID erkennen Sie die Art der Prüfung. Regeln mit BR und einer Zahl prüfen Pflichtfelder und deren Anzahl, BR-CO prüft Berechnungen und Abhängigkeiten zwischen Feldern, BR-CL prüft Codelisten und BR-DEC die Nachkommastellen von Beträgen. Regeln wie BR-S, BR-AE oder BR-IC prüfen die Angaben zu einzelnen Umsatzsteuerkategorien.

Die CEN-Dateien enthalten außerdem syntaxspezifische Regeln. Regeln mit dem Präfix UBL-CR melden zum Beispiel eine Warnung, wenn eine UBL-Datei Elemente enthält, die nicht zum Datenmodell der EN 16931 gehören.

Regeln von XRechnung und Peppol BIS Billing 3.0

XRechnung und Peppol BIS Billing 3.0 sind Anwendungsspezifikationen der EN 16931, fachsprachlich CIUS (Core Invoice Usage Specification) genannt. Sie schreiben zusätzliche Felder vor und ergänzen die EN 16931 um eigene Regeln. Neue Datenfelder darf eine CIUS nicht einführen.

Die Regeln der XRechnung beginnen mit BR-DE und stammen von der Koordinierungsstelle für IT-Standards (KoSIT). Peppol BIS Billing 3.0 ergänzt Regeln mit den Präfixen PEPPOL-EN16931 und PEPPOL-COMMON sowie länderspezifische Regeln.

Die Spezifikationskennung in BT-24 legt fest, welche Anwendungsspezifikation für die Datei gilt. Der Validator der KoSIT wählt anhand dieser Kennung das passende Prüfszenario aus. Eine falsche oder veraltete Kennung kann deshalb dazu führen, dass die Datei gegen andere Regeln geprüft oder abgelehnt wird.

Was eine Validierung nicht prüft

Ein Validator erkennt nicht, ob der Steuersatz zur Leistung passt oder ob die Leistungsbeschreibung ausreicht.

Laut dem Bundesfinanzministerium müssen alle umsatzsteuerlichen Pflichtangaben im strukturierten Teil der E-Rechnung stehen. Ein bloßer Verweis auf eine Anlage mit der Leistungsbeschreibung genügt nicht. Ein Artikelname wie „siehe Anlage“ in BT-153 besteht die Validierung trotzdem, weil keine Regel den Inhalt dieses Feldes bewertet.

Die KoSIT und das Forum elektronische Rechnung Deutschland (FeRD) haben eine Tabelle veröffentlicht, die den Pflichtangaben nach dem Umsatzsteuergesetz die passenden BT-Felder zuordnet. Anhand dieser Tabelle können Sie festlegen, welche Pflichtangaben Ihre Software mit eigenen Plausibilitätsprüfungen absichern sollte.

Jeder Eintrag im Prüfbericht enthält in der Regel vier Angaben.

Regel-ID

Die Regel-ID wie BR-CO-15 oder BR-DE-2 verweist auf die Regel in der Dokumentation des jeweiligen Regelwerks.

Schweregrad

Ein Validator kennzeichnet jede Meldung als Fehler oder als Warnung. In den Peppol-Regeln heißen Fehler fatal. Eine Warnung allein führt in der Regel nicht zur Ablehnung. Manche Validatoren geben außerdem Hinweise aus, also Empfehlungen zur sauberen Umsetzung ohne Einfluss auf das Ergebnis. Der KoSIT-Validator empfiehlt am Ende seines Berichts, das Dokument anzunehmen oder abzulehnen.

Peppol führt neue Regeln häufig zunächst als Warnung ein und stuft sie in einem späteren Release zum Fehler hoch. Mit Version 3.0.21 wurden zum Beispiel die Regeln PEPPOL-COMMON-R052 und PEPPOL-COMMON-R053 von Warnungen zu Fehlern, so steht es in den Release Notes von Peppol BIS Billing 3.0.

Fundstelle

Die Fundstelle ist ein XPath-Ausdruck, der auf das betroffene Element im XML zeigt. Dieselbe BT-Nummer liegt in UBL und CII an unterschiedlichen Stellen. Der Rechnungsbetrag mit Umsatzsteuer (BT-112) steht in UBL im Element cbc:TaxInclusiveAmount unter cac:LegalMonetaryTotal, in CII im Element ram:GrandTotalAmount unter ram:SpecifiedTradeSettlementHeaderMonetarySummation.

Bei Regeln, die mehrere Felder vergleichen, zeigt die Fundstelle oft auf ein übergeordnetes Element. Den Wert, der die Meldung auslöst, finden Sie dann über den Meldungstext.

Meldungstext

Der Meldungstext beschreibt die Regel und nennt meist die beteiligten BT-Nummern. Die Meldung zu BR-CO-15 besagt zum Beispiel, dass der Rechnungsbetrag mit Umsatzsteuer (BT-112) der Summe aus Rechnungsbetrag ohne Umsatzsteuer (BT-109) und Umsatzsteuerbetrag (BT-110) entsprechen muss.

Seit Version 3.0.21 beginnen die Texte der Peppol-Regeln mit der Regel-ID.

Ein langer Prüfbericht geht oft auf wenige Ursachen zurück.

Die Regelgruppe zeigt oft schon, an welcher Stelle Ihrer Software die Korrektur ansetzt.

Schemafehler ohne Regel-ID

Die Ursache liegt bei der Elementreihenfolge, dem Namespace oder einem falschen Datentyp im Export. Die Korrektur setzt in der Exportfunktion an, einmal für alle Kunden.

BR mit Zahl

Die Ursache liegt bei einem Pflichtfeld, das nicht gemappt oder in den Stammdaten leer ist. Die Korrektur setzt im Mapping oder beim Pflichtfeld in der Oberfläche an.

BR-CO und BR-DEC

Die Ursache liegt bei Summen, Rundung, Nachlässen und Zuschlägen auf Belegebene. Die Korrektur setzt in der Rechenlogik der Rechnungserstellung an.

BR-CL

Die Ursache liegt bei einem veralteten oder eigenen Code, etwa für Mengeneinheiten oder Länder. Die Korrektur setzt bei den Codelisten in Ihrer Software an.

BR-S, BR-AE, BR-IC und weitere Kategorien

Umsatzsteuerkategorie, Steuersatz und Befreiungsgrund passen nicht zusammen. Die Korrektur setzt in der Steuerlogik und bei den Artikelstammdaten an.

UBL-CR

Der Export enthält UBL-Elemente außerhalb des Datenmodells der EN 16931. Die Korrektur setzt in der Exportfunktion an.

BR-DE

Kontaktdaten des Verkäufers, Zahlungsangaben oder die Käuferreferenz fehlen. Die Korrektur setzt meist bei den Stammdaten Ihrer Kunden an.

PEPPOL-EN16931 und PEPPOL-COMMON

Die elektronische Adresse fehlt oder eine Kennung hat das falsche Format. Die Korrektur setzt bei den Stammdaten und der Verwaltung der Peppol-IDs an.

Fehlende Käuferreferenz bei XRechnung (BR-DE-15)

Die Regel BR-DE-15 meldet eine fehlende Käuferreferenz in BT-10. Bei Rechnungen an die öffentliche Verwaltung steht dort die Leitweg-ID der Behörde. Für B2B-Rechnungen reicht laut dem Bundesfinanzministerium umsatzsteuerlich ein Platzhalter wie „-“, wenn der Rechnungsempfänger keinen eigenen Bezeichner vorgibt. Ihre Software kann das Feld für B2B-Rechnungen deshalb mit einem Platzhalter vorbelegen, den Ihre Kunden überschreiben können.

Rundungsdifferenzen bei der Umsatzsteuer (BR-S-09)

Die Regel BR-S-09 vergleicht den Umsatzsteuerbetrag der Kategorie Normalsatz mit dem Produkt aus Bemessungsgrundlage und Steuersatz. Wenn Ihre Software die Umsatzsteuer je Position rundet und die Beträge addiert, kann die Summe davon abweichen. Bei vielen Positionen kann die Abweichung größer werden als die Toleranz, die die Regel zulässt. Berechnen Sie den Steuerbetrag deshalb je Kategorie aus Bemessungsgrundlage und Steuersatz, wie es die Regel vorgibt.

Die Validierung gehört an fünf Stellen in Ihre Software und Ihren Entwicklungsprozess.

Vor dem Versand

Ihre Software sollte jede E-Rechnung direkt nach der Erstellung validieren und den Versand bei Fehlern anhalten. Ihre Kunden können mit einer Regel-ID oder einem XPath-Ausdruck wenig anfangen. Übersetzen Sie deshalb die Regeln, die Ihre Kunden selbst beheben können, in einen Hinweis am betroffenen Formularfeld. Der Hinweis zu BR-DE-6, der Telefonnummer des Verkäuferkontakts in BT-42, kann zum Beispiel lauten „Bitte hinterlegen Sie eine Telefonnummer für Rückfragen“.

Fehler, die auf Ihr Mapping oder Ihre Rechenlogik zurückgehen, kann Ihr Kunde nicht beheben. Solche Fehler sollten als interner Hinweis an Ihr Team gehen.

Beim Empfang

Ihre Software sollte auch eingehende E-Rechnungen validieren und das Ergebnis am Beleg anzeigen. Speichern Sie die Originaldatei unverändert und den Prüfbericht als eigenes Dokument daneben. Das Bundesfinanzministerium verlangt, dass zumindest der strukturierte Teil einer E-Rechnung unversehrt in seiner ursprünglichen Form aufbewahrt wird.

Wenn eine Eingangsrechnung Fehler enthält, kann Ihr Kunde beim Absender eine berichtigte Rechnung anfordern. Ihre Software kann diesen Schritt unterstützen, etwa mit einer vorbereiteten Rückfrage an den Absender, die den Prüfbericht enthält.

In automatisierten Tests

Legen Sie eine Sammlung von Testrechnungen an, die Ihre Rechnungsarten mit ihren Codes abdeckt, zum Beispiel 380 für eine Rechnung und 384 für eine Rechnungsberichtigung. Decken Sie außerdem jede Umsatzsteuerkategorie ab, die Ihre Kunden nutzen. Dazu kommen Nachlässe und Zuschläge sowie jede Syntax, die Ihre Software erzeugt. Nehmen Sie auch bewusst fehlerhafte Dateien auf und prüfen Sie, dass der Validator sie ablehnt.

Der KoSIT-Validator ist ein Open-Source-Programm für die Kommandozeile und lässt sich in eine Build-Pipeline einbinden. Die KoSIT stellt außerdem eine Testsuite mit Beispielrechnungen bereit, die sich als Ausgangspunkt für Ihre eigene Sammlung eignet.

Nach jedem Update der Regelwerke

Die Regelwerke ändern sich auch ohne neue Versionsnummer. Die KoSIT veröffentlicht für XRechnung 3.0.2 regelmäßig Bundles mit Fehlerkorrekturen, zuletzt in der Fassung vom 31. August 2026. XRechnung 3.0 bleibt bis mindestens 31. Juli 2027 in Kraft.

Die Vorversion der Spezifikation XRechnung 4.0 ist am 15. September 2026 erschienen. Sie ist ausdrücklich nicht für den produktiven Einsatz bestimmt, sondern gibt Ihnen einen frühen Überblick über die neuen und geänderten Funktionalitäten. Die finale Version wird voraussichtlich im Frühjahr 2027 zusammen mit den technischen Komponenten erscheinen.

OpenPeppol veröffentlicht für Peppol BIS Billing 3.0 regelmäßig neue Releases, in den letzten Jahren jeweils im Mai und im November. Version 3.0.21 wurde am 20. Mai 2026 veröffentlicht und ist seit dem 17. August 2026 verbindlich.

Planen Sie für jedes Release einen festen Termin, an dem Sie Ihre Testsammlung gegen die neuen Regeln validieren. Halten Sie in jedem Prüfbericht fest, mit welcher Version von Validator und Regelwerk er entstanden ist. Damit können Sie ein Ergebnis auch dann nachvollziehen, wenn sich die Regeln inzwischen geändert haben. Für den Wechsel auf XRechnung 4.0 sollte Ihre Testumgebung beide Versionen parallel prüfen können.

Prüfberichte über alle Kunden hinweg auswerten

Wenn Ihre Software E-Rechnungen für viele Kunden erzeugt, lohnt sich eine Auswertung der Prüfberichte über alle Kunden hinweg. Taucht dieselbe Regel-ID plötzlich bei vielen Kunden auf, liegt die Ursache wahrscheinlich im Mapping oder in einem neuen Regelwerk. Tritt sie nur bei einem Kunden auf, liegt die Ursache eher in dessen Stammdaten.

Die Schritte aus diesem Beitrag können Sie vollständig selbst umsetzen. Der einmalige Aufwand dafür ist überschaubar, der dauerhafte nicht: Regelwerke, Codelisten und Prüfkonfigurationen ändern sich mehrmals im Jahr, und jede Änderung muss in Ihre Tests, in Ihren Versand und in Ihre Releaseplanung.

Validierung, Versand und die Pflege der Regelwerke lassen sich deshalb auch an einen zertifizierten Peppol Access Point wie InvoiceRails abgeben.

E-Rechnungs-Validator für Einzelprüfungen

Der kostenlose E-Rechnungs-Validator von InvoiceRails prüft XML-Dateien in UBL und CII sowie hybride PDF-Rechnungen, ohne Anmeldung. Er erkennt Syntax, Version und Profil automatisch, darunter XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X und weitere Profile der EN 16931. Er validiert die Datei dann gegen das XML-Schema sowie gegen die Schematron- und Geschäftsregeln des erkannten Profils. Den Prüfbericht können Sie als PDF herunterladen oder per Link teilen, etwa wenn Ihr Support eine abgelehnte Rechnung mit einem Kunden bespricht.

InvoiceRails-API in Ihrer Software

InvoiceRails ist der OpenPeppol-zertifizierte Peppol Access Point von fino data services. Ihre Software bindet InvoiceRails über eine REST-API an und versendet und empfängt darüber E-Rechnungen für beliebig viele Kunden, auf Wunsch als Whitelabel.

Die API bietet die Validierung als eigenen Endpunkt, ebenfalls mit automatischer Profilerkennung. Ihre Software kann E-Rechnungen damit direkt nach der Erstellung prüfen. Jede Meldung in der Antwort enthält Regel-ID, Schweregrad, Meldungstext und Fundstelle als XPath. Ihre Software kann die Validierungs-ID bei der Rechnung speichern und das Ergebnis mindestens 90 Tage lang erneut abrufen.

InvoiceRails validiert jede Datei, die Ihre Software über Peppol versendet, auch ohne diesen Aufruf. Ihre Software muss vorab prüfen, welche Formate ein Empfänger unterstützt.

InvoiceRails prüft auch eingehende E-Rechnungen und übergibt die Originaldatei zusammen mit den ausgelesenen Rechnungsdaten an Ihre Software. Ein Webhook meldet Ihrer Software jede Änderung des Zustellstatus.

Ihre Software übernimmt weiterhin die Zuordnung der Felder aus Ihrem Datenmodell, die verständlichen Hinweise in Ihrer Oberfläche und die Plausibilitätsprüfungen für Pflichtangaben, die keine Regel abdeckt.