Methodik
So prüfen wir E-Rechnungen
Diesen Satz trägt jeder Prüfbericht; Werkzeugstand 09.10.2026:
Technische Validierung der Testdatei gegen das Regelwerk XRechnung 3.0.2 mit dem KoSIT-Validator 1.6.3 am 09.10.2026. Keine Steuer- oder Rechtsberatung.
Wir prüfen Technik und beraten nicht zu Steuern oder Recht. Ob und ab wann Sie E-Rechnungen ausstellen müssen, klären Sie bitte mit Ihrer Steuerberatung.
Was wir prüfen
Was sich messen lässt, messen wir – statt es zu meinen.
Wir prüfen, ob ein Rechnungsprogramm aus 8 festgelegten Testfällen XRechnung-Dateien erzeugt, die der KoSIT-Validator annimmt. XRechnung ist ein deutscher Standard für elektronische Rechnungen im XML-Format. Der KoSIT-Validator ist das Prüfprogramm der Koordinierungsstelle für IT-Standards (KoSIT); er prüft eine Datei gegen die Regeln von XRechnung.
Jedes Ergebnis ist nachprüfbar: Testfall, Version, Werkzeugversion, Datum und Rohdaten stehen dabei.
Die 8 Testfälle
Testfall-Satz 1.0. Alle Programme bekommen dieselben Fälle. Namen, Adressen und Steuernummern in den Testdaten sind erfunden. Die Rechnungsart ist der Code für die Art des Belegs, zum Beispiel 380 für eine Rechnung.
| Testfall | Zweck |
|---|---|
| S1 · Standardrechnung mit 19 Prozent (Rechnungsart 380) | Dieser Fall ist die Grundlage: Erzeugt das Programm eine Datei, die der Validator annimmt? |
| S2 · Gemischte Steuersätze 19 und 7 Prozent (Rechnungsart 380) | Dieser Fall prüft mehrere Steueraufschlüsselungen und die zugehörigen Summen. |
| S3 · Kleinunternehmer nach § 19 UStG (Rechnungsart 380) | Dieser Fall prüft eine Rechnung ohne Umsatzsteuer samt Befreiungsgrund. |
| S4 · Reverse Charge nach § 13b UStG (Rechnungsart 380) | Dieser Fall prüft Reverse Charge (die Steuerschuld geht auf den Leistungsempfänger über) mit beiden USt-IdNr.-Angaben. |
| S5 · Gutschrift und Rechnungskorrektur (Rechnungsart 381 bzw. 384) | Dieser Fall prüft die Storno-Logik (das Aufheben oder Korrigieren einer früheren Rechnung) mit Verweis auf die Ursprungsrechnung. |
| S6 · Rechnung an eine Behörde mit Leitweg-ID (Rechnungsart 380) | Dieser Fall prüft die XRechnung-Pflichtfelder für öffentliche Auftraggeber, darunter die Leitweg-ID (Kennung der Behörde für den Rechnungseingang). |
| S7 · Rabatt und Zuschlag auf Belegebene (Rechnungsart 380) | Dieser Fall prüft Nachlässe und Zuschläge auf Ebene des gesamten Belegs samt Nettosumme. |
| S8 · Anzahlung und Schlussrechnung (Rechnungsart 386 + 380) | Dieser Fall prüft die Vorauszahlung und den Zahlbetrag der Schlussrechnung mit Verweis auf die Anzahlungsrechnung. |
Ablauf je Programm
- Testbedingungen prüfen. Wir lesen die AGB und Testbedingungen des Anbieters im Volltext. Ergebnisse und Testdateien veröffentlichen wir nur, wenn die Bedingungen das erlauben.
- Testfälle eingeben. Wir legen ein Testkonto an und geben die 8 Testfälle nach einer festen Checkliste ein. Programmversion, Tarif und Exportformat halten wir im Protokoll fest.
- Zweite Eingabeprüfung. Eine zweite Prüfung gleicht jede exportierte Datei Feld für Feld mit dem Testfall ab: Beträge, Steuersätze und Pflichtfelder. Einen Eingabefehler geben wir neu ein; er zählt nicht als Fehler des Programms.
- Reproduktion im Cluster. Jede Testdatei wird in unserer eigenen Prüfumgebung (Cluster) ohne Internetzugang mit dem fest versionierten KoSIT-Validator erneut geprüft. Dieser Lauf ist maßgeblich. Weichen Ergebnis oder Meldungscodes vom Bericht ab, erscheint der Bericht nicht.
- Herstellerinfo mit Korrekturfrist. Vor der Veröffentlichung erhält der Hersteller den Berichtsentwurf, die Testdateien und die Prüfberichte. Er hat 14 Tage Zeit, auf Eingabe- oder Verfahrensfehler hinzuweisen. Eine Stellungnahme drucken wir auf Wunsch im Bericht ab. Ist ein Hinweis auf einen Eingabefehler berechtigt, geben wir den Fall neu ein und prüfen ihn neu.
- Freigabe und Veröffentlichung. Erst danach geben wir den Bericht frei. Er erscheint mit den Testdateien und den Prüfberichten des Validators.
Ergebnisarten
Ein Ergebnis gilt nur für die geprüfte Programmversion, den Testfall-Satz, die Regelwerksversion und das Prüfdatum.
- angenommen
- Der KoSIT-Validator hat die Testdatei ohne Warnung angenommen.
- angenommen mit Warnungen
- Der Validator hat die Testdatei angenommen und mindestens eine Warnung gemeldet. Wir nennen jede Warnung mit ihrem Regelcode.
- abgelehnt
- Der Validator hat die Testdatei abgelehnt. Wir nennen jeden Fehler mit seinem Regelcode, zum Beispiel BR-DE-15, und erklären ihn technisch.
- im Programm nicht abbildbar
- Das Programm kann den Testfall nicht abbilden. Wir nennen die Begründung.
Werkzeuge
- KoSIT-Validator, Version 1.6.3, Lizenz Apache-2.0 (Release auf GitHub). SHA-256 der Datei validator-1.6.3-standalone.jar:
799e64befca97d4080e03608c80b85dd5a5ecc5f4ae4f35d1116ec2855b9a7c9 - Konfiguration XRechnung, Version 3.0.2, Release v2026-08-31, Lizenz Apache-2.0 (Release auf GitHub). SHA-256 der Datei xrechnung-3.0.2-validator-configuration-2026-08-31.zip:
2530cd107c414511c5d0462ec10f886910395abfca820db82e83d70bf01221a8
Vor jedem Lauf vergleichen wir beide Prüfsummen mit den Angaben der Releases.
Selbst nachprüfen
Jede veröffentlichte Testdatei können Sie mit denselben Werkzeugen selbst prüfen. Dies ist eine Anleitung für Linux mit der Shell Bash; Sie brauchen curl, sha256sum, unzip und eine Java-Laufzeitumgebung. Auf anderen Systemen heißt der Befehl für die Prüfsumme anders, und Anführungszeichen folgen anderen Regeln.
Die Befehle laden Validator und Konfiguration herunter, prüfen beide Prüfsummen, entpacken die Konfiguration und prüfen die Datei testdatei.xml. Ersetzen Sie testdatei.xml durch die Testdatei aus dem Bericht. Den Prüfbericht als HTML finden Sie danach im Ordner berichte.
curl -fLO https://github.com/itplr-kosit/validator/releases/download/v1.6.3/validator-1.6.3-standalone.jar && \
curl -fLO https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip && \
echo "799e64befca97d4080e03608c80b85dd5a5ecc5f4ae4f35d1116ec2855b9a7c9 validator-1.6.3-standalone.jar" | sha256sum -c - && \
echo "2530cd107c414511c5d0462ec10f886910395abfca820db82e83d70bf01221a8 xrechnung-3.0.2-validator-configuration-2026-08-31.zip" | sha256sum -c - && \
unzip -o xrechnung-3.0.2-validator-configuration-2026-08-31.zip -d config && \
java -jar validator-1.6.3-standalone.jar -s config/scenarios.xml -r config -h -o berichte testdatei.xmlMeldet sha256sum für eine Datei nicht „OK“, ist sie beschädigt. Die Befehle sind verkettet, deshalb endet der Ablauf dann, ohne die Prüfung zu starten.
Die Prüfsumme schützt vor beschädigten Dateien, nicht vor einer gefälschten Herkunft. Unsere Prüfung im Cluster läuft in einer privaten CI, die von außen nicht einsehbar ist – deshalb veröffentlichen wir Testdateien und Prüfberichte.
Korrektur und Rücknahme
Halten Sie ein veröffentlichtes Ergebnis für falsch, schreiben Sie uns mit Begründung an die E-Mail-Adresse im Impressum. Wir prüfen jede begründete Meldung binnen 7 Tagen. Bis dahin steht am Bericht der Hinweis „in Prüfung“. Liegt der Fehler bei uns, korrigieren wir den Bericht mit einem Eintrag im Änderungsprotokoll oder nehmen ihn zurück.
Grenzen der Prüfung
- Wir prüfen Format und Geschäftsregeln der Datei, nicht ihre steuerliche Richtigkeit.
- Geprüft wird nur XRechnung, in den beiden XML-Syntaxen UBL und CII. ZUGFeRD prüfen wir erst, wenn eine passende Prüfkonfiguration vorliegt.
- 8 festgelegte Testfälle sind kein umfassender Produkttest.
- Ein Ergebnis gilt nur für die geprüfte Programmversion und das Prüfdatum.