ZUGFeRD- oder Factur-X-Rechnung prüfen: so geht es

Eine Rechnung zu prüfen dauert wenige Sekunden. Eine abgelehnte Rechnung kostet einen Zahlungszyklus — das Dokument geht zurück, jemand muss herausfinden, woran es lag, es wird korrigiert, neu ausgestellt, und die Uhr läuft von vorn. Dieses Missverhältnis ist das ganze Argument dafür, jede Datei vor dem Versand zu prüfen — und jede eingehende, bevor sie in die Buchhaltung wandert.

Diese Seite beschreibt das praktische Vorgehen: welche Datei Sie hochladen, wie ein Bericht aufgebaut ist, wie ein echter Bericht Zeile für Zeile gelesen wird und was zu tun ist, wenn etwas beanstandet wird. Was innerhalb der einzelnen Prüfungen geschieht, steht in So funktioniert die Prüfung.

Was haben Sie überhaupt vorliegen?

Drei verschiedene Dinge werden „E-Rechnung“ genannt, und nur zwei davon lassen sich prüfen.

• Ein hybrides PDF — eine ZUGFeRD- oder Factur-X-Datei: eine ganz normal aussehende PDF-Seite mit eingebetteter Rechnungs-XML. Laden Sie das PDF hoch; die XML wird automatisch entnommen.
• Eine reine XML-Datei — eine XRechnung oder ein CII-/UBL-Dokument ohne PDF darum herum. Laden Sie sie so hoch, wie sie ist. Es gibt keinen Container zu prüfen, der Bericht beginnt also bei der Schemaschicht.
• Ein gewöhnliches PDF — eine gedruckte oder gescannte Rechnung ganz ohne strukturierte Daten. Da ist nichts zu prüfen: Es ist ein Bild einer Rechnung. Daraus eine echte E-Rechnung zu machen, ist eine andere Aufgabe — sie steht in PDF-Rechnung umwandeln.

Wenn Sie nicht sicher sind, welches der drei Sie in der Hand halten: einfach hochladen. Findet der Validator keine eingebettete XML, sagt er es sofort — und auch diese Antwort ist nützlich. Der schnellste Handgriff ohne Werkzeug ist ein Blick auf die Anhänge: Ein Reader, der Dateianhänge anzeigt, listet bei einer hybriden Rechnung eine XML-Datei mit einem Namen wie factur-x.xml oder zugferd-invoice.xml. Sehen Sie dort nichts, ist auch nichts drin.

Schritt 1 — Datei hochladen

Es muss nichts vorbereitet werden. Nichts entpacken, die XML nicht von Hand herauslösen, die Datei nicht umbenennen. Laden Sie das Dokument genau so hoch, wie es erzeugt wurde oder wie es angekommen ist — eine Datei, die ausgepackt und wieder eingepackt wurde, ist nicht mehr die Datei, die der Empfänger sieht, und gerade die Containerprüfungen prüfen genau diese Verpackung.

Drei Dinge, die an dieser Stelle Zeit kosten, wenn man sie nicht weiß:

• Ein ZIP-Archiv ist keine Rechnung. Prüfbar ist die einzelne Datei darin, nicht das Archiv. Packen Sie aus und laden Sie das Dokument hoch.
• Die Datei aus dem Postfach, nicht die aus dem Drucker. Wer eine empfangene Rechnung erneut speichert, „optimiert“ oder durch ein PDF-Werkzeug schickt, prüft danach ein anderes Dokument — mit einem Container, den unterwegs jemand anderes geschrieben hat.
• Die Größe. Auf unserer öffentlichen Seite liegt die Grenze bei 5 MB je Datei. Eine Rechnung, die deutlich darüber liegt, enthält fast immer eingebettete Scans oder Bilder in Druckauflösung — prüfenswert ist dann auch die Frage, warum.

Schritt 2 — den Bericht der Reihe nach lesen

Die Ergebnisse kommen in drei Schichten zurück und sind von oben nach unten zu lesen, denn ein Fehlschlag auf einer früheren Schicht macht die späteren unzuverlässig. Ist der PDF/A-3-Container defekt, gibt es womöglich gar keine belastbare XML zu begutachten, und der Abschnitt zu den Geschäftsregeln beschreibt dann eine Datei, die ohnehin niemand einlesen kann.

1. Container — ist das eine gültige PDF/A-3-Datei, mit der XML so angehängt, wie die Norm es verlangt? Entfällt bei reinem XML-Upload.
2. Schema — ist die XML wohlgeformt und entspricht jedes Element seinem XSD? Diese Schicht ist streng in der Form und vollkommen blind für den Sinn. Sie beanstandet ein Datum im falschen Format, nicht ein Datum im falschen Jahr.
3. Geschäftsregeln — gehen die Beträge auf, ist die Steueraufschlüsselung stimmig, ist der Verkäufer identifizierbar? Hier entstehen die meisten echten Ablehnungen, und hier lohnt sich das genaue Lesen.

Anatomie einer Meldung

Jede einzelne Zeile eines Prüfberichts besteht aus vier Teilen. Wer sie auseinanderhält, braucht für die meisten Befunde keine zweite Meinung.

Die Fundstelle ist ein XPath — eine Wegbeschreibung durch den Baum der XML. Sie müssen ihn nicht lesen können. Es genügt, das letzte Element zu erkennen und den Regelcode nachzuschlagen: Die Regelfamilien und die Fehler, die wirklich vorkommen, stehen in Geschäftsregeln der EN 16931, eine Seite mit einem Abschnitt je Code.

Fehler, Hinweis, Warnung — was welcher Rang bedeutet

Der Rang einer Meldung ist keine Geschmacksfrage, er steht in der Regel selbst. Drei Stufen kommen vor:

• Fatal. Die Datei ist an dieser Stelle nicht verwertbar — ein kaputter Container, eine XML, die sich nicht lesen lässt. Danach hat weiteres Prüfen keinen Sinn mehr.
• Fehler. Eine verbindliche Regel ist verletzt. Das Dokument ist ungültig, und ein Empfänger, der maschinell prüft, wird es zurückweisen.
• Hinweis. Etwas ist ungewöhnlich, aber erlaubt. Sehr häufig stammt der Hinweis aus einer nationalen Ausprägung, die auf Ihr Dokument gar nicht angewandt werden müsste.

Umgekehrt gilt: Ein Empfänger darf strenger sein als die Norm. Manche Behörden und Konzerne lehnen Dokumente ab, die jede Regel bestehen, weil eine Bestellnummer fehlt oder ein anderes Profil erwartet wurde. Das ist kein Prüffehler, sondern eine Anforderung, die außerhalb der Norm liegt — und die man erfragt, statt sie zu erraten.

Ein echter Bericht, Zeile für Zeile

Am schnellsten lernt man das Lesen an einem durchgerechneten Fall. Die Rechnung: drei Positionen, zwei Steuersätze, ein Nachlass auf Belegebene.

So weit ist alles richtig. Der Fehler steckt in der Steueraufschlüsselung: Das Rechnungsprogramm hat den Nachlass zwar von der Nettosumme abgezogen, aber nicht von der Bemessungsgrundlage des 19-Prozent-Satzes. In der Datei steht deshalb:

Der Bericht sieht dann so aus:

• Container: bestanden. Gültiges PDF/A-3, XML mit der erwarteten Beziehung angehängt, XMP-Metadaten vorhanden.
• Schema: bestanden. Jedes Element sitzt an seinem Platz, jede Zahl hat das richtige Format.
• Geschäftsregeln: zwei Fehler, ein Hinweis.

Fehler 1 — BR-S-08: Für jeden Steuersatz muss die Bemessungsgrundlage der Summe der Positionsnettobeträge dieses Satzes abzüglich der zugehörigen Nachlässe entsprechen. 1.140,00 + 240,00 − 67,00 = 1.313,00, in der Datei stehen 1.380,00. Fundstelle: die 19-Prozent-Zeile der Steueraufschlüsselung.

Fehler 2 — BR-CO-15: Der Bruttogesamtbetrag muss Nettogesamtbetrag plus Steuergesamtbetrag sein. 1.400,00 + 268,29 = 1.668,29, in der Datei stehen 1.655,56. Fundstelle: der Gesamtbetrag im Kopf des Dokuments.

Hinweis — BR-DE-21: die Kennung in BT-24 ist nicht die von XRechnung. Richtig so, es ist eine ZUGFeRD-Rechnung.

Und hier zeigt sich, warum man den Bericht liest, statt ihn abzuarbeiten: Zwei Fehler, eine Ursache. Der Nachlass wurde ohne Steuerkategorie gebucht. Wer den zweiten Befund für sich nimmt und den Bruttobetrag von Hand auf 1.668,29 setzt, macht die Datei nicht richtig, sondern verschiebt den Widerspruch nur: Auf der sichtbaren Seite stehen dann 1.655,56 und in den Daten 1.668,29 — und maßgeblich ist der strukturierte Teil.

Die Reparatur besteht aus einem Klick im Rechnungsprogramm: Dem Nachlass wird die Steuerkategorie „Regelsatz 19 %“ zugewiesen. Danach rechnet das Programm 1.313,00 → 249,47 → 255,56 → 1.655,56 durch, und der zweite Fehler verschwindet mit dem ersten.

Befunde, die immer wieder vorkommen

Die folgenden Meldungen stehen hinter dem größten Teil der Ablehnungen in der Praxis. Jede Zeile führt in den ausführlichen Abschnitt zum Code.

Schritt 3 — die Ursache beheben, nicht die Datei

Jeder Befund nennt einen Regelcode und zeigt auf eine Stelle in der XML. Die Stelle sagt Ihnen, wo; der Code sagt Ihnen, warum. Korrigieren Sie dann die zugrunde liegenden Daten in dem System, das die Rechnung erzeugt hat: die fehlende USt-IdNr. im Firmenprofil, die Rundungsstufe im Rechnungsprogramm, die nie erfasste Position. Erzeugen Sie das Dokument von dort aus neu.

Die XML direkt zu bearbeiten ist verlockend und fast immer falsch — aus drei Gründen:

• Die Seite und die Daten laufen auseinander. In einer hybriden Datei sollen die sichtbare Seite und die eingebetteten Daten dasselbe aussagen. Eine von Hand nachgebesserte XML passt nicht mehr zur Seite daneben.
• Der Fehler kommt wieder. Die Ursache sitzt in den Stammdaten oder in einer Einstellung. Wer die Datei repariert, repariert einen Einzelfall und stellt die nächste Rechnung mit demselben Mangel aus.
• Die Datei bricht. Wird die XML in einem hybriden PDF verändert, stimmt der Container nicht mehr — der Anhang ist ein Teil der Datei, nicht eine Beilage.

Schritt 4 — erneut prüfen, dann versenden

Lassen Sie die korrigierte Datei noch einmal durchlaufen. Korrekturen verschieben Probleme häufiger, als man erwartet: Eine ergänzte Position ändert die Nettosumme, die ändert die Steueraufschlüsselung, und die kann eine andere Rechenregel auslösen. Fertig ist eine Datei, wenn der Bericht auf allen drei Schichten sauber ist — nicht, wenn der erste Fehler verschwunden ist.

Wie oft geprüft werden sollte, hängt davon ab, wie frisch die Umstellung ist:

• In den ersten Wochen jede Rechnung. Die Fehler der Anfangszeit sitzen in den Stammdaten und wiederholen sich, bis jemand sie sieht.
• Danach bei jeder Änderung. Neue Vorlage, neuer Steuersatz, neues Zahlungsziel, ein Update des Rechnungsprogramms, ein neuer Kunde mit eigenen Anforderungen — jedes Mal einmal prüfen.
• Immer bei fremden Dateien. Was Sie empfangen, haben Sie nicht erzeugt, und Sie merken es an nichts, bis die Buchhaltung stolpert.

Checkliste vor dem Versand

Für die ersten Dokumente einmal durchgehen, und erneut, wenn sich an der Rechnungsstellung etwas ändert. Das meiste beantwortet ein Validator; der Rest braucht einen menschlichen Blick.

• Die Datei öffnet sich in jedem Reader als normales PDF, und die Seite ist lesbar.
• Das Profil entspricht dem, was der Empfänger verlangt hat — manche geben eines ausdrücklich vor.
• Die Positionsnettobeträge ergeben die Nettosumme, und netto plus Steuer ergibt die Bruttosumme.
• USt-IdNr. von Verkäufer und Käufer sind vorhanden und tragen ein Länderpräfix.
• Rechnungsdatum und Fälligkeitsdatum sind gefüllt.
• Mengeneinheiten sind Standardcodes, kein Freitext wie „Stk.“ oder „Stunden“.
• Jede Steuerkategorie, die eine Begründung verlangt — steuerbefreit, Reverse-Charge, Ausfuhr —, trägt auch eine.
• Die Zahlen auf der sichtbaren Seite stimmen mit denen in der XML überein.
• Der Prüfbericht zeigt auf keiner Schicht einen fatalen Befund.
• Wurde eine Bestell- oder Referenznummer verlangt, steht sie drin. Öffentliche Auftraggeber in Deutschland verlangen eine Leitweg-ID; ohne sie kommt die Rechnung zurück.

Eingehende Rechnungen prüfen

Bei eingehenden Dokumenten stellen sich etwas andere Fragen, denn Sie prüfen hier nicht Ihre eigene Arbeit.

• Passt die XML zur Seite? Das wird am häufigsten vergessen und ist der teuerste Befund. In einer hybriden Datei werden die eingebetteten Daten gebucht, und sie können von dem abweichen, was das PDF anzeigt. Wo beides auseinandergeht, muss das mit dem Lieferanten geklärt werden, bevor das Dokument in die Buchhaltung geht — maßgeblich ist der strukturierte Teil.
• Ist sie überhaupt gültig? Eine Lieferantendatei, die schon an der Containerprüfung scheitert, wird sich nirgends sauber einlesen lassen — und es ist billiger, das am ersten Tag zu sagen als nach dem Zahllauf.
• Sind die Steuerangaben plausibel? USt-IdNr., Kategorie und Satz — oder eine angegebene Begründung, wo keine Steuer berechnet wird.
• Ist es eine Dublette? Strukturierte Daten machen Doppelerfassungen weit leichter auffindbar, als gescanntes Papier es je konnte. Das Paar aus Rechnungsnummer und USt-IdNr. des Verkäufers identifiziert ein Dokument eindeutig.
• Was archivieren Sie? Aufzubewahren ist der strukturierte Teil, unverändert — acht Jahre nach § 14b UStG. Eine Ablage, die nur den Ausdruck behält, erfüllt das nicht; Einzelheiten in Aufbewahrung und GoBD.

Was ein sauberer Bericht nicht beweist

Die Prüfung ist ein Konformitätsnachweis, keine Revision, und über ihre Grenzen genau zu sein erspart später Diskussionen.

• Sie bestätigt keine 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 über die Norm hinaus eigene Bestellnummern, Referenzen oder Profile verlangen.
• Sie ersetzt keine Steuerberatung. Ob eine Rechnung dem Steuerrecht eines Landes genügt, ist eine andere Frage als die Konformität zur EN 16931.
• Sie sagt nichts über den Transportweg. Eine gültige Datei, die im falschen Postfach landet oder auf einem Kanal ankommt, den der Empfänger nicht liest, ist so unbezahlt wie eine ungültige.

Häufige Fragen

Muss ich die XML erst aus dem PDF herauslösen?

Nein. Laden Sie das PDF hoch, wie es ist. Das Herauslösen und Wiedereinpacken verändert genau den Teil, den die Containerprüfung beurteilt — Sie würden am Ende ein anderes Dokument prüfen als das, das Ihr Empfänger bekommt.

Der Bericht zeigt Hinweise, aber keine Fehler. Darf ich versenden?

Ja. Ein Hinweis bedeutet „ungewöhnlich, aber zulässig“, und sehr oft stammt er aus einer nationalen Ausprägung, die auf Ihr Dokument gar nicht angewandt werden muss. Lesen Sie ihn einmal, und versenden Sie.

Warum meldet jede meiner ZUGFeRD-Rechnungen BR-DE-21?

Weil diese Regel prüft, ob die Kennung in BT-24 die von XRechnung ist. Bei einer ZUGFeRD-Rechnung ist sie es nicht — und soll es nicht sein. Die Meldung ist kein Mangel Ihrer Datei; wir rechnen sie in unserem Bericht bereits heraus.

Kann ich eine Rechnung prüfen, die ich längst versendet habe?

Ja, und in zwei Fällen lohnt es sich: wenn ein Empfänger reklamiert und Sie wissen wollen, ob es an der Datei liegt, und stichprobenartig nach jeder Änderung an Vorlagen oder Stammdaten. Eine bereits versendete Rechnung wird dadurch nicht verändert.

Der Bericht ist sauber, der Empfänger lehnt trotzdem ab. Was nun?

Dann liegt die Anforderung außerhalb der Norm. Die häufigsten drei: eine fehlende Bestell- oder Referenznummer, ein bestimmtes verlangtes Profil, oder ein Kanal, über den eingereicht werden muss. Fragen Sie nach dem Ablehnungsgrund im Wortlaut — er nennt fast immer das Feld.

Wie prüfe ich eine reine XRechnung?

Genauso: Die XML-Datei hochladen. Es gibt keinen Container, der Bericht beginnt bei der Schemaschicht, und die deutschen Zusatzregeln BR-DE-* gelten hier vollständig, einschließlich der Leitweg-ID bei Behörden.

Woran erkenne ich, gegen welchen Stand geprüft wurde?

Ein brauchbarer Bericht nennt sein Regelwerk. Unserer prüft gegen die Schematron-Regeln der EN 16931 und die Formatregeln von ZUGFeRD beziehungsweise Factur-X; Grundlage ist Mustang 2.26.0 vom 25. August 2026. Die aktuelle Formatversion ist ZUGFeRD 2.5.2 / Factur-X 1.09.2 und gilt seit dem 1. September 2026.

Wird meine Rechnung gespeichert?

Auf der öffentlichen Prüfseite nicht. Die Datei existiert als temporärer Upload für die Dauer der Prüfung und wird mit dem Ende der Anfrage gelöscht. Wer einen Verlauf seiner Prüfungen behalten möchte, findet ihn im Konto.

Kurz zusammengefasst

• Die Datei so hochladen, wie sie ist — nicht entpacken, nicht neu speichern.
• Von oben nach unten lesen: Container, Schema, Geschäftsregeln. Ein Fehlschlag oben macht alles darunter unzuverlässig.
• Fehler und Hinweise trennen, bevor Sie irgendetwas ändern. BR-DE-21 gehört auf jede ZUGFeRD-Rechnung.
• Mehrere Befunde haben oft eine Ursache. Erst die Ursache suchen, dann rechnen.
• Im Quellsystem korrigieren, nie in der XML — sonst widersprechen sich Seite und Daten, und maßgeblich sind die Daten.
• Nach jeder Korrektur erneut prüfen, und bei eingehenden Rechnungen Seite und XML vergleichen.

Eine Datei hier prüfen

Unser Validator durchläuft alle drei Schichten auf derselben quelloffenen Grundlage, auf die sich die Branche geeinigt hat — dem Mustang-Projekt — und meldet jeden Befund mit Regelcode, Schweregrad und Fundstelle. Er ist kostenlos und verlangt keine Anmeldung: Sie laden die Datei hoch und bekommen den Bericht. Je Datei gelten 5 MB, pro Stunde und Absender ein Dutzend Prüfungen — genug für den Alltag und knapp genug, um die Seite nicht an Skripte zu verlieren. Hochgeladene Dateien werden nicht gespeichert: Das Dokument existiert als temporäre Upload-Datei für die Dauer der Prüfung und wird mit dem Ende der Anfrage gelöscht.