# ZUGFeRD-Validatoren: was Sie vor dem Versand einer Hybridrechnung prüfen sollten

- Date: 2026-04-20
- Modified: 2026-10-04
- Geprüft: 15. August 2026
- Reading time: 3 Min. Lesezeit

Praxisleitfaden 2026 zur Validierung von ZUGFeRD- und Factur-X-Rechnungen: XML-Regeln, PDF/A-3-Prüfung, Profilpassung, typische Fehler und sinnvolle

> Geprüft anhand von FNFE-MPE Factur-X-Ressourcen, UN/CEFACT-XML-Schemata.

Dieser Leitfaden richtet sich an Teams, die ZUGFeRD oder Factur-X erzeugen und wissen wollen, ob „die PDF lässt sich öffnen“ bereits Versandreife bedeutet.

Das tut es nicht. Eine nutzbare Hybridrechnung braucht mehr als eine lesbare PDF: Die eingebettete XML muss zum gewählten Profil passen, Pflichtdaten müssen vorhanden sein, Summen müssen stimmen und auch der PDF-Container selbst sollte die Archivierungsanforderungen des Formats erfüllen.

## Was ein Validator tatsächlich prüfen sollte

- Die eingebettete XML ist vorhanden und lässt sich korrekt aus dem PDF-Container lesen.
- Die Rechnungsdaten entsprechen EN 16931 und dem gewählten ZUGFeRD- oder Factur-X-Profil.
- Summen, USt-Aufschlüsselung, Einheiten und Datumswerte sind intern konsistent.
- Die PDF-Datei erfüllt die erwarteten PDF/A-3-Anforderungen für einen Hybridrechnungsprozess.
## Verwenden Sie mehr als eine Art von Validierung

Ein belastbarer Ablauf kombiniert in der Regel mindestens zwei Ebenen. Zuerst validieren Sie die fachlichen Regeln und die XML-Struktur. Danach prüfen Sie den PDF/A-3-Container und die Einbettung. Wenn ein Empfängerkanal eigene Prüfungen hat, ist das eine dritte Schranke und nicht Ihr einziger Test.

Darum kombinieren Teams häufig einen ZUGFeRD-fähigen Rechnungsvalidator mit einer PDF/A-Prüfung wie [veraPDF](https://verapdf.org/) für den Dokumentcontainer.

## Empfohlener Validierungsablauf

- ZUGFeRD- oder Factur-X-Rechnung aus bereits geprüften Quelldaten erzeugen.
- Regelbasierte Rechnungsvalidierung gegen Zielprofil und EN-16931-Erwartungen durchführen.
- PDF/A-3-Prüfung auf dem finalen Dokument ausführen und nicht auf einer Vorab-PDF ohne eingebettete XML.
- Dokument in einem Viewer öffnen, der die strukturierten Rechnungsdaten anzeigen kann, und Schlüsselfelder mit der Ausgangsrechnung vergleichen.
- Erst danach über E-Mail, Portal oder Peppol an den Empfänger schicken.
## Typische Fehler und ihre Bedeutung

- Die PDF öffnet sich normal, aber die XML fehlt, ist beschädigt oder nicht korrekt eingebettet.
- Die XML ist technisch lesbar, aber Pflichtfelder oder Profilkennungen sind falsch.
- Positionssummen, Steuerbasen und USt-Beträge stimmen nach Extraktion oder Mapping nicht überein.
- Das Dokument sieht für Menschen richtig aus, scheitert aber an PDF/A-3-Prüfungen, weil der Hybridcontainer unvollständig oder nicht konform ist.
## Offizielle und primäre Quellen

- [FeRD-Paket zu ZUGFeRD 2.5.2 / Factur-X 1.09.2](https://www.ferd-net.de/publikationen-produkte/publikationen/detailseite/zugferd-252-english).
- [KoSIT-Validator-Konfiguration für EN 16931 und XRechnung](https://github.com/itplr-kosit/validator-configuration-xrechnung).
- [KoSIT-FAQ zum XRechnung-Kontext](https://xeinkauf.de/xrechnung/faq/).
- [veraPDF-Projekt zur PDF/A-Validierung](https://verapdf.org/).

## FAQ

### Reicht es aus, dass sich die PDF öffnen lässt?

Nein. Eine lesbare PDF beweist nur, dass die visuelle Ebene vorhanden ist. Sie beweist nicht, dass die eingebettete XML vorhanden, gültig oder profilkonform ist.

### Warum sowohl Rechnungsvalidator als auch PDF/A-Validator einsetzen?

Beide prüfen unterschiedliche Dinge. Der eine fokussiert auf Rechnungssemantik und Regeln, der andere auf Archivierungs- und Verpackungsanforderungen des PDF-Containers.

### Ersetzt Validierung die menschliche Prüfung?

Nein. Validierung ist Pflicht, aber menschliche Prüfung bleibt nötig bei Quellproblemen, falscher Profilauswahl und fachlichen Fehlern, die ein Automat nicht vollständig einordnen kann.

## Offizielle Quellen

- [FNFE-MPE Factur-X-Ressourcen](https://fnfe-mpe.org/factur-x/)
- [UN/CEFACT-XML-Schemata](https://unece.org/trade/uncefact/xml-schemas)