Öffnen Sie eine hybride Rechnung in irgendeinem PDF-Reader, und Sie sehen ein ganz normales Dokument: Briefkopf, Positionen, Endbetrag. Über die Gültigkeit der Datei sagt diese Ansicht nichts. Entscheidend für die Buchhaltungssoftware des Empfängers ist die XML-Datei im Inneren — und die Art, wie sie an das PDF angehängt ist.
Das ist die häufigste Überraschung für alle, die mit dem Format neu zu tun haben. Ein PDF, das gedruckt und dem anschließend in einem PDF-Editor eine XML-Datei „angehängt“ wurde, sieht auf dem Bildschirm exakt aus wie eine echte ZUGFeRD-Rechnung — und fällt bei der Prüfung sofort durch. Genau diesen Unterschied fängt die Validierung ab: zwischen „sieht richtig aus“ und „ist richtig“.
Schicht 1 — ist die Datei wirklich PDF/A-3?
Eine hybride Rechnung ist nicht einfach ein PDF mit Anhang. Sie muss eine gültige PDF/A-3-Datei sein — die Archivvariante des PDF, gebaut für Lesbarkeit über Jahrzehnte — und die Rechnungs-XML muss auf eine ganz bestimmte Weise eingebettet sein.
Geprüft wird auf dieser Schicht unter anderem:
- PDF/A-3-Konformität — die strukturellen Anforderungen des Archivformats selbst.
- Eingebettete Schriften. PDF/A verbietet es, sich auf Schriften zu verlassen, die auf dem Rechner des Lesers installiert sind: alles zur Darstellung Nötige muss in der Datei stecken.
- Farbprofile, ausdrücklich deklariert statt stillschweigend vorausgesetzt.
- XMP-Metadaten — ein maschinenlesbarer Block, der die Datei beschreibt, samt Angabe, welchem Standard und welchem Profil sie zu folgen behauptet.
- Die Art der Verknüpfung. Die eingebettete XML muss mit der richtigen Beziehung (
AFRelationship) und dem erwarteten Dateinamen versehen sein, damit Software sie als Rechnungsdaten erkennt und nicht als beliebigen Anhang.
Werkzeuge in diesem Bereich setzen für diese Schicht in aller Regel veraPDF ein, den quelloffenen PDF/A-Validator. Eine Datei, die hier durchfällt, ist keine gültige E-Rechnung — egal wie gut ihre XML ist.
Schicht 2 — ist die XML wohlgeformt und schemagültig?
Die eingebetteten Daten verwenden die Syntax UN/CEFACT Cross Industry Invoice (CII) — das Datenmodell, das unser Artikel zur XML-Struktur beschreibt.
Diese Schicht liest die XML und prüft sie gegen ihr XML-Schema (XSD): jedes Element dort, wo das Schema es erwartet, richtige Datentypen, Pflichtelemente vorhanden, Werte im richtigen Format. Ein Datum als 31.12.2026 geschrieben, wo das Schema 20261231 verlangt, fällt hier durch.
Die Schemaprüfung ist streng in der Form und völlig blind für den Inhalt. Eine Rechnung kann einwandfrei schemagültig sein und trotzdem eine Umsatzsteuersumme ausweisen, die nicht zu ihren eigenen Positionen passt. Dafür ist die dritte Schicht da.
Schicht 3 — die Geschäftsregeln
Die strengste und interessanteste Schicht prüft Schematron-Geschäftsregeln: mehrere hundert inhaltliche Zusicherungen, die neben der EN 16931 definiert sind und testen, ob der Inhalt der Rechnung in sich stimmig und vollständig ist.
Es sind die Regeln, die genau die Probleme abfangen, an denen Rechnungen in der Praxis scheitern:
- eine Steueraufschlüsselung, die nicht auf den ausgewiesenen Gesamtbetrag führt;
- eine Steuerkategorie, die eine Begründung verlangt, wo keine angegeben wurde;
- eine fehlende Leitweg-ID beziehungsweise Käuferreferenz bei einer Rechnung an eine öffentliche Stelle;
- eine Währung, die an einer Stelle angegeben und an anderer anders unterstellt wird.
Regeln sind in Familien gruppiert, und das Präfix verrät, woher eine Regel stammt:
| Präfix | Herkunft | Was geprüft wird |
|---|---|---|
BR-* | EN 16931, Kern | Vorhandensein und Anzahl der erforderlichen Angaben |
BR-CO-* | EN 16931, Kern | Stimmigkeit und Rechenlogik zwischen zusammengehörigen Feldern |
BR-CL-* | EN 16931, Codelisten | ein Wert muss aus einer zugelassenen Codeliste stammen |
BR-S-*, BR-Z-*, BR-E-*, BR-AE-*, BR-G-*, BR-O-*, BR-IC-* | EN 16931 | Regeln je Steuerkategorie — Regelsatz, Nullsatz, steuerbefreit, Reverse Charge, Ausfuhr, nicht steuerbar, innergemeinschaftlich |
BR-DE-* | XRechnung (deutsche CIUS) | zusätzliche deutsche Anforderungen |
PEPPOL-EN16931-R* | Peppol BIS Billing | zusätzliche Regeln für den Versand über das Peppol-Netz |
Was die Kernfamilien im Einzelnen zusichern, steht unter Geschäftsregeln der EN 16931.
Nicht jede Regel gilt für jede Datei
An dieser Stelle werden Prüfberichte am häufigsten falsch gelesen. Welcher Regelsatz gilt, hängt davon ab, was die Datei zu sein behauptet.
Eine ZUGFeRD-Datei im Profil EN 16931 wird gegen die Kernregeln der EN 16931 gemessen. Die Familie BR-DE-* gehört zur XRechnung, der deutschen Ausprägung (CIUS) des Standards — diese Regeln greifen, wenn das Dokument eine XRechnung ist, nicht bei jeder deutschen Rechnung. Eine völlig gültige ZUGFeRD-Rechnung kann deshalb BR-DE-*-Hinweise zeigen, die für sie schlicht nicht einschlägig sind. Wer sie als Fehler behandelt, „repariert“ Dateien, die nie kaputt waren.
Dasselbe gilt für Profile: eine Datei im Profil MINIMUM oder BASIC WL trägt bewusst weniger Informationen, als die EN 16931 verlangt, und wird deshalb nicht am vollen Regelsatz gemessen. Welches Profil was enthält, steht unter ZUGFeRD- und Factur-X-Profile.
Eine Prüfmeldung lesen
Eine Meldung trägt in der Regel drei brauchbare Teile:
- Den Regelcode — etwa
BR-CO-15. Das ist der schnellste Weg herauszufinden, was tatsächlich zugesichert wurde, und danach sucht man, wenn man nicht weiterkommt. - Den Schweregrad — ein harter Fehler, der das Dokument ungültig macht, oder eine Warnung, die auf etwas Fragwürdiges, aber Zulässiges hinweist.
- Einen Ort, meist als XPath in die XML, der auf das gescheiterte Element zeigt.
Der Ort sagt Ihnen, wo — der Regelcode, warum. Beheben Sie die Ursache in dem System, das die Rechnung erzeugt hat, statt die XML von Hand zu ändern: eine Rechnung, deren XML nachträglich gepatcht wurde, passt nicht mehr zur PDF-Seite daneben, und dieser Widerspruch ist schlimmer als der ursprüngliche Fehler.
Was die Prüfung nicht aussagt
Validierung ist eine Konformitätsprüfung, keine Revision — und über ihre Grenzen lohnt es sich, genau zu sein:
- Sie bestätigt nicht die Richtigkeit. Eine Datei kann jede Regel bestehen und trotzdem den falschen Preis, den falschen Kunden oder das falsche Datum zeigen. Geprüft wird innere Stimmigkeit, nicht Wahrheit.
- Sie garantiert keine Annahme. Ein Empfänger kann eigene Anforderungen stellen — eine Bestellnummer, eine bestimmte Referenz, ein bestimmtes Profil.
- Sie ersetzt keine steuerliche Beratung. Ob eine Rechnung dem Steuerrecht eines Landes genügt, ist eine andere Frage als die, ob sie der EN 16931 genügt.
Drei Versionsnummern, und sie meinen nicht dasselbe
In einem einzigen Prüflauf treffen drei verschiedene Versionen aufeinander. Sie zu verwechseln kostet viel vermeidbaren Streit:
- Die Formatversion. Aktuell ist ZUGFeRD 2.5.2 / Factur-X 1.09.2, veröffentlicht am 4. August 2026 und anzuwenden ab dem 1. September 2026. Es handelt sich um ein Corrigendum zu ZUGFeRD 2.5 vom Juni 2026: korrigiert wurden Stimmigkeit, Rundung, Steueraufschlüsselung und Prüfregeln — überwiegend im Profil EXTENDED — samt aufgefrischter XSD- und Schematron-Artefakte. Eine Version 3.0 gibt es nicht; siehe ZUGFeRD-Versionen.
- Die Validator-Version. Mustang, der quelloffene Validator, auf den sich der größte Teil dieser Branche stützt, wird in einer eigenen 2.x-Linie entwickelt — derzeit 2.26.0, erschienen am 25. August 2026. Seine Nummer hat mit der Formatversion nichts zu tun. Siehe das Mustang-Projekt.
- Die Regelsatz-Version. Die Schematron-Artefakte sind noch einmal getrennt versioniert — EN 16931 Schematron v1.3.16 ist der Satz, der zur korrigierten Fassung ZUGFeRD 2.5.2 gehört.
Eines sei deutlich gesagt: der semantische Standard selbst wurde überarbeitet. CEN hat EN 16931-1:2026 im Februar 2026 gebilligt und im Mai 2026 veröffentlicht; die Ausgabe von 2017 wurde zurückgezogen. In der Praxis sind die Werkzeuge noch nicht nachgezogen — ZUGFeRD 2.5.2 und die aktuellen Schematron-Sätze bauen weiterhin auf der Semantik von 2017 auf, und Unterstützung für die neue Fassung wird mit dem für Herbst 2026 erwarteten ZUGFeRD-Release gerechnet. Wer heute behauptet, gegen die Fassung 2026 zu prüfen, sollte gefragt werden, was genau er damit meint.
Was nach dem Klick auf „Prüfen“ passiert
Eine Prüfung ist kein Blick in eine Tabelle, sondern ein Durchlauf durch die oben beschriebenen Schichten — deshalb dauert sie Sekunden und nicht Millisekunden. Praktisch heißt das:
- Zwei Stufen nacheinander. Erst der Container (ist das wirklich ein PDF/A-3 mit Anhang?), dann das XML gegen Schema und Geschäftsregeln. Das Urteil entsteht aus beiden: ein gültiges PDF/A mit fehlerhaftem XML ist keine gültige E-Rechnung.
- Ein ehrlicher Fortschritt statt eines Ladekreises. Die Anzeige sagt, welche Stufe gerade läuft — bei großen Dateien ist das der Unterschied zwischen „es arbeitet“ und „es hängt“.
- Prüfungen laufen in einer Warteschlange. Eine aufwendige Datei blockiert damit nicht den Rest des Kontos, und mehrere Prüfungen hintereinander stören einander nicht.
- Das Ergebnis bleibt, die Datei nicht. Der Bericht liegt anschließend unter „Dokumente“; die hochgeladene Datei selbst wird kurz darauf vom Server gelöscht — siehe Aufbewahrung, das Archiv führen Sie selbst.
Eine eingegangene Rechnung prüfen
Seit dem 1. Januar 2025 muss jedes Unternehmen in Deutschland strukturierte Rechnungen empfangen können; das Ausstellen wird ab dem 1. Januar 2027 für Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz verpflichtend und ab dem 1. Januar 2028 für alle übrigen. Eine Datei zu empfangen ist einfach — zu wissen, ob das Empfangene in Ordnung ist, ist der nützliche Teil.
Vier Dinge lohnen sich bei einer eingehenden Rechnung:
- Passt die XML zur Seite? In einer hybriden Datei wird gebucht, was eingebettet ist — und das kann von dem abweichen, was das PDF anzeigt. Wo beides auseinandergeht, muss das geklärt werden, bevor das Dokument in die Bücher wandert.
- Besteht sie die Prüfung? Alle drei Schichten, den Container eingeschlossen.
- Sind die Steuerangaben plausibel? Steuernummer beziehungsweise USt-IdNr., Kategorie und Satz — oder eine angegebene Begründung, wo keine Steuer ausgewiesen wird.
- Ist es eine Dublette? Strukturierte Daten machen Doppelerfassungen weit leichter erkennbar, als gescanntes Papier es je konnte.
Prüfen, bevor Sie versenden
Der billigste Zeitpunkt, ein Problem zu finden, ist vor dem Kunden. Eine zurückgewiesene Rechnung kostet einen Zahlungszyklus, ein Prüflauf ein paar Sekunden. Wie Sie dabei mit Ihren eigenen Dokumenten vorgehen, steht unter Rechnung prüfen — Schritt für Schritt.