Auf dieser Seite
- Das Format: keine erzwungene Signatur in EN 16931
- Die relevanten Felder für Angreifer
- Angriffsvektor 1: IBAN-Swap über abgefangene E-Mail
- Angriffsvektor 2: Belegtypcode-Manipulation (380 → 381)
- Transportweg: E-Mail versus Peppol
- E-Mail-Versand (unkontrollierter Transportweg)
- Peppol / TRAFFIQX (kontrolliertes Netzwerk)
- ERP-seitige Kontrollen vor dem Zahllauf
- 1. IBAN-Abgleich gegen Kreditorenstamm
- 2. Eingangskanal-Dokumentation
- 3. Belegtypcode-Plausibilitätsprüfung
- 4. Neuer-Lieferant-Schwellenwert
- Verification of Payee: Schutz und Grenzen
- Was die Software sichtbar macht
XRechnung ist ein reines XML-Format. Wer technisch damit arbeitet, sei es als ERP-Verantwortliche/r, IT-Administrator oder Steuerberater, sollte genau verstehen, warum das Format von sich aus keinen Schutz vor Datenmanipulation bietet, wo Angreifer konkret eingreifen und welche Kontrollmaßnahmen vor dem Zahllauf diese Lücke schließen.
Dieser Artikel setzt grundlegendes Verständnis von XML voraus. Den Überblick ohne Technikjargon für Buchhaltung und kaufmännische Leitung gibt es separat. Verwandte Lösungsthemen zeigt Lösungen im Überblick. Einordnung in den Kontext der gesetzlichen E-Rechnungspflicht: E-Rechnungspflicht 2025 bis 2028.
Das Format: keine erzwungene Signatur in EN 16931
XRechnung ist die deutsche CIUS (Core Invoice Usage Specification) zur europäischen Norm EN 16931. Diese Norm definiert die semantische Struktur einer strukturierten E-Rechnung: welche Informationselemente (Business Terms, kurz BT) vorhanden sein müssen, welche optional sind und in welchem Wertebereich sie liegen dürfen.
Was die Norm nicht vorschreibt: eine verpflichtende elektronische Signatur über den Datensatz. § 14 Abs. 1 UStG nennt elektronische Signatur, EDI-Verfahren und „sonstige innerbetriebliche Kontrollverfahren" als gleichwertige Möglichkeiten, die Echtheit der Herkunft und die Unversehrtheit des Inhalts sicherzustellen. Dem Empfänger räumt er damit aber erheblichen Spielraum ein. In der Praxis versenden die meisten ERP-Systeme XRechnung-Dateien als unsignierte, rohe XML-Dateien.
Das Ergebnis: eine XRechnung ist ein Klartext-Dokument. Jeder Texteditor kann sie öffnen, einzelne Feldwerte verändern und speichern, ohne dass der Empfänger im Normalfall einen Hinweis auf die Änderung erhält.
Die relevanten Felder für Angreifer
Die Zahlungsdaten einer XRechnung stecken im Segment ram:SpecifiedTradeSettlementPaymentMeans (UN/CEFACT-Notation in ZUGFeRD/Factur-X) bzw. im UBL-Pendant cac:PaymentMeans/cac:PayeeFinancialAccount. In der Business-Term-Nomenklatur der EN 16931 sind das:
| BT-Feld | Inhalt | Pflicht |
|---|---|---|
| BT-81 | Zahlungsmittel-Typ (Code, z. B. 30 = Überweisung) | Ja |
| BT-84 | Zahlungskonto-Identifikator (in der Praxis: IBAN) | Bedingt |
| BT-85 | Kontoinhaber | Optional |
| BT-86 | BIC des kontoführenden Instituts | Optional |
BT-84 ist der Angriffspunkt. Ein Angreifer, der Zugang zur XML-Datei erhält, tauscht dort die IBAN des legitimen Lieferanten gegen ein eigenes Konto. Alles andere bleibt unverändert. Das Dokument sieht weiterhin korrekt aus, besteht die XRechnung-Schemavalidierung und landet im ERP des Empfängers, das die Überweisung auf die manipulierte IBAN auslöst.
Angriffsvektor 1: IBAN-Swap über abgefangene E-Mail
Der häufigste Angriffsweg: Die Rechnung des Lieferanten wird auf dem Transportweg abgefangen oder das Postfach eines Beteiligten ist kompromittiert. Der Angreifer öffnet die XML-Datei, ändert BT-84, und leitet das Dokument an den Empfänger weiter, oft mit unveränderter Absender-Adresse (E-Mail-Spoofing oder nach vollständiger Postfachübernahme).
Das BKA dokumentiert diese Masche als Business E-Mail Compromise (BEC) im Rechnungskontext: Täter beschaffen sich Rechnungsdaten aus öffentlichen Ausschreibungsunterlagen (TED-Datenbank der EU), erstellen täuschend echte Folgekommunikation und leiten manipulierte Belege ein. Der FBI-IC3-Report 2024 weist BEC-Schäden global mit 2,77 Milliarden USD aus. Das Muster ist nicht auf Papierdokumente beschränkt, sondern greift auf strukturierte Formate über.
Weshalb XML das Risiko gegenüber PDF erhöht: Bei einer klassischen PDF-Rechnung sieht der Bearbeiter die Kontonummer. Bei einer XRechnung oder dem XML-Anteil einer ZUGFeRD-Hybrid-Datei verarbeitet das ERP die Felder direkt, ohne dass ein Mensch den Rohinhalt zu Gesicht bekommt. Manipulation im XML bleibt damit systematisch unsichtbarer als im visuellen Dokument.
Angriffsvektor 2: Belegtypcode-Manipulation (380 → 381)
Weniger bekannt, aber technisch relevant: der TypeCode-Wert im Dokumentkopf. EN 16931 kennt für den täglichen Einsatz drei Hauptcodes:
- 380: Handelsrechnung (Normalfall, positive Beträge)
- 381: Gutschrift/Stornorechnung (Betrag ist rechnerisch negativ, d. h. der Empfänger schuldet dem Aussteller)
- 384: Korrekturrechnung
Ein Angreifer, der TypeCode 380 auf 381 umstellt und gleichzeitig die IBAN tauscht, erzeugt eine Datei, die von automatisierten Verarbeitungssystemen als Gutschrift interpretiert werden kann. Je nach ERP-Konfiguration kann das dazu führen, dass ein Guthaben auf das angegebene Konto ausgezahlt oder eine bestehende Forderung gegengerechnet wird. Die XRechnung-Validierung (KoSIT-Validator) prüft dabei nur die Schemakonformität des Codes; ob 381 an dieser Stelle inhaltlich plausibel ist, liegt außerhalb der Formatprüfung.
Der TypeCode findet sich in der UBL-Darstellung im Element <cbc:InvoiceTypeCode> (bzw. bei Gutschriften <cbc:CreditNoteTypeCode>), in der UN/CEFACT-Variante unter <rsm:ExchangedDocument>/<ram:TypeCode>.
Transportweg: E-Mail versus Peppol
Der Angriffsvektor hängt stark vom Transportweg ab. Die beiden relevanten Varianten im deutschen Markt unterscheiden sich grundlegend:
E-Mail-Versand (unkontrollierter Transportweg)
Eine XRechnung, die als E-Mail-Anhang eingeht, hat keinen technischen Integritätsschutz, es sei denn, Absender und Empfänger verwenden S/MIME oder PGP-Signierung, was im Mittelstand die Ausnahme bleibt. Die Datei liegt auf Mailservern, Zwischenknoten und im Postfach; jeder dieser Punkte ist ein potenzieller Angriffspunkt. DATEV empfiehlt explizit, E-Mail als Transportweg zu verlassen und auf Peppol bzw. TRAFFIQX zu wechseln.
Peppol / TRAFFIQX (kontrolliertes Netzwerk)
Peppol (Pan-European Public Procurement Online) ist ein reguliertes Vier-Ecken-Modell: Sender-Access-Point → Peppol-Infrastruktur → Empfänger-Access-Point. Die Übertragung erfolgt über das AS4-Protokoll mit Transport Layer Security (TLS) und gegenseitiger Zertifikatauthentifizierung. Jeder Teilnehmer muss sich bei einem akkreditierten Access-Point-Betreiber registrieren; die Identität ist damit verifiziert.
TRAFFIQX, das führende deutsche Provider-Netzwerk für E-Rechnungen (über 250.000 Teilnehmer), ist technisch in Peppol eingebunden und bietet zusätzlich automatische Viren-Scans und Zustellbestätigungen in Echtzeit. Eine Manipulation auf dem Transportweg ist in diesem Modell erheblich schwerer: der Absender ist registriert und identifizierbar, die Übertragung ist Ende-zu-Ende gesichert.
Das bedeutet nicht, dass Peppol jede Manipulation ausschließt: ein kompromittierter Lieferanten-Access-Point wäre weiterhin ein Angriffsvektor. Aber das Risikoprofil ist strukturell besser als offene E-Mail.
ERP-seitige Kontrollen vor dem Zahllauf
Transportwegsicherheit und Formatvalidierung schließen die Lücke nicht vollständig. Die entscheidende Kontrolle liegt im ERP, bevor der Zahllauf angestoßen wird:
1. IBAN-Abgleich gegen Kreditorenstamm
Vor der Zahlungsfreigabe sollte das ERP (oder ein vorgelagertes Eingangsrechnungssystem) den IBAN-Wert aus BT-84 gegen die im Kreditorenstamm hinterlegte Kontoverbindung abgleichen. Abweichungen werden als Warnhinweis geflaggert und erfordern manuelle Freigabe.
Voraussetzung: der Kreditorenstamm ist gepflegt und IBAN-Änderungen im Stamm durchlaufen selbst ein Vier-Augen-Verfahren. Eine neue IBAN, die nur per E-Mail-Anfrage eines angeblichen Lieferanten eingetragen wurde, ist selbst ein Angriffsvektor (Kreditor-Stammdatenbetrug).
2. Eingangskanal-Dokumentation
Der Kanal, über den eine Rechnung eingegangen ist, sei es Peppol, dediziertes Eingangspostfach oder manueller Upload, sollte am Beleg dokumentiert sein. Rechnungen, die über unkontrollierte E-Mail-Adressen eingehen, können mit einem höheren Prüfbedarf versehen werden.
3. Belegtypcode-Plausibilitätsprüfung
TypeCode-Wechsel zwischen 380 und 381 sollten automatisch markiert werden. Ein Lieferant, der bisher ausschließlich Rechnungen (380) gestellt hat, und plötzlich eine Gutschrift (381) einreicht, ist ein Signal für manuelle Prüfung, insbesondere wenn sich gleichzeitig die IBAN ändert.
4. Neuer-Lieferant-Schwellenwert
Erstmalige Zahlungen an eine IBAN, die bisher nie belastet wurde, sollten unabhängig vom Belegbetrag eine Freigabestufe höher laufen. Dieses Prinzip, bekannt aus Treasury-Systemen für große Unternehmen, lässt sich auch in mittelständischen ERP-Systemen als Workflow-Regel abbilden.
Verification of Payee: Schutz und Grenzen
Seit dem 9. Oktober 2025 sind Zahlungsdienstleister in der Eurozone verpflichtet, bei SEPA-Überweisungen zu prüfen, ob IBAN und Empfängername übereinstimmen. Rechtsgrundlage ist die EU-VO 2024/886 (Instant Payments Regulation), allgemein als „Verification of Payee" (VoP) bekannt.
Was VoP schützt: Tippfehler bei der IBAN-Eingabe und bestimmte Fälle, in denen ein Betrüger eine falsche IBAN mit einem fremden Namen kombiniert.
Was VoP nicht schützt: Ein Angreifer, der ein legitim eröffnetes Konto unter einem plausibel klingenden Firmennamen führt, besteht die VoP-Prüfung. Und vor allem: VoP prüft zum Zeitpunkt der Überweisung bei der Bank, nicht beim Eingang der Rechnung im ERP. Der IBAN-Abgleich gegen Kreditorenstammdaten muss daher vor dem Zahllauf stattfinden, nicht erst beim Zahlungsdienstleister.
VoP ist eine ergänzende Schutzschicht, kein Ersatz für den internen Stammdaten-Abgleich.
Was die Software sichtbar macht
Der Dienst liest eingehende XRechnung- und ZUGFeRD-Belege und stellt die enthaltenen Felder, darunter BT-84 (IBAN), BT-85 (Kontoinhaber) und den TypeCode, lesbar bereit, bevor sie im ERP verarbeitet werden. Der Eingangskanal (Peppol, Postfach, Upload) wird am Beleg dokumentiert.
Der Dienst hat ausschließlich Lesezugriff. Er löst keine Zahlungen aus. Die Freigabe liegt bei Ihnen.
Eingehende Rechnungen, die auf diesem Weg geprüft ankommen, liefern gleichzeitig die Fälligkeitsdaten für die 13-Wochen-Liquiditätsvorschau: ein Datenpunkt, zwei Verwendungen.
Zurück zur Übersicht: IBAN-Betrug per XRechnung: das Risiko im XML erkennen
Kontrolle vor dem Zahllauf
Wer eingehende XRechnung-Belege auf IBAN, TypeCode und Eingangskanal prüft, bevor das ERP den Zahllauf anstößt, schließt die Lücke, die das XML-Format von sich aus offen lässt. Wer tatsächlich bezahlt wird, bleibt damit Ihre Entscheidung, nicht die des Automatismus.
Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.
