PDF und XML einer E-Rechnung abgleichen: Warum der Blick ins PDF nicht reicht

Thema

VB.NET

Business Terms

BT-112 Rechnungsgesamtbetrag einschließlich Umsatzsteuer BT-115 Fälliger Zahlungsbetrag BT-84 Kennung des Zahlungskontos BT-109 Rechnungsgesamtbetrag ohne Umsatzsteuer BT-110 Gesamtbetrag der Umsatzsteuer BT-1 Rechnungsnummer

Codebeispiele

VB.NET

Veröffentlicht

12. November 2026

Eine ZUGFeRD-Rechnung besteht aus zwei Teilen: dem PDF, das Menschen lesen, und dem eingebetteten XML, das Programme verarbeiten. Rechtlich zählt das XML. Geprüft und freigegeben wird in vielen Unternehmen aber, was im PDF steht. Niemand stellt sicher, dass beide Teile dasselbe sagen.

Kurz: Bei einer hybriden E-Rechnung ist der strukturierte Teil – das XML – maßgeblich. Weicht das sichtbare PDF davon ab, sieht der Sachbearbeiter einen anderen Betrag oder eine andere Bankverbindung, als die Buchhaltungssoftware verarbeitet. Das kann ein Versehen sein oder ein Betrugsversuch. Ab Version 11.0.0.19 prüft das Aloaha ZUGFeRD SDK mit CheckPDFTextAgainstXML in einem Aufruf, ob Rechnungsbetrag, Zahlbetrag, Rechnungsnummer und IBAN des XML auch auf den PDF-Seiten gedruckt sind.

Warum das wichtig ist

Nach dem Schreiben des Bundesfinanzministeriums vom 15. Oktober 2024 (Rn. 31) sind bei einem hybriden Format wie ZUGFeRD die Rechnungsdaten im XML der führende Teil. Weichen PDF und XML voneinander ab, gehen die Daten des XML vor. Zeigt das PDF andere Rechnungsangaben, kann es als weitere Rechnung gelten, für die § 14c UStG zu prüfen ist; der Vorsteuerabzug ist nur aus dem strukturierten Teil möglich (Rn. 32). Das PDF ist also nur ein Abbild für das menschliche Auge.

In der Praxis läuft es oft umgekehrt: Die Rechnung kommt per E-Mail, jemand öffnet das PDF, prüft Betrag und Lieferant und gibt frei. Die Software liest danach das XML ein und überweist, was dort steht. Zwischen beiden Schritten gibt es keine Kontrolle.

Eine formale Prüfung gegen EN 16931 findet solche Fälle nicht: Das XML kann für sich völlig gültig sein. Es passt nur nicht zum PDF.

Die Prüfung: CheckPDFTextAgainstXML

Die Funktion liest das eingebettete XML und den Text der PDF-Seiten und sucht die wichtigsten Werte des XML im gedruckten Text. Beträge werden in allen üblichen Schreibweisen erkannt (1.234,56 – 1,234.56 – 1234,56 – 1 234,56).

' VB.NET
Dim key As String = "IHR-LIZENZSCHLUESSEL"
Dim alo As New Aloaha_ZUGFeRD.XML(key)

Select Case alo.CheckPDFTextAgainstXML("C:\Eingang\RE-4711.pdf", key)
    Case 1
        ' passt: weiter in die Verarbeitung
    Case 2
        ' Warnung: Bericht einem Menschen vorlegen
        System.IO.File.WriteAllText("C:\Klaerung\RE-4711.txt", alo.PDFTextCheckReport)
    Case 0
        ' Abweichung: Zahlung sperren, beim Lieferanten nachfragen
        System.IO.File.WriteAllText("C:\Gesperrt\RE-4711.txt", alo.PDFTextCheckReport)
    Case Else
        ' nicht prüfbar: Grund steht in PDFTextCheckReport bzw. LastError
End Select

Der Bericht in PDFTextCheckReport nennt jeden verglichenen Wert in einer Zeile:

PDF text check: WARNING - the payable amount is printed, but 1 other value(s) of the XML differ from the PDF.
OK       BT-112 grand total 1190.00: printed as 1.190,00
OK       BT-109 net total 1000.00: printed as 1.000,00
OK       BT-110 VAT total 190.00: printed as 190,00
OK       BT-1 invoice number RE-1001: printed
WARNING  BT-84 IBAN DE02120300000000202051: not printed - the PDF prints another IBAN: DE89370400440532013000
Rough check only: a value counts as printed when it appears anywhere in the page text.

Die Prüfung läuft lokal. Die Rechnung verlässt das Haus nicht.

Ohne Programmierung: in der GUI und im PDF Viewer

Dieselbe Prüfung steckt ab Version 11.0.0.19 in unseren Programmen. In der Aloaha ZUGFeRD GUI läuft sie bei E-Rechnung prüfen… für jede PDF mit, und nach dem Zusammenführen von XML und PDF warnt die GUI, wenn beide nicht zusammenpassen. Der Aloaha ZUGFeRD PDF Viewer zeigt beim Öffnen einer ZUGFeRD-PDF das Ergebnis als farbigen Hinweis in der Werkzeugleiste.

Was der Test mit echten Rechnungen gezeigt hat

Wir haben die Vergleichslogik vor der Veröffentlichung mit 15 echten ZUGFeRD-Rechnungen aus unserem Support geprüft:

• 12 Rechnungen: Ergebnis 1, Betrag und Rechnungsnummer stehen im PDF.
• 2 Rechnungen: Ergebnis 2. Bei einer druckt das PDF zwei andere Bankverbindungen als das XML, bei der anderen fehlt die Rechnungsnummer im Text.
• 1 Rechnung: Ergebnis 0. Das XML stammte aus einem Beispiel, das PDF war eine echte Rechnung – kein Betrag stimmte überein.

Drei von fünfzehn Dateien verdienten also einen zweiten Blick, und keine davon wäre bei einer reinen Formatprüfung aufgefallen.

Was die Prüfung nicht kann

• Sie ist eine grobe Prüfung. Ein Wert gilt als gedruckt, wenn er irgendwo im Seitentext steht – nicht unbedingt neben dem Wort „Gesamtbetrag“.
• Gescannte PDFs ohne Text sind nicht prüfbar (Ergebnis -1). Das ist kein Hinweis auf Betrug.
• Bankverbindung im Briefpapier als Bild: Dann findet die Prüfung keine IBAN und gibt nur einen Hinweis.
• Kein Ersatz für die Formatprüfung und nicht für den Abgleich mit den Stammdaten. Ob die IBAN zum Lieferanten gehört, weiß nur Ihre Buchhaltung.

Empfohlener Ablauf im Rechnungseingang

1. Format prüfen: ValidateInvoicePDF – ist die Rechnung nach EN 16931 gültig?
2. PDF und XML abgleichen: CheckPDFTextAgainstXML – sagt das PDF dasselbe wie das XML?
3. Daten einlesen: FillZUGFeRD_Structure – Beträge, USt-IdNr. und IBAN aus dem XML übernehmen.
4. Mit den Stammdaten vergleichen: Stimmen USt-IdNr. und IBAN mit dem bekannten Lieferanten überein? Siehe E-Rechnung von neuem Absender: echt oder Phishing?

Business Terms in diesem Artikel: BT-112 BT-115 BT-84 BT-109 BT-110 BT-1