Die Anlage und Veränderung von Stammdaten oder Master Data der Lieferanten ist ein Risikofeld. Denn Kreditoren werden bilanziell auf der Habenseite erfasst. Das bedeutet, sobald eine Lieferantenrechnung buchhalterisch erfasst ist, gilt diese als Verbindlichkeit und der Ausgleich einer Verbindlichkeit erfolgt in der Regel durch Auszahlung. Geld fließt aus dem Unternehmen.
Ergo kann ein BetrügerIn, der Zugriff auf die Kreditorenstammdaten hat, unrechtmäßig Geld aus dem Unternehmen auf seine/ihre oder von ihm/ihr bestimmte Konten schleusen. Im schlimmsten Fall, fällt dies nicht einmal auf, weil das interne Kontrollsystem lückenhaft ist, also zum Beispiel Funktionstrennung nicht gegeben ist.
Wie man solche systemseitigen Schwachstellen identifiziert, schildere ich im Folgenden. Später zeige ich wie man mit Datenanalyse im SAP Hinweise auf mögliche betrügerische Auszahlungen an Kreditoren durch Änderungen der Kontodaten von Lieferanten aufspüren kann.
Einstellungen im SAP
Das betrifft alle Benutzerberechtigungen in SAP: Mit der SAP_ALL oder SAP_NEW Berechtigung kann ein User alles in dem ERP System. Das Risiko dieser Berechtigungen ist damit sehr groß und daher sollten sie im Unternehmen sehr restriktiv vergeben werden. Man glaubt aber nicht, dass es in der Praxis meist ganz anders aussieht. Daher fängt eine systemseitige Überprüfung der Berechtigungen im SAP System hier an.
Anhand der SAP Tabelle UST04 können wir die Nutzer mit diesen Berechtigungen identifizieren und diese dann mit der Abteilung besprechen, die für die Vergabe der Nutzerrechte in SAP zuständig ist. SAP Tabellen ziehe ich immer über die Transaktion SE16. Wer Zugriff zur Transaktion SE16n hat: Noch besser.
Nun gehen wir zurück zu den Kreditorenstammdaten: Systemseitig ist SAP so angelegt, dass bei der Anlage und Änderung von Kreditorenstammdaten das Vier-Augen-Prinzip greift. Stammdaten werden von einer Person angelegt oder geändert und eine separate Person gibt dies im System frei. Somit soll die Funktion der Anlage/Änderung von der Bestätigung getrennt sein. Oftmals trennen die Systemeinstellungen im Unternehmen jedoch nicht klar diese Funktionen. Das werden wir mit den folgenden Schritten untersuchen:
Dazu benötigen wir einerseits die SAP Tabelle LFB1, die die Lieferanten-Buchungsdaten beinhalten, sowie andererseits die Tabelle mit den Änderungsbelegköpfen, CDHDR. Letztere Tabelle filtern wir im Feld "TCODE" nach Transaktion "FK08" und "FK09". Beide Transaktionen stehen für die Freigabe von Kreditorenstammdatenänderungen. Mit Hilfe des Quik Viewers direkt in SAP, also der Transaktion SQVI, oder mit einem Datenanalysetool wie IDEA verbinden wir dann die beiden Tabellen.
Das Feld über das wir verknüpfen heißt in der Tabelle LFB1 "ERNAM" und in der Tabelle CDHDR "USERNAME". Das Feld "ERNAM" zeigt den User, der die Buchungsdaten, also auch die kritischen Kreditorendaten, angelegt hat. Während "USERNAME" den Nutzer hinter der Freigabe aus der Tabelle "CDHDR" zeigt. Wenn wir als Verbindungsart "Nur Übereinstimmungen" wählen, so erhalten wir als Ergebnis alle User die Kreditorenstammdaten verändert haben und dies selber freigegeben haben.
Änderungen an Kontodaten von Kreditoren
Im Folgenden untersuchen wir speziell kurzzeitige Änderungen an Lieferantenbankdaten: Der potentielle Betrüger ändert kurz vor der Auszahlung einer Rechnung eines bestehenden und legitimen Lieferanten dessen Kontodaten. So fließt die Zahlung des Unternehmens an beispielsweise sein oder ihr Konto. Kurz nach der Auszahlung ändert der Betrüger oder die Betrügerin die Bankdaten wieder auf ihre ursprünglichen Einstellungen. So bekommt niemand was mit.
Das glaubt zumindest der Betrüger.
Doch da hat er nicht mit uns gerechnet. Anhand der im Folgenden erläuterten Schritte, kommen wir solcher Betrügereien nämlich auf die Schliche.
1. Schritt: Schritt: Daten extrahieren
Dazu ziehen wir uns zuerst einmal alle Einzelpositionen der Änderungen in SAP mit der Tabelle "CDPOS". Grundsätzlich speichert SAP Änderungen in zwei Tabellen ab: In der Tabelle "CDHDR" werden die Änderungsbelegköpfe abgelegt und in der eben genannten CDHDR wie gesagt die dazugehörigen Änderungsdetails. Wir machen es hier nicht komplizierter als nötig und gehen daher auch nicht tiefer ins Detail dieser Tabellen.
Wir beginnen also mit der CDPOS und grenzen die Ausgabe noch wie im nebenstehenden Schaubild ein -->
Dabei steht die Objectclas "KRED" natürlich für die Eingrenzung auf Kreditoren. Mit der Auswahl der Tabelle "LFBK" limitieren wir die Auswahl auf Änderungen der Tabelle mit Daten zu Bankverbindungen der Lieferanten und grenzen dann noch weiter ein auf Änderungen der u.a. Kontonummer mit der Eingabe "KEY" in der Spalte Feldname oder FNAME.
Als nächstes ziehen wir ebenso mit Hilfe der Transaktion SE16 die Tabelle CDHDR. Hierin sind die Kopfdaten der Änderungsbelege gespeichert und wir benötigen sie für das Datum und sowie die Uhrzeit der Änderung. Wir ziehen sie aus SAP mit folgenden Eingaben:
Wie schon bei der CDPOS wählen wir nur die Objectclas "KRED" aus. In der Spalte Transaktionscode, also TCODE, wählen wir die zwei Transaktionen "FK02" und "XK02", die für die Änderung von Kreditorenstammdaten von den Anwendern benutzt wird:
Beide SAP Tabellen speichern wir lokal ab, so dass wir sie in einem nächsten Schritt in Excel zum weiteren Bearbeiten öffnen. Wie man SAP - Tabellen speichert und in Excel öffnet, zeige ich in einem separaten Blogeintrag.
2. Schritt: Datentabellen aufbereiten in Excel
Sobald wir beide Dateien als Excel - Tabellen geöffnet haben, verbinden wir sie miteinander, damit wir das Änderungsdatum in der CDPOS Tabelle haben. Das machen wir also in der CDPOS in Excel mit der Funktion SVerweis. Die genaue Funktionsweise zu dieser für die Data Science wichtige Funktion beschreibe ich in einem separaten Blogpost. Hier hängen wir nun über das Suchkriterium "CHANGENR", also die Änderungsbelegnummer, aus der Matrix CDHDR, den Spaltenindex "UDATE", also das Änderungsdatum an. In einer Spalte weiter hängen wir über das selbe Suchkriterium und aus derselben Matrix noch die Spalte "UTIME", also Änderungsuhrzeit mit Hilfe des SVerweises an.
[Das Verbinden der beiden SAP - Tabellen geht sauberer und einfacher mit Datenbanktools wie IDEA. Wer damit arbeitet, kann den Table-Join und auch die folgende Auswertung in einer Pivot-Tabelle auch in einer solchen Datenbanksoftware durchführen. Das hat den Vorteil höherer Transparenz. Table-Joins mit IDEA zeige ich in diesen Blogposts. An dieser Stelle zeige ich jedoch wie die Prüfung komplett mit Excel gelingt.]
Die somit erweiterte CDPOS - Tabelle schmeißen wir dann in eine Pivottabelle. Hier nehmen wir als Zeilen das Feld "OBJECTID" und darunter als zweite Zeile das Feld mit der Datumsspalte aus der Ursprungstabelle CDHDR. Als Wert nimmt man dann noch die Anzahl von dem eben genannten Datumsfeld aus der CDHDR und wählt dann noch das klassische Pivot - Layout wie folgt aus:
-rechter Mausklick auf die Pivot-Tabelle
-Reiter: Anzeige
-Haken setzen bei "Klassisches PivotTable-Layout
Abschließend sortieren wir die Ergebnisspalte absteigend und fertig sind wir mit der Datenaufbereitung! Als Ergebnis sollte die Pivottabelle von der Struktur her nun wie nebenstehend ausschauen:
Weitere Erklärungen zum SVerweis bietet auch diese Seite von Microsoft: hier
3. Schritt: Data Mining
Mit dieser Sortierung finden wir nun Kreditoren deren Bankverbindung innerhalb eines Tages verändert wurde. Mit einem Doppelklick auf eines der Werte in der Spalte Ergebnis sehen wir genauere Details wie vor allem die Uhrzeit.
Doch wir erfahren noch mehr über die Änderungen an dem jeweiligen Lieferanten mit Hilfe der Änderungshistorie in SAP. Dazu benutzen wir entweder den Report RFKABL00 mit der Transaktion SA38. Oft sind die Berechtigungen im Reportreader von SAP eingeschränkt. Daher geht das genauso über die Transaktion S_ALR_87012089:
Hier geben wir als Kreditor den Wert aus der Spalte "OBJECTID" aus unserer Pivottabelle ein. Wenn nämlich Änderungen an den Kreditorenstammdaten vorgenommen werden, ist die ObjectID gleich der Lieferantennummer in SAP.
In dieser Auswertung sehen wir nun was Schritt für Schritt wann geändert wurde. Falls nun in kurzer Zeit hintereinander im Feldnamen Bankverbindung von ein und derselben Person zuerst gelöscht, eine neue Kontonummer dann angelegt, wenig später wieder gelöscht und die vorige Kontonummer wieder eingegeben wurde, sollte man diesen Vorgang mit einem Red-Flag versehen und weiter nachforschen.
Das geht beispielsweise mit Hilfe des Abgleichs der zwischenzeitlich angegebenen Bankverbindung mit den Angaben auf den Rechnungen dieses Lieferanten. Denn grundsätzlich sollte der Wert sowie die Bankverbindung der Auszahlung mit der Lieferantenrechnung übereinstimmen.
Gibt es hier weiterhin Unstimmigkeiten, wäre der nächste Schritt mit Interviews der Anwender oder Genehmiger dieses Vorgangs, um genaue Gründe für die Änderung oder den Inhaber des zwischenzeitlichen Bankkontos zu nennen, wahrscheinlich.
So geben uns Auffälligkeiten bei dieser Process Mining - Analyse in den ERP - Stammdaten der Lieferanten also starke Indikation für betrügerische Transaktionen, sprich Red-Flags, und Anlass die Verdachtsmomente mit weiteren Beweisen oder Indizien zu untermauern. Ist sicherlich nicht die einfachste Analyse und hoffentlich führt sie auch zu einem negativen Ergebnis. Doch und denn hier geht es ja darum in der Regel schwerwiegenden Betrug aufzudecken.
Kommentar schreiben