ZUGFeRD Beispielrechnung: gültige Testdateien und wie Sie sie prüfen

Wer seine Software auf E-Rechnungen umstellt, braucht als Erstes eine Datei, von der er sicher weiß, dass sie korrekt ist. Sonst suchen Sie stundenlang den Fehler im eigenen Import — und er steckt in der Testdatei.

Drei geprüfte Dateien liegen zum sofortigen Herunterladen bereit:

• xrechnung-beispiel-ubl.xml — XRechnung in UBL-Syntax, der Standardfall im Behördenverkehr.
• xrechnung-beispiel-cii.xml — dieselbe Rechnung in CII-Syntax (UN/CEFACT), der zweiten zulässigen XML-Variante der EN 16931 und technischen Grundlage von ZUGFeRD.
• zugferd-beispiel.pdf — eine ZUGFeRD-PDF im Profil EN 16931: normal lesbar und mit eingebettetem XML.

Alle drei finden Sie mit Beschreibung und einer gerenderten Vorschau auf der Beispiele-Seite.

Der Rechnungsstandard ZUGFeRD in einem Absatz

ZUGFeRD ist keine eigene Rechnungssprache, sondern eine Verpackung: ein PDF/A-Dokument, in das eine XML-Datei nach EN 16931 eingebettet ist. Der Mensch öffnet das PDF und sieht eine Rechnung, die Software liest das XML und braucht nichts abzutippen. Technisch ist ZUGFeRD ab Version 2.1 identisch mit dem französischen Factur-X. Ausführlich steht das unter Was ist ZUGFeRD.

Nicht jedes ZUGFeRD zählt: die Profile

Der häufigste Irrtum beim Testen ist die Annahme, „ZUGFeRD“ sei eine Zusage. Ein Profil legt fest, wie viele Datenfelder das eingebettete XML enthält — und erst ab einem bestimmten Umfang gilt die Datei als E-Rechnung nach § 14 UStG.

Eine Datei im Profil MINIMUM ist rechtlich eine „sonstige Rechnung“ — so, als hätten Sie ein gewöhnliches PDF verschickt. Wenn Ihre Software also ZUGFeRD ausgibt, prüfen Sie zuerst, welches Profil sie schreibt, bevor Sie das Format für erledigt halten. Unsere Beispiel-PDF nutzt bewusst EN 16931, damit ein Test damit auch aussagekräftig ist.

So testen Sie in vier Schritten

1. Datei laden. Eine der drei Beispieldateien herunterladen — oder eine Rechnung aus Ihrer eigenen Software erzeugen.
2. In den Validator ziehen. Auf /validator die Datei hochladen; XML und PDF werden beide angenommen, bei PDF wird das eingebettete XML automatisch herausgelöst.
3. Ansicht und Ergebnis vergleichen. Oben erscheint die lesbare Rechnungsansicht, darunter das Prüfergebnis. So sehen Sie in einem Durchgang, ob die Daten stimmen und ob sie formal gültig sind.
4. Gegenprobe machen. Ändern Sie im XML testweise einen Pflichtwert, etwa die Käuferreferenz, und laden Sie erneut hoch. Wenn Ihr eigener Import den Fehler ebenfalls meldet, funktioniert Ihre Kette.

Die Beispieldateien liefern beim Hochladen das Ergebnis „gültig“. Das ist der Referenzpunkt: Wenn Ihre eigene Datei danach durchfällt, liegt es nicht am Prüfwerkzeug.

Was das Prüfergebnis bedeutet

Geprüft wird gegen zwei Regelwerke gleichzeitig: die europäische Norm EN 16931 und die zusätzlichen deutschen XRechnung-Regeln der KoSIT. Als Prüfmotor kommt die Open-Source-Bibliothek Mustang zum Einsatz.

Jede Meldung bekommt bei uns eine Übersetzung ins Deutsche statt eines nackten Regelcodes: Zu jeder Regel gibt es eine eigene Seite mit Ursache und Lösung — 255 Stück. Bei beschädigten Dateien schlägt die KI-Korrektur eine reparierte Fassung vor und zählt die Fehler vorher und nachher; Geschäftsdaten wie IBAN oder Steuernummer erfindet sie bewusst nicht.

Zwei Grenzen, die jede Validierung hat: Sie prüft die Form, nicht die inhaltliche Richtigkeit — ein falscher Steuersatz kann formal einwandfrei sein. Und sie ist keine Zusage über den Vorsteuerabzug.

XML aus der ZUGFeRD-PDF herausholen

Für Entwicklertests brauchen Sie oft nur den XML-Teil. Laden Sie die PDF in den ZUGFeRD-Extraktor und laden Sie das XML herunter — das ist exakt das, was ein Buchhaltungsprogramm aus der Datei liest.

Der Extraktor beantwortet nebenbei die praktische Frage bei eingehenden PDFs: Steckt überhaupt eine E-Rechnung darin? Kommt die Meldung, dass kein XML enthalten ist, handelt es sich um ein gewöhnliches PDF — und damit seit 2025 nicht um eine E-Rechnung im Sinne des Gesetzes.

Testdaten, die wirklich gültig sind

Beispieldateien aus Blogs, Foren und alten Handbüchern sind eine häufige Fehlerquelle: Sie stammen oft aus ZUGFeRD 1.0 oder aus einem zu kleinen Profil und fallen deshalb zu Recht durch die Prüfung. Verlässlich sind zwei Quellen:

• Die offizielle Testsuite der KoSIT zur XRechnung. Sie enthält gültige und bewusst fehlerhafte Fälle und ist die Grundlage, gegen die auch kommerzielle Software abgeglichen wird. Unsere beiden XML-Beispiele stammen daraus.
• Der ZUGFeRD-Korpus der Community, aus dem unsere Beispiel-PDF kommt. Beide Quellen stehen unter Apache-2.0-Lizenz, die Inhalte sind fiktive Testdaten — keine echten Firmen, keine echten Bankverbindungen.

Für den Praxistest empfiehlt sich zusätzlich ein Blick auf beide Syntaxen: UBL und CII enthalten dieselben Informationen in unterschiedlicher Struktur. Wenn Ihre Software nur eine davon einliest, fällt es genau hier auf und nicht erst bei der ersten echten Lieferantenrechnung. Die Formatlandschaft erklärt E-Rechnung Formate.

Häufige Fragen

Darf ich die Beispieldateien für eigene Tests verwenden? Ja, sie sind genau dafür da: Apache-2.0-Lizenz, fiktive Daten. Als Vorlage für echte Rechnungen taugen sie nicht — Ihre Software sollte die Datei erzeugen.

Warum ist meine ZUGFeRD-Datei ungültig, obwohl sie sich öffnen lässt? Weil PDF-Ansicht und XML-Inhalt zwei verschiedene Dinge sind. Das PDF kann tadellos aussehen, während im eingebetteten XML eine Pflichtangabe fehlt oder das Profil zu klein ist.

Brauche ich für den Test ein Konto? Nein. Prüfen, Ansehen und Extrahieren funktionieren ohne Anmeldung; die Datei wird nach der Verarbeitung gelöscht.

Welches Format soll ich selbst erzeugen? Für Behörden meist XRechnung, im B2B-Geschäft häufig ZUGFeRD, weil der Empfänger die PDF auch ohne Viewer lesen kann. Die Abwägung steht unter XRechnung oder ZUGFeRD.

Keine Steuer- oder Rechtsberatung. Angaben Stand August 2026 nach Anbieterangaben.