Journal Entry Testing: Lückenlos glücklich oder unglückliche Lücken?

Journal Entry Testing (JET) prüft gewissermaßen die ganz grundsätzlichen Anforderungen an das Rechnungswesen, sozusagen die „Foundations of Accounting“. In diesem Blog Beitrag wollen wir wirklich den ganz grundsätzlichen Anforderungen nachgehen und zeigen, wie Sie in Ihrem SAP mit SQL schnell und einfach prüfen können, ob Belegnummern eindeutig sind und ob diese systematisch fortlaufend sind. Also eine ganz grundsätzliche Prüfung der Vollständigkeit ihrer Buchungen und Rechnungen. Immer interessant für Wirtschaftsprüfer und auch: das Finanzamt.

In diesem Artikel gucken wir uns zunächst eine mögliche Auswertung mit SQL an, um im Anschluss die rechtlichen Grundlagen zu klären.

Belegnummernlückenanalyse

Also, machen wir uns an eine klassische Belegnummernlückenanalyse!

Es sollte eine Selbstverständlichkeit sein, dass Belegnummern nicht doppelt vorkommen dürfen. Dies würde das Vertrauen in das Rechnungswesen arg in Mitleidenschaft ziehen. Dies ist sehr einfach mit Hilfe von SQL prüfbar. Sie können DIY (Do it yourself) konform mitmachen, indem Sie in SAP die Transaktion „DBACOCKPIT“ aufrufen und über die „Diagnose“ zum „SQL-Editor“ navigieren. Alternativ kann auch das SAP HANA Studio verwendet werden. Alle folgenden SQL Queries wurden bereits auf einer SAP HANA Datenbank getestet:

SELECT MANDT, BUKRS, GJAHR, BELNR, COUNT(*) FROM BKPF
GROUP BY MANDT, BUKRS, GJAHR, BELNR
HAVING COUNT(*)>1

In meinem Testdatensatz kommt als Ergebnis “leere Menge” – was für ein Glück – alles andere wäre auch sehr gegen unsere Erwartung gewesen.

Jetzt aber zu den Belegnummernlücken! Wenn es keine Belegnummernlücken gibt, dann müsste jede Belegnummer einen Nachfolger haben, also eine um 1 höhere Belegnummer müsste existieren. Das ist eine sehr formale Definition und lässt sich sehr gut in einem SQL formulieren:

SELECT BLART, MANDT, BUKRS, GJAHR, BELNR FROM BKPF B1 WHERE
MANDT='800' AND BUKRS='1000' AND GJAHR=2018
AND
NOT EXISTS (
SELECT B2.BELNR FROM BKPF B2 WHERE B1.MANDT=B2.MANDT AND B1.BUKRS=B2.BUKRS AND B1.GJAHR=B2.GJAHR AND LPAD(TO_NUMBER(B1.BELNR)+1,10,'0' ) = B2.BELNR)
AND BELNR NOT IN (SELECT MAX(B.BELNR) FROM BKPF B WHERE B.MANDT='800' AND B.BUKRS='1000' AND B.GJAHR=2018 GROUP BY B.BLART)

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

Das Query zeigt an, welche Belegnummer keinen Nachfolger hat. In meinem Testdatensatz kommt folgendes heraus (Ausschnitt):

Die Belegart RV ist in SAP für gewöhnlich eine (Ausgangs)rechnung. Immer wieder scheinen hier Lücken vorzukommen. Das ist sicherlich eine Nachfrage wert und ein systematischer Grund für solche Lücken sollte die Revision hier erwarten dürfen.

Über die letzte Nebenbedingung im SQL Query, die auf „AND BELNR NOT IN“ folgt, habe ich bereits die jeweils letzten Belegnummern einer Belegart ausgefiltert. Diese können logischerweise keinen Nachfolger haben.

Kommen bei dem Query allerdings Belege heraus, so gibt es Belegnummernlücken.

Ist das schlimm?

– es kommt darauf an.

Zumindest das Finanzamt schreibt im Umsatzsteueranwendungserlass zu 14.5 Absatz 10:

„…Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht zwingend. Es ist auch zulässig, im Rahmen eines weltweiten Abrechnungssystems verschiedener, in unterschiedlichen Ländern angesiedelter Konzerngesellschaften nur einen fortlaufenden Nummernkreis zu verwenden.“

Das bedeutet, dass Lückenlosigkeit nicht zwingend gefordert wird. Jedoch wird man Lücken in den Belegnummern erklären müssen. Ansonsten sind Belegnummernlücken ein Hinweis auf Unvollständigkeit.

Dazu heißt es außerdem in den auf Seite 9 Punkt 32:

„Die Buchführung muss so beschaffen sein, dass sie einem sachverständigen Dritten innerhalb angemessener Zeit einen Überblick über die Geschäftsvorfälle und über die Lage des Unternehmens vermitteln kann. Die Geschäftsvorfälle müssen sich in ihrer Entstehung und Abwicklung lückenlos verfolgen lassen (progressive und retrograde Prüfbarkeit).“