Beiträge

Belegausgabepflicht zur Vermeidung von Steuerbetrug – über Sinn, Unsinn und die Realität

9.3.2020 / Falk Borgmann, Strategy Consultant, Deepshore GmbH

Dem Steuerbetrug den Kampf ansagen – so lautet das Motto. Und die Aufregung ist jetzt groß. Seit diesem Jahr gilt in Deutschland eine Belegausgabepflicht, die verbindlich vorschreibt, dass ein Händler oder Verkäufer seinem Kunden ein Kassenbeleg überlassen muss, mit dem der Kunde dann machen kann, was er will. Tonnen an Thermopapier werden nun verbraucht, das meistens direkt im Mülleimer landet. Nein, nicht einmal im Altpapier, selbst wenn es „Papier“ heißt und auch dann nicht, wenn bei der Herstellung auf den Stoff Bisphenol A verzichtet wurde. In den meisten Fällen ist es einfach Restmüll.

Überrascht wurde der Handel nun von dem 2016 verabschiedeten „Gesetz zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen“ (GSMdG) und der dazugehörigen Kassensicherungsverordnung (KassenSichV, 2017) und geht jetzt gegen die Papierverschwendung in die Offensive. Wer denkt: „Wir haben doch 2020? Dann ist das Gesetz doch schon über drei Jahre alt?“, der hat vollkommen recht. Die Ausgabepflicht ist daher auch nicht isoliert zu betrachten, sondern immer im Gesamtkontext bestehender und neuer Regelungen. Um den Sinn und Unsinn des öffentlichen Diskurses einmal etwas zu ordnen, habe ich die Hintergründe für den Laien im folgenden Beitrag etwas sortiert.

Wer hat an der Uhr gedreht?

So richtig nahm das Thema „Steuerbetrug im Kassendatenkontext“ im Jahr 2003 mit einem Bericht des Bundesrechnungshofes Fahrt auf. Von Steuerausfällen in Milliardenhöhe war hier die Rede. Damals wurde das INSIKA-Verfahren (INSIKA – Integrierte Sicherheitslösung für messwertverarbeitende Kassensysteme) zusammen mit mehreren Partnern entwickelt. Es sollte die angemahnten möglichen Manipulationen an den Kassen verhindern. Geplant war, die rechtlichen Grundlagen zur Einführung von INSIKA im Jahr 2008 zu schaffen. Daraus wurde jedoch nichts. Vielmehr wurde dem Wunsch des Handels nachgegeben, nicht ein konkretes Verfahren oder eine bestimmte Technologie vorzuschreiben – zu teuer und zu unflexibel, so die Argumentation. Stattdessen stand am Ende in den beiden zuvor genannten Verordnungen, eine neutral formulierte Variante im Gesetzestext, die sich ausschließlich auf das gewünschte technische Verhalten konzentrierte und dabei insbesondere zwei Dinge fokussierte: Zum einen handelt es sich um eine sogenannte TSE (Technische Sicherheitseinrichtung), die jeden Kassenbeleg technisch signieren muss und es so unmöglich machen soll, innerhalb eines Einzelbelegs zu manipulieren oder gar ganze Belege verschwinden zu lassen. Zum anderen gibt es die als DSFinV-K (Digitale Schnittstelle der Finanzverwaltung für Kassensysteme) bekannte Datenüberlassung, mit der ein Steuerprüfer Kassendaten bis auf Einzelpositionsebene prüfen kann. Der Handel hatte also gewonnen und man konnte sich auch die teure Umrüstung seiner Kassen mit Smart Cards sparen. Auf den ersten Blick ein Sieg für die Freiheit.

Manchmal kommt es anders

Aber eines wurde von den Akteuren nicht ganz bis zu Ende gedacht, denn ohne eine konkrete Vorgabe konnte es keinen fest definierten Standard geben, sondern lediglich einen technischen Rahmen. Oder anders ausgedrückt: Nun war es an den Kassenherstellern und Handelsunternehmen, diesen Standard je nach Lösung ganz individuell zu definieren. Volkswirtschaftlich sicherlich nicht der sinnvollste Ansatz – aber immerhin fast technologieoffen. Der Staat, der bei INSIKA die Ausgabe der Smart Card quasi organisiert und somit auch die Funktion der jeweiligen Lösung ein Stück weit mit verantwortet hätte, ist nun fein raus. Das Bundesministerium für Finanzen (BMF) hat gesagt, was das Ergebnis sein muss und jeder Händler oder Kassenhersteller kann es realisieren, wie er lustig ist – solange man sich an die technischen Vorgaben des Bundesamtes für Sicherheit in der Informationstechnik (BSI) hält und einen Prüfer von der rechtlichen Sinnhaftigkeit der individuellen Gesamtlösung überzeugen kann.

GoBD (2014 – Neufassung 2019) und Aufbewahren digitaler Unterlagen bei Bargeschäften (BMF-Schreiben von 2010)

Was bei der Diskussion häufig vollständig verdrängt wird, ist die Tatsache, dass die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) und das o. g. Schreiben des BMF von 2010 auch noch gültig sind. Es ist sogar sehr wichtig, zukünftige Lösungen nicht nur im Lichte neuer Regularien, sondern im Kontext der bereits bestehenden rechtlichen Rahmenbedingungen zu bewerten. GoBD und das BMF-Schreiben von 2010 regeln gewissermaßen all das, was mit einem Kassenbeleg oder einem TSE-Transaktionsprotokoll passieren muss, wenn diese produziert wurden und das Quellsystem verlassen haben. Dass diese Daten ein Quellsystem verlassen sollten, liegt zumindest bei größeren Handelsunternehmen mit mehreren Kassensystemen und einer zentralen IT auf der Hand. Denn die Aufbewahrungsfrist von zehn Jahren übersteigt die durchschnittliche Lebenserwartung einer Kassenhardware und einer USB-basierten TSE. Von daher ist es zwingend erforderlich, diese Daten in einem Archivsystem zu verwahren. Außerdem müssen die entsprechenden Informationen für eine zentrale Steuerprüfung greifbar sein, was mit einer dezentralen Datenhaltung nicht sinnvoll umsetzbar ist.

Vor den Regularien der Fiskalisierung war die Lücke aus Sicht des BMF das Kassensystem selbst, denn es gab keine genaue Definition, was die Originaldaten des Kassensystems sind (lokaler Kassenschieber, lokaler Server, zentraler Kassenserver), respektive, wie innerhalb eines Kassensystems sichergestellt werden muss, dass alle Transaktionen korrekt erfasst und verarbeitet wurden. Andere EU-Länder sind schon lange einen Schritt weiter und haben diesen Bereich auch von rechtlicher Seite mit genauen Vorgaben unterfüttert. Mithilfe von spezieller Software wie „Zapper“, konnten in Deutschland Kassensysteme relativ einfach manipuliert werden. Unter Zappern versteht der Gesetzgeber jene Art von Software, die nur vorübergehend für die Manipulation von Daten in das Kassensystem geladen wird und keine direkten Spuren hinterlässt. Sie kann gespeicherte Transaktions- und Umsatzdaten nachträglich verändern oder ganz löschen. Mit dieser Software kann am Kassensystem selbst manipuliert werden, auch wenn der folgende Gesamtprozess im Sinne der GoBD sowie des BMF-Schreibens von 2010 vollständig und transparent realisiert wurde. Diese Lücke wurde durch die Kombination von TSE und DSFinV-K geschlossen. Somit bilden GoBD, BMF-Schreiben 2010, KassenSichV und GSMdG und alle zugehörigen Ergänzungen (z. B. DSFinV-K, §146a AO und technische Richtlinien des BSI) ein gesamtheitliches Konstrukt, das den Rahmen einer Kasseninfrastruktur definiert. Dazu gehören also:

  • Kassensoftware,
  • Technische Sicherheitseinrichtung (TSE),
  • angeschlossenes Langzeitarchiv,
  • datenlogistische Prozesse (Datenentsorgung aus der Kasse/TSE),
  • DSFinV-K-Download und
  • Verfahrensdokumentation.

Sich als Händler dabei auf den Kassenhersteller zu verlassen bzw. zu glauben, dass mit der Einbindung einer TSE alles erledigt sei, ist grob fahrlässig und kann im Zweifel sehr teuer werden.

Ziele einer Prüfung ab Oktober 2020

Auf Basis der skizzierten Gesetze und Verordnungen und den sich daraus ableitenden weitreichenden Prüfungsmöglichkeiten ist ein Steuerprüfer in der Lage, sich ein relativ umfassendes und vollständiges Bild über die (Kassen-)Daten eines Händlers zu verschaffen. Über die bereits erwähnte Datenüberlassung (DSFinV-K) kann schnell die Vollständigkeit der Belege überprüft werden. Zusammen mit den Transaktionsdaten einer TSE, die das Erstellen jedes einzelnen Belegs speichert, hat der Prüfer ein mächtiges und schwer zu manipulierendes Werkzeug zur Hand. Und entgegen der verbreiteten Auffassung, dass die DSFinV-K nur bei einer Außenprüfung (einer sogenannten Kassennachschau) relevant ist (und deshalb nur Stichproben auf Einzelkassenebene durchgeführt werden können), wird sich eine Prüfung mit hoher Wahrscheinlichkeit nun auf die zentralen IT-Systeme ausweiten. Denn warum sollte ein Prüfer auf dieses Instrument bei einer zentralen Steuerprüfung verzichten? Einen DSFinV-K-Download im Rahmen einer zentralen Steuerprüfung zu fordern, ist rechtlich keinesfalls ausgeschlossen – ganz im Gegenteil. Als explizites Ziel der DSFinV-K sind „die Auslagerung von Daten in ein Archivsystem“ und die „vereinfachte Überprüfung von Daten der Finanzbuchhaltung auf Basis von Kassendaten“ definiert. Das bedeutet so viel wie: Eine DSFinV-K-Datenüberlassung aus einem zentralen Sicherungssystem (Archiv) zum Abgleich mit der Finanzbuchhaltung wird sehr wahrscheinlich kommen. Hier wird klar, dass die bisher häufig übliche Datenüberlassung (Z3- im alten IDEA-Format) auf Basis der Finanzbuchhaltung im Fall von Kassendaten obsolet wird. Es sei denn, man kann seinen Steuerprüfer davon überzeugen, dass es sinnvoll ist, die Daten der FiBu anhand eines Datenextraktes aus eben dieser FiBu zu validieren.

kassendaten belegpflicht

Die Haltung des Handels in dieser Sache ist sehr unterschiedlich. Einige Händler bereiten sich seit Monaten akribisch auf die Zukunft vor und einige sind Meister darin, den Kopf in den Sand zu stecken. „Man kann doch nicht erwarten, dass die Buchungen in der Finanzbuchhaltung mit den Rohdaten aus der Kasse vergleichbar sind“, so ein Verantwortlicher eines Handelskonzerns. Ich bin mir nicht sicher, inwieweit ein Finanzbeamter dieser Argumentation im Falle von Auffälligkeiten im Rahmen einer Prüfung folgen wird. Ich halte es für wahrscheinlicher, dass der Fiskus ein gesteigertes Interesse daran hat, sich entsprechende Strafzahlungen nicht entgehen zu lassen. Auf jeden Fall gibt es ab Oktober 2020 kaum noch die Möglichkeit, Daten innerhalb eines Kassensystems zu manipulieren.

Bleibt die Frage, welchen Beitrag die Belegausgabepflicht liefert, um Steuerbetrug zu vermeiden? Klare und kurze Antwort: keinen.

Teilen: