Im Fokus einer Prüfung von Geschäftsprozessen in SAP steht unserer Erfahrung nach ganz häufig der Einkauf, gefolgt von Berechtigungen. Über die Gründe dafür möchte ich an dieser Stelle gar nicht spekulieren. Viel mehr geht es in diesem Artikel um alles, aber auch wirklich alles, was mir zu den Grundlagen der Prüfung des Verkaufs in SAP anhand von Datenanalysen eingefallen ist.
Okay alles war vielleicht etwas übertrieben, allerdings habe ich mal zusammengefasst, welche Themen und Bereiche im Verkauf relevant sind und vielleicht Gegenstand der nächsten Prüfung sein könnten. Also legen wir los.
Bevor in einer Prüfung des Verkaufs in SAP mit umfangreichen Datenanalysen begonnen werden kann, sollten auch in einer digitalen Prüfung die Kenntnisse der tatsächlichen Verkaufsprozesse Grundlage der Prüfung sein. In dem Zusammenhang rede ich allerdings nicht von Interviews zur Erhebung, sondern der empirischen Ermittlung aus dem vorhandenen Datenbestand. Was Sie außerdem in diesem Beitrag erwartet?
- Was unterscheidet den Einkauf von dem Verkauf in SAP?
- Was versteht man unter der datenbasierten Prüfung?
- Welche Tabellen dienen als Grundlage und wie erhält man eigentlich Daten?
- Wie kann eine Prüfung der Stammdaten im Verkauf aussehen?
- Welche Prüfungsfragen bringen im Verkauf bares Geld ein?
- Ein Klassiker: Funktionstrennungen im Verkauf
1. Was unterscheidet den Einkauf von dem Verkauf in SAP
Vergleicht man die Organisation der Daten im SAP System zwischen Einkauf und Verkauf so fällt folgendes auf: Im Verkauf sind die Datenstrukturen so angelegt, dass der Verkaufsprozess (SAP Modul Sales and Distribution SD) erheblich komplexer ausgestaltet werden kann als der Einkauf. Während es im Einkauf im Wesentlichen außerhalb des Rechnungswesens „nur“ Bestellanforderungen und Bestellungen gibt, gibt es im Verkaufsprozess den sogenannten Verkaufsbelegfluß. Dieser Verkaufsbelegfluß kann recht flexibel und individuell definiert werden und enthält im einfachsten Fall den „Dreiklang“: Auftrag => Auslieferung => SD Rechnung. Der Vertriebsbelegfluß kann aber auch erheblich erweitert werden z.B. um Anfragen und Angebote, muss dies aber nicht. Der Financial Process Mining Algorithmus in zap Audit und zapCash berücksichtigt auch den Vertriebsbelegfluss und schreitet diesen vollständig ab, sodass jeder individuelle Verkaufsablauf in den Daten offenbar wird.
2. Was versteht man unter der datenbasierten Prüfung?
Nachdem die Prozesse rekonstruiert wurden, ganz unabhängig davon, ob in zap Audit oder auch manuell über die Erkenntnisse über den Vertriebsbelegfluß, folgen die eigentlichen Datenanalysen und die Prüfung. Wir nennen die Datenanalysen bei uns Indikatoren, weil die Ergebnisse einer Datenanalyse, Indikationen für eine Feststellung darstellen. Es gibt nur wenige Datenanalysen, wo man bei einem Ergebnis direkt sagen kann, dass es sich um eine Feststellung handelt. Allerdings wären Funktionstrennungskonflikte so ein Beispiel, denn Belege werden nun mal mit einer bestimmten Transaktion gebucht und das ist erstmal ein Fakt und lässt keine Zweifel offen.
Indikatoren korrespondieren stets mit einer revisionsrelevanten Prüfungsfrage. Technisch gesehen handelt es sich um Datenabfragen (Database Queries), die Belege aus dem Datenbestand suchen und bestimmten vordefinierten Kriterien genügen.
Allerdings muss der Indikator so definiert sein, dass er stets und ausschließlich auf die Ermittlung einer Menge von einzelnen Belege abzielt, d.h. alle Belege im Datenbestand werden daraufhin untersucht, ob der Indikator für einen Beleg relevant ist oder nicht (der Indikator teilt alle Belege also in eine Art „Schwarz-Weiß-Welt“ ein).
Nachdem der Indikator „durchgelaufen“ ist, werden alle einschlägigen Belege mit dem Indikator markiert. Betroffene Belege haben dann eine Indikation auf eine Feststellung im Hinblick auf diesen Indikator.
Um besser in den Indikatoren navigieren zu können, ist jeder Indikator verschiedenen Dimensionen zugeordnet. Jeder Indikator gehört zu einem bestimmten Prozess, zu einem bestimmten Prozessbereich und hat ein bestimmtes Prüfungsziel. Für den Verkauf bedeutet das:
- Prozess: Verkauf
- Prozessbereiche: Stammdaten, Faktura, Zahlung, Lieferung, Verkaufsbeleg und Prozessplausibilität
- Prüfungsziele: Ordnungsmäßigkeit, Wirtschaftlichkeit und Prozessstandardisierung
In dem folgenden ePaper haben wir alle genannten Informationen für Sie inkl. einem beispielhaften Risiko zusammengefasst:
Einige Beispiele aus den verschiedenen Prozessbereichen stelle ich außerdem im Laufe des Artikels vor. Eine detaillierte und ausführliche Auflistung würden den Rahmen des Artikels an dieser Stelle wohl sprengen.
3. Welche Tabellen dienen als Grundlage?
Die für den Revisor wichtigsten SAP Tabellen des Verkaufs sind:
- VBRK: Kopfdaten von Rechnungen aus dem SAP Modul Sales and Distribution (SD)
- VBRP: Positionsdaten von Rechnungen aus dem SAP Modul Sales and Distribution (SD)
- LIKP: Kopfdaten von Lieferungen
- LIPS: Positionsdaten von Lieferungen
- VBAK: Kopfdaten von Aufträgen
- VBAP: Positionsdaten von Aufträgen
- BKPF: Kopfdaten eines Rechnungswesenbelegs
- BSEG: Kontierungszeile oder Position eines Rechnungswesenbelegs
- KNA1: Stammsatz für Kunden / allgemeiner Teil
- KNB1: Stammsatz für Kunden/ buchungskreisspezifischer Teil
- KNBK: Bankkontenstamm der Kunden
Zusammenhänge mit dem Rechnungswesen
Bestimmte Belege im Rechnungswesen (FI) verweisen auf Belege des Verkaufs. Solche Rechnungswesenbelege sind häufig debitorische Rechnungen und Warenausgänge. Dabei verweist die Position eines Rechnungswesenbelegs (Tabelle BSEG) im Datenfeld VBELN (Verkaufsbelegnummer) auf den Kopf einer SD Rechnung (in Tabelle VBRK).
Wie bekomme ich Daten aus SAP
Die Beschaffung der Daten aus einem SAP System ist nicht immer eine einfache Sache. Es gibt verschiedene Tools auf dem Markt, die Datenextraktionen aus einem SAP System anbieten. In der Regel wird dafür ein ABAP Programm auf dem SAP System eingespielt. Dies ist aber zugleich auch ein „Showstopper“, da Transporte in ein SAP System einen Change Management Prozess voraussetzen und häufig lange dauern und diverse Genehmigungsschritte durchlaufen müssen.
Eine weitere Möglichkeit besteht daran, im SAP Dialog einzelne Tabellen manuell aus dem SAP System herunterzuladen. Hierfür kann die Transaktion SE16 verwendet werden. Dies ist aber insgesamt mit vielen Handgriffen verbunden und eher umständlich.
Per Remote Function Call (RFC) kann man SAP Datentabellen aus einem SAP System extrahieren. Hierfür wird lediglich ein User mit entsprechenden Nutzerrechten für das Aufrufen von Remote Function Call Bausteinen benötigt. Es braucht dabei kein ABAP Programm in das SAP System transportiert zu werden. RFC ist zwar verhältnismäßig alt und z.T. auch langsam, jedoch etabliert und bei jedem SAP System verfügbar. Man kann einen solchen Datenabzug mit RFC clever optimieren und so bequem Daten für eine Analyse aus dem SAP System beschaffen. In zap Audit nutzen wir diesen Ansatz, um die Daten automatisiert aus dem SAP System in eine lokale Datenbank beim Kunden zu spiegeln.
4. Wie kann eine Prüfung der Stammdaten im Verkauf aussehen?
Nachdem wir ausreichend Daten gesammelt haben können die ersten Datenanalysen losgehen. Doch was will ich überhaupt prüfen? Hier mal ein paar Anreize aus zap Audit:
Buchungen mit Debitoren ohne Umsatzsteuer ID
Eine recht einfache, jedoch wirkungsvolle Analyse, die immer einen Blick wert ist. Warum? Weil das Risiko besteht, dass die Umsatzsteuer nicht richtig erfasst wurde und sich der Fiskus meldet. Doch zwei kleine Besonderheit gilt es zu beachten: Der Debitor…
- …muss in einem anderen EU Land als dem eigenen sitzen und
- darf keine natürliche Person sein
Buchungen mit nicht existierendem Debitor
Okay diese Analyse ist wirklich einfach: Zu dem Feld KUNNR der Tabelle BSEG wird kein Stammsatz in den Tabellen KNA1 und KNB1 gefunden. In dem Zusammenhang sind diverse Szenarien denkbar, warum das der Fall sein könnte. Der einfachste Grund dürfte das harte Löschen eines Stammsatzes sein, was laut dem Radierverbot (§239 HGB) nicht erlaubt ist.
Sie suchen noch mehr? Dann finden Sie hier alle 42 Indikatoren zur Prüfung des Verkaufs aus zap Audit:
5. Welche Prüfungsfragen bringen im Verkauf bares Geld ein?
Mögliche doppelt bezahlte Gutschriften
Das Pendant zu den doppelt bezahlten Rechnungen im Einkauf sind die doppelt bezahlten Gutschriften. In diesem Zusammenhang gilt es folgendes zu prüfen: Wenn ein Beleg eine Gutschrift enthält, welche durch eine (ausgehende) Zahlung ausgeziffert oder verrechnet wurde, wobei es weitere Positionen von anderen Gutschriften gibt (bzgl. desselben Kunden), die auch ausbezahlt oder verrechnet wurden und die die gleiche Höhe haben, dann liegt die Vermutung für eine Feststellung nahe.
Nicht fakturierte Lieferungen
Wieder etwas einfacher: Eine Lieferung, für die keine SD Faktura / Rechnung gefunden werden kann. Das Risiko ist schlichtweg, dass Lieferungen nicht fakturiert wurden und dementsprechend auch nicht bezahlt werden.
Sie suchen noch mehr? Dann finden Sie hier alle 42 Indikatoren zur Prüfung des Verkaufs aus zapAudit:
6. Ein Klassiker: Funktionstrennungen im Verkauf
Funktionstrennung in SAP bedeutet, dass bestimmte Kombinationen von Aufgaben nicht von derselben Person durchgeführt werden sollen, weil es sich um eine kritische Kombination von Aufgaben 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.
Folgende konkrete Funktionstrennungskonflikte in den SAP Verkaufsprozessen könnten interessant sein:
- Verkaufsbeleg bearbeiten und einen Fakturabeleg dafür generieren
- Zahlung durch Anlegen fiktiver Gutschriften initiieren
- Kundenstammsätze bearbeiten und in betrügerischer Absicht erstellte Zahlungen buchen
- Abrechnung anlegen und Zahlung unangemessen buchen
- Verkaufsbelege bearbeiten und inkorrekte Rechnung eingeben
- Fiktiven Kunden anlegen und Aufträge initiieren
