Rechnungsbetrug mit neuer IBAN: Wie ein n8n-Workflow die Zahlung stoppt, bevor sie rausgeht

228.420 Euro. So viel sollte eine Wohnbaugesellschaft in Salzburg im Juli überweisen. Die Rechnung sah aus wie immer, der Lieferant war der richtige, und die Bitte, ab sofort auf ein neues Konto zu zahlen, sei ja vorher angekündigt worden. War sie nicht. Der Buchhaltung fiel das auf, die Zahlung wurde gestoppt, und die Polizei fand später heraus, wem das Konto wirklich gehörte (salzburg24.at, 01.08.2026).

Das Geld ist nur deshalb noch da, weil ein Mensch genau hingeschaut hat. Und genau darum geht es in diesem Artikel: Wie man dieses Hinschauen nicht dem Zufall überlässt.

Wie die Masche funktioniert

Die Täter brauchen keine gefälschte Firma. Sie verschaffen sich Zugang zu einem Postfach, das am Rechnungsverkehr beteiligt ist – beim Lieferanten oder beim Kunden –, lesen eine Weile mit und schicken dann im richtigen Moment eine echte Rechnung mit einer einzigen geänderten Zeile: der Bankverbindung. Manchmal kommt dazu ein freundlicher Hinweis, man habe die Bank gewechselt. Das LKA Baden-Württemberg warnt vor genau diesem Muster seit Jahren; teilweise werden sogar Briefe per Post nachgeschoben, damit alles glaubwürdig wirkt (IHK Osnabrück, Warnmeldung des LKA BW).

Das Tückische: Alles an dieser Rechnung ist richtig. Lieferant, Leistung, Betrag, Rechnungsnummer. Wer nur prüft, ob die Rechnung plausibel ist, prüft an der falschen Stelle.

Hilft die Empfängerüberprüfung der Banken nicht schon?

Teilweise, und das ist ein echter Fortschritt. Seit dem 9. Oktober 2025 gleichen Banken bei Euro-Überweisungen den Empfängernamen mit dem Inhaber der IBAN ab (Verification of Payee). Passt der Name nicht, gibt es eine Warnung (DATEV zur Verification of Payee).

Drei Lücken bleiben trotzdem:

Die Prüfung kommt erst ganz am Ende, beim Überweisen – wenn die Rechnung längst freigegeben im Zahlungslauf steckt. Bei Sammelüberweisungen dürfen Unternehmen auf die Prüfung verzichten, und dann haften sie selbst (Lexware, Deutsche Bank). Und eine Warnung „Name stimmt nur teilweise überein“ ist schnell weggeklickt, wenn freitags vierzig Zahlungen auf einmal rausgehen.

Die bessere Stelle für die Frage „Ist das wirklich die Bankverbindung dieses Lieferanten?“ ist der Rechnungseingang. Dort ist noch Zeit, anzurufen.

Was der Workflow macht

Ich habe dafür einen n8n-Workflow gebaut, der offen auf GitHub liegt (n8n-e-rechnung). Er liest eingehende E-Rechnungen – XRechnung, ZUGFeRD, Factur-X – direkt in n8n, ohne externe API, rechnet sie nach und vergleicht dann jede Rechnung mit den früheren desselben Lieferanten.

Steht dort eine IBAN, die dieser Lieferant noch nie benutzt hat, wird die Rechnung angehalten. Die Buchhaltung bekommt den Hinweis, beim Lieferanten anzurufen – unter einer Nummer, die sie schon kennt, nicht unter der aus der Mail. Erst wenn jemand die neue Bankverbindung bestätigt hat, gilt sie als bekannt. Eine Rechnung, die mit dem Alarm hereinkam, kann sich also nicht selbst auf die Liste der vertrauenswürdigen Konten setzen.

Beim Testen ist eine zweite Lücke aufgefallen, die mir selbst entgangen war und die erst ein zweites KI-Modell beim Gegenlesen des Codes gefunden hat: Eine Fälschung, die einfach die USt-IdNr. weglässt, sah für den Abgleich wie ein neuer Lieferant aus – und löste deshalb keinen Alarm aus. Jetzt wird ein Lieferant über die USt-IdNr. oder den Namen erkannt, und eine fehlende oder abweichende Steuernummer ist selbst ein Hinweis.

Danach kommt die Freigabe vor der Zahlung: Ab einem Betrag, den man festlegt, geht jede saubere Rechnung als Anfrage aufs Handy – per E-Mail, WhatsApp oder Telegram, mit Lieferant, Betrag, IBAN und allen Hinweisen und zwei Knöpfen, Freigeben oder Ablehnen. Nur Freigegebenes wird an DATEV Upload Mail weitergeleitet. Kommt keine Antwort, erfährt es nach der eingestellten Zeit die Buchhaltung.

Und weil Betrug selten allein kommt, prüft der Workflow nebenbei, was sonst gern durchrutscht: ob der Zahlbetrag zum Rechnungsbetrag passt (ein unerklärter Unterschied ist ein eigener Prüfgrund), ob die Umsatzsteuer je Satz stimmt, ob die IBAN überhaupt eine gültige Prüfziffer hat, ob dieselbe Rechnung schon einmal kam. ZIP-Archive werden entpackt, und Mails, in denen statt eines Anhangs nur ein Link auf ein Lieferantenportal steht, landen bei einem Menschen statt im Nichts.

Was er nicht ersetzt

Den Anruf. Der Workflow entscheidet nicht, ob eine neue IBAN echt ist – er sorgt dafür, dass niemand sie übersieht. Er ersetzt auch keine vollständige Schematron-Validierung der E-Rechnung, und die XML-Datei bleibt das rechtlich maßgebliche Original. Und er braucht etwas Einrichtung: eine bestätigte Absenderadresse für DATEV Upload Mail, bei WhatsApp die Business-API von Meta, einen n8n-Server, idealerweise in der EU.

Getestet ist er gegen den öffentlichen ZUGFeRD-Bestand und die Testrechnungen der KoSIT (330 Dateien, alle 284 Rechnungen darunter ohne Lesefehler) und in n8n 2.43 mit den Fällen, die im Alltag passieren: neue IBAN, Fälschung ohne USt-IdNr., ZIP, Portal-Link, Scan, ausgefallenes Sprachmodell, XML und PDF derselben Rechnung in einer Mail, Freigabe ohne Antwort. Die Freigabe per Telegram lief dabei echt, mit Knopfdruck auf dem Handy.

Häufige Fragen

Was ist Rechnungsbetrug mit geänderter IBAN? Täter schicken eine echte oder täuschend echte Rechnung eines bekannten Lieferanten, in der nur die Bankverbindung ausgetauscht ist. Wer zahlt, überweist an die Täter; das Geld ist meist verloren, und den Schaden trägt in der Regel das zahlende Unternehmen.

Reicht die Empfängerüberprüfung (Verification of Payee) der Banken aus? Sie hilft, greift aber erst beim Überweisen. Bei Sammelüberweisungen kann darauf verzichtet werden, und Teilübereinstimmungen werden im Alltag oft weggeklickt. Besser ist ein zweiter Prüfpunkt beim Rechnungseingang.

Woran erkennt der Workflow eine neue Bankverbindung? Er vergleicht die IBAN jeder Rechnung mit allen früheren Rechnungen desselben Lieferanten. Eine IBAN, die dieser Lieferant noch nie verwendet hat, stoppt die Rechnung, bis jemand sie bestätigt.

Funktioniert das auch ohne XRechnung, mit normalen PDF-Rechnungen? Ja. PDFs ohne E-Rechnungsdaten liest ein lokales Sprachmodell; diese Rechnungen werden immer zur Prüfung markiert. Scans ohne Textebene gehen direkt an einen Menschen.

Kostet der Workflow etwas? Der Code ist offen auf GitHub. Kosten entstehen für den Betrieb von n8n und gegebenenfalls für die Einrichtung im eigenen Betrieb.

Wer sehen möchte, wie das am eigenen Rechnungseingang aussieht: E-Rechnung mit n8n in Freiburg – oder unten kurz anfragen. Die technische Diskussion zum Workflow läuft im n8n-Community-Forum.