Stornieren, aber zügig! Und nicht wie bei Hempels unterm Sofa!

Nick Gehrke
März 1, 2018

In einer sauberen Finanzbuchhaltung in SAP will aufgeräumt sein. Manchmal muss man Korrekturen vornehmen und dies passiert in der Finanzbuchhaltung natürlich mit Stornos. Was man über die „saubere“ Buchhaltung alles erfahren kann, merkt man insbesondere dann, wenn man sich die „Aufräumarbeiten“ einmal genauer ansieht. Also lassen Sie uns einen Blick auf Ihre Stornos in der FiBu werfen. Das Thema scheint trocken, aber berührt letztlich grundlegende Themen wie die Ordnungsmäßigkeit Ihrer Buchhaltung und seltsame Stornos können sogar den Eindruck erwecken, dass Ihre Geschäftsvorfälle nicht periodengerecht verbucht wurden.

Warum sollte ich mich mit Stornos beschäftigen?

Eine saubere Buchhaltung kann für sich beanspruchen, wer sich an die Grundsätze ordnungsmäßiger Buchhaltung (GoB) oder etwas konkreter an die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) hält. Hier findet sich z.B. die Anforderung:

„Jeder Geschäftsvorfall ist zeitnah, d. h. möglichst unmittelbar nach seiner Entstehung in einer Grundaufzeichnung oder in einem Grundbuch zu erfassen. Nach den GoB müssen die Geschäftsvorfälle grundsätzlich laufend gebucht werden (Journal). Es widerspricht dem Wesen der kaufmännischen Buchführung, sich zunächst auf die Sammlung von Belegen zu beschränken und nach Ablauf einer langen Zeit auf Grund dieser Belege die Geschäftsvorfälle in Grundaufzeichnungen oder Grundbüchern einzutragen“ (Tz. 46)

Natürlich bedeutet dies auch, dass Fehler zeitnah entdeckt und dann korrigiert werden sollten. Dies können wir am Stornoverhalten in Ihrer Firma erkennen.

Dazu möchte ich Ihnen im Folgenden verschiedene Analysemöglichkeiten basierend auf dem SAP Datenmodell aufzeigen.

Wie findet man Stornos in der SAP Datenbank?

In SAP sind alle Belegköpfe des Rechnungswesens in der Tabelle BKPF abgelegt. Ob ein Beleg storniert wurde oder ein Stornobeleg ist, kann man an dem Datenfeld XREVERSAL erkennen. Dabei bedeutet XRESERVAL='1', dass der Beleg storniert wurde und XRESERVAL='2', dass es sich um einen Stornobeleg handelt. In dem Datenfeld STBLG steht dann die Belegnummer des zugehörigen Stornobelegs bzw. der stornierte Beleg, je nachdem welchen der beiden Belege man gerade betrachtet. Stornierter Beleg und Stornobeleg sind damit also wechselseitig referenziert. Im Datenfeld STJAH steht das Geschäftsjahr des zugehörigen Stornobelegs bzw. des stornierten Belegs.

Diese Infos reichen erstmal, damit man sich eine Liste basteln kann, wo stets stornierter Beleg und Stornobeleg zusammen aufgeführt wurden. Ich habe für Sie ein paar SQL-Queries zum mit Machen geschrieben. Wenn Sie diese in Ihrem SAP-System ausprobieren wollen nutzen Sie die Transaktion „DBACOCKPIT – Diagnose – SQL-Editor“.

Folgendes Query listet den stornierten Beleg (STORNIERT_BELNR), sowie für diesen Beleg das Buchungsdatum (STORNIERT_BUDAT), das Belegdatum (STORNIERT_BLDAT) und das Erfassungsdatum (STORNIERT_CPUDT). Weiterhin wird jeweils der Stornobeleg (STORNO_BELNR), sowie dessen Buchungsdatum (STORNO_BUDAT), das Belegdatum (STORNO_BLDAT) und das Erfassungsdatum (STORNO_CPUDT) gezeigt.

Query 1 (getestet auf HANA):

SELECT STORNIERT.MANDT,STORNIERT.BUKRS,STORNIERT.GJAHR STORNIERT_GJAHR,STORNIERT.BELNR STORNIERT_BELNR,STORNIERT.BUDAT STORNIERT_BUDAT,STORNIERT.BLDAT STORNIERT_BLDAT,STORNIERT.CPUDT STORNIERT_CPUDT,STORNO.GJAHR STORNO_GJAHR,STORNO.BELNR STORNO_BELNR,STORNO.BUDAT STORNO_BUDAT,STORNO.BLDAT STORNO_BLDAT,STORNO.CPUDT STORNO_CPUDT FROM BKPF STORNIERT JOIN BKPF STORNO ON (STORNIERT.MANDT=STORNO.MANDT AND STORNIERT.BUKRS=STORNO.BUKRS AND STORNIERT.STBLG=STORNO.BELNR AND STORNIERT.STJAH=STORNO.GJAHR) WHERE STORNIERT.XREVERSAL='1' AND STORNO.XREVERSAL='2'

Somit haben wir damit zunächst mal eine gute Datengrundlage.

Seltsame Ungereimtheiten oder: zurück in die Zukunft

Jetzt sollten wir unsere Belegsammlung nutzen, um festzustellen, ob es wenig plausible Konstellationen gibt zwischen storniertem- und Stornobeleg. Sehr seltsam wäre es hierbei, wenn der Stornobeleg ein früheres Buchungsdatum als der stornierte Beleg hätte. Lassen Sie und dies doch einfach mal prüfen. Dazu müssen wir Query 1 nur wie folgt erweitern.

Query 2(getestet auf HANA):

Hier sollte die Ergebnismenge also leer sein!

Genauso verhält es sich natürlich mit dem Belegdatum. Dies prüfen Sie, indem Sie einfach die letzten beiden Bedingungen im WHERE ändern zu:

… AND STORNIERT.BLDAT>STORNO.BLDAT

Kopf kürzer: Cut-Off Problem

Ganz besonders kritisch ist es, wenn Stornos passieren, bei denen der stornierte Beleg in einem anderen Geschäftsjahr liegt als der Stornobeleg. Das ist deshalb wichtig, weil durch den Storno im Nachhinein ein vergangener (abgeschlossener) Jahresabschluss verändert wird. Das mag der Wirtschaftsprüfer gar nicht, weil es die periodengerechte Erfassung der Geschäftsvorfälle stört. Man spricht auch von einem „Cut-Off Problem“. Wir können das nun leicht prüfen mit

Query 3 (getestet auf HANA):

Wohl dem, dessen Ergebnismenge bei diesem Query leer ist.

Alle anderen sollten bei den Treffern nachvollziehen, ob es sich nur um Stornos im Januar auf den Dezember des Vorjahres handelt, oder ob längere Zeiträume dazwischenliegen!

Zeitnahes Aufräumen vermeidet Diskussionen mit Prüfern

Zu guter Letzt verschaffen wir uns nun noch einen Überblick darüber, inwiefern zeitnah Fehler in der Finanzbuchhaltung entdeckt und storniert wurden. Dazu macht es Sinn eine Statistik zu zeigen, die berechnet wie viele Belege nach wie vielen Tagen storniert wurden. Daran erkennt man, die zeitnah aufgeräumt wurde und hat einen guten Gesamtüberblick darüber, ob es wohl geordnet in der Buchhaltung zugeht.

Query 4 (getestet auf HANA):

SELECT STORNO.MANDT, STORNO.BUKRS, STORNO.GJAHR, DAYS_BETWEEN (STORNIERT.CPUDT, STORNO.CPUDT) "DAYS_BETWEEN", COUNT(*) NUMBER_DOCS

FROM BKPF STORNIERT

JOIN BKPF STORNO ON (STORNIERT.MANDT=STORNO.MANDT AND STORNIERT.BUKRS=STORNO.BUKRS AND STORNIERT.STBLG=STORNO.BELNR AND STORNIERT.STJAH=STORNO.GJAHR)

WHERE STORNIERT.XREVERSAL='1' AND STORNO.XREVERSAL='2'

GROUP BY STORNO.MANDT,STORNO.BUKRS,STORNO.GJAHR, DAYS_BETWEEN (STORNIERT.CPUDT, STORNO.CPUDT)

ORDER BY STORNO.MANDT,STORNO.BUKRS,STORNO.GJAHR, DAYS_BETWEEN (STORNIERT.CPUDT, STORNO.CPUDT) DESC

Query 4 zeigt pro Buchungskreis und Geschäftsjahr des Stornos, wie viele Belege (NUMBER_DOCS) nach wie vielen Tagen (DAYS_BETWEEN) storniert wurden. Hier sollte man natürlich die großen Zeiträume mit Priorität betrachten.

Die Statistik aus Query 4 sieht dann z.B. wie folgt aus:

Zu mühsam?

Es ist nicht immer leicht, per SQL an die Daten von SAP zu kommen. Auch ist nicht jeder Revisor ein begeisterter Datenanalyse-Fan.

Deshalb probieren Sie doch einfach mal zap Audit aus. Hier werden Ihnen alle Datenanalysen abgenommen und Sie können sich auf die fachlichen Schlussfolgerungen konzentrieren.

Ein zap Audit Proof-of-Concept mit einem kleinen Buchungskreis Ihrer Wahl bieten wir Ihnen kostenfrei. Melden Sie sich dafür bei uns:

Nick Gehrke

is Chief of Data & Knowledge and Co-Founder at zapliance as well as Professor of Information Systems with a Big 4 background. He prefers to work as a business information scientist and tax consultant at the converging points of finance, accounting, taxation, audit and ERP systems, data science and information technology.

ALLE BEITRÄGE