Rechnungsbetrug per E-Mail technisch abwehren

Auf dieser Seite

• SMTP: kein Authentifizierungsprotokoll by Design
• Die drei Säulen der E-Mail-Authentifizierung
• SPF: Sender Policy Framework
• DKIM: DomainKeys Identified Mail
• DMARC: Domain-based Message Authentication, Reporting and Conformance
• Domain-Lookalike: der unterschätzte Angriffsvektor
• ZUGFeRD-PDF-Manipulation: wenn PDF und XML auseinanderfallen
• Quishing: QR-Codes als Vehikel für Zahlungsumleitungen
• Peppol als identitätsgeprüfter Transportkanal
• ERP-Eingangskontrollen: IBAN-Whitelist, 3-Wege-Abgleich, Dublettenkontrolle
• IBAN-Whitelist im Kreditorenstamm
• 3-Wege-Abgleich (Three-Way-Match)
• Dublettenkontrolle
• Innerbetriebliches Kontrollverfahren (IKV) nach §14 UStG
• Verification of Payee seit Oktober 2025
• Abwehr-Ebenen im Überblick
• Zum Weitergeben an Ihren ERP-Berater

E-Mail wurde in den 1970er-Jahren entworfen, ohne Authentifizierungskonzept. Das Absenderfeld From: ist bis heute frei beschreibbar. Wer das weiß, versteht, warum Business Email Compromise (BEC) laut FBI IC3 Annual Report 2026 (PDF) im Jahr 2025 weltweit einen Schaden von 3,04 Milliarden US-Dollar verursacht hat. Dieser Artikel richtet sich an IT-Verantwortliche, ERP-Berater und Steuerberater, die den Rechnungseingang technisch absichern wollen. Der Überblick für Entscheider und Einkaufsleiter steht auf der Übersichtsseite gefälschte Rechnungen erkennen.

---

SMTP: kein Authentifizierungsprotokoll by Design

Das Simple Mail Transfer Protocol (SMTP, RFC 5321) kennt zwei Adressfelder, die unabhängig voneinander sind:

• Envelope-From (MAIL FROM): die technische Absenderadresse für Bounces und Routing. Für den Empfänger unsichtbar.
• Header-From (From:): die angezeigte Absenderadresse im Mailclient. Frei setzbar; kein Server prüft sie.

Ein Angreifer kann From: buchhaltung@bekannter-lieferant.de setzen und die Mail von einem beliebigen Server versenden. Ohne zusätzliche Mechanismen wie SPF, DKIM und DMARC hat der empfangende Mailserver keine Möglichkeit, das zu erkennen. Das ist kein Bug, sondern Designentscheidung aus einer Zeit, in der Vertrauen vorausgesetzt wurde.

BEC-Grundmuster: Angreifer recherchieren Lieferantenbeziehungen (öffentliche Handelsregistereinträge, LinkedIn, Impressum), registrieren eine täuschend ähnliche Domain und versenden Rechnungen mit geänderter IBAN, oft mit dem Hinweis „neue Bankverbindung ab sofort". Laut BKA-Infografik Rechnungsbetrug fangen Täter in fortgeschrittenen Szenarien echte E-Mails ab (Man-in-the-Mailbox), lesen laufende Korrespondenz mit und antworten im richtigen Moment.

---

Die drei Säulen der E-Mail-Authentifizierung

SPF, DKIM und DMARC sind DNS-basierte Standards. Alle Records sind öffentlich abrufbar, ohne Anmeldung und ohne Kosten. Das erlaubt es, die Mail-Sicherheit eines Lieferanten zu prüfen, bevor eine Zahlung autorisiert wird. Eine ausführliche Erklärung der einzelnen Protokolle bietet die Seite SPF, DKIM und DMARC erklärt.

SPF: Sender Policy Framework

SPF (RFC 7208) legt fest, welche IP-Adressen im Namen einer Domain E-Mails versenden dürfen. Der Record ist ein DNS-TXT-Eintrag auf der Absenderdomain:

beispiel-lieferant.de.  IN TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Grenze von SPF: SPF prüft den Envelope-From, nicht den Header-From. Ein Angreifer kann SPF bestehen und trotzdem eine gefälschte From:-Adresse anzeigen. SPF allein reicht nicht.

DKIM: DomainKeys Identified Mail

DKIM (RFC 6376) signiert ausgehende Mails kryptografisch. Die sendende Organisation hält einen privaten Schlüssel; der öffentliche Schlüssel wird als DNS-TXT-Record veröffentlicht:

selector1._domainkey.beispiel-lieferant.de.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Beim Empfang prüft der Server die Signatur im DKIM-Signature:-Header gegen den DNS-Record. Ist die Signatur gültig, wurde die Mail seit dem Versand nicht verändert. Das ist der entscheidende Punkt für ZUGFeRD: Eine DKIM-signierte Mail, deren Anhang nachträglich manipuliert wurde, verliert ihre gültige Signatur, sofern der Anhang im signierten Body-Bereich enthalten war.

Prüfung: nslookup -type=TXT selector1._domainkey.beispiel-lieferant.de oder öffentliche DKIM-Lookup-Tools.

DMARC: Domain-based Message Authentication, Reporting and Conformance

DMARC (RFC 7489) verbindet SPF und DKIM und gibt Mailservern eine Policy:

_dmarc.beispiel-lieferant.de.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel-lieferant.de"

Nur p=reject verhindert zuverlässig, dass gefälschte Mails im Posteingang landen. Ein Lieferant mit p=none hat keinen aktiven DMARC-Schutz, auch wenn der Record existiert.

Sofortprüfung per DNS: nslookup -type=TXT _dmarc.lieferant-domain.de

---

Domain-Lookalike: der unterschätzte Angriffsvektor

SPF, DKIM und DMARC schützen eine registrierte Domain vor Missbrauch durch Dritte. Sie schützen nicht vor Lookalike-Domains. Angreifer registrieren Domains wie:

• lieferant-gmbh.com statt .de
• lieferant--gmbh.de (Doppelbindestrich)
• lieferant-gmbh.de.invoice-portal.net (Subdomain-Täuschung)
• 1ieferant-gmbh.de (Zahl 1 statt Buchstabe l)

Diese Domains können vollständige SPF-, DKIM- und DMARC-Konfigurationen haben und trotzdem alle Prüfungen bestehen, weil sie technisch valide Domains sind. Der Abgleich, ob die Absenderdomain zur bekannten Lieferanten-Domain passt, muss im Kreditorenstamm oder im Eingangsrechnungs-Workflow erfolgen, nicht im Mailprotokoll.

---

ZUGFeRD-PDF-Manipulation: wenn PDF und XML auseinanderfallen

ZUGFeRD (ab Version 2.x, auch Factur-X) ist ein hybrides Format: eine PDF-Datei enthält eingebettetes XML (Dateiname factur-x.xml bzw. ZUGFeRD-invoice.xml). Beide Schichten sind unabhängig voneinander editierbar.

Der Angriffsvektor: Ein Angreifer fängt eine legitime ZUGFeRD-Rechnung per E-Mail ab, öffnet die PDF, extrahiert das XML, ändert darin das <ram:IBANID>-Element, bettet das veränderte XML wieder ein und leitet die Datei weiter. Die PDF-Ansicht zeigt weiterhin die korrekte, bekannte Rechnung des Lieferanten: Rechnungsnummer, Datum, Betrag stimmen. Nur die IBAN im maschinenlesbaren XML ist eine fremde Kontonummer.

Bankingsoftware, die ZUGFeRD-Rechnungen per Drag-and-Drop importiert (Hibiscus, StarMoney, SFirm, DATEV Unternehmen online), liest das XML und befüllt das Überweisungsformular automatisch, mit der manipulierten IBAN. Der Sachbearbeiter prüft den Betrag, der stimmt, und gibt frei.

Hintergrund zum Format: ZUGFeRD und Factur-X erklärt. Die spezifischen Sicherheitsrisiken des hybriden Formats beschreibt ZUGFeRD: die Hybrid-Falle.

Gegenmaßnahmen:

• XML-IBAN maschinell gegen die Kreditorenstamm-IBAN prüfen, bevor die Zahlung freigegeben wird.
• DKIM-Signatur der eingehenden Mail prüfen: Eine nachträglich manipulierte Anlage bricht die Signatur (wenn der Body korrekt signiert war).
• Keine automatische Übernahme von IBAN-Änderungen ohne manuelle Freigabe durch eine zweite Person.

---

Quishing: QR-Codes als Vehikel für Zahlungsumleitungen

Seit Ende 2025 ist Quishing (QR-Code-Phishing) als eigenständiger Angriffsvektor in Rechnungs-PDFs dokumentiert. Zwischen August und November 2025 hat sich die Zahl schädlicher QR-Codes laut Branchenberichten verfünffacht.

Mechanismus: In der Rechnungs-PDF befindet sich ein QR-Code, optisch gestaltet wie ein Zahlungs-QR oder ein Link zur Auftragsbestätigung. Scannt ein Mitarbeiter den Code mit dem Smartphone, gelangt er auf eine gefälschte Zahlungsseite außerhalb des Firmennetzwerks. Dort werden entweder Zugangsdaten abgefangen oder eine SEPA-Überweisung mit manipulierter IBAN initiiert.

Der entscheidende Trick: das Smartphone ist in der Regel nicht durch den Unternehmens-Proxy oder die EDR-Lösung des Firmennetzwerks geschützt. Schutzmechanismen auf dem Arbeitsrechner greifen nicht.

Quelle: QR-Code-Phishing verfünffacht sich zum Jahreswechsel (ad-hoc-news.de / Keepnet-Daten)

Gegenmaßnahmen:

• Mitarbeiter im Rechnungseingang sensibilisieren: QR-Codes in Rechnungs-PDFs grundsätzlich nicht mit privaten Smartphones scannen.
• QR-Codes in eingehenden Rechnungs-PDFs maschinell dekodieren und die enthaltene URL gegen eine Allowlist prüfen.
• Mobile Device Management (MDM) mit Proxy-Weiterleitung auch für dienstlich genutzte Privatgeräte.

---

Peppol als identitätsgeprüfter Transportkanal

Peppol (Pan-European Public Procurement Online) ist ein dezentrales Netz zertifizierter Zugangspunkte (Access Points), über das Rechnungen strukturiert und verschlüsselt übertragen werden. Im Gegensatz zu E-Mail ist die Teilnehmeridentität im Netz geprüft.

4-Corner-Modell:

Lieferant → Access Point A → Access Point B → Empfänger

Jeder Teilnehmer besitzt eine geprüfte Peppol Participant ID (z. B. 0088:4012345678901 für GLN-basierte Kennung). Der Access Point des Empfängers prüft, ob die Sender-ID mit der registrierten ID des Lieferanten übereinstimmt. Niemand kann sich als ein anderer Teilnehmer ausgeben, ohne Zugriff auf dessen zertifizierten Access Point zu haben.

Sicherheitsmerkmale im Vergleich zu E-Mail:

DATEV empfiehlt für den Rechnungsaustausch mit bekannten Lieferanten den Umstieg auf Peppol oder das deutsche Netz TRAFFIQX, das ebenfalls auf Identitätsprüfung der Teilnehmer setzt. Quelle: DATEV, E-Rechnung: Wachsam sein.

---

ERP-Eingangskontrollen: IBAN-Whitelist, 3-Wege-Abgleich, Dublettenkontrolle

Auch mit optimaler E-Mail-Absicherung braucht der Rechnungseingang eigene Kontrollen im ERP-System.

IBAN-Whitelist im Kreditorenstamm

Jeder Kreditor erhält im Stammsatz eine oder mehrere freigegebene IBANs. Jede eingehende Rechnung, deren Zahlungsziel-IBAN nicht in dieser Whitelist steht, wird automatisch blockiert und zur manuellen Prüfung weitergeleitet. Eine IBAN-Änderung ist nur über einen definierten Freigabeprozess möglich, nicht durch eine eingehende Rechnung allein.

Kritischer Punkt: Die Änderung einer IBAN im Kreditorenstamm muss denselben Vier-Augen-Prozess durchlaufen wie eine Zahlungsfreigabe. Systeme, die IBAN-Änderungen per API oder Import ohne separaten Freigabeschritt erlauben, schaffen eine Umgehung.

3-Wege-Abgleich (Three-Way-Match)

Bestellung (PO) → Wareneingang / Lieferschein → Rechnung: alle drei müssen übereinstimmen. Toleranzschwellen (z. B. ±1 % oder ±50 EUR für Rounding-Differenzen) sind zu dokumentieren. Rechnungen ohne referenzierte Bestellnummer kommen in manuelle Prüfung.

Dublettenkontrolle

Gleiche Rechnungsnummer desselben Lieferanten: automatisch blockieren. Gleicher Betrag desselben Lieferanten innerhalb von 30 Tagen: Flag zur Prüfung. Beide Prüfungen fangen Szenarien ab, in denen manipulierte Rechnungen parallel zur echten Rechnung eingereicht werden.

---

Innerbetriebliches Kontrollverfahren (IKV) nach §14 UStG

Das Umsatzsteuergesetz verlangt für jede Eingangsrechnung, dass Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit gewährleistet sind. Seit der Reform 2011 kann das durch ein innerbetriebliches Kontrollverfahren (IKV) mit verlässlichem Prüfpfad zwischen Rechnung und erbrachter Leistung erfüllt werden, ohne Pflicht zur elektronischen Signatur.

In der Praxis bedeutet das: der Abgleich Rechnung ↔ Bestellung ↔ Lieferschein (3-Wege-Abgleich) ist bereits ein IKV. Er muss dokumentiert sein. Ein Rechnungsworkflow im ERP, der Genehmigungsschritte protokolliert, erfüllt diese Anforderung.

Rechtstext: §14 UStG auf gesetze-im-internet.de

Wichtig: Das IKV schafft steuerrechtlich einen verlässlichen Prüfpfad, bietet aber keine Garantie gegen Betrug. Es dokumentiert den Prozess; die technischen Kontrollen (IBAN-Whitelist, DMARC-Prüfung, Peppol) schützen aktiv. Im Zweifel Steuerberater hinzuziehen.

---

Verification of Payee seit Oktober 2025

Seit dem 9. Oktober 2025 sind Zahlungsdienstleister in der EU verpflichtet, bei SEPA-Einzelüberweisungen zu prüfen, ob der angegebene Empfängername mit dem Kontoinhaber der IBAN übereinstimmt (Instant Payments Regulation EU 2024/886). Die Überweisung wird nicht automatisch blockiert, aber der Zahlungsauftrag erhält einen Hinweis, wenn Name und IBAN nicht übereinstimmen.

Das schließt eine spezifische Lücke: eine manipulierte IBAN, die einem fremden Kontoinhaber gehört, erzeugt jetzt vor der Ausführung eine Warnung. Die Prüfung ersetzt keine internen Kontrollen, weil sie erst am Ende des Prozesses greift, wenn die Rechnung bereits genehmigt wurde.

Quelle: VDIV: Verification of Payee ab 9. Oktober 2025 Pflicht

Hinweis zur Haftung: Ob und in welchem Umfang Banken haften, wenn VoP nicht korrekt implementiert ist, ist Stand 2026 noch nicht abschließend gerichtlich geklärt. Haftungsfragen bitte mit Rechtsberater abstimmen.

---

Abwehr-Ebenen im Überblick

---

Zum Weitergeben an Ihren ERP-Berater

Die folgende Checkliste fasst die implementierbaren Maßnahmen zusammen:

• [ ] SPF-, DKIM- und DMARC-Records aller bekannten Lieferanten-Domains dokumentieren und auf p=reject prüfen
• [ ] Lieferanten-Domains gegen Lookalike-Varianten prüfen (Tooling: DNS-Lookup, Typosquatting-Checker)
• [ ] IBAN-Whitelist im Kreditorenstamm aktivieren; Änderungsprozess mit Vier-Augen-Prinzip definieren
• [ ] 3-Wege-Abgleich im ERP aktivieren; Toleranzschwellen dokumentieren
• [ ] Dublettenkontrolle (Rechnungsnummer + Betrag) als automatische Blockierregel konfigurieren
• [ ] XML-IBAN bei ZUGFeRD/Factur-X-Rechnungen maschinell gegen Stammdaten abgleichen
• [ ] Peppol-Anbindung für Hauptlieferanten evaluieren (Access Point erforderlich)
• [ ] QR-Code-Inhalte in eingehenden PDF-Rechnungen maschinell dekodieren und prüfen
• [ ] VoP-Warnmeldungen der Hausbank in den Zahlungsfreigabeprozess integrieren
• [ ] IKV schriftlich dokumentieren (Prozessbeschreibung, Genehmigungsschritte, Archivierungspfad)

---

Der Dienst macht die Absender-Authentifizierung bekannter Lieferanten-Domains automatisch sichtbar, noch bevor eine Zahlung autorisiert wird. Mehr dazu auf der Übersichtsseite gefälschte Rechnungen erkennen.

Zum allgemeinen Sicherheitskonzept: Sicherheit auf liqui.de.