ZUGFeRD-Validator: Rechnung prüfen, Bericht lesen, Fehler beheben

Eine ZUGFeRD-Rechnung sieht im PDF-Reader immer gut aus – auch wenn sie ungültig ist. Ob das eingebettete XML vollständig ist, die Summen aufgehen und die PDF wirklich eine PDF/A-3 ist, zeigt erst ein Validator. Dieser Artikel erklärt, was dabei geprüft wird, welche Werkzeuge es gibt und was sie taugen, wie Sie eine Datei mit dem Referenzprüfer Mustangproject validieren, wie Sie den Bericht lesen und was die häufigsten Fehlermeldungen bedeuten.

Was ein ZUGFeRD-Validator prüft

ZUGFeRD ist ein hybrides Format, deshalb hat die Prüfung mehrere Ebenen, die aufeinander aufbauen. Was ZUGFeRD ist und wie es aufgebaut ist, erklärt der Leitfaden ZUGFeRD.

Ebene 1: Die PDF. Ist die Datei eine gültige PDF/A-3? Sind alle Schriften eingebettet, ist ein Farbprofil hinterlegt, gibt es XMP-Metadaten, die Version und Profil deklarieren? Ist eine Datei namens factur-x.xml als Anhang mit der richtigen Beziehung eingebettet? Diese Prüfung übernimmt bei Mustangproject die Bibliothek veraPDF, der Standardprüfer für PDF/A – er kann, auch einzeln genutzt, nur diese Ebene.

Ebene 2: Das XML-Schema. Ist das eingebettete XML wohlgeformt, und folgt es der Struktur der UN/CEFACT CII? Stehen die Elemente an der richtigen Stelle, haben Datumsfelder das Format 102, sind Beträge Dezimalzahlen? Ein Schemafehler bedeutet meist ein defektes oder von Hand bearbeitetes XML.

Ebene 3: Die Geschäftsregeln. Das ist die eigentliche Prüfung. Die EN 16931 definiert mehr als hundert Business Rules (BR), die per Schematron geprüft werden: Ist eine Rechnungsnummer vorhanden (BR-02)? Hat der Verkäufer eine Postanschrift (BR-08)? Ergibt Netto plus Steuer den Bruttobetrag (BR-CO-15)? Passt der Steuerbetrag zum Steuersatz? Hat eine steuerbefreite Position 0 Prozent (BR-E-05)? Dazu prüft der Validator, ob das im XML deklarierte Profil zum Inhalt passt – ein als EN 16931 deklariertes XML ohne Positionen fällt durch.

Ebene 4 (nur Profil XRECHNUNG): Trägt das XML die XRechnung-Kennung, gelten zusätzlich die deutschen Regeln der KoSIT (BR-DE-…): Leitweg-ID, Kontaktdaten des Verkäufers, Zahlungsangaben. Mustangproject wendet sie automatisch an; die offizielle Referenz für diese Ebene bleibt der KoSIT-Validator, siehe XRechnung-Validator.

Die Werkzeuge

Mustangproject (mustangproject.org) ist eine Open-Source-Bibliothek in Java mit Kommandozeilenwerkzeug, Apache-Lizenz, entwickelt im Umfeld des FeRD. Es prüft alle Ebenen, extrahiert und erzeugt ZUGFeRD-Dateien und wird von Rechnungsprogrammen als Referenz genutzt. Braucht Java 17 oder neuer. Für alle, die wirklich wissen wollen, ob eine Datei gültig ist.

Quba-Viewer (quba-viewer.org) ist ein kostenloses Anzeigeprogramm für Windows, macOS und Linux aus derselben Community. Es öffnet ZUGFeRD-PDFs und XRechnungen und stellt den XML-Inhalt lesbar dar. Sinn: eine empfangene Rechnung ansehen und mit der PDF vergleichen. Eine Regelprüfung im Umfang von Mustangproject ist es nicht.

ELSTER E-Rechnungs-Viewer (elster.de/eportal/e-rechnung) ist das kostenlose Angebot der Finanzverwaltung: Datei hochladen, Rechnung lesen, ohne Registrierung. Die Daten verlassen laut ELSTER die Server der Steuerverwaltung nicht. Ausgelegt ist der Viewer auf XRechnung; er zeigt an, was er lesen kann, ist aber kein Validator im technischen Sinn.

Der Pennio-Prüfer (E-Rechnung prüfen) holt das eingebettete XML aus der ZUGFeRD-PDF, zeigt die Rechnung lesbar an und prüft die Pflichtfelder und Rechenregeln der EN 16931 – im Browser, ohne Upload. Die PDF/A-3-Ebene und die vollständige Regelprüfung deckt er nicht ab; dafür bleibt Mustangproject das Werkzeug der Wahl.

veraPDF (verapdf.org) prüft ausschließlich PDF/A-Konformität – gründlich und Open Source, aber ohne Blick ins XML. Interessant, wenn Sie gezielt wissen möchten, warum eine PDF nicht als PDF/A-3 durchgeht.

Online-Validatoren. Es gibt Webseiten, auf die Sie eine Datei hochladen und ein Prüfergebnis bekommen. Bedenken Sie, was Sie hochladen: eine Rechnung mit Namen, Adressen, Bankverbindung und Beträgen. Prüfen Sie Datenschutzerklärung und Betreiber, oder nutzen Sie ein Werkzeug, das lokal läuft. Für Testdateien ohne echte Daten ist die Hürde niedriger.

Schritt für Schritt: prüfen mit Mustangproject

1. Java installieren. Sie brauchen ein Java Runtime Environment ab Version 17. Ob es vorhanden ist, zeigt java -version in der Kommandozeile.

2. Mustang-CLI laden. Die aktuelle Version liegt als .jar-Datei auf der Projektseite (Bereich „Commandline") beziehungsweise bei den Releases des GitHub-Projekts ZUGFeRD/mustangproject. Die Datei heißt etwa Mustang-CLI-2.24.0.jar.

3. Validieren. In der Kommandozeile, im Ordner mit der Rechnung:

java -jar Mustang-CLI-2.24.0.jar --no-notices --action validate --source rechnung.pdf

--action validate startet die Prüfung, --source benennt die Datei, --no-notices unterdrückt Hinweise, die keine Fehler sind. Statt einer PDF können Sie auch direkt eine XML-Datei angeben; dann entfällt die PDF-Ebene. Mit --log-as-pdf erhalten Sie den Bericht zusätzlich als PDF.

4. Bericht lesen. Mustangproject gibt einen XML-Bericht aus (dazu gleich mehr). Die letzte Zeile entscheidet: <summary status="valid"/> oder <summary status="invalid"/>.

5. Bei Bedarf das XML extrahieren. Um den eingebetteten Datensatz anzusehen: java -jar Mustang-CLI-2.24.0.jar --action extract --source rechnung.pdf --out factur-x.xml. Wie das XML einer Rechnung aufgebaut ist, zeigt der Artikel ZUGFeRD-Rechnung: Beispiel.

Den Prüfbericht lesen

Ein Bericht für eine gültige Datei sieht gekürzt so aus:

<validation filename="rechnung.pdf" datetime="2026-09-12 11:40:53">
  <pdf>
    <summary status="valid"/>
  </pdf>
  <xml>
    <info>
      <version>2</version>
      <profile>urn:cen.eu:en16931:2017</profile>
      <rules>
        <fired>89</fired>
        <failed>0</failed>
      </rules>
    </info>
    <summary status="valid"/>
  </xml>
  <summary status="valid"/>
</validation>

Drei Blöcke: <pdf> für die PDF/A-Ebene, <xml> für Schema und Geschäftsregeln, dazu die Gesamtwertung am Ende. Unter <info> stehen die erkannte ZUGFeRD-Version (2) und das Profil als URN – urn:cen.eu:en16931:2017 ist EN 16931, mit dem Zusatz #compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 wäre es XRECHNUNG. <rules> zählt, wie viele Regeln liefen und wie viele fehlschlugen.

Bei einer ungültigen Datei kommt ein Block <messages> mit einem <error> je Verstoß hinzu. Jeder Fehler nennt in eckigen Klammern die Regelkennung, dann den Regeltext der Norm in Englisch mit den betroffenen Feldnummern (BT). Beispiel:

[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount
without VAT (BT-109) + Invoice total VAT amount (BT-110).

Die Kennung ist der Schlüssel: BR-… sind Regeln der EN 16931, BR-CO-… Rechenregeln („calculation"), BR-S-…, BR-E-…, BR-AE-… Regeln je Steuerkategorie, BR-DE-… deutsche XRechnung-Regeln, PEPPOL-EN16931-… Regeln des Peppol-Netzes, die XRechnung übernommen hat. Die BT-Nummer sagt, welches Feld betroffen ist.

Die häufigsten Fehlermeldungen und ihre Ursache

„Not a PDF/A-3" oder „Invalid XMP Metadata not found". Die Datei ist eine gewöhnliche PDF – erzeugt mit einem PDF-Drucker oder aus Word – an die jemand ein XML angehängt hat. Ohne PDF/A-3 und XMP-Deklaration ist es kein ZUGFeRD, das XML wird oft gar nicht erst gelesen („XML could not be extracted"). Ursache: das Programm erzeugt keine echte PDF/A-3. Lösung: Programm wechseln oder aktualisieren; nachträglich lässt sich das nicht sauber flicken.

„XML could not be extracted" bei einer echten PDF/A-3. Der Anhang fehlt, heißt anders als factur-x.xml (etwa rechnung.xml) oder ist nicht als zugehörige Datei (AFRelationship) verknüpft. Ursache: fehlerhafte Einbettung.

BR-CO-15, BR-CO-16, BR-CO-10 bis BR-CO-14 – Summen stimmen nicht. Netto plus Steuer ergibt nicht den Bruttobetrag, die Positionssumme passt nicht zu LineTotalAmount, der Zahlbetrag weicht vom Bruttobetrag ab, ohne dass eine Vorauszahlung erfasst ist. Ursache fast immer: Rundung an mehreren Stellen oder Beträge, die aus der PDF-Darstellung statt aus den Rohdaten übernommen wurden. Ein Programm muss an genau einer Stelle runden und PDF wie XML aus demselben Ergebnis befüllen.

BR-CO-25 – Fälligkeit oder Zahlungsbedingungen fehlen. Bei positivem Zahlbetrag muss entweder ein Fälligkeitsdatum (BT-9) oder ein Zahlungsbedingungstext (BT-20) vorhanden sein. Auf Papierrechnungen steht „zahlbar innerhalb 14 Tagen" oft nur im Fließtext; das XML braucht ein Datum.

„Buyer electronic address MUST be provided" (PEPPOL-EN16931-R010), BR-DE-… Beim Profil XRECHNUNG sind E-Mail-Adresse des Käufers, Kontaktdaten des Verkäufers und Leitweg-ID Pflicht. Ursache: Kundenstammdaten unvollständig. Lösung: Felder beim Kunden ergänzen – vor dem Festschreiben.

BR-E-05, BR-E-09, BR-E-10 – Steuerkategorie passt nicht. Eine Position ist als steuerbefreit (E) markiert, trägt aber 19 Prozent; oder ein steuerbefreiter Umsatz hat keinen Befreiungsgrund. Typisch bei Kleinunternehmern nach § 19 UStG, deren Programm „0 %" mit Kategorie S statt E mit Begründung ausgibt.

Profil-Mismatch. Die XMP-Metadaten deklarieren EN 16931, das XML trägt eine andere Kennung – oder das XML behauptet EN 16931, enthält aber keine Positionen. Ursache: Programm mit inkonsistenter Konfiguration. Der Validator prüft immer gegen das deklarierte Profil; was fehlt, ist ein Fehler.

Wenn die Rechnung schon raus ist

Der Validator meldet einen Fehler, aber die Rechnung liegt bereits beim Kunden. Was jetzt?

Nicht reparieren. Es ist verlockend, das XML zu korrigieren und die Datei noch einmal zu schicken. Damit existieren zwei Dateien mit derselben Rechnungsnummer und unterschiedlichem Inhalt – für den Kunden, für dessen Buchhaltung und für eine spätere Prüfung ist das die schlechteste aller Varianten. Eine ausgestellte Rechnung ist ein Beleg, kein Entwurf.

Stornieren und neu stellen. Der saubere Weg: eine Stornorechnung mit eigener Nummer, die auf das Original verweist und den Betrag negativ ausweist; danach eine neue, korrekte Rechnung mit neuer Nummer. Der Kunde bekommt beide, seine Buchhaltung hebt die erste auf und bucht die zweite. Wie das geht, steht im Artikel Stornorechnung schreiben.

Ursache abstellen. Fehler, die ein Validator findet, sind fast immer systematisch: ein fehlendes Stammdatenfeld, eine falsche Steuerkategorie, ein Programm ohne PDF/A-3. Wer die Ursache behebt, hat das Problem bei der nächsten Rechnung nicht mehr.

Der beste Zeitpunkt für die Validierung ist vor dem Festschreiben – dann ist ein Fehler eine Korrektur im Entwurf und kein Storno. Ein Rechnungsprogramm, das jede Datei vor dem Versand automatisch gegen Mustangproject prüft, nimmt Ihnen diesen Schritt ab. Wie Sie eine E-Rechnung unabhängig vom Format prüfen, steht im Artikel E-Rechnung prüfen.

Häufige Fragen

Stand: September 2026. Quellen: EN 16931 (Geschäftsregeln BR), ZUGFeRD-Spezifikation 2.5 (FeRD), Mustangproject 2.24, KoSIT XRechnung 3.0, § 14 UStG, BMF-Schreiben vom 15. Oktober 2024.