ZUGFeRD-Falle: Wenn PDF und XML nicht übereinstimmen

Eine ZUGFeRD-Rechnung sieht aus wie eine normale PDF. Sie öffnet sich im normalen PDF-Reader, zeigt das gewohnte Layout mit Logo, Anschrift und Positionen. Was viele nicht wissen: Im Hintergrund steckt eine zweite Schicht — eine eingebettete XML-Datei mit den strukturierten Rechnungsdaten. Im Normalfall enthalten beide Schichten exakt dieselben Informationen.

Im Normalfall.

In der Praxis kommt es vor, dass PDF-Inhalt und XML-Daten nicht übereinstimmen. Manchmal um Cent-Beträge, manchmal um den ganzen Bruttobetrag, in seltenen Fällen sogar um den Rechnungsempfänger. Das ist ein technisches und gleichzeitig ein steuerliches Problem — und es wird selten in der Beratung erwähnt, weil viele Anwender die XML-Schicht ohnehin nicht ansehen.

Dieser Artikel klärt, warum die Diskrepanz auftaucht, was sie rechtlich bedeutet und wie sich beide Seiten — Aussteller und Empfänger — davor schützen können.

Was die XML-Schicht eigentlich ist

Eine ZUGFeRD-Datei ist technisch ein PDF/A-3-Dokument mit einer eingebetteten XML-Datei als Anhang. Wer die PDF mit einem Standard-Viewer öffnet, sieht nur das PDF-Layout. Die XML-Datei kann mit speziellen Werkzeugen extrahiert oder direkt aus dem PDF-Anhang geöffnet werden.

Die zwei Schichten haben unterschiedliche Aufgaben:

• Die PDF-Schicht ist die menschenlesbare Darstellung. Sie kann Layout, Logos, freie Texte und visuelle Hierarchien enthalten. Sie ist das, was Buchhaltungs-Personal beim Prüfen am Bildschirm sieht.
• Die XML-Schicht ist die maschinenlesbare Datenrepräsentation nach EN 16931. Sie enthält strukturierte Felder wie BT-1 (Rechnungsnummer), BT-9 (Fälligkeitsdatum), BT-112 (Gesamtbetrag) und so weiter. Sie ist das, was Buchhaltungs-Software automatisch verarbeitet.

Eine sauber erzeugte ZUGFeRD-Datei enthält in beiden Schichten dieselben Werte. Eine PDF, in der "Rechnungsbetrag: 1.190 € brutto" steht, hat in der XML-Schicht das Feld BT-112 mit dem Wert 1190.00.

Warum es zu Diskrepanzen kommt

In den meisten Fällen sind beide Schichten konsistent — denn sie werden vom selben Tool aus denselben Datenquellen erzeugt. Die Diskrepanz entsteht typischerweise durch einen von vier Wegen.

1. Manuelle Nachbearbeitung der PDF. Ein Mitarbeiter merkt nach dem Versenden, dass die PDF einen Tippfehler enthält. Er öffnet die ZUGFeRD-Datei, ändert die PDF mit einem PDF-Editor und versendet sie erneut. Die XML-Schicht bleibt dabei unverändert — also weicht sie jetzt vom korrigierten PDF-Inhalt ab.

2. Falsche Datenquellen beim Generieren. Manche Rechnungssoftware-Lösungen erzeugen die PDF aus einem Layout-Template und die XML aus einer separaten Datenbank-Abfrage. Wenn beide Wege unterschiedliche Datenstände nutzen (zum Beispiel ein Update der Position passiert nur in einer der beiden Quellen), entsteht eine Diskrepanz.

3. Konvertierungs-Fehler bei PDF-zu-ZUGFeRD-Tools. Wer eine fertige PDF in eine ZUGFeRD-Datei umwandelt, ist auf eine korrekte Extraktion der Rechnungsdaten angewiesen. Bei OCR-Fehlern oder unklarer Strukturierung kann die extrahierte XML andere Werte enthalten als die ursprüngliche PDF. Das ist die häufigste Ursache in unserer Praxis-Pipeline.

4. Manipulation. In Einzelfällen wird die Diskrepanz bewusst herbeigeführt — etwa um eine Rechnung visuell anders darzustellen als die strukturierten Daten suggerieren. Das ist umsatzsteuerlich riskant und bei Aufdeckung mit erheblichen Konsequenzen verbunden.

In allen vier Fällen entsteht ein Dokument, das auf den ersten Blick okay aussieht, aber bei genauerer Prüfung Probleme macht.

Was das BMF-Schreiben vom 15.10.2025 dazu sagt

Das BMF hat zur ZUGFeRD-Diskrepanz im Schreiben vom 15. Oktober 2025 eine klare Position bezogen. Sinngemäß: Bei Abweichungen zwischen PDF-Darstellung und strukturiertem Datensatz gilt ausschließlich der strukturierte Teil als steuerlich verbindlicher Inhalt der Rechnung.

Das hat weitreichende praktische Konsequenzen. Wenn die PDF "Rechnungsbetrag: 1.190 €" anzeigt, die XML aber 1090.00 enthält, dann ist der steuerlich relevante Rechnungsbetrag 1.090 Euro. Der Empfänger schuldet 1.090 Euro, der Aussteller hat über 1.090 Euro abgerechnet. Die in der PDF angezeigten 1.190 Euro haben keinen Rechtswert mehr.

Das wirkt akademisch, ist aber in der Praxis ein echter Knackpunkt. Vier Konsequenzen sind besonders relevant:

1. Beim Vorsteuerabzug. Der Empfänger zieht die Vorsteuer aus dem Betrag der XML-Schicht, nicht aus dem PDF. Wenn die XML 1.090 Euro enthält, bekommt er die Umsatzsteuer aus 1.090 Euro als Vorsteuer, nicht aus den angezeigten 1.190 Euro.

2. Beim Zahlungsanspruch. Der zivilrechtliche Anspruch des Ausstellers richtet sich grundsätzlich nach der Rechnung — und die ist in der strukturierten Form. Wenn die XML 1.090 Euro enthält, kann der Aussteller umsatzsteuerlich nur 1.090 Euro fordern, nicht die im PDF angezeigten 1.190 Euro.

3. Bei der Validierung. Eine fehlerhafte Konsistenz zwischen PDF und XML ist kein direkter Validierungsfehler nach EN 16931. Schematron-Regeln prüfen die XML-Struktur, nicht die Übereinstimmung mit der PDF. Die Diskrepanz fällt also bei der technischen Validierung nicht auf. Sie muss separat geprüft werden.

4. Bei der Archivierung. Beide Schichten sind Teil derselben Datei. Wer die ZUGFeRD-Datei revisionssicher archiviert, hat automatisch beide Schichten. Im Streitfall können beide Versionen herangezogen werden — was die XML-Schicht steuerlich verbindlich macht, schließt die PDF als Beweismittel für andere Zwecke (zum Beispiel zivilrechtlich) nicht aus.

Wie sieht eine echte Diskrepanz aus?

Drei reale Beispiele aus unserer Pipeline, anonymisiert.

Beispiel 1: Rundungsfehler im Bruttobetrag. Eine Handwerkerrechnung mit drei Positionen zu je 33,33 Euro netto. In der PDF stand: Netto 99,99 Euro, USt 19,00 Euro, Brutto 118,99 Euro. In der XML stand: Netto 99,99, USt 19,00, Brutto 119,00. Differenz: ein Cent. Erscheint banal, aber ein Validator schlägt bei BR-CO-17 zu, weil die Summe in der XML nicht aufgeht (99,99 + 19,00 = 118,99, nicht 119,00). Hier war die XML falsch, die PDF korrekt.

Beispiel 2: Falscher Skonto-Abzug. Eine Rechnung mit 5.000 Euro brutto und 2% Skonto-Hinweis. In der PDF wurde der Skonto-Betrag korrekt mit 100 Euro angezeigt. In der XML wurde der Skonto im strukturierten Feld BT-20 aber mit dem Format #SKONTO#TAGE=14#PROZENT=2.50# (also 2,5% statt 2%) eingespielt. Die PDF zeigte 100 Euro Skonto, die XML implizierte 125 Euro. Bei automatischer Verarbeitung auf Empfängerseite hätte der Empfänger 125 Euro abgezogen statt 100.

Beispiel 3: Falsche IBAN durch OCR-Fehler. Eine PDF-zu-ZUGFeRD-Konvertierung las die IBAN DE89370400440532013100 als DE89370400440532013l00 (Kleinbuchstabe l statt Ziffer 1) aus der PDF. Die PDF zeigte die korrekte IBAN, die XML enthielt eine ungültige Variante. Bei manueller Überweisung kein Problem (das Buchhaltungs-Personal sieht die PDF). Bei automatischer Zahlungsanweisung aus dem ERP heraus — Geld geht nirgendwohin, weil die IBAN-Prüfsumme nicht stimmt.

Alle drei Beispiele sind in der Form jeweils nicht durch reine EN-16931-Validierung erkennbar. Es braucht eine zusätzliche Konsistenzprüfung zwischen PDF-Inhalt und XML-Daten.

Wie man als Empfänger das prüft

Drei Möglichkeiten, je nach Aufwand und Volumen.

Manuell, mit einem XRechnungs-Viewer. Wer eine ZUGFeRD-Datei empfängt, kann mit einem Viewer wie unserem XRechnungs-Viewer die eingebettete XML auslesen lassen. Das Tool rendert die XML-Inhalte in eine lesbare Darstellung, die direkt mit der PDF-Schicht verglichen werden kann. Bei wenigen Rechnungen pro Monat ein praktikabler Weg.

Halbautomatisch, mit Validierungsbericht. Manche Validierungs-Tools (auch unser eigener E-Rechnungs-Validator) prüfen optional die Konsistenz von PDF und XML. Das ist nicht Teil der EN-16931-Standardvalidierung, aber eine zusätzliche Prüfschicht, die viele Tools mittlerweile anbieten.

Vollautomatisch, im Empfangs-Workflow. Wer regelmäßig E-Rechnungen empfängt, sollte eine Lösung wählen, die die Konsistenz im Hintergrund prüft. Belegschmiede macht das bei jeder eingehenden ZUGFeRD-Rechnung automatisch und meldet, wenn PDF und XML abweichen. Das ist der entspannteste Weg, weil keine manuelle Prüfung pro Rechnung nötig ist.

Wie man als Aussteller das verhindert

Wer selbst ZUGFeRD-Rechnungen erzeugt, kann durch drei Maßnahmen die Diskrepanz vermeiden.

1. Beide Schichten aus derselben Quelle erzeugen. Die zuverlässigste Methode: PDF und XML stammen vom selben Tool, aus derselben Datenquelle, im selben Erzeugungslauf. Das ist bei moderner Rechnungssoftware Standard, bei selbstgebauten Workflows nicht immer der Fall.

2. Keine nachträgliche PDF-Bearbeitung. Wenn eine ZUGFeRD-Datei generiert wurde, sollte sie nicht mehr im PDF-Editor angefasst werden. Bei einem Fehler ist die saubere Lösung eine neue Generierung, nicht eine Korrektur am fertigen Dokument. Eine Korrektur am PDF macht die XML inkonsistent.

3. Vor dem Versand Konsistenz prüfen. Wer auf Nummer sicher gehen will, lässt jede ausgehende ZUGFeRD-Datei durch einen Validator laufen, der nicht nur die EN-16931-Konformität, sondern auch die PDF-XML-Konsistenz prüft. Das ist eine zusätzliche Vorsichtsmaßnahme, die bei Rechnungen mit höherem Beträgen oder kritischen Mandanten Sinn macht.

Was Belegschmiede macht

Bei jeder ZUGFeRD-Rechnung, die durch unseren Konvertierungs- oder Validierungs-Workflow läuft, prüfen wir automatisch:

• Ob die XML-Schicht der EN 16931 und den deutschen CIUS-Regeln entspricht (Schematron-Validierung)
• Ob der ausgewiesene Bruttobetrag im PDF mit dem strukturierten Wert in BT-112 übereinstimmt
• Ob IBAN, Steuernummer, USt-IdNr. und Rechnungsnummer in beiden Schichten konsistent sind
• Ob der Skonto-Hinweis im freien PDF-Text mit dem strukturierten Feld BT-20 übereinstimmt

Bei Auffälligkeiten melden wir das vor dem Versand (bei ausgehenden Rechnungen) oder beim Empfang (bei eingehenden Rechnungen). Der Nutzer kann entscheiden, ob er die Rechnung trotzdem akzeptiert oder zur Klärung an den Aussteller zurückgibt.

Was zu tun ist, wenn eine Diskrepanz auftaucht

Wenn Empfänger eine Diskrepanz zwischen PDF und XML feststellen, ist die saubere Reaktion:

1. Beim Aussteller nachfragen. Welche Schicht ist die korrekte? Ist die PDF richtig und die XML falsch? Oder umgekehrt? Das klärt die Buchhaltung in der Regel innerhalb von Stunden.

2. Korrigierte Rechnung anfordern. Der Aussteller sollte eine korrigierte E-Rechnung schicken, in der PDF und XML konsistent sind. Wie das im Detail funktioniert (Storno oder Rechnungskorrektur), haben wir im Storno-Artikel beschrieben.

3. Original behalten. Die ursprüngliche, fehlerhafte ZUGFeRD-Datei muss trotzdem revisionssicher archiviert werden — sie war Bestandteil der ursprünglichen Korrespondenz und kann bei einer späteren Prüfung relevant sein.

Was die Diskrepanz strategisch bedeutet

Die ZUGFeRD-Diskrepanz ist einer der Punkte, bei denen die E-Rechnung über die klassische PDF-Rechnung hinausgeht. In der PDF-Welt war das Dokument selbst die Quelle der Wahrheit. In der ZUGFeRD-Welt ist es die XML-Schicht — auch wenn niemand sie sieht.

Wer die E-Rechnung als reines Format-Update versteht ("statt PDF jetzt ZUGFeRD"), übersieht diese Verschiebung. Wer sie als Datenmodell-Update versteht ("die strukturierten Daten sind das Original"), ist besser auf die Praxis vorbereitet.

In der Beratung mit Mandanten oder Kunden lohnt sich der Hinweis, dass die XML-Schicht der eigentliche Inhalt ist. Wer in einer Mandantenvereinbarung oder einem Liefervertrag konkret regelt, was bei Abweichungen gilt, kann sich spätere Diskussionen sparen.

Das BMF-Schreiben vom 15. Oktober 2025 ist hier die zentrale Referenz. Wer sich mit ZUGFeRD ernsthaft auseinandersetzt, sollte dieses Schreiben mindestens überflogen haben. Mehr dazu im nächsten Artikel über die Praxis-Auswirkungen des BMF-Schreibens vom 15.10.2025.