E-Rechnung testen: So führen Sie einen erfolgreichen Integrationstest durch

Eine E-Rechnung ist erst dann wirklich produktiv, wenn drei Dinge zusammenpassen: Ihr System erzeugt valides XML, der Transportweg funktioniert, und der Empfänger kann die Daten verbuchen. Wer ohne Test live geht, riskiert, dass die ersten 100 Rechnungen reklamiert werden. Mit einem strukturierten Integrationstest verhindern Sie das.

Dieser Beitrag zeigt, wie ein vollständiger Test aufgebaut ist – vom isolierten XML-Check bis zum echten End-to-End-Versand über Peppol.

Vier Teststufen

Sinnvoll ist ein Aufbau in vier Stufen, die aufeinander aufbauen:

Jede Stufe darf nur grünes Licht bekommen, bevor die nächste gestartet wird.

Stufe 1: Schema-Validierung

XSD-Validierung prüft die Struktur: Sind alle Elemente an der richtigen Stelle, in der richtigen Reihenfolge, mit dem richtigen Datentyp? Beispiel mit xmllint:

xmllint --noout --schema CrossIndustryInvoice_100pD22B.xsd rechnung.xml

Ein „validates"-Ergebnis heißt: technisch sauber. Es heißt nicht , dass die Rechnung fachlich korrekt ist. Dafür ist Stufe 2 zuständig.

Stufe 2: Geschäftsregeln (Schematron)

Hier prüft der Validator die EN-16931-Regeln:

• Pflichtfelder vorhanden?
• Summen plausibel (BT-106 bis BT-115)?
• Steuerlogik konsistent (BR-S-08, BR-AE-09 …)?
• Nationale Ergänzungen (CIUS XRechnung) erfüllt?

Werkzeuge:

• KoSIT-Validator (offizielles Tool für XRechnung): kostenfrei, CLI und Web-Frontend.
• Mustang Validator (für ZUGFeRD/Factur-X): Open-Source.
• Unser eigener Online-Validator: direkt im Browser.

Faustregel: Solange auch nur eine Schematron-Warnung übrig ist, gehen Sie nicht live.

Stufe 3: Empfänger-Verarbeitung

Eine valide Datei ist nicht zwangsläufig eine brauchbare Datei. Schicken Sie Testrechnungen an typische Empfänger und prüfen Sie:

• Werden Beträge korrekt übernommen?
• Stimmt die Rechnungsnummer?
• Wird die Bestellnummer erkannt und automatisch verknüpft?
• Wird die Bankverbindung korrekt für Zahlungslauf übernommen?
• Welche Anhänge (BG-24) gehen verloren oder werden falsch zugeordnet?

Viele Buchhaltungs-Suites bieten Sandbox-Mandanten für genau diesen Zweck (DATEV, lexware, sevDesk, …). Falls nicht: legen Sie einen leeren Testmandanten an.

Stufe 4: Transport End-to-End

Hier wird scharf geschossen – aber in eine Test-Umgebung.

Peppol-Testbed

Die offizielle Peppol-Testumgebung simuliert die produktive Infrastruktur:

• Eigener Test-Access-Point oder Service Provider mit Test-Endpoint.
• Test-Empfänger über Peppol Directory abrufbar.
• Antworten als MLR (Message Level Response) und IRR (Invoice Response).

Dauer: Account-Beantragung beim Service Provider, dann Tests innerhalb von wenigen Tagen.

B2G – ZRE / OZG-RE

Für den Bund stehen separate Testportale zur Verfügung:

• ZRE-Test (Bundesverwaltung)
• OZG-RE-Test (für Länder, die das Portal nutzen)

Beide akzeptieren Test-Leitweg-IDs und liefern strukturierte Fehlerausgaben. Mehr in Leitweg-ID und OZG-RE.

E-Mail

Wenn Ihr Workflow E-Mail nutzt: Schicken Sie an eine Testadresse, prüfen Sie das Anhangverhalten, MIME-Typen, Größenlimits, Zeichensatz im Subject. Klingt banal, scheitert in der Praxis ständig.

Testdaten – realistisch, aber nicht echt

Echte Daten in Tests sind ein DSGVO-Thema und ein Risiko. Bauen Sie sich Testkunden:

• „Mustermann Test GmbH" mit Test-USt-ID DE000000000 (formal nicht gültig, aber als Marker geeignet).
• Test-IBAN aus dem IBAN-Testbereich der Bundesbank (z. B. DE00000000000000000000).
• Test-Leitweg-ID 991-12345-67.

Variieren Sie:

• Steuersätze: 19 %, 7 %, 0 % (Reverse Charge), gemischt.
• Positionen: Stückzahlen, Maßeinheiten, Nachlässe, Zuschläge.
• Zahlungsarten: Überweisung (BG-17), Lastschrift (BG-19), Karte (BG-18).
• Sonderfälle: Stornorechnung, Gutschrift, Anzahlung, Schlussrechnung. Mehr in Stornierung und Abschlagsrechnung.

Testchecklist

Eine pragmatische Liste, die Sie abhaken sollten, bevor der erste Live-Versand losgeht:

• Rechnung mit 19 % geht durch Validator
• Rechnung mit gemischten Steuersätzen geht durch
• Reverse-Charge-Rechnung geht durch
• Innergemeinschaftliche Lieferung geht durch
• Anhang (PDF) bleibt im ZUGFeRD-Container
• Empfänger kann Datei in Sandbox einlesen
• Peppol-Test-Versand erfolgreich (Quittung erhalten)
• Stornorechnung mit negativen Beträgen valide
• Archivierung legt Datei revisionssicher ab
• Verfahrensdokumentation aktualisiert

Häufige Stolperfallen im Test

• UTF-8 vs. ISO-8859-1: Umlaute „verschwinden" oder werden zu Fragezeichen.
• Datumsformat: ISO YYYYMMDD (CII) vs. YYYY-MM-DD (UBL) verwechselt.
• Beträge mit Tausendertrennzeichen: nicht erlaubt, nur Punkt als Dezimaltrennzeichen.
• PDF/A-3 statt PDF/A-1: ZUGFeRD verlangt /A-3.
• Profil-Mismatch: ZUGFeRD-Profil-URN passt nicht zum tatsächlichen Inhalt. Mehr in ZUGFeRD-Profile.

Wann ist „getestet" wirklich getestet?

Eine bewährte Definition: mindestens 30 verschiedene Rechnungsfälle (verschiedene Steuern, Empfänger, Beträge, Sonderfälle) wurden Stufe 1 bis 4 fehlerfrei durchlaufen, und drei reale Testempfänger haben die Verbuchung bestätigt. Erst dann ist der Schalter auf „live" gerechtfertigt.

Häufige Fragen

Reicht ein Validator wirklich aus?

Für Stufe 1 und 2 ja. Für die Verbuchung beim Empfänger nicht – das prüft kein Validator.

Brauche ich einen separaten Test-Mandanten in der Buchhaltung?

Dringend empfohlen. Sonst landen Testbuchungen in den echten Auswertungen.

Wie lange dauert ein vollständiger Integrationstest?

Bei mittlerer Komplexität: 2–4 Wochen. Wer Peppol erstmals einrichtet, plant zusätzlich 2–3 Wochen für Service-Provider-Onboarding.

Was, wenn der Empfänger meine Testrechnung trotz grünem Validator ablehnt?

Holen Sie die Fehlermeldung des Empfänger-Systems ein. Häufig fehlen branchenspezifische Felder (Kostenstelle, BT-19 Buchungshilfe) oder Pflichtanhänge.

Lohnt sich ein automatisierter Regressions-Test?

Ja. Wer regelmäßig Software-Updates fährt, sollte ein Set Referenz-Rechnungen automatisiert validieren. Eine kleine CI-Pipeline mit dem KoSIT-Validator reicht.