E-Rechnung testen: Testablauf vor dem ersten Versand

E-Rechnung testen heißt: eine echte Rechnung aus Ihrer Software in vier Stufen prüfen, bevor sie an Kunden geht. Erst das XSD-Schema, dann die Geschäftsregeln der EN 16931 und der XRechnung, dann den Inhalt nach § 14 Abs. 4 UStG und zuletzt den Übertragungsweg bis zum Empfänger, etwa über die Testumgebung der OZG-RE.

Der Ablauf richtet sich an Rechnungssteller, die ihre ersten E-Rechnungen verschicken, an Buchhaltungen, die eine neue Software einführen, und an Softwarehäuser, die Kunden anbinden. Am Ende haben Sie einen Testplan, passende Testdateien und eine Vorlage für ein Testprotokoll.

Was brauchen Sie für den Test?

• Eine Rechnung aus Ihrem Produktivsystem mit echten Stammdaten (Firmenname, Anschrift, USt-IdNr. oder Steuernummer, Bankverbindung), aber mit fiktivem Empfänger oder als Testbeleg gekennzeichnet.
• Die Anforderungen Ihres Rechnungsempfängers: Format (XRechnung in UBL oder CII, ZUGFeRD), Übertragungsweg (E-Mail, Portal, Peppol) und bei Behörden die Leitweg-ID (BT-10).
• Einen Validator mit der aktuellen Prüfkonfiguration der Koordinierungsstelle für IT-Standards (KoSIT). Stand Oktober 2026 ist das die Konfiguration 2026-08-31 für XRechnung 3.0.2; ein neueres Release gibt es auf GitHub nicht.
• Je eine gültige und eine absichtlich fehlerhafte Testdatei, um zu sehen, ob Ihr Prüfschritt Fehler überhaupt erkennt.
• Eine Tabelle oder ein Dokument für das Testprotokoll.

Testplan: Welche vier Ebenen prüfen Sie?

Ein Validator deckt nur die ersten beiden Ebenen ab. Die übrigen zwei bleiben Handarbeit, und genau dort scheitern viele erste Rechnungen.

Welche Felder in Ebene 2 Pflicht sind, zeigt die Übersicht der XRechnung Pflichtfelder. Wie sich Formatfehler, Geschäftsregelfehler und Inhaltsfehler steuerlich unterscheiden, erklärt der Beitrag Formatfehler oder Inhaltsfehler.

Schritt für Schritt: So testen Sie eine E-Rechnung

1. Testfall wählen. Nehmen Sie Ihren häufigsten Rechnungstyp, etwa eine Rechnung mit zwei Positionen und einem Steuersatz. Ergebnis: ein Beleg, den Sie später täglich erzeugen.
2. Datei erzeugen. Exportieren Sie die Rechnung aus Ihrer Software als XRechnung oder ZUGFeRD. Ergebnis: eine .xml-Datei oder ein PDF mit eingebetteter XML.
3. Kennung prüfen. Öffnen Sie die XML und suchen Sie die Spezifikationskennung (BT-24). Für XRechnung 3.0 lautet sie urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Eine veraltete Kennung führt dazu, dass der Validator gar kein Prüfszenario findet.
4. Validieren. Prüfen Sie die Datei mit der Prüfkonfiguration 2026-08-31. Ergebnis: Annahme oder Zurückweisung, dazu eine Liste mit Regelcodes.
5. Fehler an der Quelle beheben. Korrigieren Sie die Stammdaten oder die Vorlage in der Rechnungssoftware, nicht die einzelne XML-Datei. Erzeugen Sie die Rechnung neu und validieren Sie erneut.
6. Inhalt kontrollieren. Gehen Sie die Angaben aus § 14 Abs. 4 UStG durch: Name und Anschrift beider Parteien, Steuernummer oder USt-IdNr., Ausstellungsdatum, Rechnungsnummer, Menge und Art der Leistung, Leistungszeitpunkt, Entgelt nach Steuersätzen, Steuersatz und Steuerbetrag.
7. Negativtest. Prüfen Sie eine absichtlich fehlerhafte Datei. Meldet Ihr Prüfschritt dort keine Fehler, prüft er nicht das, was Sie glauben.
8. Empfängerweg testen. Senden Sie die Datei an die Testumgebung des Empfängers oder als vereinbarte Testrechnung. Ergebnis: Eingangsbestätigung oder Fehlermeldung des Empfängers.
9. Protokollieren. Halten Sie Datei, Prüfstand und Ergebnis fest (Vorlage weiter unten).

Wiederholen Sie die Schritte 1 bis 6 für jeden Sonderfall, der bei Ihnen tatsächlich vorkommt: Gutschrift, Rechnungskorrektur, steuerfreie Leistung, Reverse Charge, Rabatte oder Skonto.

Welche Testdateien eignen sich für Positiv- und Negativtests?

Ein Test mit nur einer gültigen Datei zeigt nicht, ob Ihr Prüfschritt Fehler erkennt. Kombinieren Sie deshalb beide Arten.

Die Testsuite der KoSIT ist laut Changelog mit XRechnung 3.0 kompatibel. Die Geschäftsfälle beschreibt die Datei test-overview.md als positive Testinstanzen, etwa „01.01: Standard invoice with 2 lines, 1 tax category, 1 payment means code 58“. Wählen Sie die Fälle, die Ihrem eigenen Rechnungsbild am nächsten kommen, und vergleichen Sie Ihre Datei Feld für Feld.

Die fehlerhafte Testdatei enthält unter anderem eine fehlende Käuferreferenz (BR-DE-15), eine Überweisung ohne IBAN (BR-DE-23-a: Bei Zahlungsart 30 oder 58 muss die Gruppe BG-17 „CREDIT TRANSFER“ übermittelt werden) und eine Summe BT-106, die nicht zur Summe der Positionen passt (BR-CO-10). Wie Sie solche Meldungen beheben, zeigt der Beitrag XRechnung-Fehler beheben.

Wie testen Sie den Weg zum Empfängerportal?

Eine valide Datei kann trotzdem abgelehnt werden, etwa weil die Leitweg-ID nicht zum Empfänger passt oder der Übertragungsweg falsch eingerichtet ist. Deshalb gehört der Versand selbst zum Test.

Für Rechnungen an die Bundesverwaltung nennt die FAQ auf e-rechnung-bund.de (öffnet in neuem Tab) folgende Regeln:

• Die Rechnungseingangsplattform OZG-RE hat eine eigene Testumgebung. Rechnungssteller sollen sich dort registrieren und die Rechnungsstellung testen.
• Testrechnungen gehören nie in die Produktivumgebung, echte Rechnungen nie in die Testumgebung.
• Wer die Kanäle „Weberfassung“ oder „Upload“ nutzt, kann die E-Rechnung direkt auf der Plattform validieren lassen und sieht einen Prüfbericht mit den formalen Fehlern noch vor dem Versand.
• Bei anderen Kanälen führt ein Lupensymbol in der Rechnungsübersicht zu den Detailergebnissen der formalen Prüfung, falls die Plattform eine Rechnung zurückweist.
• Für Peppol-Tests veröffentlicht die FAQ eine eigene Peppol-Receiver-ID und Leitweg-ID der Referenzumgebung. Erst wenn die Übertragung dort funktioniert, sollen produktive Rechnungen folgen.
• In der Testumgebung dürfen Sie fiktive IBAN-Angaben verwenden.

Bei Landes- und Kommunalportalen und bei Geschäftskunden mit eigenem Lieferantenportal fragen Sie nach einer Testumgebung oder vereinbaren eine gekennzeichnete Testrechnung. Wie die Übertragungswege im Einzelnen funktionieren, steht im Beitrag E-Rechnung versenden.

Vorlage: Testprotokoll fürs Kunden-Onboarding

Ein kurzes Protokoll beantwortet später die Frage, mit welchem Regelstand eine Rechnungsart freigegeben wurde. Es hilft auch, wenn ein Kunde nach der ersten Ablehnung fragt, was geprüft wurde. Die Daten im Beispiel sind fiktiv.

Legen Sie das Protokoll zusammen mit der Testdatei ab. Ändert sich die Prüfkonfiguration, etwa mit XRechnung 4.0, testen Sie erneut und legen ein neues Protokoll an.

Häufige Fehler beim Testen

So testen Sie eine E-Rechnung mit docutools.pro

1. Öffnen Sie den XRechnung Validator und wählen Sie „Beispielrechnung laden“, um den Ablauf mit einer gültigen Datei zu sehen. Die Beispielrechnung hat ein eigenes Kontingent und verbraucht keinen Ihrer Uploads.
2. Laden Sie mit „Datei auswählen“ Ihre eigene XML hoch. Die Datei wird zur Prüfung an unseren Server übertragen und dort mit der KoSIT-Prüfung geprüft wie mit dem KoSIT-Validator (Konfiguration 2026-08-31). Kostenlos sind zwei Uploads pro Tag bis 500 KB; das Kontingent setzt sich um Mitternacht UTC zurück. ZUGFeRD-PDFs nimmt der Validator nicht an: Holen Sie die XML vorher mit dem Werkzeug ZUGFeRD-XML extrahieren heraus.
3. Lesen Sie das Ergebnis: „KoSIT-konform / Gültige XRechnung“ oder „Nicht KoSIT-konform“, dazu der „Compliance-Score“ und die Liste der Befunde mit Regelcode. Details zu einzelnen Codes finden Sie in der Übersicht der KoSIT-Fehler; maßgeblich bleibt der Regeltext im Prüfergebnis.
4. Für den Negativtest laden Sie die fehlerhafte Testdatei herunter und prüfen sie genauso. Sie sollten die Befunde aus der Vorlagenbeschreibung sehen.
5. Für Ebene 3 gehen Sie die Pflichtangaben mit dem Modus „XRechnung/ZUGFeRD XML“ des Werkzeugs Pflichtangaben prüfen durch. Leistungsdatum, Befreiungshinweis und Rabatte markiert es beim XML-Import immer als fehlend; diese Punkte haken Sie nach eigener Prüfung von Hand ab.
6. Haben Sie noch keine Software, die E-Rechnungen ausgibt, können Sie mit dem Generator eine Testrechnung E-Rechnung erstellen lassen, ohne Konto, als „XRechnung XML“, „ZUGFeRD XML“ oder „ZUGFeRD PDF“. Er erzeugt nur normale Rechnungen (Typ 380), keine Gutschriften oder Korrekturen.

Einen Prüfbericht zum Aufbewahren erzeugt der Validator von docutools.pro nicht; das Ergebnis erscheint nur auf der Seite. Für einen Bericht fürs Protokoll nutzen Sie zusätzlich den KoSIT-Validator. Weitere Beiträge finden Sie auf der Themenseite Validierung und Fehler.

Was prüfen Sie nach bestandenem Test?

• Die erste produktive Rechnung an jeden neuen Empfänger erneut validieren und den Eingang bestätigen lassen.
• Nach jedem Update der Rechnungssoftware einen Testfall wiederholen.
• Das Konfigurationsdatum der KoSIT-Prüfregeln im Blick behalten: XRechnung 3.0.2 gilt aktuell, die Vorversion von XRechnung 4.0 ist seit September 2026 veröffentlicht.
• Ablehnungen des Empfängers mit Regelcode im Protokoll ergänzen, damit der nächste Test genau diesen Fall abdeckt.

Quellen

• FAQ E-Rechnung in der Bundesverwaltung, Testumgebung und Peppol-Tests der OZG-RE (öffnet in neuem Tab)
• XRechnung-Testsuite der KoSIT auf GitHub, Release 2026-08-31 (öffnet in neuem Tab)
• Prüfkonfiguration XRechnung der KoSIT auf GitHub (öffnet in neuem Tab)
• § 14 UStG, Ausstellung von Rechnungen (öffnet in neuem Tab)

Stand: Oktober 2026

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Steuer- oder Rechtsberatung.