ZUGFeRD validieren: Profile, EN 16931 und PDF/A-3 prüfen

ZUGFeRD ist ein Hybridformat: eine PDF-Datei nach dem Standard PDF/A-3 mit einem eingebetteten XML-Datensatz (Syntax CII). Genau dieser XML-Teil macht die Rechnung erst zur strukturierten E-Rechnung im Sinne von § 14 UStG. Ein Empfänger oder dessen Software liest in der Regel den Datensatz automatisch aus und verbucht ihn. Ist der Datensatz fehlerhaft oder das Profil nicht zulässig, wird die Rechnung im schlimmsten Fall abgewiesen oder gar nicht erst als E-Rechnung akzeptiert.

Validieren heißt: Du prüfst vor dem Versand, ob deine Datei die Anforderungen erfüllt, statt beim Kunden ins offene Messer zu laufen. Das ist besonders relevant, seit jedes inländische Unternehmen im B2B seit dem 01.01.2025 strukturierte E-Rechnungen empfangen können muss – ganz ohne Zustimmung des Absenders. Die Pflicht, selbst E-Rechnungen auszustellen, kommt dagegen gestaffelt: ab 01.01.2027 für Betriebe mit mehr als 800.000 Euro Vorjahresumsatz, ab 01.01.2028 für alle inländischen B2B-Umsätze. Wer heute schon sauber validiert, hat den Übergang entspannt hinter sich, bevor es ernst wird.

Eine geprüfte Rechnung spart außerdem Rückfragen und Zahlungsverzug. Wenn dein Kunde die Datei nicht einlesen kann, verzögert sich die Zahlung – und die Ursache ist oft ein vermeidbarer Formatfehler, den eine Validierung sofort sichtbar gemacht hätte. Zwei Minuten Prüfung ersparen dir am Ende die Mahnung und den peinlichen Rückruf.

ZUGFeRD kennt seit Version 2.0.1 mehrere Profile, die festlegen, wie viele Datenfelder der eingebettete XML-Teil enthält. Nicht jedes Profil reicht aus, um als vollwertige E-Rechnung nach EN 16931 zu gelten. Der entscheidende Punkt: Zwei Profile enthalten zu wenige strukturierte Daten und sind daher nicht als E-Rechnung zulässig.

Merke dir diese Trennung, bevor du ein Profil in deiner Software einstellst. Wählst du versehentlich MINIMUM oder BASIC-WL, sieht das PDF für dich völlig normal aus – der eingebettete Datensatz erfüllt die Norm aber nicht, und der Empfänger kann die Datei nicht als E-Rechnung verarbeiten.

Eine vollständige ZUGFeRD-Validierung besteht aus zwei Ebenen. Zuerst wird der eingebettete XML-Datensatz gegen die europäische Norm EN 16931 und – falls es um XRechnung geht – gegen deren deutsche Ausprägung (das CIUS, verwaltet von der KoSIT) geprüft. Dafür nutzt du eine Validierungsanwendung, etwa den KoSIT-Validator mit den passenden Schematron-Regeln. Diese Prüfung meldet fehlende Pflichtfelder, falsche Codes oder Rechenfehler bei Beträgen und Steuersätzen.

Die zweite Ebene betrifft die PDF-Hülle selbst. Weil ZUGFeRD auf PDF/A-3 aufsetzt, muss die Datei auch als PDF/A-3 konform sein – sonst darf das XML formal gar nicht eingebettet sein. Diese Konformität prüfst du mit einem PDF/A-Validator wie veraPDF. Erst wenn beide Ebenen durchlaufen, ist die Datei technisch sauber und wirklich versandfertig.

Wichtig ist das saubere Zusammenspiel der Begriffe: EN 16931 ist die semantische Norm (das Datenmodell), kein Dateiformat. XRechnung ist ein rein strukturiertes XML nach dieser Norm, ZUGFeRD ist das Hybrid aus PDF und XML. Peppol wiederum ist nur der Transportweg, kein Format. Wer diese Ebenen auseinanderhält, versteht auch die einzelnen Validierungsschritte leichter und sucht Fehler an der richtigen Stelle.

Viele Beanstandungen entstehen nicht durch exotische Sonderfälle, sondern durch immer dieselben Standardfehler. Wenn du diese Punkte vorab durchgehst, fällt der Großteil der Probleme schon vor dem ersten echten Versand weg.

Besonders tückisch sind Rundungsdifferenzen: Wenn die Summe der Positionen nicht exakt zum ausgewiesenen Steuerbetrag pro Steuersatz passt, schlägt die Norm-Prüfung an, obwohl die Rechnung optisch stimmig wirkt. Solche Cent-Abweichungen sind mit bloßem Auge kaum zu finden – ein Validator zeigt sie sofort.

Bei ZUGFeRD gibt es zwei Darstellungen derselben Rechnung: die menschenlesbare PDF-Seite und den maschinenlesbaren XML-Datensatz. Weichen beide voneinander ab, gilt für die E-Rechnung der strukturierte Datensatz – nicht das, was du auf dem Papier oder Bildschirm siehst. Genau deshalb reicht es nicht, nur das sichtbare PDF Korrektur zu lesen.

In der Praxis heißt das: Wenn deine Software beim Erstellen den Betrag im sichtbaren Layout ändert, aber den XML-Teil nicht mitzieht, verschickst du eine widersprüchliche Rechnung. Der Kunde verbucht den XML-Wert, du meinst den PDF-Wert – und der Ärger ist programmiert. Eine Validierung, die beide Ebenen betrachtet, deckt solche Abweichungen auf, bevor sie im Buchhaltungssystem des Empfängers landen.

Software wie Gewerko erzeugt E-Rechnungen als XRechnung und Factur-X (technisch identisch zu ZUGFeRD 2.x) direkt aus deinen Aufträgen und Positionen, sodass Layout und Datensatz aus einer Quelle stammen. Das reduziert die häufigste Fehlerklasse – auseinanderlaufende Bild- und Datenwerte – von vornherein, weil beide Darstellungen aus demselben Datenstand berechnet werden.

Validieren ist nur der erste Schritt – die geprüfte E-Rechnung musst du anschließend GoBD-konform aufbewahren. Entscheidend ist, dass der strukturierte XML-Teil unveränderbar, vollständig und maschinell auswertbar archiviert wird. Ein nachträglich bearbeitetes oder neu ausgedrucktes PDF genügt dafür nicht, weil damit gerade der maßgebliche Datensatz verloren geht.

Die Aufbewahrungsfrist für Rechnungen beträgt seit dem 01.01.2025 acht Jahre (zuvor zehn). Bewahre die Originaldatei so auf, wie sie versendet oder empfangen wurde, inklusive des eingebetteten XML. Wer die Datei nur als ausgedrucktes PDF ablegt und den Datensatz verliert, erfüllt die Anforderungen an eine E-Rechnung nicht mehr – und die Validierung von vorhin war umsonst.