E-Rechnung prüfen: Validatoren für XRechnung und ZUGFeRD und was ihre Fehlermeldungen bedeuten

Die Prüfung betrifft jedes Unternehmen, denn seit 1. Januar 2025 muss jeder im Inland ansässige Unternehmer E-Rechnungen empfangen können, ohne Übergangsregelung (Rn. 62 BMF-Schreiben vom 15.10.2024). Wer eine XRechnung oder eine ZUGFeRD-Datei erhält, entscheidet mit dem Prüfergebnis, ob er die Rechnung bucht, zurückfragt oder eine Berichtigung verlangt. Prüfen ist damit ein praktischer Teil der Pflichten, die die E-Rechnungspflicht in Deutschland für den Rechnungseingang mit sich bringt.

Was der Prüfbericht für die Rechnung bedeutet, hängt von der Fehlerart ab. Ein Formatfehler macht die Datei zur sonstigen Rechnung. Ein Geschäftsregelfehler ohne Formatfehler lässt sie umsatzsteuerlich prinzipiell eine E-Rechnung bleiben. Ein Inhaltsfehler betrifft die Pflichtangaben und kann auch dann vorliegen, wenn der Validator nichts meldet.

Die Abschnitte folgen dieser Reihenfolge: welche Werkzeuge es gibt und was sie prüfen, welche Fehlerarten die BMF-Schreiben unterscheiden, was die häufigsten Codes im Prüfbericht bedeuten, worauf sich ein Empfänger verlassen darf und wie ein Betrieb die Prüfung beim Empfang und vor dem Versand einbaut.

Die Tabelle fasst zehn Kernpunkte zur Prüfung einer E-Rechnung mit ihrer Grundlage zusammen.

Was eine Prüfung umfasst: Technik und Inhalt

Die Prüfung einer E-Rechnung hat zwei Ebenen: Die technische Validierung zeigt, ob die Datei dem Format und seinen Geschäftsregeln entspricht, die inhaltliche Kontrolle, ob die umsatzsteuerlichen Pflichtangaben richtig und vollständig sind. Ein Validator deckt nur die erste Ebene ab: Auf sein Ergebnis darf sich ein Unternehmer nach Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025 „hinsichtlich des Formats und der Geschäftsregeln“ verlassen. Ob der Steuersatz stimmt oder die Leistung richtig beschrieben ist, erkennt kein Programm, das nur die Struktur der Datei kennt. Beide Ebenen gehören zu dem, was jedes Unternehmen seit 1. Januar 2025 beim Empfang können muss.

Technische Validierung: Schema und Schematron

Technisch prüft ein Validator, ob die XML-Datei dem Schema ihrer Syntax entspricht, und testet sie danach mit Schematron-Regeln gegen die Geschäftsregeln der EN 16931 und, bei einer XRechnung, gegen die nationalen BR-DE-Regeln. Das Schema beschreibt, welche Elemente in welcher Reihenfolge stehen dürfen. Schematron-Regeln prüfen die logischen Abhängigkeiten zwischen den Feldern, etwa ob ein Steuerbetrag zum Steuersatz passt.

Zwei Syntaxen kommen in Frage: UBL 2.1 und UN/CEFACT CII in der Fassung D16B. Beide decken die CEN-Validierungsartefakte in der Version 1.3.17 vom 12. Oktober 2026 ab, die unter der Lizenz EUPL 1.2 stehen (Stand: 29.10.2026). Rechtlich knüpft § 14 Abs. 1 Satz 6 Nr. 1 UStG die E-Rechnung an die EN 16931 und ihre Syntaxen; nach Nr. 2 genügt auch ein vereinbartes Format, wenn es nach Satz 7 die richtige und vollständige Extraktion der Angaben ermöglicht.

Die deutschen Zusatzregeln der XRechnung veröffentlicht die KoSIT als XRechnung Schematron, derzeit in der Version 2.6.0 vom 31. August 2026, auf GitHub freigegeben am 2. September 2026 und kompatibel mit XRechnung 3.0. Ein Prüfbericht kann deshalb zwei Regelquellen nebeneinander nennen: europäische Regeln aus der Norm und BR-DE-Regeln der KoSIT. Woher die europäischen Regeln stammen, erklärt die Seite über die europäische Norm hinter jeder E-Rechnung.

Inhaltliche Kontrolle der umsatzsteuerlichen Angaben

Ein positives Prüfergebnis ersetzt nicht die Pflicht des Empfängers, die Rechnung auf Vollständigkeit und Richtigkeit zu prüfen (Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025; Abschn. 15.2a Abs. 6 UStAE). Der Validator bestätigt nur, dass die Datei technisch stimmig ist. Ob die Angaben in der Sache zutreffen, bleibt eine Frage an den Empfänger.

Das Beispiel der Finanzverwaltung in Rn. 35a ist ein fehlerhafter Steuersatz: Er ist ein Inhaltsfehler, auch wenn kein Validierungsfehler vorliegt. Der Validator prüft nur, ob Steuerbetrag und Steuersatz zueinander passen, nicht, ob der Satz für die Leistung zutrifft.

Alle umsatzsteuerlichen Pflichtangaben müssen im strukturierten Teil der E-Rechnung stehen; ein bloßer Verweis auf eine Anlage genügt nicht (BMF-FAQ Frage 7a). Die inhaltliche Kontrolle richtet sich deshalb auf die XML-Daten, nicht auf eine Bildansicht. Welche Angaben dazu gehören, listet die Seite zu den Pflichtangaben einer Rechnung nach § 14 Abs. 4 UStG.

Validatoren im Überblick: öffentliche Werkzeuge und was sie prüfen

Öffentlich zugänglich sind vor allem der KoSIT-Validator mit der Konfiguration XRechnung, die Schematron-Regeln der KoSIT und des CEN, das Mustangproject für ZUGFeRD sowie die Prüfberichte der Rechnungsportale von Bund und Baden-Württemberg; eine bestimmte Anwendung empfiehlt das BMF nicht (BMF-FAQ Frage 7). Die Tabelle zeigt, wer sie herausgibt, was sie prüfen und welche Version aktuell ist.

Der KoSIT-Validator und seine Prüfszenarien

Der KoSIT-Validator ist eine Prüfengine für XML-Dateien, die selbst keine Regeln enthält: Was er prüft, legt eine Szenario-Konfiguration fest, für die XRechnung die Konfiguration v2026-08-31 mit den CEN-Schematron-Regeln 1.3.16 (Stand: 29.10.2026). Die aktuelle Version 1.6.3 des Validators stammt vom 20. August 2026 und arbeitet mit Schema und Schematron. Zu jeder geprüften Datei erzeugt er immer einen Prüfbericht im XML-Format; mit der Option -D läuft er als HTTP-Daemon. Die Konfiguration v2026-08-31 ist am 2. September 2026 erschienen; ihre Vorgängerin vom 31. Januar 2026 (veröffentlicht am 5. Februar 2026) enthielt noch die CEN-Regeln 1.3.15 und den Validator 1.6.0. Versionen und Änderungen stehen in den Releases des KoSIT-Validators auf GitHub.

Die Konfiguration prüft gegen XRechnung 3.0. Aktuell ist die XRechnung 3.0.2; die Version 3.0 bleibt nach Angabe der KoSIT bis mindestens 31. Juli 2027 gültig. Die XRechnung 4.0 liegt nur als Vorversion 4.0.0 vom 15. September 2026 vor und ist nicht für den produktiven Einsatz bestimmt; die CEN-Validierungsartefakte für die EN 16931-1:2026 stehen nach der KoSIT (16. September 2026) noch aus. Zu beachten ist ein Versionsabstand: Die Konfiguration v2026-08-31 enthält die CEN-Regeln 1.3.16, während das CEN am 12. Oktober 2026 die Fassung 1.3.17 veröffentlicht hat. Welche Fassung der Standard selbst hat, beschreibt die Seite zur XRechnung, der deutsche Standard mit seinen Versionen.

Werkzeuge für ZUGFeRD-Dateien: Mustangproject und Quba

Für ZUGFeRD-Dateien steht das Mustangproject zur Verfügung, eine Open-Source-Bibliothek unter APL2, die ZUGFeRD 2 mit seinem technischen Zwilling Factur-X, ZUGFeRD 1 und XRechnung lesen, schreiben und validieren kann; die Version 2.26.0 stammt vom 25. August 2026 (Stand: 29.10.2026). Das Mustangproject richtet sich an Entwickler, die eine Prüfung in eigene Programme einbauen. Es ist kein fertiges Programm für die Buchhaltung.

Quba 2.0 vom 15. Oktober 2026 validiert offline und beruht auf dem Mustangproject; das Projekt ist Open Source, kostenlos und läuft unter Windows, macOS und Linux. Bei einer hybriden ZUGFeRD-Datei ist der strukturierte Teil der führende Teil, bei Abweichungen gelten seine Daten (Abschn. 14.4 Abs. 3 Sätze 5, 6 UStAE); entscheidend ist also das Prüfergebnis der XML-Datei. Technische Fehler des PDF/A-Containers sind nach der ZUGFeRD-FAQ des FeRD nur eine Warnung und kein schwerwiegender Fehler; der Empfänger kann aber eine korrigierte Fassung verlangen. Als E-Rechnung gilt ZUGFeRD ab Version 2.0.1, mit Ausnahme der Profile MINIMUM und BASIC-WL (BMF-FAQ Frage 7).

Prüfberichte vor dem Versand an öffentliche Stellen

Wer an den Bund schreibt, erhält in der OZG-RE bei Weberfassung und Upload noch vor dem Versand einen Prüfbericht mit formalen Fehlern; die frühere Zentrale Rechnungseingangsplattform des Bundes ist abgeschaltet. Das beschreibt die FAQ der OZG-RE auf e-rechnung-bund.de. Fehler lassen sich damit beheben, bevor die Rechnung den Auftraggeber erreicht.

Die OZG-RE ist seit 19. September 2025 die einzige Plattform des Bundes für den Rechnungsempfang (Stand: 29.10.2026). Das Land Baden-Württemberg betreibt zusätzlich einen öffentlichen E-Rechnungs-Validator für die formale Validierung von XRechnungen unter erechnungsvalidator.service-bw.de. Wie die Einreichung beim Bund im Einzelnen abläuft, zeigt die Seite OZG-RE: Registrierung, Login und Einreichung.

Formatfehler, Geschäftsregelfehler, Inhaltsfehler: was eine Fehlermeldung für die Rechnung bedeutet

Ob eine Datei nach einer Fehlermeldung noch eine E-Rechnung ist, hängt von der Fehlerart ab: Ein Formatfehler macht sie zur sonstigen Rechnung, ein Geschäftsregelfehler ohne Formatfehler lässt sie umsatzsteuerlich prinzipiell eine E-Rechnung bleiben, und ein Inhaltsfehler betrifft die Pflichtangaben (Rn. 6a, 6b, 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025; Rn. 22, 23 BMF-Schreiben vom 15.10.2026). Die drei Fehlerarten stehen im BMF-Schreiben vom 15.10.2025 und im BMF-Schreiben vom 15.10.2026. Die Tabelle stellt sie mit ihrer Folge nebeneinander.

Formatfehler: Die Datei verliert ihren Status

Ein Formatfehler liegt vor, wenn die Datei nicht den zulässigen Syntaxen oder ihren technischen Vorgaben entspricht oder, bei einem vereinbarten Format nach § 14 Abs. 1 Satz 6 Nr. 2 UStG, keine richtige und vollständige Extraktion zulässt (Rn. 6a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025; Abschn. 14.1 Abs. 11 UStAE).

Die Datei ist dann eine sonstige Rechnung, also eine Rechnung, die in einem anderen elektronischen Format oder auf Papier übermittelt wird (§ 14 Abs. 1 Satz 4 UStG). Auf die Art des Formatfehlers kommt es nach Rn. 6a nicht an: Jeder Formatfehler führt zu dieser Folge. Welche Formate die Voraussetzungen erfüllen, zeigt die Übersicht Formate der E-Rechnung im Vergleich.

Geschäftsregelfehler: Der Status bleibt, solange keine Pflichtangabe betroffen ist

Ein Geschäftsregelfehler ist ein Verstoß gegen die technischen Vorschriften zur Überprüfung der logischen Abhängigkeiten, etwa ein fehlendes Feld BT-10 oder ein Steuerbetrag, der nicht zum Steuersatz passt; ein Validator meldet ihn zum Beispiel als „critical Error“ (Rn. 6b BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025). Technisch gilt eine solche Datei als fehlerhaft, auch wenn ihr Schema stimmt.

Umsatzsteuerlich bewertet die Finanzverwaltung den Fall anders. Rn. 23 BMF-Schreiben vom 15.10.2026 lautet: „Umsatzsteuerlich stellt eine Datei, die einen Geschäftsregelfehler (aber keinen Formatfehler) aufweist, dennoch prinzipiell eine E-Rechnung im Sinne von § 14 UStG dar.“ Die technische Sichtweise, nach der eine verletzte Geschäftsregel des Kern-Datenmodells keine E-Rechnung ergibt, ist für umsatzsteuerliche Fragen wie den Vorsteuerabzug nicht maßgebend.

Zum Inhaltsfehler führt ein Geschäftsregelfehler nur, wenn er eine umsatzsteuerliche Pflichtangabe betrifft (Rn. 22 BMF-Schreiben vom 15.10.2026). Geschäftsregelfehler zu anderen Inhalten sind nach Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025 umsatzsteuerlich unbeachtlich. Was ein Empfänger riskiert, wenn eine Pflichtangabe fehlt, behandelt die Seite zum Vorsteuerabzug bei fehlerhaften Rechnungen.

Inhaltsfehler: auch ohne Meldung des Validators möglich

Ein Inhaltsfehler ist ein Verstoß gegen die Pflichtangaben nach § 14 Abs. 4 und § 14a UStG; die Rechnung ist dann nicht ordnungsmäßig, auch wenn kein Validator einen Fehler meldet (Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025; Abschn. 14.5 Abs. 1 Satz 7 ff. UStAE). Der Validator kennt die Regeln der Datei, nicht den Sachverhalt dahinter.

Rn. 35a nennt als Beispiel die Angabe eines fehlerhaften Steuersatzes. Rn. 23 BMF-Schreiben vom 15.10.2026 bestätigt den Maßstab: Für die Ordnungsmäßigkeit der Rechnung müssen die Pflichtangaben nach §§ 14, 14a UStG richtig und vollständig sein.

Typische Fehlermeldungen im Prüfbericht und ihre Bedeutung

Die Meldungen eines Prüfberichts tragen den Code der verletzten Regel, etwa BR-DE-15 für die XRechnung-Regeln der KoSIT, und eine Stufe wie fatal oder warning; die Tabelle zeigt die Regeln, deren Wortlaut in der XRechnung Schematron 2.6.0 steht (Stand: 29.10.2026). Eine BR-DE-Meldung ist eine Meldung zu einer Geschäftsregel. Ob sie umsatzsteuerlich zählt, folgt aus der Einordnung im vorigen Abschnitt: Entscheidend ist, ob eine Pflichtangabe betroffen ist.

Quelle: XRechnung Schematron 2.6.0, Datei XRechnung-UBL-validation.sch, FAQ e-rechnung-bund.de, Peppol BIS Billing 3.0, FeRD; Stand: 29.10.2026.

BR-DE-15: das fehlende Feld BT-10

Die Regel BR-DE-15 lautet „Das Element "Buyer reference" (BT-10) muss übermittelt werden.“ und hat in der XRechnung Schematron 2.6.0 die Stufe fatal. Die Finanzverwaltung nennt gerade dieses Feld als Beispiel, wenn sie die Folgen eines Geschäftsregelfehlers erklärt. Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025 lautet: „Geschäftsregelfehler zu anderen Inhalten (z. B. die fehlende Angabe des Feldes „BT-10 Buyer reference") sind umsatzsteuerlich unbeachtlich.“

Bei Rechnungen an öffentliche Auftraggeber trägt BT-10 die Leitweg-ID. Zwischen Unternehmen ist keine Leitweg-ID nötig: „zum Empfang und Versand von E-Rechnungen im B2B-Bereich benötigen Sie keine Leitweg-ID“ (KoSIT, FAQ zur XRechnung). Laut BMF-FAQ Frage 6 reicht im B2B-Bereich umsatzsteuerlich bereits ein Platzhalter (z. B. „-“) in diesem Feld. Wie die Kennung für öffentliche Auftraggeber aufgebaut ist, erklärt die Seite Leitweg-ID: Aufbau und wo Sie sie finden.

Meldungen mit dem Präfix PEPPOL-EN16931

Codes mit dem Präfix PEPPOL-EN16931 stammen aus den Regeln der Spezifikation Peppol BIS Billing 3.0, die beim Versand über das Peppol-Netz angewendet werden; Peppol ist ein Netzwerk, kein Rechnungsformat. Seit der Version 3.0.18 (November 2024) gilt die Regel PEPPOL-EN16931-R002, nach der höchstens eine Notiz auf Dokumentebene (BT-22) erlaubt ist, nicht, wenn Käufer und Verkäufer deutsche Organisationen sind. Aktuell ist die Version 3.0.21, veröffentlicht am 20. Mai 2026 und verbindlich seit 17. August 2026 (Stand: 29.10.2026).

Fünf weitere Regeln der Schematron-Datei für Peppol BIS Billing 3.0 (Release 3.0.21) sind unten aufgeführt; alle haben die Stufe fatal.

• PEPPOL-EN16931-R001: Der Geschäftsprozess (Business process) muss angegeben sein.
• PEPPOL-EN16931-R008: Die Datei darf keine leeren Elemente enthalten.
• PEPPOL-EN16931-R010: Die elektronische Adresse des Käufers muss angegeben sein.
• PEPPOL-EN16931-R020: Die elektronische Adresse des Verkäufers muss angegeben sein.
• PEPPOL-EN16931-R120: Der Nettobetrag der Rechnungszeile muss Menge mal (Nettopreis durch Basismenge) plus Zuschläge minus Abschläge der Zeile ergeben.

Änderungen der Regeln dokumentieren die Release Notes zu Peppol BIS Billing 3.0.

Warum Meldungen vorübergehend auftreten können

Nach Angabe der KoSIT können Fehlermeldungen eines Validators vorübergehend auftreten, weil die Regelwerke von KoSIT, national und auf EU-Ebene nicht synchron aktualisiert werden. Maßgeblich ist daher, welche Konfiguration der Validator nutzt: Die Konfiguration XRechnung v2026-08-31 arbeitet mit den CEN-Regeln 1.3.16, das CEN hat am 12. Oktober 2026 die Fassung 1.3.17 veröffentlicht. Vergleichen Sie die im Prüfbericht genannten Versionen mit der Tabelle im Abschnitt zu den Validatoren, bevor Sie eine Meldung als Fehler des Absenders werten.

Prüfbericht und Sorgfalt: worauf sich Empfänger verlassen können

Ein Unternehmer kann sich bei Beachtung der Sorgfaltspflichten eines ordentlichen Kaufmanns auf das technische Ergebnis einer Validierung durch eine geeignete Validierungsanwendung verlassen, und zwar hinsichtlich des Formats und der Geschäftsregeln (Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025). Der Verlass reicht damit genau so weit wie die technische Prüfung. Für die Pflichtangaben gilt er nicht: Die Prüfung auf Vollständigkeit und Richtigkeit bleibt beim Empfänger.

Den Validierungsbericht als Nachweis aufbewahren

Zum Nachweis bietet es sich nach Rn. 35a BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025 an, den Validierungsbericht aufzubewahren. Der KoSIT-Validator erzeugt diesen Bericht zu jeder Datei automatisch im XML-Format, sodass er neben der Rechnung abgelegt werden kann.

Die Rechnung selbst wird acht Jahre aufbewahrt (§ 14b Abs. 1 Satz 1 UStG), und zwar mindestens ihr strukturierter Teil „unversehrt in seiner ursprünglichen Form“ (Abschn. 14b.1 Abs. 1 Satz 4 UStAE). Eine Visualisierung ist keine gültige XRechnung und ersetzt die XML-Datei im Archiv nicht. Wie Datei und Bericht zusammen abgelegt werden, beschreibt die Seite E-Rechnung archivieren nach UStG und GoBD.

Nichtbeanstandung für Dateien, die bis 31.12.2026 ausgestellt werden

E-Rechnungen, die bis 31. Dezember 2026 ausgestellt werden und den BMF-Schreiben vom 15.10.2024 und 15.10.2025 entsprechen, nicht aber den zusätzlichen Vorgaben des Schreibens vom 15.10.2026, beanstandet die Finanzverwaltung nicht, auch nicht beim Vorsteuerabzug (Anwendungsregelung des BMF-Schreibens vom 15.10.2026). Diese Nichtbeanstandung ist eine Regel der Verwaltung, kein Gesetz, und endet mit dem 31. Dezember 2026. Grundlage sind damit alle drei BMF-Schreiben aus der Übersichtstabelle am Anfang der Seite.

Prüfen im Betrieb umsetzen: Schritte beim Empfang und vor dem Versand

Im Betrieb gehört die Prüfung an zwei Stellen: beim Empfang, bevor eine Rechnung gebucht und bezahlt wird, und beim Ausstellen, bevor die eigene E-Rechnung das Haus verlässt; das BMF empfiehlt die Validierung bereits bei Erstellung und Versand (BMF-FAQ Frage 7). Eine weitergehende elektronische Verarbeitung, als die Aufbewahrung ohnehin verlangt, schuldet der Empfänger nicht (BMF-FAQ Frage 9). Die vier Schritte beim Empfang sind unten aufgeführt.

1. Ansicht: Eine XRechnung enthält keine PDF-Datei, Unternehmen „benötigen insofern eine zusätzliche Software zur Visualisierung der XML-Datei (sogenannte Viewer)“ (BMF-FAQ Frage 12a). Werkzeuge dafür: E-Rechnung lesen mit kostenlosen Viewern.
2. Validierung: Die Datei läuft durch den KoSIT-Validator oder ein Rechnungsprogramm mit Validierung; der Prüfbericht wird gespeichert. Freie Werkzeuge: E-Rechnung kostenlos: freie Tools und Behördenportale.
3. Rückfrage und Korrektur: Wo die Pflicht zur E-Rechnung gilt, ist auch die Berichtigung eine E-Rechnung (BMF-FAQ Frage 7b). Ablauf: E-Rechnung korrigieren und stornieren.
4. Ablage: Die XML-Datei wird zusammen mit dem Prüfbericht unverändert gespeichert.

Welche Programme E-Rechnungen einlesen und mit Prüfbericht validieren, zeigt unser Überblick E-Rechnung Software im unabhängigen Überblick.

Prüfen, lesen, ablegen: wie die Schritte nach dem Empfang zusammenhängen

Die Prüfung ist ein Schritt zwischen dem Empfang und der Ablage einer E-Rechnung: Vorher steht der Eingang über ein E-Mail-Postfach oder einen anderen Kanal, danach die Buchung, gegebenenfalls eine Korrektur und die Aufbewahrung. Für den Eingang reicht es aus, wenn der Empfänger ein E-Mail-Postfach zur Verfügung stellt (Rn. 40 BMF-Schreiben vom 15.10.2024). Wer selbst ausstellt, prüft vor dem Versand und findet die Wege zur eigenen E-Rechnung auf einer eigenen Seite.

Häufige Fragen zur Validierung

Sechs Einzelfragen zur Validierung, jeweils kurz beantwortet.

Ist eine Validierung Pflicht?

Nein: Die Validierung ist keine unmittelbare Voraussetzung für die steuerliche Anerkennung, etwa für den Vorsteuerabzug, das BMF hält sie aber für sinnvoll (BMF-FAQ Frage 7). Das gilt für XRechnung und ZUGFeRD gleichermaßen.

Empfiehlt das BMF einen bestimmten Validator?

Nein, nach der BMF-FAQ Frage 7 kann das BMF „aus Gründen der Gleichbehandlung aller Wirtschaftsbeteiligten“ keine bestimmte Validierungsanwendung empfehlen. Die Auswahl liegt beim Unternehmen.

Prüft der Viewer von ELSTER die Datei?

Nein, der E-Rechnungs-Viewer im ELSTER-Portal stellt E-Rechnungen im Format XRechnung oder ZUGFeRD nur lesbar dar (BMF-FAQ Frage 12a). ELSTER nennt ihn „ein unverbindlicher Service der Steuerverwaltung“; eine Validierung bietet er nicht.

Unter welcher Lizenz steht der KoSIT-Validator?

Der KoSIT-Validator steht unter der Open-Source-Lizenz Apache-2.0 und wird im Repository des KoSIT-Validators auf GitHub veröffentlicht (Stand: 29.10.2026).

Welche Java-Version braucht der KoSIT-Validator?

Seit Version 1.6.0 (GitHub-Release vom 6. November 2025) läuft die Standalone-Datei erst ab Java 11. Für Java 8 bleibt die Version 1.5.0.

Was bedeutet „critical Error“ im Prüfbericht?

Ein „critical Error“ kann einen Geschäftsregelfehler anzeigen (Rn. 6b BMF-Schreiben vom 15.10.2024 i. d. F. vom 15.10.2025). Ohne Formatfehler bleibt die Datei umsatzsteuerlich prinzipiell eine E-Rechnung (Rn. 23 BMF-Schreiben vom 15.10.2026).