Im Dunkeln ist gut Munkeln oder: Let‘s Do Journal Entry Testing again!

Untersucht der Auditor seinen Buchungsstoff, fällt häufig das Stichwort: Journal Entry Testing. Häufig neben den höchsten, häufigsten und glattesten Beträgen ist auch die Frage nach: Buchungen am Wochenende. Buchungen am Wochenende können Sie mit zap Audit natürlich auch sofort entdecken. Aber uns fällt immer häufiger auf: Am Wochenende wird regelmäßig gearbeitet. Das Wochenende sind nicht wirklich Tage, an denen im Regelbetrieb nichts passiert. Was also nützt eine Auswertung der Buchungen am Wochenende und wie kann man Tage entdecken, an denen wirklich nicht viel los war und jemand vielleicht etwas unbeobachtet gebucht hat? Wir zeigen es Ihnen im SAP-System und mit einigen SQL-Tricks!

Am Wochenende passiert im Betrieb doch immer wieder eine ganze Menge: Automatische Prozesse werden gebucht oder im Lager kommen am Samstag und Sonntag immer wieder Wareneingänge an. Ganz getreu dem Motto:

The Company Never Sleeps!

Wann aber war wirklich wenig los im Betrieb und wann gab es dementsprechend Gelegenheit unbeobachtet etwas zu buchen? Wir gehen dieser Frage nach und entwickeln eine Antwort mit ein paar einfachen statistischen Überlegungen.

Was ist los an den Wochentagen?

Dass am Wochenende immer durchgearbeitet wird, stimmt sicherlich so für die meisten Firmen nicht. Man muss viel mehr betrachten, welche Tätigkeiten und Geschäftsvorfälle auch am Wochenende durchgeführt werden und welche nicht. Deshalb erscheint es eine gute Idee, Geschäftsvorfälle an den Belegarten zu unterscheiden.

Ganz unkompliziert gestaltet sich eine Auswertung mit zap Audit. Mit der neuen Version werden wieder einige Indikatoren „geschärft“ und neue hinzugefügt. So z.B. auch: „Buchungen an anderen Tagen als normalerweise gebucht wird“. Zugegebenermaßen waren wir mal wieder nicht sehr kreativ bei der Namenswahl. Wenn Sie also eine gute Idee haben, dann lassen Sie es uns in den Kommentaren wissen. Die Ergebnisse in zap Audit sehen dann z.B. folgendermaßen aus:

Um die nachfolgend beschriebene Analyse direkt im SAP auszuprobieren, rufen Sie ganz einfach die Transaktion „DBACOCKPIT“ auf. Im linken Baum über „Diagnose“ zum „SQL-Editor“ navigieren und schon kann es losgehen. Die nachfolgenden SQL Queries haben wir allesamt bereits auf einer SAP HANA Datenbank für Sie getestet.

Wir untersuchen zunächst, wie hoch die durchschnittliche Beleganzahl und die Standardabweichung dieser Beleganzahl pro Wochentag sind. Und dies für jede Belegart separat:

SELECT BLART, WEEKDAY, COUNT(DISTINCT CPUDT) DAYS_POSTED, AVG(NUMBER_DOCS) AVG_DOCS, STDDEV(NUMBER_DOCS) STDDEV_DOCS FROM
(

• SELECT BLART, DAYNAME(CPUDT) WEEKDAY, CPUDT, COUNT(DISTINCT BELNR) NUMBER_DOCS FROM BKPF WHERE BUKRS='1000' AND GJAHR='2018' GROUP BY BLART, CPUDT

)
GROUP BY BLART, WEEKDAY
ORDER BY BLART, AVG_DOCS DESC

Hinweis: Ändern Sie die rot markierten Felder auf Ihren Untersuchungsgegenstand.

Schauen wir uns einen Ausschnitt aus der Ergebnismenge an für die Belegart RE (Rechnungseingang):

Was sagt uns das Ergebnis?

Offenbar werden Eingangsrechnungen am Wochenende nicht wirklich häufig bearbeitet. Am Sonntag schon gar nicht. In dem ganzen Jahr wurden lediglich zwei Rechnungen an einem Sonntag gebucht. Die wären es auf jeden Fall schon mal Wert angesehen zu werden, wenn man denn nach Belegen sucht bei denen „im Dunklen gut Munkeln“ ist.

Jetzt aber machen wir eine einfache statistische Überlegung. Wie war das noch mit Mittelwert und Standardabweichung? Eine Daumenregel ist: Wenn man eine Normalverteilung der Beleghäufigkeiten an den Wochentagen unterstellt, dann müssten ca. 95% aller Wochentage ein Belegvolumen innerhalb von dem Intervall haben:

Mittelwert (AVG_DOCS) +/- 2 * Standardabweichung (STDDEV_DOCS)

Das nennt sich dann Konfidenzintervall.
Belegvolumina oberhalb von:

Mittelwert + 2 * Standardabweichung

und unterhalb von

Mittelwert – 2 * Standardabweichung

dürften jeweils nur an ca. 2,5% dieser Wochentage vorkommen.

Wir interessieren uns für Tage mit besonders wenig Volumen und nutzen das SQL-Query von gerade eben noch einmal und erweitern es lediglich um die untere Konfidenzgrenze:

SELECT BLART, WEEKDAY, COUNT(DISTINCT CPUDT) DAYS_POSTED,AVG(NUMBER_DOCS) AVG_DOCS, STDDEV(NUMBER_DOCS) STDDEV_DOCS,AVG(NUMBER_DOCS)-2*STDDEV(NUMBER_DOCS) LOWER_LIMIT FROM
(

• SELECT BLART, DAYNAME(CPUDT) WEEKDAY, CPUDT, COUNT(DISTINCT BELNR) NUMBER_DOCS FROM BKPF WHERE BUKRS='1000' AND GJAHR='2018' GROUP BY BLART, CPUDT

)
GROUP BY BLART,WEEKDAY
ORDER BY BLART,AVG_DOCS DESC

Hinweis: Ändern Sie die rot markierten Felder auf Ihren Untersuchungsgegenstand.

Schauen wir uns wiederum die Belegart RE an:

Das LOWER_LIMIT ist stets größer 0 Belege. Das bedeutet, wir sollten jetzt prüfen, ob es für die Belegart RE Tage gibt mit einer Anzahl von Buchungen unterhalb von LOWER_LIMIT. Dies könnte man als seltenes Ereignis werten z.B. könnte es ein Feiertag gewesen sein. Und trotzdem wurden aber Rechnungen gebucht!

Wir untersuchen jetzt einmal den Mittwoch und prüfen, ob es einen Mittwoch gab, an dem weniger als 36 Rechnungen gebucht wurden:

SELECT BLART, DAYNAME(CPUDT) WEEKDAY, CPUDT, COUNT(DISTINCT BELNR) NUMBER_DOCS
FROM BKPF

• WHERE BLART='RE' AND DAYNAME(CPUDT)='WEDNESDAY' AND BUKRS='1000' AND GJAHR='2018'

GROUP BY BLART, CPUDT
HAVING COUNT(DISTINCT BELNR) < 36;

Hinweis: Ändern Sie die rot markierten Felder auf Ihren Untersuchungsgegenstand.

In meinem Testdatensatz kommt dabei heraus:

Das ist einigermaßen interessant. Der eine Mittwoch ist der 2. Weihnachtsfeiertag. Da hat wohl jemand in der Belegschaft vor dem Jahreswechsel etwas vergessen. Und der andere Mittwoch scheint Mitten im Sommerloch zu liegen.

Jetzt wissen wir, welches die Tage für diese Belegart ist, wann „im Dunkeln gut Munkeln“ ist. Als Auditor können wir jetzt einen Blick gezielt auf solche Belege werfen. Wir kommen vollständig ohne die Prämisse aus, dass das Wochenende besonders „verdächtige“ Tage sind. Die Analyse ist vollkommen dynamisch und stützt sich auf empirische Tatsachen.