In dem zweiten Teil zur Prüfung des Einkaufs stelle ich den automatisierten Ansatz mit seinen verschiedenen Facetten etwas näher vor. Ein Großteil der Analysen können selbstverständlich auch manuell durchgeführt werden, wird aufgrund des Umfangs allerdings nicht empfohlen.
Die Themen des Blog Beitrags zu den Details der automatisierten Prüfung des Einkaufs in der Übersicht:
- Stammdaten im Einkauf
- Bestellungen und Wareneingänge
- Rechnungsprüfung
- Doppelzahlungen
- Exotische Prozesse
- Funktionstrennung
Stammdaten im Einkauf
„Kreditoren“ ist das Stichwort im Prozessbereich der Prüfung von SAP Stammdaten. Dabei handelt es sich ganz klassisch um die Lieferanten einer Waren- oder Dienstleistung. In diesem Bereich können sehr viele Fehler unterlaufen, die spätestens bei einer Prüfung Fragen aufkommen lassen. Das geht stellenweise so weit, dass Sie in sich gehen und fragen werden: „Wie geht das denn?“. Aber auch dann können wir Ihnen versichern, dass nahezu alle Indikatoren schon vorgekommen sind und nicht aus heiterem Himmel gegriffen wurden. Ein Paradebeispiel dafür ist meiner Ansicht nach der Indikator:
Buchungen mit nichtexistierendem Kreditor
Betrachten wir das Kriterium, nach dem ein Beleg „getagged“, bzw. markiert wird, dann wird die Funktionsweise deutlicher:
Der Rechnungswesenbeleg wird markiert, weil dieser einen Kreditor referenziert, zu dem ein Stammsatz nicht gefunden wurde.
Im letzten Blog Post im Abschnitt der SAP Datenstruktur des Einkaufs haben wir die entsprechenden Tabellen bereits kennengelernt. Die Kreditorenstammdaten befinden sich demnach in den Tabellen LFA1 und LFB1. Den Ursprung der Referenz haben wir im letzten Blog Post über die Prüfung des Einkaufs auch bereits erwähnt: Einer der Dreh und Angelpunkte im SAP Finanzwesen: Tabelle BSEG (Belegsegment Buchhaltung). Aber warum hält die Tabelle BSEG denn nur eine Referenz auf die Tabellen LFA1 und / oder LFB1 werden Sie sich vermeintlich fragen. Die Antwort darauf ist so einfach, wie einleuchtend: So kann gewährleistet werden, dass Daten nicht mehrmals gespeichert werden. Stellen Sie sich vor, dass alle Daten über Obst Müller, wie z.B. Adresse, Konto, USt. ID, usw. immer und immer wieder in den Tabellen stehen. Sie schreiben doch schließlich auch keinen Einkaufszettel für sich, um dann einen zweiten für Ihren Ehepartner zu schreiben, oder?
Den Indikator verdeutlichen die zwei Tabellen auf vereinfachte Weise noch einmal:
Tabelle BSEG Tabelle LFA1
| Kreditorennummer / Lieferantennummer | Belegnummer | Kreditorennummer / Lieferantennummer | Name | |
| 1203 | 1800000004 | 1203 | Obst Müller | |
| 1204 | 1800000013 | 1205 | Beton Berta | |
| 1205 | 1800000068 |
Sollte die Kreditorennummern „1204“ in LFB1 auch nicht vorhanden sein, so würde der Beleg von dem Indikator markiert werden. Damit besteht das Risiko, dass Buchungen nicht mehr nachvollzogen werden können, weil der Kreditorenstammsatz nicht (mehr) existiert.
Weitere Indikatoren aus dem Bereich Stammdaten im Einkauf sind z.B.:
Kreditorenstammdaten ohne oder mit unvollständigen Zahlungsbedingungen
Dieser Indikator ist dem Prüfungsziel Wirtschaftlichkeit zugeordnet.
Es besteht das Risiko von Vermögensschäden, da Skonto nicht genutzt werden kann.
Das Kriterium für das Markieren eines Belegs ist:
Der Beleg wird markiert, wenn bei dem referenzierten Kreditor keine oder unvollständige Zahlungsbedingungen gepflegt sind.
Rechnungen mit Kreditoren ohne Bankverbindung
Dieser Indikator ist dem Prüfungsziel Ordnungsmäßigkeit zugeordnet.
Es besteht das Risiko nicht rückverfolgbarer Zahlungen.
Das Kriterium für das Markieren eines Belegs ist:
Der Rechnungswesenbeleg wird markiert, da dieser einen Kreditor referenziert, für den kein Bankkonto gepflegt wurde. Für den Lieferanten wurde im Geschäftsjahr aber mindestens eine Zahlung identifiziert.
Die Vorstellung aller Indikatoren würde den Rahmen eines einzigen Blog Posts deutlich sprengen. Daher haben wir Ihnen alle Indikatoren aus dem Bereich des Einkaufs in einem Whitepaper zusammengefasst und nach Prozessbereich gegliedert. Dieses erhalten Sie unter folgendem Link:
Bestellungen und Wareneingänge
Insbesondere im Bereich der Bestellungen und Wareneingänge kommt es sehr häufig zu ungewollten Prozessabläufen. Entweder werden erst Wareneingänge gebucht und danach die zugehörige Bestellung, Wareneingänge ohne Referenz auf eine Bestellung, oder Bestellungen mit fehlenden oder unvollständigen Zahlungsbedingungen. Damit hätten wir schon drei Indikatoren benannt, die in die Prozessbereiche der Bestellungen und Wareneingänge fallen. Diese Liste könnte ich noch weiter fortführen, aber werfen wir mal einen genaueren Blick auf die erwähnten drei Indikatoren:
Nachträglich angelegte Bestellung
Die nachträglich angelegten Bestellungen unterliegen dem Prüfungsziel der Ordnungsmäßigkeit, da Standardprozesse unter Umständen nicht eingehalten werden.
Der Rechnungswesenbeleg wird markiert, wenn dieser früher als die referenzierte Bestellung erfasst wurde.
Wareneingänge ohne Bestellungen
Dieser Indikator unterliegt dem Prüfungsziel der Prozessstandardisierung, weil das Risiko besteht, dass bei Warenbewegungen später die Rechnungsprüfung, mangels fehlender Bestellung, erschwert wird.
Der Rechnungswesenbeleg wird markiert, wenn dieser mit einem Materialbeleg verknüpft ist, bei dem die Bewegungsart 501 verwendet wird. 501 bedeutet Wareneingang ohne Bestellung.
Bestellungen mit fehlenden oder unvollständigen Zahlungsbedingungen
Fehlende Zahlungsbedingungen deuten bereits auf das Prüfungsziel der Wirtschaftlichkeit hin, dem dieser Indikator unterliegt. Es besteht das Risiko entgangener Skonti aufgrund fehlender Zahlungsbedingungen. Dieser Indikator hilft Ihnen schnell und einfach in Zukunft Geld im Einkauf zu sparen und den Einkauf so effizienter zu gestalten. Insgesamt haben wir 15 Indikatoren implementiert, die dem Prüfungsziel Wirtschaftlichkeit unterliegen.
Rechnungsprüfung
Wurden die Bestellungen und Wareneingänge ordnungsgemäß geprüft, dann folgen in der Prozesskette in aller Regel die Rechnungen. Allerdings kann es auch bei den Rechnungen zu Abweichungen vom Standardprozess kommen, indem Rechnungen vor den Wareneingängen beglichen werden. Selbstverständlich haben wir dafür auch einen Indikator entwickelt und implementiert:
Rechnungsausgleich vor Wareneingang
Dieser Indikator prüft weniger auf die Daten an sich, sondern auf Basis der erstellten Sequenzen des Financial Process Minings. Ein denkbares Risiko wäre dann z.B. die Zahlung einer Leistung, ohne dass diese (bereits) erbracht wurde. Demnach wird ein Rechnungswesenbeleg markiert, wenn das Erfassungsdatum des Ausgleichsbelegs zur Auszifferung der Rechnung (in der Regel die Zahlung) vor dem Buchungsdatum des Wareneingangs liegt.
Allerdings analysiert zap Audit nicht nur sequentielle Probleme in den Prozessen. Speziell bei den Rechnungen gibt es viele Facetten, die analysiert werden können. Angefangen von statistischen Ausreißern, wie z.B. der Indikator „Eingangsrechnung mit hoher Rechnungssumme“ verdeutlicht, bis hin zu Doppelzahlungen, auf die wir im nächsten Abschnitt etwas genauer eingehen werden. Für die Statistikfans unter Ihnen:
Eingangsrechnung mit hoher Rechnungssumme
Ein Rechnungswesenbeleg wird markiert, wenn dieser eine Rechnungssumme enthält, die für den Lieferanten außergewöhnlich hoch ist. Das bedeutet, sie liegt 6 Standardabweichungen über der durchschnittlichen Rechnungssumme des Lieferanten. Es werden nur Lieferanten berücksichtigt, für die über 20 verschiedene Rechnungsbelege gefunden wurden. Diese Analyse basiert auf der Ungleichung von Tschebyscheff, die wir bereits im Artikel „Anleitung zur Analyse hoher Rechnungssummen“ beschrieben haben.
Doppelzahlungen
Es ist nicht immer leicht für die Revision, Ihren Wertbeitrag für das Unternehmen aufzuzeigen und zu kommunizieren. Häufig wird die Revision schlicht als regulatorische Notwendigkeit betrachtet. Natürlich ist es einfacher, wenn durch die Erkenntnisse der Revision bares Geld gespart wird. Deshalb haben wir eine vierteilige Serie komplett dem Thema der Doppelzahlungen in SAP gewidmet. Hier finden Sie den ersten Teil der Serie „Cashback: Wie sich die Revision mit Hilfe von Doppelzahlungen amortisiert„. Aus diesem Grund werden an dieser Stelle lediglich kurz und knapp die Grundlagen zur Erkennung von Doppelzahlungen genannt. Es lässt sich in den seltensten Fällen definitiv sagen, dass es sich um eine Doppelzahlung handelt, aber sollten die folgenden Indikationen gemeinsam, oder größtenteils gemeinsam auftreten, so erhöht sich die Wahrscheinlichkeit:
gleiche Beträge in verschiedenen Belegen und
gleiches Buchungsdatum und
gleiches Belegdatum und
gleiche Belegart und
gleiches Rechnungswesen Konto und
gleicher Lieferant und
gleiche externe Rechnungsnummer.
Exotische Prozesse
Die Überschrift „Exotische Prozesse“ ist unter Umständen etwas weit hergeholt, aber beschreibt ziemlich gut, wovon diese Indikatoren eigentlich handeln. Neben den Prüfungsbereichen Stammdaten, Bestellungen, Wareneingang, Eingangsrechnungen und Zahlungen beinhaltet zap Audit zusätzlich den Bereich der Prozessplausibilität, den wir in diesem Abschnitt kurz und knapp betrachten. Eine Vielzahl an Indikatoren aus diesem Bereich lässt bereits beim Lesen des Namens einen kleinen Schauer über den Rücken laufen. Das ist nicht verwunderlich, da sie in einzelnen Fällen durchaus zu Fraud Fällen führen. Dazu zählen z.B. Buchungen mit gesperrten Kreditoren oder Mehrfach geänderte Kreditor-Bankverbindungen.
Betrachten wir die Buchungen mit gesperrten Kreditoren, so lässt der Name vermuten, dass es sich um einen Widerspruch in sich handeln muss. Allerdings weit gefehlt. Entweder hat ein SAP Nutzer ausreichend Rechte, um einen Kreditor zu entsperren, eine Buchung vorzunehmen und diesen wieder zu sperren, aber es besteht auch die Möglichkeit der Absprache zwischen zwei SAP Nutzern. Beides denkbare Szenarien, die selbstverständlich nicht die einzigen Gründe für das Markieren von Belegen durch diesen Indikator sein müssen:
Ein Rechnungswesenbeleg wird markiert, wenn dieser einen Kreditor referenziert, bei dem es vor und nach diesem Beleg eine Änderung des Sperrkennzeichens gab. Die Änderung findet dabei am selben Tag statt.
Die mehrfach geänderten Kreditor-Bankverbindungen sind vom Grundprinzip ähnlich. Ein Rechnungswesenbeleg wird genau dann markiert, wenn dieser zwischen zwei Änderungen des Bankkontos eines im Beleg verwendeten Lieferanten erfasst wurde. Dabei liegen diese Änderungen an dem Bankkonto maximal 7 Tage auseinander.
Funktionstrennung
Funktionstrennung in SAP bedeutet, dass bestimmte Kombinationen von Aufgaben nicht von derselben Person durchgeführt werden sollen, weil es sich um eine kritische Aufgabenkombination handelt. Es gibt am Markt verschiedene Tools zur Auswertung von Funktionstrennungskonflikten in SAP. In der Regel werden dabei die Berechtigungen in SAP ausgewertet, um festzustellen, welcher Nutzer welche Transaktionen durchführen darf. Dies führt zu der Feststellung, ob ein User eine kritische Kombination von Transaktionen durchführen könnte.
Insbesondere interessant ist aber, ob ein Nutzer eine kritische Kombination tatsächlich ausgeführt hat und zwar im Rahmen desselben Prozessablaufs. Denn in einem solchen Fall wurde die Funktionstrennung bezüglich der kritischen Aufgabenkombination tatsächlich in einem zusammenhängenden Geschäftsvorfall verletzt. Eine solche Analyse wird von den meisten Analysetools am Markt nicht geboten, weil dazu zuerst der komplette Prozessablauf ermittelt werden muss. Durch den Financial Process Mining Algorithmus ist diese Voraussetzung erfüllt, sodass eine solche Analyse ermöglicht wird.
Einige Beispiele der knapp 149 Funktionstrennungskonflikte, die zap Audit automatisiert über alle Prozessbereiche aufdeckt, sind im Bereich des Einkaufs:
- Fiktiven Lieferanten anlegen und Zahlung an den Lieferanten initiieren
- Fiktiven Lieferanten bearbeiten und Auszahlung dorthin leiten
- Fiktive Lieferantenrechnung anlegen und Zahlung dafür initiieren
- Nicht autorisierte Positionen kaufen und Zahlung durch Rechnungsstellung initiieren
- Nicht autorisierte Positionen kaufen und durch unvollständigen Empfang des Auftrags verbergen
- Nicht autorisierte Positionen kaufen und Zahlung für sie veranlassen
- Fiktiven Lieferanten bearbeiten und Kauf beim Lieferanten initiieren
- Dienstleistungen empfangen und gesperrte Rechnung zur Gegenbuchung des Zugangs freigeben
- Bestellung bearbeiten und eine zuvor gesperrte Rechnung freigeben
