Auf dieser Seite

ZUGFeRD ist ein Hybridformat: eine einzige PDF/A-3-Datei enthält zwei vollständig unabhängige Rechnungsrepräsentationen – das sichtbare PDF und ein eingebettetes XML nach dem UN/CEFACT CII-Schema. Beide können identische Daten enthalten. Sie müssen es aber nicht. Das ist das technische Fundament der ZUGFeRD-Hybrid-Falle.

Dieser Artikel richtet sich an ERP-Berater, IT-Verantwortliche und Steuerberater mit technischem Hintergrund. Der Kontext für Entscheider und Buchhalter steht auf der Übersichtsseite zur ZUGFeRD-Hybrid-Falle, einem Teil der Lösungen im Überblick.

1. Warum das XML steuerlich Vorrang hat

EN 16931 – die Norm

Die europäische Norm EN 16931-1 definiert das semantische Datenmodell für elektronische Rechnungen. ZUGFeRD 2.x implementiert dieses Modell in der CII-Syntax (Cross Industry Invoice). Die Norm selbst schreibt vor, dass das strukturierte Datum das rechtsverbindliche Rechnungsdatum ist – die visuelle Darstellung ist nachrangig.

BMF-Schreiben vom 15. Oktober 2025 – klare Aussage

Das BMF-Schreiben zur obligatorischen E-Rechnung vom 15.10.2025 stellt für hybride Formate ab ZUGFeRD 2.0.1 klar: Weichen die Daten im XML-Datensatz von der sichtbaren PDF-Darstellung ab, ist ausschließlich der XML-Datensatz steuerlich maßgebend – Stand: 01/2026. Der Vorsteuerabzug wird aus dem strukturierten Teil abgeleitet; eine reine PDF-Ablage reicht für GoBD-konforme Archivierung nicht mehr aus.

Praktische Konsequenz: Wenn ein Lieferant eine ZUGFeRD-Rechnung mit manipuliertem XML liefert, buchen und zahlen Ihre Systeme anhand der XML-Werte – steuerlich ist das der gültige Beleg.

ZUGFeRD 2.4 – kein Fix für das strukturelle Problem

ZUGFeRD 2.4 ist seit dem 15.01.2026 in Kraft. Die neue Version setzt das BMF-Schreiben 15.10.2025 um und präzisiert einzelne Profilregeln. Das hybride Grundprinzip – PDF und XML sind unabhängige Dateiteile ohne kryptografische Bindung – bleibt in Version 2.4 strukturell unverändert. Kein Profil erzwingt eine digitale Signatur über beide Schichten. Das Konsistenzrisiko existiert weiterhin. Wer auf ZUGFeRD 2.4 umgestellt hat, braucht trotzdem einen expliziten Abgleichschritt.

2. Wie Banking- und ERP-Systeme das XML lesen

Der blinde Fleck in der Verarbeitung

Banking-Software (DATEV Unternehmen online, Lexoffice, sevDesk, ELBA und vergleichbare) ermöglicht es, eine ZUGFeRD-Datei per Drag-and-drop hochzuladen oder aus einem Postfach zu importieren. Die Software liest dann automatisch aus dem eingebetteten XML:

  • IBAN (Zahlungsziel)
  • Fälliger Betrag (DuePayableAmount)
  • Verwendungszweck / Referenz
  • Belegtypcode (Rechnung vs. Gutschrift)

Der Sachbearbeiter sieht auf seinem Bildschirm das PDF. Er prüft den Lieferantennamen, den Rechnungsbetrag, vielleicht das Datum – und klickt auf „Zahlung freigeben". Was tatsächlich in der Zahlungsanweisung steht, haben die Systemfelder aus dem XML gezogen. Die offizielle ZUGFeRD-FAQ warnt wörtlich: „due to possible fraud please do not check e.g. only the PDF and then pay the XML version."

Die relevanten XML-Pfade (CII-Format)

ZUGFeRD verwendet CII (UN/CEFACT Cross Industry Invoice) mit den Namensräumen rsm und ram. Die sicherheitsrelevanten Felder liegen an folgenden XPath-Positionen:

IBAN (BT-84):

/rsm:CrossIndustryInvoice
  /rsm:SupplyChainTradeTransaction
    /ram:ApplicableHeaderTradeSettlement
      /ram:SpecifiedTradeSettlementPaymentMeans
        /ram:PayeePartyCreditorFinancialAccount
          /ram:IBANID

Fälliger Betrag (BT-115):

/rsm:CrossIndustryInvoice
  /rsm:SupplyChainTradeTransaction
    /ram:ApplicableHeaderTradeSettlement
      /ram:SpecifiedTradeSettlementHeaderMonetarySummation
        /ram:DuePayableAmount

Belegtypcode (BT-3):

/rsm:CrossIndustryInvoice
  /rsm:ExchangedDocument
    /ram:TypeCode

380 = Handelsrechnung (Forderung), 381 = Gutschrift (Guthaben). Die Zahlungsart (BT-81, SpecifiedTradeSettlementPaymentMeans/TypeCode) enthält 58 für SEPA Credit Transfer.

3. Angriffsvarianten – was dokumentiert ist

Die folgende Einordnung folgt dem Bericht des Linux Magazins (04/2025) über eine Designschwächen-Meldung an das BSI durch einen IT-Sicherheitsforscher (eingereicht Februar 2025; ein BSI-Advisory wurde bis Stand 06/2026 nicht veröffentlicht). Alle aufgeführten Varianten sind mit einem einfachen Hex-Editor oder XML-Editor umsetzbar – es sind keine Spezialkenntnisse erforderlich; ob und wie häufig sie aktiv ausgenutzt werden, ist öffentlich nicht belegt.

Variante 1 – IBAN-Austausch

Das PDF zeigt die korrekte IBAN des Lieferanten. Im XML-Block PayeePartyCreditorFinancialAccount/IBANID steht eine fremde IBAN. Banking-Software befüllt die Zahlungsmaske aus dem XML; der Sachbearbeiter sieht im PDF-Preview die richtige IBAN und gibt frei. Die Überweisung landet auf dem falschen Konto.

Analogfall aus der Rechtsprechung: Das OLG Schleswig hat IBAN-Manipulation über manipulierte E-Mail-Rechnungen beurteilt – kein ZUGFeRD-Urteil, aber das Angriffsmuster ist strukturell identisch (zitiert im ELSTER-Anwenderforum).

Variante 2 – Betrag (DuePayableAmount)

Im PDF ist der Gesamtbetrag korrekt. Im XML-Feld DuePayableAmount steht ein abweichender Wert – geringfügig erhöht (schwer zu entdecken) oder stark erhöht (bei Nichtprüfung der Zahlung). ERP-Systeme, die Zahllauf-Dateien direkt aus dem XML-Import erzeugen, übernehmen den XML-Wert ohne Rückfrage.

Zusatzrisiko: GrandTotalAmount (BT-112, Gesamtsumme inkl. MwSt.) und DuePayableAmount (BT-115, fälliger Betrag) sind separate Felder. Eine Manipulation nur in BT-115 bei unverändertem BT-112 fällt im normalen Buchungsprozess selten auf.

Variante 3 – Belegtypcode 380 → 381 (theoretisch)

Wird ExchangedDocument/TypeCode von 380 (Rechnung) auf 381 (Gutschrift) geändert, interpretiert ein ERP-System den Beleg als eingehende Gutschrift statt als Verbindlichkeit. Je nach System bucht es automatisch: Lieferant bekommt keinen Zahlungsauftrag, stattdessen entsteht eine Forderung gegenüber dem Lieferanten – oder der Betrag wird direkt als Guthaben verbucht und verrechnet.

Diese Variante ist theoretisch beschrieben und im Sicherheitsforscher-Bericht erwähnt. Ein belegter Einzelfall aus der Praxis liegt nicht vor. Dennoch: ERP-Systeme, die den Belegtypcode aus dem XML beziehen und keine manuelle Gegenprüfung erzwingen, sind strukturell anfällig.

Variante 4 – Fälligkeitsdatum

SpecifiedTradePaymentTerms/DueDateDateTime (BT-9) kann auf ein Datum in der Vergangenheit gesetzt werden. Systeme mit automatischer Fälligkeitssteuerung lösen die Zahlung sofort aus, ohne dass ein Sachbearbeiter die Abweichung zum PDF-Fälligkeitsdatum bemerkt.

4. PDF↔XML-Abgleich implementieren

FeRD (Forum elektronische Rechnung Deutschland) empfiehlt ausdrücklich, „eigene Prüfmechanismen zur Sicherstellung der inhaltlichen Identität der beiden Rechnungen einzuführen" – eine Aufforderung, die implizit bestätigt: der Standard selbst liefert diese Prüfung nicht mit.

Architektur des Prüfschritts

Ein vollständiger Abgleich vor dem Zahllauf benötigt drei Komponenten:

  1. XML-Extraktion – das eingebettete XML aus dem PDF/A-3-Container lesen
  2. PDF-Textextraktion / OCR – die relevanten Felder aus der visuellen PDF-Schicht extrahieren
  3. Feldvergleich – die Werte gegeneinander halten; bei Abweichung: Stopp und Alert

Tooling und Bibliotheken

Java – Mustang (Open Source)

Mustangproject ist die meistgenutzte Open-Source-Bibliothek für ZUGFeRD/Factur-X in Java (Apache-Lizenz, Maven-verfügbar). Sie ermöglicht das Extrahieren des eingebetteten XML aus einem PDF sowie das Parsen aller Rechnungsfelder über eine typisierte IExportableTransaction-Schnittstelle.

ZUGFeRDImporter importer = new ZUGFeRDImporter(inputStream);
String ibanXml   = importer.getIBAN();          // PayeePartyCreditorFinancialAccount/IBANID
BigDecimal betrag = importer.getAmount();       // DuePayableAmount
// TypeCode (BT-3): kein typisierter Getter; via XPath aus dem rohen XML:
// XPath: /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:TypeCode
// String rawXml = importer.getUTF8(); // dann XPath-Abfrage gegen rawXml

Für eigene XPath-Abfragen gibt importer.getUTF8() den rohen XML-String zurück; direktes XPath gegen den geparsten DOM ist dann der robustere Weg.

Python – factur-x

Die PyPI-Bibliothek factur-x (fork/nachfolger von invoice2data) liest ZUGFeRD- und Factur-X-PDFs und liefert das XML als bytes:

from facturx import get_facturx_xml_from_pdf

xml_bytes = get_facturx_xml_from_pdf(open("rechnung.pdf", "rb"))

Anschließend parsen mit lxml und XPath wie oben angegeben.

PDF-Textseite – Apache PDFBox / pdfminer

Für den Vergleich mit dem PDF-Text: Apache PDFBox (PDFTextStripper) extrahiert den sichtbaren Text seitenweise. Dann reguläre Ausdrücke auf IBAN-Muster (DE\d{20}) und Betragsfelder anwenden. Das Ergebnis ist fehleranfälliger als der XML-Wert (Zeilenumbrüche, Tabellen, Sonderzeichen) – reicht aber, um grobe Abweichungen zuverlässig zu erkennen.

Welche Felder vergleichen?

Priorität XML-Feld (XPath, verkürzt) BT Vergleich mit PDF
Kritisch PayeePartyCreditorFinancialAccount/IBANID BT-84 IBAN-Regex im PDF-Text
Kritisch DuePayableAmount BT-115 Betrag im PDF-Text (Toleranz ± 0,01 EUR)
Kritisch ExchangedDocument/TypeCode BT-3 Textmarker „Rechnung" vs. „Gutschrift"
Hoch DueDateDateTime BT-9 Fälligkeitsdatum im PDF
Mittel GrandTotalAmount BT-112 Gesamtbetrag im PDF
Mittel SellerTradeParty/Name BT-27 Absendername im PDF

Prüfschritt im Zahllauf – empfohlene Sequenz

  1. ZUGFeRD-PDF empfangen (SMTP, Postfach, Netzlaufwerk)
  2. XML extrahieren – prüfen, ob überhaupt ein factur-x.xml-Attachment im PDF/A-3-Stream vorhanden ist (fehlendes XML = keine E-Rechnung)
  3. Schema-Validierung gegen CII-XSD (kostenlos über KoSIT-Validator)
  4. Kritische Felder aus XML extrahieren
  5. PDF-Textextraktion – kritische Felder aus PDF-Text extrahieren
  6. Feldvergleich – bei Abweichung in Priorität „Kritisch": Beleg in manuelle Prüfung; kein automatischer Zahllauf
  7. Log-Eintrag mit Zeitstempel, Dateiname, abweichendem Feld, XML-Wert, PDF-Wert
  8. Erst nach positivem Abgleich: Weiterleitung in Zahllauf / ERP-Buchung

5. Grenzen des Abgleichs

OCR-basierter PDF-Textabgleich ist kein kryptografischer Beweis. Er erkennt grobe Abweichungen zuverlässig, aber nicht alle denkbaren Manipulationen – zum Beispiel einen minimal veränderten Betrag in einem PDF mit komplexem Tabellenlayout. Eine vollständige Absicherung würde eine digitale Signatur über beide Schichten erfordern; das ist in keinem ZUGFeRD-Profil (auch nicht 2.4) verpflichtend.

Die ZUGFeRD-FAQ empfiehlt zusätzlich den Abgleich gegen Stammdaten: „whitelisted bank details" – also eine geführte Liste der bekannten Lieferanten-IBANs. Wer nur Zahlungen an bekannte IBANs freigibt, reduziert das Risiko unabhängig vom PDF/XML-Abgleich erheblich. Stammdaten-Abgleich und PDF/XML-Konsistenzprüfung ergänzen sich.

Weiterführende Ressourcen

Einbindung in den Rechnungseingang

Der Abgleichschritt ist kein Einmalaufwand – er gehört als fester Validierungsschritt in die Eingangsrechnungsverarbeitung, idealerweise als Middleware-Komponente zwischen Postfachimport und ERP-Übergabe. Wer den Schritt manuell nachrüstet, verlängert den Prüfprozess; wer ihn automatisiert, hat ein dokumentierbares Kontrollsystem.

Der Dienst auf liqui.de implementiert diesen Abgleich automatisch im Rechnungseingang: IBAN, Betrag und Belegtypcode werden aus dem XML extrahiert, gegen die PDF-Schicht gehalten und bei Abweichung vor der Weitergabe in den Zahllauf markiert. Das Ergebnis fließt direkt in die Cashflow-Sicht aus Belegen ein – mit dem sicheren XML-Wert als Datenbasis, nicht mit dem, was im PDF steht.

Weitere Hintergründe zum ZUGFeRD-Format und seinen Profilen: ZUGFeRD und Factur-X erklärt.