Social Hacking, Rechnungsbetrug und Fraud Prevention

1.1 Ausgangslage im Rechnungseingangs/SAP-Kontext

Ein digitalisierter Rechnungseingang beschleunigt den Procure-to-Pay-Prozess – und erhöht zugleich die Wirkung eines gut vorbereiteten Angriffs. Eine formal plausible Rechnung kann schnell in einen scheinbar korrekten Workflow gelangen und ohne harte Gegenkontrollen bis in Freigabe oder Zahlung durchlaufen.

Im Zentrum darf deshalb nicht die äußere Form stehen, sondern die Frage nach inhaltlicher Legitimität, prozessualer Freigabe, technischer Konsistenz und dem Abgleich gegen bestätigte Stammdaten.

1.2 Warum Social Hacking im Rechnungsprozess so gefährlich ist

Angreifer greifen selten die Kryptographie oder SAP selbst frontal an. Sie nutzen Menschen, Gewohnheiten, Ausnahmen, Monatsabschlussdruck, Lieferanteneskalationen und vermeintlich harmlose Abkürzungen im Alltag aus.

Besonders gefährlich sind glaubwürdiger Kontext, scheinbar harmlose Ausnahmeentscheidungen und eine oft späte Schadenserkennung – häufig erst nach dem Zahlungslauf oder wenn der echte Lieferant mahnt.

1.3 Zielbild eines belastbaren AP-Prozesses

Das Zielbild ist kein einzelnes Tool, sondern ein kontrollierter End-to-End-Prozess. Zahlungen dürfen nie allein wegen des Vorliegens einer Rechnung ausgelöst werden, sondern erst nach logisch zusammenpassender Bestellung, Leistungserbringung und Rechnung – oder nach einer bewusst geregelten Ausnahme mit Zusatzkontrolle.

Vendor- und Bankdaten sind Hochrisikodaten. Verdächtige Fälle müssen automatisch aus dem Standardfluss herausgenommen und in eine Review- oder Fraud-Queue geroutet werden.

2.1 Social Hacking, BEC und Vendor Fraud

Unter Social Hacking wird hier die gezielte Täuschung von Personen und Prozessen verstanden, um Rechnungen, Freigaben oder Zahlungen zu manipulieren. Im Rechnungswesen überschneidet sich das eng mit Business Email Compromise, Vendor Fraud, Zahlungsumleitung, Identitätsmissbrauch und Stammdatenangriffen.

2.2 Typische Täter und Motive

Das Spektrum reicht vom opportunistischen Betrüger bis zur organisierten Gruppe. Manche skalieren breit mit Lookalike-Domains und Massenrechnungen, andere beobachten das Zielunternehmen über Wochen, sammeln Kontext und imitieren Schreibstile und Lieferantenbeziehungen.

2.3 Kill Chain eines Rechnungsbetrugs

Der typische Angriff verläuft in wiederkehrenden Phasen: Informationsbeschaffung, Auswahl eines glaubwürdigen Lieferanten- oder Projektkontexts, Vorbereitung von Domain, Dokument und Storyline, Platzierung der Rechnung oder Bankdatenänderung, Erzeugung von Zeitdruck und schließlich Auszahlung oder Folgeauszahlungen.

1. Öffentlich verfügbare Informationen sammeln
2. Realistischen Lieferanten- oder Projektkontext auswählen
3. Domain, Dokument und Storyline vorbereiten
4. Rechnung oder Bankdatenänderung platzieren
5. Zeitdruck oder Autoritätseffekt erzeugen
6. Auszahlung und Verschleierung anstoßen

2.4 Primäre Ziele des Angreifers

Das unmittelbare Ziel ist die Zahlung auf ein vom Angreifer kontrolliertes Konto. Zusätzlich sind falsche Vendor-Stammdaten, das Ausspähen von Freigabeketten, das Testen von Kontrolllücken und das Sammeln von Metadaten über Mitarbeiter und Sonderwege relevant.

3.1 Prozessbild

Der Rechnungsprozess ist eine Kette aus Eingangskanal, Extraktion, Zuordnung, Stammdatenabgleich, Freigabe, Zahlungsvorbereitung und Zahlungsfreigabe. Ein Angreifer sucht sich nicht den formal schönsten, sondern den wirtschaftlich günstigsten Bruchpunkt.

3.2 Kritische Kontrollpunkte

Besonders kritisch sind alle Schritte, an denen Vertrauen stillschweigend übertragen wird: automatisches Matching auf einen bekannten Vendor, Akzeptanz neuer Zahlungsdaten, Nicht-PO-Ausnahmen oder Freigaben unter Verweis auf Management-Dringlichkeit. Jede dieser Abkürzungen spart Zeit – und kann bei Missbrauch den Rest des Prozesses entwerten.

3.3 Medienbrüche und Ausnahmepfade

Viele Schäden entstehen nicht im Standardprozess, sondern im Ausnahmeweg: manueller Nachtrag, telefonische Beschleunigung, fehlender Wareneingang oder historisch gewachsene Sonderregeln. Ausnahmepfade müssen inventarisiert, dokumentiert, genehmigt und stärker statt schwächer kontrolliert werden.

4.1 Fake-Rechnung ohne Bestellung

Das einfachste Muster ist die frei erfundene Rechnung ohne belastbaren Bestellbezug. Besonders anfällig sind Bereiche mit vielen Nicht-PO-Rechnungen, kleinen Beträgen und hoher Routine.

4.2 Echte Bestellung, manipulierte Rechnung

Gefährlicher ist die Variante mit echtem Kontext. Wenn Bestellnummer, Ansprechpartner oder Lieferbeziehung stimmen, wirken geänderte Beträge, Bankdaten oder Leistungsbeschreibungen intern viel plausibler.

4.3 Bankdatenwechsel als Kernangriff

Eine glaubwürdige Nachricht über neue Treasury-Strukturen, ein Shared Service Center oder eine geänderte Tochtergesellschaft reicht oft aus, um Bankdaten in die Stammdaten zu schleusen. Danach kann sogar eine echte spätere Rechnung auf das falsche Konto gehen.

4.4 Kompromittierte Lieferantenkonten

Wenn nicht eine Fake-Domain, sondern ein echtes Lieferantenpostfach verwendet wird, helfen Bauchgefühl und Schreibstil kaum noch. Dann zählen nur bestätigte Kontaktwege, dokumentierte Verifikation und technische Holds.

4.5 Lookalike-Domain und Schreibstil-Imitation

Ein Buchstabentausch, eine andere TLD oder eine minimal veränderte PDF-Datei ist für Menschen unter Zeitdruck schwer zu erkennen. Domainprüfungen und Absendervertrauen sollten daher maschinell unterstützt und nicht rein manuell erwartet werden.

4.6 Interne Kollusion oder überschießende Berechtigungen

Nicht jeder Fall ist reines Social Engineering von außen. Zu breite Rollen, ungetrennte Aufgaben und lang liegende Dienstleisterrechte erleichtern Missbrauch erheblich.

4.7 Die gefährlichste Mischung: plausibler Kontext plus Zeitdruck

Ein echter Lieferantenname plus plausible Story plus Zeitdruck plus leicht geänderte Domain genügt oft, um mehrere Schutzinstinkte gleichzeitig auszuhebeln. Kontrollen müssen gerade in Stresssituationen halten.

5.1 Dokumentbezogene Auffälligkeiten

Kein Einzelmerkmal beweist Betrug. Mehrere kleine Signale zusammen rechtfertigen jedoch immer einen strengeren Prüfpfad und einen dokumentierten Kontrollschritt.

5.2 Verhaltensbezogene Auffälligkeiten

Ungewöhnlich kurzer Stil, Ausweichen bei Rückfragen, neue Hotmail- oder Gmail-Adressen, wiederholter Druck auf „heute noch“ oder auffällig hilfsbereite Erklärungen sind klassische Fraud-Indikatoren. Schulungen müssen solche Muster als Prozessauslöser verankern.

5.3 Technische Indikatoren

Relevante technische Signale sind Domain-Abweichungen, SPF/DKIM/DMARC-Fehler, OCR-Konfidenz, Fuzzy-Matches der Rechnungsnummer, Herkunftsland des Kontos, Historienbrüche und die zeitliche Einbettung. Gute Systeme konsolidieren diese Signale in Regeln oder Scores.

6.1 Drei Verteidigungslinien

Die erste Linie arbeitet operativ in AP, Einkauf und Fachbereichen. Die zweite Linie definiert Standards und Mindestkontrollen – typischerweise Compliance, Fraud- oder InfoSec-Funktionen. Die dritte Linie prüft unabhängig, ob die Kontrollen tatsächlich wirksam sind.

6.2 RASCI für den Rechnungsprozess

Ein klarer Rollenrahmen verhindert Diskussionen im Verdachtsfall und macht Ausnahmen prüfbar. Besonders kritisch sind Onboarding, Bankdatenwechsel, Hochrisiko-Freigaben und Incident Response.

6.3 Eskalationsregeln

Es braucht kurze, eindeutige Regeln: Wer darf bei neuer Bankverbindung entscheiden? Wer hebt einen Fraud-Block auf? Wann wird Management eingebunden? Gute Eskalation ersetzt Improvisation durch trainierte Routine.

7.1 3-Way-Match als Grundprinzip

Die wirksamste Grundregel lautet: Keine Zahlung nur wegen einer Rechnung. Bestellung, Leistungserbringung und Rechnung müssen zusammenpassen – oder ein dokumentierter Ersatzprozess mit vergleichbarer Sicherheit muss greifen.

7.2 Policy für PO- und Nicht-PO-Rechnungen

Nicht-PO-Rechnungen dürfen kein blinder Fleck sein. Definiert werden sollten zulässige Kategorien, Betragsgrenzen, Pflichtnachweise und Zusatzfreigaben, damit legitime Ausnahmen nicht in informelle Nebenwege abwandern.

7.3 Vendor Onboarding und Stammdatenhygiene

Neue Lieferanten und Änderungen an bestehenden Lieferanten sind Hochrisikopunkte. Beantragung, Prüfung und Umsetzung dürfen nicht bei derselben Rolle liegen; Änderungen müssen versioniert, begründet und nachvollziehbar sein.

7.4 Bankdatenwechsel nur mit unabhängiger Verifikation

Bankdaten dürfen niemals nur aufgrund einer E-Mail oder eines Vermerks auf der Rechnung geändert werden. Das sichere Minimum ist ein Rückruf über eine bereits bestätigte Nummer aus Vertrag, Stammdaten oder offiziellem Portal.

7.5 Vier-Augen-Prinzip, Maker-Checker und Betragsgrenzen

Wer einen Lieferanten anlegt, darf nicht dieselbe Person sein, die seine Bankdaten ändert und die erste Rechnung freigibt. Hohe oder ungewöhnliche Beträge sowie manuelle Ausnahmen brauchen zusätzliche Freigaben mit dokumentierter Begründung.

7.6 Payment Holds und finale Zahlungsfreigabe

Verdächtige Konstellationen gehören in einen Hold, nicht in die normale Verarbeitung. Die finale Zahlungsfreigabe sollte auf Dateiebene oder Zahlungslaufebene nochmals absichern, dass keine blockierte Position herausrutscht.

7.7 Dokumentationspflicht statt stiller Ausnahme

Jede Ausnahme braucht einen Grund, einen Verantwortlichen und einen Nachweis. Dokumentation ist hier kein Selbstzweck, sondern Schutz gegen Kontextverlust, Rückversicherungsbetrug und spätere Diskussionen.

8.1 Eingangskanal und Datenerfassung härten

Ein Lieferantenportal oder streng kontrollierter Mailfluss ist sicherer als verteilte Postfächer ohne zentrale Validierung. Bereits am Eingang sollten bekannte Domains, bekannte Gegenstellen, Dateitypen, Mehrfachzustellungen und Authentifizierungssignale ausgewertet werden.

8.2 Plausibilität in der Extraktion und Zuordnung

OCR- und Extraktionsstrecken sollten nicht nur Felder auslesen, sondern deren Plausibilität bewerten: Passt die IBAN zum Land? Ist die Rechnungsnummer neu oder nur leicht abgewandelt? Ist Betrag, Währung oder Zahlungsziel untypisch?

8.3 SAP-seitige Kontrollobjekte

Im SAP-nahen Prozess sind Vendor-Stammdaten, Freigabeworkflows, Payment Blocks, Rollen, Änderungsprotokolle und Review-Queues entscheidend. SAP sollte nicht nur Buchungsmaschine, sondern Kontrollplattform sein.

8.4 Duplicate Detection und Fuzzy Matching

Angreifer ändern Bindestriche, Leerzeichen, Datumsformate oder einzelne Ziffern. Deshalb muss die Dublettenprüfung ähnliche Rechnungen, Beträge, Vendoren, Referenzen und Zeiträume erkennen – nicht nur exakt identische Datensätze.

8.5 E-Mail- und Domain-Schutz

SPF, DKIM und DMARC reduzieren klassische Spoofing-Angriffe, lösen das Problem aber nicht allein. Ergänzend helfen Lookalike-Domain-Erkennung, Warnhinweise für externe Absender, sichere Vendor-Änderungspfade und – thematisch passend – ein E-Mail-Security-Gateway wie NoSpamProxy für den Eingangskanal.

8.6 Logging und Monitoring

Hochwertige Fraud Prevention braucht Telemetrie: Vendor-Änderungen, manuelle Overrides, fehlgeschlagene Validierungen, Fuzzy-Dubletten, Hold-Aufhebungen und Eskalationen. Diese Daten sollten SIEM- oder Reporting-fähig aggregiert werden.

9.1 Regelbasiert, ML und Validierungsnetze

Fraud-Detection-Tools im Rechnungsumfeld arbeiten im Kern mit drei Logiken: klaren Regeln, anomaliestützter Analyse und externer Validierung von Vendor- oder Kontodaten. Der größte Mehrwert entsteht meist aus einer Kombination dieser Ansätze.

9.2 SAP Business Integrity Screening

SAP Business Integrity Screening ist besonders interessant, wenn Fraud Detection nicht als Insellösung, sondern als Teil der SAP-nahen Kontrollarchitektur gedacht wird. Der Mehrwert liegt in SAP-Nähe, Regelwerken, Alerts und Investigationslogik.

9.3 Drittanbieter-Lösungen

Drittanbieter adressieren oft einen engeren, aber sehr wirkungsvollen Bereich – etwa AP-Risikoanalyse, P2P-Monitoring, Bankkonto-Validierung oder vorgelagerte E-Mail-Sicherheit. Sie sind sinnvoll, wenn Grundprozesse und Verantwortlichkeiten bereits sauber stehen.

9.4 Auswahlkriterien für Werkzeuge

Die entscheidende Frage lautet nicht, welches Produkt die meisten KI-Claims hat, sondern an welcher Stelle der eigenen Prozesskette heute die größte Sicherheitswirkung fehlt. Wichtige Kriterien sind Datenqualität, Integrationsfähigkeit, Erklärbarkeit, Betriebsmodell, Alert-Qualität und messbarer Nutzen.

9.5 Wie Tools in der Praxis wirken

Ein hoher Score ohne Payment Hold ist wertlos. Ein Dublettenhinweis ohne klaren Bearbeiter versandet. Tooling entfaltet erst dann Wirkung, wenn Signale in verbindliche Entscheidungen, Playbooks und messbare Prozessschritte übersetzt werden.

10.1 Definition

Ein SAP Fraud-Workflow ist kein einzelner Knopf und kein einzelnes Produkt. Gemeint ist ein organisierter Ablauf, in dem verdächtige Rechnungen, Vendor-Änderungen oder Zahlungen aus dem Standardfluss herausgenommen, bewertet, dokumentiert, eskaliert und erst nach definierter Klärung wieder freigegeben oder verworfen werden.

10.2 Ziel und Architektur

Ziel ist, dass nicht der Sachbearbeiter improvisieren muss, sondern die Organisation eine klare Route hat: Eingang, Signalerhebung, Scoring, Queue, Playbook, Entscheidung und Rückkopplung. Architektur bedeutet also vor allem saubere Prozessführung, Statuslogik und Rollenübergaben.

10.3 Beispielablauf

1. Eingang von Rechnung oder Vendor-Änderung
2. Automatische Erhebung von Risikoindikatoren
3. Scoring, Duplicate-Check und Stammdatenabgleich
4. Hold-Code und Routing in Fraud- oder Review-Queue
5. Manuelle Verifikation über bestätigte Kontaktwege
6. Dokumentierte Entscheidung: freigeben, zurückweisen, Vendor sperren oder Incident starten

10.4 Fraud Queue und Analyst Playbooks

Die Queue funktioniert nur mit klaren Playbooks: Welche Daten werden geprüft? Welche Kontaktwege sind erlaubt? Wer darf eine Sperre aufheben? Wann werden Einkauf, Legal oder Management eingebunden? Gute Playbooks reduzieren Streuung in der Bearbeitungsqualität.

10.5 Statuslogik und Hold-Codes

Typische Statuswerte sind etwa FRAUD_REVIEW, BANK_CHANGE_VERIFY, DUPLICATE_SUSPECT, HIGH_AMOUNT_ANOMALY oder UNVERIFIED_VENDOR. Sie machen Reporting, Auditierbarkeit und disziplinierte Bearbeitung überhaupt erst möglich.

10.6 Warum der Workflow wichtiger ist als die Einzelerkennung

Viele Projekte investieren zuerst in die Erkennung und zu wenig in die Bearbeitung. Der eigentliche Sicherheitsgewinn entsteht aber nicht beim bloßen Flaggen, sondern beim sauberen Umgang mit dem Flag: Hold, Review, Verifikation, Dokumentation, Entscheidung und Rückkopplung.

11.1 Bewertungslogik

Ein funktionales Regelwerk muss für Fachbereich und Revision nachvollziehbar bleiben. Eine Kombination aus additiven Risikopunkten und harten K.-o.-Kriterien ist in der Praxis oft robuster als eine Blackbox.

11.2 Routing nach Schwellwerten

Ein praxistaugliches Modell kann so aussehen: unter 20 Punkten Standardprozess, 20–39 Punkte erweiterte Fachprüfung, 40–59 Punkte Payment Hold plus Callback, ab 60 Punkten Fraud Review mit zusätzlicher Freigabe. Bestimmte K.-o.-Kriterien stoppen unabhängig vom Score sofort.

11.3 Fehlalarme und Tuning

Fehlalarme am Anfang sind normal. Wichtig ist ihre systematische Auswertung: Welche Regeln sind zu breit? Welche Lieferantenprofile erzeugen harmlose Treffer? Wo fehlen historische Vergleichsdaten? Tuning gehört in den Regelbetrieb.

11.4 Verknüpfung mit menschlicher Entscheidung

Der Score ist Entscheidungshilfe, kein Verantwortungsersatz. Ziel ist, Menschen von Routineprüfungen zu entlasten und ihre Aufmerksamkeit auf hochwertige Verdachtsfälle zu konzentrieren – bei klarer Aussteuerung und nachvollziehbaren Gründen.

12.1 Warum Awareness im Rechnungswesen anders sein muss

Allgemeine Phishing-Schulungen reichen für AP, Einkauf und Fachfreigaben nicht aus. Diese Funktionen brauchen kontextnahe Trainings mit echten Rechnungsbeispielen, Bankänderungsszenarien, Monatsenddruck und Management-Eskalationen.

12.2 Zielgruppenspezifische Trainings

AP-Teams brauchen Mustererkennung für Rechnungen und Stammdaten, Einkauf Fokus auf Lieferantenbeziehungen und Verträge, Fachbereiche ein Verständnis der Leistungsbestätigung als Kontrollakt und IT/SAP ein Bewusstsein für Berechtigungen, Logs und Änderungsprozesse.

12.3 Goldene Verhaltensregeln

• Keine Bankdatenänderung ohne unabhängige Verifikation.
• Keine Zahlung nur auf Basis einer Rechnung ohne Leistungs- oder Bestellbezug.
• Keine manuelle Beschleunigung von Ausnahmen ohne Zusatzfreigabe.
• Keine Freigabe unter Autoritätsdruck ohne Rückversicherung im Standardprozess.
• Jeder Verdacht erzeugt einen Prozessschritt, nicht nur ein Bauchgefühl.

12.4 Schulungsdesign

Wirksam sind kurze Pflichtmodule, regelmäßige Refreshs, realitätsnahe Fallbeispiele, Testsimulationen und Lessons Learned aus Beinahevorfällen. Besonders wichtig ist die direkte Anbindung an den tatsächlichen Prozess statt an abstrakte Security-Folien.

12.5 Kommunikationskultur

Awareness scheitert oft kulturell. Wenn Rückfragen als störend gelten, entscheidet sich die Organisation unbewusst für Geschwindigkeit statt Sicherheit. Management muss vorsichtige Rückfragen sichtbar als Professionalität legitimieren.

13.1 Verdacht vor Zahlung

Bei Verdacht vor der Zahlung lautet die erste Regel: nicht diskutieren, sondern blockieren. Payment Hold setzen, Fall in Fraud Queue überführen, Vendor-Daten gegen bestätigte Quellen prüfen, Rückrufskript nutzen und alles dokumentieren.

13.2 Schaden nach Zahlung

Wenn bereits gezahlt wurde, zählt Zeit. Treasury oder Bank müssen sofort eingebunden werden, um Rückruf- oder Sperrversuche einzuleiten. Parallel sind Vendor, Stakeholder, Kommunikationsdaten und technische Spuren zu sichern.

13.3 Beweissicherung

Zu sichern sind Originalmails inklusive Header, Anhänge, Systemprotokolle, Änderungsbelege, Freigabeschritte, Screenshots, Zahlungsdaten, Kontaktprotokolle und Zeitstempel. Ohne saubere Beweise bleibt die Ursache später oft unklar.

13.4 Lessons Learned statt Einzelfallheilung

Nach jedem Fall muss gefragt werden: Welche Kontrollstufe hat gegriffen? Welche nicht? War das Regelwerk zu schwach, der Ausnahmepfad zu breit, die Kultur zu nachgiebig oder der Eingangskanal zu offen? Reife entsteht in der Rückkopplung.

13.5 Externe Kommunikation und Rechtsfragen

Je nach Schaden und Gesellschaftsstruktur können Legal, Datenschutz, Versicherer, Steuerberater oder Strafverfolgungsbehörden relevant werden. Diese Schritte sollten nicht im Chaos erfunden, sondern im Incident-Plan vorgezeichnet sein.

14.1 Welche Kennzahlen wirklich helfen

Sinnvoll sind Kennzahlen, die Steuerung ermöglichen: Anteil Nicht-PO-Rechnungen, Anzahl Bankdatenänderungen, Verifikationsquote, Anzahl Payment Holds, Trefferquote der Regeln, Bearbeitungszeit in der Fraud Queue, Zahl manueller Overrides und verifizierte Beinahevorfälle.

14.2 Board-Reporting

Das Management braucht kein Technikprotokoll, sondern ein Lagebild: Wo wurden Zahlungen gestoppt? Welche Muster nehmen zu? Welche Gesellschaften oder Prozesse zeigen viele Ausnahmen? Reporting soll Entscheidungen provozieren, nicht nur dokumentieren.

14.3 Reifestufen

Ein Reifegradmodell macht sichtbar, ob die Organisation noch personengebunden reagiert oder bereits datengetrieben steuert. Der Sprung von dokumentierten Grundkontrollen zu einer echten Fraud Queue mit KPI-Feedback ist dabei meist der entscheidende Hebel.

14.4 Vom KPI zur Steuerungsentscheidung

Ein Anstieg von Nicht-PO-Rechnungen muss Ursachenanalyse auslösen. Viele manuelle Overrides müssen Governance-Prüfung auslösen. Viele neue Vendor-Bankdaten brauchen vielleicht mehr Tooling. Erst die Konsequenz macht Kennzahlen wertvoll.

15.1 30 Tage

Für die ersten 30 Tage braucht es kein Großprojekt. Entscheidend sind wenige, konsequente Maßnahmen: Callback für Bankdaten verbindlich machen, Hochrisiko-Szenarien in Holds überführen, Nicht-PO-Ausnahmen sichtbar machen und Verantwortlichkeiten benennen.

15.2 90 Tage

Zwischen 30 und 180 Tagen wird der Prozess belastbar: Vendor-Prozess, Änderungsprotokolle, Fraud Queue, Scoring, Dashboards, Awareness-Zyklen und realistische Tests kommen zusammen und machen aus Einzelfallreaktion einen Standardprozess.

15.3 180 Tage und 12 Monate

Langfristig sollte Fraud Prevention Teil des normalen Betriebs sein: mit Regelreviews, Metriken, Rollen, Simulationen und einer lernenden Kultur. Dann ist Rechnungsbetrug kein Sonderthema mehr, sondern gelebte Finance Governance.

16.1 Rückrufskript

Eine sichere Rückrufroutine nutzt nie die Nummer aus der eingegangenen Mail oder Rechnung. Dokumentiert werden sollten Name, Funktion, Datum, Uhrzeit, bestätigte Kontodaten, Anlass der Änderung und der interne Bearbeiter.

16.2 Checkliste für verdächtige Rechnungen

• Liegt ein belastbarer Bestell-, Vertrags- oder Leistungsbezug vor?
• Stimmen Lieferant, Gesellschaft, Betrag, Währung und Steuerlogik mit der Historie überein?
• Ist die Bankverbindung bestätigt und unverändert?
• Gibt es Druck, Dringlichkeit oder ungewöhnliche Kommunikationsmuster?
• Wurde eine Lookalike-Domain, ein neuer Ansprechpartner oder neuer Kanal festgestellt?
• Ist ein Payment Hold gesetzt, solange Fragen offen sind?

16.3 Entscheidungsbaum für Bearbeiter

Schwache Einzelhinweise ohne harte Warnsignale gehen in die erweiterte Fachprüfung. Neue Bankverbindung, Lookalike-Domain, fehlender PO-Bezug in kritischen Kategorien oder mehrere Red Flags führen zwingend zu Block und Verifikation. Bestätigter Missbrauch verbindet Vendor, Zahlung, Kommunikation und Incident Handling in einem Fall.

16.4 Vierteljährlicher Kontrolltest

Mindestens vierteljährlich sollten neue Vendoren, Bankdatenwechsel, manuelle Overrides, simulierte Bankänderungen, offene Holds und False Positives stichprobenartig überprüft werden. Der Test muss nicht groß sein, aber verbindlich.

16.5 Was eine gute SOP auszeichnet

Eine gute SOP ist kurz genug für den Alltag und konkret genug für den Ernstfall. Sie benennt Trigger, Schritte, zulässige Kontaktwege, Rollen, Nachweise und Abbruchkriterien. Alles, was offen bleibt, wird im Ernstfall von Gewohnheit, Hierarchie oder Zeitdruck entschieden.

A Glossar

Aus dem umfangreichen Glossar des Ausgangsdokuments wurden hier die für den Web-One-Pager wichtigsten Begriffe verdichtet.

B Praxisleitfragen für Workshops

• Welche Rechnungen dürfen heute ohne Bestellung verarbeitet werden?
• Wie oft werden Bankdaten geändert und wie wird die Verifikation belegt?
• Welche Gesellschaften oder Teams nutzen Sonderwege?
• Welche Daten braucht ein Angreifer, um einen plausiblen Fall zu bauen, und wo könnte er sie erhalten?
• Welche Hold-Gründe existieren heute, und sind diese mit klaren Playbooks verbunden?
• Wer würde im Ernstfall in den ersten 30 Minuten was tun?

C Hinweis zu Herstellerprodukten

Produktnamen wie SAP Business Integrity Screening, AppZen, Oversight, Medius Fraud & Risk Detection, Trustpair oder NoSpamProxy sind hier als Marktbeispiele bzw. thematische Ergänzungen eingeordnet. Funktionsumfang, Lizenzierung, Integrationen und Produktbezeichnungen können sich ändern; eine konkrete Auswahl braucht immer aktuelle Herstellerunterlagen und eine Passungsprüfung zur eigenen Prozesslandschaft.

D Schlussbemerkung

Rechnungsbetrug im Umfeld Rechnungseingang und SAP ist weder ein reines IT- noch ein reines Finance-Thema. Die wirksamsten Organisationen sind jene, die Standards durchsetzen, Ausnahmen begrenzen, Signale früh erkennen und verdächtige Fälle diszipliniert behandeln.

E Optionale Lesetipps und Herstellerseiten

Die folgenden Links dienen als Ausgangspunkt für Produktrecherche und thematische Vertiefung. Sie öffnen jeweils in einem neuen Tab; auf den deutsch- und englischsprachigen Versionen der Seite werden – sofern verfügbar – passende Sprachversionen der Zielseiten verwendet.

SAP

SAP Business Integrity Screening

Regel- und anomaliestützte Erkennung verdächtiger Geschäftsvorfälle im SAP-nahen Umfeld.

SAP-natives Screening

AppZen

AppZen Fraud and Risk Detection

Fokus auf Rechnungsprüfung, Supplier-Checks und risikoorientierte Auffälligkeitserkennung.

AI AP Audit

Oversight

Oversight AI P2P Compliance

Kontinuierliche Überwachung von Procure-to-Pay-Mustern über Rechnungen, POs und Zahlungen.

P2P Monitoring

Medius

Medius Fraud & Risk Detection

Anomalieerkennung und Risikosignale entlang des gesamten Invoice-to-Pay-Lebenszyklus.

Invoice-to-Pay

Trustpair

Trustpair Account Validation

Verifikation von Kontoinhaberschaft und Vendor-/IBAN-Daten als Schutz vor Zahlungsumleitung.

Konto-Validierung

Net at Work

NoSpamProxy

Thematische Ergänzung für den Eingangskanal: Schutz vor Spoofing, Lookalikes und Phishing im Mailfluss.

E-Mail-Security