Die Entwicklung von Apps, die im kaufmännischen Umfeld eingesetzt werden ist vielschichtig und komplex – mit anderen Worten: kaufmännische Apps sind algorithmisch tief und schwer zu programmieren.

Diese Komplexität ergibt sich aus der Vielfalt des Wirtschaftslebens an sich (z. B. kann ein Schiff schon mal einen eigenen Devisenkurs haben) aber vor allem aus der Vielzahl von Vorschriften und rechtlichen Rahmenbedingungen, die es einzuhalten gilt sowie sich ständig ändern. Um das in jeder erdenklichen und nicht erdenklichen Situation zu gewährleisten, bedarf es Sicherheitsmaßnahmen auf Seiten der Software in Warenwirtschaft- über Lohn- und Finanzbuchhaltungsprogrammen bis hin zu Dokumentenmanagement-Systemen - die sogenannten Paranoia-Klauseln.

Woher kommt der Begriff „Paranoia-Klausel“?

Der Begriff  Paranoia-Klausel beschreibt ein Grundmuster, das wir bei dekodi für die Entwicklung von Software im Rahmen unserer Qualitätsstandards eingeführt haben. Lange sprachen wir in diesem Zusammenhang von „Eigenüberwachung“ bis eine neue Mitarbeiterin in der Softwareentwicklung nach dem Studium der entsprechenden Abschnitte in unserem Entwicklerhandbuch feststellte, dass möglicherweise alle dekodi-Entwickler eine Paranoia (im Sinne von Wahnsinn) haben. Das hat uns sehr gefallen und seither gibt es bei uns die „Paranoia-Klauseln“.

Die Abwanderung der Wertschöpfung = die Abwanderung der Datenqualität

Ein Spezialgebiet von dekodi sind die sogenannten Datenkonverter, die Daten aus einem System A so übersetzen, dass diese in ein System B eingelesen werden können. Betrachtet man diesen Vorgang im Kontext der immer weiter voranschreitenden Digitalisierung im Rechnungswesen, dann lässt sich unschwer feststellen, dass sich die Wertschöpfung aus dem Erstellen von Finanz- und Lohnbuchhaltungen immer mehr in Vorsysteme und damit auch in die von uns entwickelten Programme verlagert. Damit verlagert sich auch die Datenqualität vom Anwender in die Vorsysteme.


Abbildung: Ort der Wertschöpfung - gestern und heute

Damit ist aber auch klar: Die Computerprogramme sind an dieser Stelle nicht nur einfache Datenumwandler, sondern müssen auch Aufgaben der Kontrolle und Plausibilisierung der Daten übernehmen. Die Vorsysteme werden zu „elektronischen Buchhaltern“.

Moderne Datenkonverter oder ähnliche Systeme übernehmen heute u. a. folgende Aufgaben:

  • Summarische Kontrolle von Ausgangsrechnungen
  • Vollständigkeitskontrollen
  • Überwachung von Ausgangsrechnungen auf steuerliche Besonderheiten
    (z. B. Verkauf von innerdeutschem Unternehmen an deutsche Privatkunden mit 0 % Umsatzsteuer)
  • Kontrolle von Rechnungsvoraussetzungen nach §14 (4) UstG bei der vollautomatischen
    Verarbeitung von Eingangsrechnungen (Ist der Leistungszeitraum vorhanden? -> siehe Blogartikel zum ZUGFeRD-Format.)
  • Überwachung auf umsatzsteuerliche Auffälligkeiten (die USt.-ID der Lieferadresse weicht von der USt.-ID der Rechnungsadresse ab)
  • ...

Dieser Aufgabe kommt eine immense Bedeutung zu. Der Buchhalter, der die Daten früher manuell erfasst und dabei auch soweit als möglich kontrolliert hat, übernimmt heute fertige Daten aus unterschiedlichen Vorsystemen. Für eine Kontrolle der einzelnen Belege und der daraus erzeugten Buchungssätze hat er keine Zeit mehr. Der Buchhalter MUSS sich also darauf verlassen können, dass die Buchungsdaten, die er gerade einliest, vom Vorsystem korrekt bereitgestellt werden.

Fehlerhafte Daten ziehen den Blick der Betriebsprüfer auf sich

Auch Betriebsprüfer wissen um die Fehleranfälligkeit von Buchungsdaten. Oftmals ist es ein leichtes, die Buchhaltungen von Unternehmen zu verwerfen, deren Finanz- und Lohnbuchungsdaten aus Vorsystemen stammen. Die Betriebsprüfer kontrollieren dazu einfach, ob die Daten, die von System A erzeugt wurden, auch in System B angekommen sind.

Hierzu ein Beispiel (die Namen sind natürlich anonymisiert):

Die Kaffeerösterei „Hamburger Bohne“ übernimmt seit Jahr und Tag die Buchungssätze für Debitorensollstellungen aus den Ausgangsrechnungen ihrer Warenwirtschaft „Roasters-ERP“ per Datev-Schnittstelle in das Finanzbuchhaltungssystem Datev-Rewe. Bei der Betriebsprüfung stellt sich heraus, dass jeden Monat einige Ausgangsrechnungen aus der Warenwirtschaft nicht in der Datev-Finanzbuchhaltung angekommen sind. Dementsprechend wurde aus diesen Ausgangsrechnungen auch keine Umsatzsteuer abgeführt. Der Buchhalter des Unternehmens hat auch die OP-Liste nicht abgestimmt, sodass eingehende Zahlungen denen kein Beleg gegenüber stand, nicht aufgefallen sind.

Die Folge: Der Prüfer verwirft die gesamte Buchhaltung und nimmt eine ordentliche Zuschätzung vor.

Aus diesem Beispiel lassen sich zwei grundlegende Erkenntnisse ableiten:

  1. Die Software muss auf jeden Fall richtige Daten liefern
  2. Systemübergreifende Kontrollen kann nur der Mensch durchführen

Programme müssen sich selbst überwachen

Bei der Verarbeitung von Daten innerhalb unserer Applikationen stellen wir die vollständige und korrekte Verarbeitung der Daten sicher. Die Verarbeitung kaufmännischer Daten ist mitunter sehr komplex. Allein für die korrekte Verbuchung einer Ausgangsrechnung sind viele Programmzeilen Code erforderlich. Manche Rechnung umfasst ein Dutzend Rechnungspositionen mit unterschiedlichen Umsatzsteuersätzen zuzüglich Nebenleistungen, wie z. B. Versandkosten. Hier muss nicht nur eine umsatzanteilige Aufteilung der Nebenleistungen erfolgen, sondern die erzeugten Buchungen müssen auch pro Steuersatz verdichtet werden.

Schließlich muss die Software die Bemessungsgrundlage ermitteln und ggfs. Betragsrundungen durchführen. Um solche komplexen Aufgaben zu überwachen, führt jedes Programm eine Reihe von Prüfungen durch (sog. Validierungen). Diese Prüfungen beziehen sich jedoch immer auf einzelne Aspekte eines Vorgangs (z. B. ist die Rechnungsnummer vorhanden? Ist der Kunden-Name vorhanden? etc.) Am Schluss muss vor allem eines sichergestellt sein: Die Rechnung muss in voller Höhe verbucht werden. Genau hier stehen die Paranoia-Klauseln. Sie stehen in der Software als zusätzliche interne Sicherungsmaßnahme am Schluss komplexer Verarbeitungsvorgänge. Durch diese finalen und ganzheitlichen Prüfungen wird sichergestellt, dass die Daten vollständig verarbeitet wurden.

Die entsprechende Paranoia-Klausel würde lauten:

Prüfe, ob Gesamtsumme Rechnung = Summe der erzeugten Buchungsbeträge

Für Neugierige hier der Programmcode einer Paranoia-Klausel:




Paranoia-Klauseln dienen somit der Eigenüberwachung der Software.

Sie stellen durch summarische und inhaltliche Prüfungen fest, dass die Daten vollständig verarbeitet wurden. Dies führt automatisch zu einem schweren Programmfehler (sog. Exception), sodass der Anwender die Daten auf keinen Fall in das nachgelagerte System übernehmen kann. Und das ist volle Absicht. Greift eine Paranoia-Klausel, dann ist eine Situation eingetreten, die bei der Entwicklung des Programms nicht vorhergesehen wurde oder die nicht vorhersehbar war. Dabei kann es sich um einen Programmierfehler, fehlerhafte Daten aus dem Vorsystem, einen neuen, unbekannten Geschäftsvorfall oder ähnliches handeln. Neben der normalen Validierung der Daten sind die Paranoia-Klauseln ein wichtiges Mittel um die systemische Ordnung eines Computerprogramms zu gewährleisten.

Die Paranoia-Klausel ist nur ein Baustein von vielen

Dass ein Vorsystem richtige Daten liefert, reicht in der heutigen Zeit nicht mehr aus. Im Rahmen der GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) muss Software, die steuerlich relevante Daten verarbeitet, noch wesentlich mehr leisten. Hier die entscheidenden Hinweise zu diesem Thema: „Im Schrifttum wird daher die Auffassung vertreten, dass die Einhaltung der Grundsätze ordnungsmäßiger Buchführung bereits bei der Anwendungsentwicklung beginnt.“ (Goldshteyn/Thelen 2016: 61*)  Die Softwarehersteller sind also gefordert.

Systemübergreifende Kontrollen sind Pflicht

Prüfungen und Fehlerkontrollen können Softwareprogramme immer nur innerhalb ihres Hoheitsgebietes durchführen. Sobald mit einem Vorsystem gearbeitet wird, auf dass das jeweilige Softwareprogramm keinen Zugriff hat (z.B. per API), müssen entsprechende Kontrollen durch den Menschen erfolgen: „Dies gilt umso mehr beim Einsatz von DV-Systemen. Weil die Erfassung und die Verarbeitung von Geschäftsvorfällen nicht selten in unterschiedlichen DV-Systemen vorgenommen werden, ist auch Kontrollen bei der Datenübertragung (auch als Schnittstellenkontrollen) eine hohe Bedeutung beizumessen.“ (Goldshteyn/Thelen 2016: 61*)

Fazit

Eine richtige Finanz- oder Lohnbuchhaltung entsteht nur, wenn alle beteiligten Komponenten Teil eines vollständigen Prozesses sind. Die Verarbeitung der Daten muss von der Entstehung über ggf. mehrere Verarbeitungssysteme hinweg bis zur Finanzbuchhaltung und letztlich der Steuererklärung nachvollziehbar sein.

Alle Verantwortlichen, egal ob Unternehmer, Steuerberatungskanzlei oder Buchhalter, sollen folgendes beachten:

  • Sorgen Sie für eine vollständige GoBD-Verfahrensdokumentation.
    Diese sollte alle Besonderheiten Ihres Unternehmens abdecken
    (Im Beispiel der Kaffeerösterei wären das z. B. auch zollrechtliche Dinge).
  • Prüfen Sie, ob zu allen Vorsystemen die entsprechenden Bedienungsanleitungen
    vorhanden sind und ob aus diesen die Logik vollständig hervorgeht, nach der die Daten verarbeitet werden.
  • Archivieren Sie diese Bedienungsanleitungen (von manchen Herstellen ausgelieferte Wikis oder ähnliche Knowledge-Management-System sind an dieser Stelle völlig ungeeignet, da sich deren Inhalt permanent ändert).
  • Prüfen Sie, ob das Vorsystem Verarbeitungsprotokolle liefern kann und archivieren Sie diese regelmäßig.
  • Dokumentieren Sie die Einstellungen der Programme (Kontierregeln, Nummernkreise etc.) und archivieren Sie diese. (Stichwort: GoBD-Programmierprotokoll).
  • Führen Sie (menschliche) Kontrollen ein, die sicherstellen, dass die Daten aus System A auch in System B vollständig angekommen sind (summarische Prüfungen, Lücken- und Mehrfachbelegungsanalysen). Diese Kontrollen sind Daueraufgaben und müssen zwingend Teil der GoBD-Verfahrensdokumentation sein.
    Übrigens verhindern diese Kontrollen oftmals Unterschlagung und Diebstahl im eigenen Unternehmen.
  • Wenn Sie Ihre Finanz- oder Lohnbuchhaltung an eine Steuerkanzlei oder einen Buchhaltungsdienst ausgelagert haben, beziehen Sie dessen Tätigkeiten in Ihre GoBD-Verfahrensdokumentation mit ein. Klären Sie Datenübergaben, Bring- und Holschulden.
  • Verantwortlich für die GoBD ist immer der Steuerpflichtige selbst. Als Unternehmer sollten Sie dieses Thema selbst in Hand nehmen. Da zur Erstellung der GoBD-Verfahrensdokumentation immer eine Ist-Analyse erforderlich ist, ergeben sich hier regelmäßig Einsparpotenziale sowie Möglichkeiten zur Prozessoptimierung und Personalentlastung.

Tools, die lediglich Daten verarbeiten sind nicht zukunftsfähig. Was wir heute brauchen ist eine Software mit einer hohen Verarbeitungs- und Fehlerprüfungsintelligenz, die sich reibungslos in einen (GoBD-konformen) Prozess eingliedern lässt.

*Quellen:
Goldshteyn, Michael / Thelen, Stefan (2016): Praxishandbuch digitale Betriebsführung: Anforderungen der neuen GoBD an Buchführung, Datenspeicherung und Datenzugriff. Schäffer-Poeschel Verlag ISBN 978-3-7910-3446-1

Stefan Kaumeier
dekodi - Deutscher Konverterdienst GmbH
Geschäftsführung

Weiterempfehlen

Newsletter Anmeldung

Bitte JavaScript aktivieren, um das Formular zu senden