Grundlegende Informationen zur Wirtschaftsprüfung finden Sie unter Erste Schritte.
Beim Journal Entry Testing handelt es sich um eine Analyse der Journaldaten, die vor allem in der Wirtschaftsprüfung verwendet wird, um:
- große Datenmengen in kürzerer Zeit standardisiert zu analysieren und kritische Geschäftsvorfälle und Transaktionen zu identifizieren
- Risikofaktoren für Dolose Handlungen aufzudecken (ISA 240)
- Prüfungsschwerpunkte festzulegen
Empfohlener Mindestumfang laut ISA 240 für die Erreichung der Prüfziele:
Verwendete Abkürzungen:
VS – Vollständigkeit
G – Genauigkeit
VH/E – Vorhandensein und Eintritt
PA – Periodenabgrenzung
B – Bewertung und Zuordnung
Z – Zurechnung
A – Ausweis und Verständlichkeit
Die Umsetzung erfolgt im Paket Finanzbuchhaltung → Buchen und Vorerfassungen → Weitere Buchungsfunktionen → Journal Entry Testing.
Sie können die Funktion ebenfalls im Rahmen der Wirtschaftsprüfung aus der Checkliste aufrufen:
Nun können Sie auswählen, welche Prüfungen durchgeführt werden sollen bzw. ob die Prüfung auf bestimmte Konten, Buchungssymbole oder Buchungstexte eingeschränkt werden soll:
Die Ausgabe der Daten erfolgt in einem Editorfile. Die einzelnen Prüfungsergebnisse können somit ggf. in die Feststellung der Wirtschaftsprüfung kopiert werden.
Die einzelnen Prüfungen von Journal Entry Testing werden nun genauer beschrieben.
Hierbei handelt es sich um eine Überprüfung der Buchungen pro Ersteller.
Ziel:
Mit dieser Auswertung wird erkennbar, welche Benutzer in welchem Umfang auf welche Konten gebucht haben. Nicht personalisierte Benutzer sollen erkannt werden. Nicht berechtigte Benutzer werden ersichtlich.
Die Auswertung sieht folgendermaßen aus:
Teil 1 - Übersicht Benutzer
Je Ersteller (User) und ProgKz werden die Anzahl der Buchungen bzw. Storno-/Gutschrift-Buchungen angezeigt. Eine Summe je Ersteller und eine Gesamtsumme dienen als Kontrolle.
Teil 2 - Übersicht Konten des Benutzers
Hinweis | Bitte beachten Sie, dass der "Ersteller" der Buchung beim BuErf-Import nicht mitimportiert wird! Handelt es sich beim Import um eine NTCS FIBU, kann die Information des Erstellers sehr wohl übernommen werden. Daher wird empfohlen, diese Prüfung nur bei NTCS FIBUs durchzuführen.
|
Hier wird überprüft, ob es manuelle Buchungen auf hinterlegten Konten gibt, die in folgenden Fenstern definiert werden können:
- Fixkonten (Finanzbuchhaltung)
- Steuerkonten (Finanzbuchhaltung)
- Konten für Verbuchung in Fibu (Anlagenbuchhaltung)
- Konten für Verbuchung in Fibu (Personalrückstellungen)
Automatikkonten sollen grundsätzlich keine manuellen Buchungen enthalten. Beispielsweise werden die Umsatz- und Vorsteuer anhand des verwendeten Steuerschlüssels automatisch auf den zugeordneten Umsatz- und Vorsteuerkonten erfasst. Ein weiteres Beispiel wäre eine automatische Verbuchung der Abschreibung. Demnach sollten sich auf diesen Konten keine manuellen Buchungen befinden.
Die Auswertung sieht folgendermaßen aus:
Mit dieser Prüfung sollen Auffälligkeiten in den Umsatzerlösen entdeckt werden. Zu diesem Zweck werden die Soll-Buchungen auf Umsatzerlöskonten ermittelt. Die Auswertung unterteilt sich in eine Übersicht je Buchungsperiode, je Konto und je Mitarbeiter.
Die Auswertung sieht folgendermaßen aus:
Teil 1 - Übersicht je Buchungsperiode
Teil 2 - Übersicht je Konto
Teil 3 - Übersicht je Mitarbeiter
Buchungen mit ungewöhnlichen Buchungstexten können Hinweise auf zu prüfende Einzelfälle geben. Das Ziel dieser Prüfung ist, solche Fälle herauszufiltern, indem mit der Suche nach bestimmten Texten gearbeitet wird. Standardmäßig wird nach folgenden Buchungstexten gesucht:
- Ausbuchung
- Berichtigung
- Diverses
- Error
- Fehler
- Gutschrift
- Irrtum
- Korrektur
- Lt.
- Retoure
- Rückgabe
- Rücksendung
- Storno
- Test
- Umkehr
- Verschrottung
- #PLATZHALTER_LEER
Nachdem Sie die Funktion "Journal Entry Testing" gestartet haben, werden Ihnen für die Prüfung im Bereich der Einschränkungen die oben aufgezählten Buchungstexte bereits vorgeschlagen. Sie können diese Liste beliebig anpassen, indem Sie Einträge entfernen oder die Liste mit eigenen Texten erweitern.
Die Auswertung sieht folgendermaßen aus:
Die Gegenkontoanalyse zeigt auf, welche Gegenkonten für ein bestimmtes Konto verwendet worden sind. Die Prüfung liefert einen Überblick und Antworten auf Frage wie:
- Sind es immer dieselben Gegenkonten?
- Welche Varianten gibt es?
- Gab es exotische Gegenkonten, bei denen man etwas genauer hinsehen sollte?
- Sind Gegenkonten dabei, die fachlich nicht zum Konto passen?
Es besteht auch hier die Möglichkeit, die Analyse auf bestimmte Konten einzugrenzen, indem diese bei den Einschränkungen definiert werden:
Die Auswertung sieht folgendermaßen aus:
Hohe Auszahlungen auf Kassenkonten bergen ein grundsätzliches Risiko. Bei dieser Prüfung werden Gruppen in Tausenderschritten gebildet und die dazugehörigen Buchungen aufgelistet. Die Gruppen werden in der ersten Spalte "Betrag" gebildet:
Beispiel | Betrag 5000 - 4000 4000 - 3000 3000 - 2000 2000 - 1000 1000 - 0
|
Die Auswertung sieht folgendermaßen aus:
In unserem Beispiel sind alle Buchungen auf dem Kassenkonto in der Gruppe Betrag 1000 - 0 zu finden, somit sind die einzelnen Buchungsbeträge nicht höher als € 1.000,00.
Geschäftsfälle müssen zeitnah und laufend gebucht werden. Eine Sammlung und spätere gebündelte Erfassung verstoßen gegen die Grundsätze ordnungsmäßiger Buchführung.
Folgende Begriffe sind von Bedeutung:
- Erfassungsdatum
Tatsächliches Datum (und Uhrzeit) der Erfassung durch einen Benutzer. Wird systemseitig automatisch und unveränderbar vergeben.
- Belegdatum
Manuell vom Benutzer vergeben. Soll dem Datum des zu buchenden Beleges entsprechen, z. B. Rechnungsdatum der Lieferantenrechnung. Dient der Berechnung der Fälligkeit der Rechnung.
- Buchungsdatum
Dient der Zuordnung zur betroffenen Buchungsperiode. Bei Lieferung und Leistung entspricht es dem Leistungsdatum und wird manuell vom Benutzer vergeben.
Grundsätzlich ist zu erwarten, dass eine Leistung (Buchungsdatum) erfolgt ist, bevor sie abgerechnet (Belegdatum) und anschließend erfasst wird (Erfassungsdatum). Regelmäßig liegt also das Buchungsdatum vor dem Belegdatum und das Belegdatum vor dem Erfassungsdatum.
Abweichungen zu diesem Standardfall können Hinweise auf mangelnde Zeitnähe oder falsche Periodenzuordnung der Geschäftsfälle geben. Für die Prüfung der Zeitnähe wird das Belegdatum dem Erfassungsdatum gegenübergestellt.
Mit dieser Prüfung kann jedoch aufgrund der fehlenden Dokumentation des Erfassungsdatums in NTCS derzeit dieses nicht berücksichtigt werden. Die Prüfung beschränkt sich hier auf die Kontrolle der Periodengerechtigkeit. Das bedeutet, dass Sie mit dieser Prüfung eine Auswertung erhalten, die zeitliche Differenzen zwischen dem Buchungsdatum und dem Belegdatum aufzeigt. Da Leistungen monatlich abgerechnet werden sollen, ist eine Abweichung > 1 Monat daher unüblich.
Die Auswertung sieht folgendermaßen aus:
Diese Prüfung soll doppelte Buchungen aufzeigen. Als Kriterium zur Identifizierung doppelter Buchungen dient die identische Kombination aus Sachkonto, Buchungsbetrag und Belegnummer bzw. Sachkonto, Buchungsbetrag und Periode.
Es besteht auch hier die Möglichkeit, die Analyse auf bestimmte Konten bzw. Buchungssymbole einzugrenzen, indem diese bei den Einschränkungen definiert werden:
Die Auswertung sieht folgendermaßen aus:
Hinweis | Bitte beachten Sie den rot eingerahmten Hinweis am Ende der Auswertung!
|
Nach dem ISA 240 können Einträge im Journal mit runden Zahlen oder Endziffern ein Anhaltspunkt für Manipulation sein. Mit dieser Prüfung erhält man einen Überblick über die Anzahl bzw. Häufung solcher Fälle.
Die Auswertung sieht folgendermaßen aus:
Hinweis | Bitte beachten Sie den rot eingerahmten Hinweis am Ende der Auswertung!
|
Belegnummern müssen vollständig und lückenlos erfasst werden. Die Beleglückenanalyse überprüft, ob im System nicht erklärbare Lücken von Belegnummern vorhanden sind. Geprüft werden alle Buchungssymbole (Allgemeine und auch FIBU-bezogene Buchungssymbole), die das Feld
Kontrolle Belegnummer bei Gesamtprüfung gesetzt haben.
Die Auswertung sieht folgendermaßen aus:
Hinweis | Bitte beachten Sie den rot eingerahmten Hinweis am Ende der Auswertung!
|
Schnittstellenbuchungen können bereits Summierungen aufweisen. Werden Umsatzerlöse oder die Lohnabrechnung bereits in einem Vorsystem erfasst und in die Buchhaltung übernommen, sollten keine manuellen Buchungen mehr erfolgen.
Die Auswertung zeigt alle Buchungen, die über mögliche Schnittstellen übernommen worden sind. Diese werden in der Regel mit gleich- bzw. sehr ähnlich aussehenden Texten gebucht. Abweichungen davon fallen bei der Durchsicht auf.
Die Auswertung sieht folgendermaßen aus:
ISA 240 nennt als Merkmal manipulierter Journaleinträge oder anderer Anpassungen u. a. Einträge, die zum Ende des Geschäftsjahres oder als nachträgliche Abschlussbuchung aufgezeichnet worden sind. Ziel dieser Prüfung ist, diese Buchungen herauszufiltern, um diese manuell prüfen und analysieren zu können.
Diese Prüfung filtert folgende Buchungen heraus:
- Buchungen mit Buchungsart 2001
- Buchungen in der Periode 13
- Buchungsdatum oder Belegdatum = Bilanzstichtag
Die Auswertung sieht folgendermaßen aus:
Nach einer Datenübernahme können nicht alle Prüfungen vollständig durchgeführt werden. In folgender Tabelle finden Sie eine Auflistung, welche Punkte geprüft werden können:
Prüfungen | Prüfung möglich / nicht möglich | Information zur Prüfmöglichkeit |
| Anzahl Buchungen / Mitarbeiter | nicht möglich | Es gibt keine Info bezüglich des ursprünglichen Erfassers der Buchung. |
| Manuelle Buchungen auf "eigentliche" Automatikkonten | möglich | |
Soll-Buchungen auf Umsatzerlöse Statistiken der Umsatzerlöse | teilweise möglich | Prüfung auf Mitarbeiterebene nicht möglich, da die Info vom ursprünglichen Erfasser fehlt. |
Buchungen mit ungewöhnlichen Buchungstexten | möglich | |
Gegenkontenanalyse | Ergebnisse müssen geprüft werden | Der Zusammenhang zwischen Buchung und Gegenbuchung ist bei einer Datenübernahme nicht zwingend gegeben. |
Auszahlungen auf Kassenkonten | möglich, | wenn das Kassa- bzw. Bank-Kz am Konto hinterlegt wurde. |
Zeitnahes Erfassen und zeitnahes Buchen | nicht möglich, | da das Buchungsdatum dem Datum der Datenübernahme entspricht und nicht dem ursprünglichen Buchungsdatum. |
Doppelte Buchungen | möglich | |
Gerundete Ziffern vor dem Komma | möglich | |
Beleglückenanalyse | möglich | |
Buchungen über Schnittstellen | nicht möglich, | weil die Information aus dem Vorsystem fehlt und in BMD alle Buchungen "importiert" wurden. |
Buchungen zum Abschlussstichtag | möglich | |
Buchungen an ungewöhnlichen Tagen | nicht möglich, | da das Buchungsdatum dem Datum der Datenübernahme enstpricht und nicht dem ursprünglichen Buchungsdatum. |