GoBD-Compliance Teil 3 | Die Kasse als Datenverarbeitungssystem mit Hinweisen zum neuen IDW PH 9.860.4

Interview mit Viktor Rebant 

Mit dem Gesetz zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen (kurz KassenG) v. 28.12.2016 hat der Gesetzgeber verschiedene organisatorische und technische Maßnahmen installiert, die den Umsatzverkürzungen, mittels moderner Kassensysteme, den Kampf ansagen sollen. In diesem Interview beleuchten wir typische Praxissituationen, die nicht unbedingt mit Manipulationen, sondern mit Unwissenheit oder Undurchschaubarkeit von Prozessen im Zusammenhang mit elektronischen Aufzeichnungssystemen stehen. Bei den Aufzeichnungssystemen handelt es sich i.d.R. um Datenverarbeitungssysteme (Rz. 20 GoBD 2019), welche steuerlich relevante Daten in Form von Geschäftsvorfällen und sonstigen Vorgängen aufzeichnen. Folglich gilt es, neben den gesetzlichen Vorgaben (u.a. §§145, 146, 146a,147 Abs. 1 und 6 AO), die Anforderungen an die GoBD, insbesondere zur Verfahrensdokumentation und zum IKS umzusetzen.

Viktor, welche Änderungen bringt das KassenG mit sich?

Im Kern bringt das KassenG folgende Maßnahmen mit sich:

• Übergangsregelung für Altsysteme
  • Es dürfen nicht mehr alle Registrierkassen und PC-Kassensysteme eingesetzt werden, sondern solche, die den speziellen Anforderungen des KassenG nachkommen. Speziell im Fall einer Registrierkasse ist individuell zu prüfen, ob von der Übergangsregelung bis Ende 2022 Gebrauch gemacht werden kann.
• Einzelaufzeichnungspflicht
  • Die Einzelaufzeichnungspflicht wurde in die Abgabenordnung (§ 146 Abs. 1 AO) übernommen und somit gesetzlich verankert; Unabhängig davon, ob eine Buchführungspflicht besteht oder nicht. Alle Geschäftsvorfälle sind demnach einzeln aufzuzeichnen, insbesondere Kasseneinnahmen und Kassenausgaben sind täglich festzuhalten. 
  • Der Gesetzgeber hat damit für Klarheit gesorgt
• Verpflichtender Einsatz einer technischen Sicherheitseinrichtung
  • Zentraler technischer Baustein gegen Manipulationen in Kassensystemen; Die „Blackbox“ der Finanzverwaltung
  • Implementierung der Einheitlichen digitalen Schnittstelle
  • Standardisierte Datensatzbeschreibung DSFinV-K
• Belegausgabepflicht
  • Es muss zwingend ein Beleg (§ 146a Abs. 2 AO) ausgegeben werden, auch wenn der Kunde diesen nicht annehmen möchte
  • Auf den Beleg müssen neue Pflichtangaben aufgedruckt werden, die z.T. aus der TSE stammen
• (Kassen-) Meldepflicht
  • Alle Kassensysteme, die unter den sachlichen Anwendungsbereich des § 146a AO erfasst werden, müssen beim Finanzamt an – und abgemeldet (§ 146a Abs. 4 AO) werden
• Aufnahme neuer Sanktionierungen in den Bußgeldkatalog § 379 AO
  • Wer den Anforderungen u.a. zum Kassensystem nicht nachkommt, kann mit einem Bußgeld belangt werden (auch ohne bewiesene oder tatsächlich stattgefundene Steuerverkürzung, ein nichtgerechtfertigter Steuervorteil ist ausreichend)
  • Belegausgabepflicht und Meldepflicht werden jedoch nicht sanktioniert

Diese Maßnahmen sollten sukzessiv bis Anfang 2020 wirksam werden. Jedoch hat sich die Implementierung der TSE und die Meldepflicht zeitlich verzögert. Mittlerweile sollten alle betroffenen Kassensysteme mit einer TSE ausgerüstet sein – rein theoretisch. In der Praxis trifft man weiterhin auf einige Kassensysteme/Software-Lösungen, die noch immer keine TSE aufweisen – hier kann es wirklich teuer werden. Denn der Finanzbeamte kann bereits mit einem Blick auf den Kassenbon erkennen, ob eine TSE implementiert worden ist oder nicht.

Die Meldepflicht wurde zunächst vom BMF (BMF-Schreiben v. 06.11.2019) Ende 2019 bis zur Einrichtung einer elektronischen Übermittlungsmöglichkeit ausgesetzt. Weitere Informationen lagen der Fachwelt bis März 2021 nicht vor. Hinsichtlich der Meldepflicht nach § 146a Abs. 4 AO wurde in der Beantwortung einer Kleinen Anfrage (Tz. 17 – 17b, BD-Sache 19/27565 v. 15.03.2021) bekannt, dass vor 2023 mit keiner elektronischen Übermittlungsmöglichkeit zu rechnen sein wird.

Viktor, wer wird überhaupt vom KassenG (speziell § 146a AO) erfasst? Existieren in der Praxis in Bezug darauf Probleme oder Unklarheiten?

Der sachliche Anwendungsbereich des § 146a AO wird durch Nutzung einer für den Verkauf von Waren oder die Erbringung von Dienstleistungen und deren Abrechnung spezialisierte Software mit Kassenfunktion eröffnet. Das bedeutet konkret: Nutze ich eine Software, mit der ich zumindest teilweise bare Zahlungsvorgänge erfassen und abwickeln könnte, komme ich in Pflicht die einzelnen Maßnahmen des § 146a AO umzusetzen. Dabei ist das Wort „könnte“ zu beachten. Es geht nicht darum, ob ich diese Funktion nutze oder nicht. Es wird allein auf den Funktionsumfang abgestellt.

Gleichzeitig listet der § 1 KassenSichV alle Systeme auf, die nicht vom sachlichen Anwendungsbereich erfasst werden. So fallen z.B. elektronische Buchhaltungsprogramme nicht darunter.

Probleme sehe ich bei „Zwitterprogrammen“. Es existieren auf dem Markt Online-Anwendungen, die als Buchhaltungsprogramm beworben werden, jedoch gleichzeitig Funktionen eines „light“ ERP-Systems aufweisen. Ihr Ursprung lag in der selbständigen Erstellung der Buchhaltung, nur wurde der Funktionsumfang dieser Online-Lösungen immer weiter ausgebaut. Das in diesen Programmen befindliche Kassenbuch kann auch als POS-System/Verkaufsdialog genutzt werden. Es können Artikel angelegt und der Verkauf direkt über das Kassenbuch erfasst werden. Meist können weitere Online-Module von Drittanbietern angedockt werden (z.B. Warenwirtschaft). Eine klare Abgrenzung bei solchen Systemen ist nahezu unmöglich. Nach meiner Rechtsauffassung fallen diese Systeme in den sachlichen Anwendungsbereich des § 146a AO und damit auch in die TSE-Pflicht. (s.  Achilles/Danielmeyer RET 4/2020, 18). An der Stelle sollte der Gesetzgeber für Klarheit sorgen und den Begriff „elektronisches Buchhaltungsprogramm“ fest definieren, damit eine Abgrenzung möglich wird. Darüber hinaus wird diese Problematik durch den neu geschaffenen PH GoBD-Compliance nicht gänzlich abgebildet. Zwar sieht die Regelprüfung des Basisschrittes Verfahrensdokumentation (insbesondere in Rz. 4 – 8) die Beschreibung zu „Zwitterprogrammen“ vor. Doch werden die o.g. Nutzungsmöglichkeiten, insbesondere der Verkauf über das Kassenbuch, in der Praxis häufig nicht als diese erkannt und finden so keinen Einzug in die Verfahrensdokumentation. Es wird also unter Umständen nur das „halbe“ Verfahren beschrieben und testiert. Im Rahmen einer Betriebsprüfung könnte das zu Problemen führen.

Viktor, wie waren die Reaktionen der Unternehmen in der Praxis?

Sehr gemischt. Unternehmen im bargeldintensiven Bereich sind bereits für diese Themen sensibilisiert, da sie besonders tiefgehende digitale Betriebsprüfungen gewohnt sind. Anders war es bei den Heilberuflern (Ärzte, Zahnärzte, Physiotherapeuten, …).

Ihre Praxisabrechnungssoftware weisen nahezu alle Kassenfunktionen in Form eines Kassenbuches auf. Dessen waren sich weder die Heilberufler, noch deren Software-Anbieter oder sogar der eigene Steuerberater bewusst. Ich hatte einige Diskussionen mit Software-Unternehmen aus diesem Bereich, die voller Überzeugung waren, dass der sachliche Anwendungsbereich für ihr System gar nicht gelte und es sich doch offenkundig um kein Kassensystem handeln könne (selbst die Notwendigkeit zur Einhaltung der GoBD wurden angezweifelt, aber das ist ein anderes Thema). Jedoch haben auch diese Anbieter nach einiger Zeit zurückgerudert und eine TSE nachträglich implementiert oder die Kassenfunktion in der Software einfach deaktiviert.

Noch amüsanter waren die Fälle bei Nutzern bestimmter EC-Terminals. Einige EC-Terminals haben im Hintergrund eine Cloud-Kassensoftware laufen, mit der auch bare Zahlungsvorgänge verwaltet werden können – dieser Programmbereich ist meist unbekannt und wird daher nicht genutzt. Diese Softwareanbieter waren aber von vornherein für die Thematik des KassenG sensibilisiert und haben ihre Kunden mittlerweile mit einer Cloud-TSE ausgestattet. Auch hier führt die Unkenntnis der tatsächlichen Praxisverhältnisse zu einem unrunden Testat des neuen PH. Was ich nicht kenne, kann ich nicht prüfen. Hier wäre, insbesondere für die vorgenannten Branchen des Mittelstands, eine im Detail tiefere Prüfung und Sachverhaltsabfrage notwendig.

Welche Auswirkungen ergeben sich durch das KassenG für Softwarehersteller, Unternehmen und Steuerberater?

Das KassenG löst zwischen den drei Parteien ein gemeinsames Projekt aus. Im Zentrum steht die Kassenführung des Mandanten/Kunden. 

Dabei sehe ich den Steuerberater als Projektmanager. Dass der Steuerberater im Bereich des KassenG sprachfähig sein muss, sollte als Standard gegeben sein. Steuerberater die in diesem Bereich keine Expertise besitzen wollen, müssen sich entweder von bargeldintensiven Mandanten trennen oder diesen Bereich der Beratung an Kollegen mit entsprechender Expertise outsourcen. Denn die Haftungspotentiale sind enorm. Es reicht nicht aus, Zahlen in die Buchhaltung stumpf zu übernehmen. Der Steuerberater muss sich intensiv mit der Anwendungssoftware und den unternehmensinternen Prozessen des Mandanten auseinandersetzen. Auch die Fähigkeit, eine Datenanalyse durchführen zu können, ist für diesen Mandantenkreis von essentieller Bedeutung. 

Softwarehersteller sollten sich zwingend für die Schnittstelle zwischen TSE und elektronischem Aufzeichnungssystem (Kassensystem) steuerlichen Rat einholen. Neben den Geschäftsvorfällen, die meist eindeutig sind, müssen auch die sogenannten „Anderen Vorgänge“ identifiziert werden. Aber auch die Belegausgabepflicht kann in einigen Konstellationen Probleme aufwerfen. Gerade Software-Unternehmen mit veralteten Datenbankstrukturen müssen sich die Frage stellen, ob eine neue Architektur für die Herausforderungen der Zukunft geeigneter wäre. Es existieren einige Anwendungsprogramme auf dem Markt, die noch nicht mal eine massenhafte Schnittstellenverprobung zulassen – der Traum eines jeden Betriebsprüfers. In der Praxis ist zu beobachten, dass einige Softwarehersteller die Kassenfunktionen aus deren Software verbannen und sich dadurch dem sachlichen Anwendungsbereich entziehen möchten. Darunter leiden folglich die unternehmensinternen Prozesse, da eine separate Aufzeichnung erfolgen muss.

Unternehmen müssen mit höheren Beratungshonoraren und mit wiederkehrenden Aufwendungen für Datenanalysen rechnen. Gleichzeitig müssen sie gewillt sein, ihre Unternehmensprozesse anzupassen, wenn diese nicht konform mit dem KassenG gehen sollten. 

Aber warum Datenanalysen? 

Gerade bei „günstiger“ Software fehlen Programm-Module, mit denen bestimmte Sachverhalte abgebildet werden können. Der Lösungsweg: Die Faktura-Funktion wird genutzt, um diesen Mangel zu kompensieren. Es werden fiktive Umsätze aufgezeichnet – diese müssen zwingend in der Verfahrensdokumentation dokumentiert werden, da es sonst zu Fragen/Differenzen im Rahmen eines Umsatz-Abgleiches zwischen lokaler Datenbank und der Finanzbuchhaltung kommen kann – die TSE kommt herausfordernd dazu. Die Datenanalyse ist ein wirksames Instrument, die Qualität der Systemnutzung bzw. der Aufzeichnungsqualität festzustellen. Wir konnten bereits erste Fehler in DSFinV-K Exporten feststellen.

Das sind äußerst interessante Praxisinfos, Viktor. Bei der Durchführung einer Verfahrensdokumentationsprüfung muss hier m.E. ein besonderes Augenmerk liegen. Ein Standardprüfschritt (Basiselement Verfahrensdokumentation Nr. 1 – 8 bzw. Generelle IT-Kontrollen –Nr. 9 Changemanagement), der nach einem stringenten Plan vorgeht, könnte diese Nutzungsart bei Nichtdokumentation übersehen.

Kommen wir noch einmal auf die TSE zurück. Wie funktioniert die TSE?

Wie die TSE im Kern funktioniert, ist etwas komplizierter und würde den Rahmen sprengen. Jedoch kann man ihre Funktionsweise (sehr) kurz skizzieren und damit ihre wesentliche Kernfunktion greifen. Man kann sich die TSE als Blackbox bzw. standardisiertes und geschütztes Datenerfassungsprotokoll vorstellen. Werden Geschäftsvorfälle oder andere steuerrelevante Vorgänge im Kassensystem aufgezeichnet, wird hierdurch die TSE „getriggert“ und sie beginnt Aufzeichnungen mitzuschreiben und über kryptografische Verfahren abzusichern. Sie sichert die Geschäftsvorfälle zum Zeitpunkt ihrer Entstehung ab. Sollte nachträglich in der lokalen Datenbank des Kassensystems manipuliert werden, so können die Aufzeichnungen der TSE dies offenlegen. Jede TSE muss einen Zertifizierungsprozess beim BSI durchlaufen. Es existieren sowohl lokale als auch Cloud-Lösungen. Wobei ich die These in den Raum werfen möchte, dass die Cloud-TSE sich in Zukunft klar durchsetzen wird. 

Viktor, was empfiehlst du Unternehmen konkret mit Blick auf die Neuerungen des KassenG?

Oft erlebe ich in Beratungen, dass im Bereich der Software gerne gespart wird. An der Stelle sollte jedoch nicht gespart werden. Einer günstigen Software fehlt es oft an Programmfunktionen, die medienbruchfreie und GoBD-konforme Prozesse im Unternehmen ermöglichen (z.B. Aufbewahrung EC-Belege). Aufzeichnungen sind nicht immer vollständig in der Datenbank oder es existieren zu wenig Auswertungsmöglichkeiten im Bereich der Compliance. Auch ist die Rechteverwaltung meist zu grob strukturiert und eine feine Rechtevergabe wird nicht ermöglicht. Die eingesparten Kosten sind lediglich verlagerte Kosten. Im Rahmen von digitalen Betriebsprüfungen erzeugen solche Systeme mehr Rückfragen seitens der Finanzverwaltung, was höhere Beratungshonorare und idR höhere Schätzungen mit sich führt. Gute Software sollte als Investition in die Prozesslandschaft des Unternehmens verstanden werden. Auch aus diesem Grund wird der neue Prüfschritt zwar zu Testaten führen. Mangels Kenntnis dieser elementaren Basics wird sich das Unternehmen in Sicherheit wägen, aber durch eine evtl. Kassen-Nachschau oder Betriebsprüfung sehr schnell von einem besseren belehrt werden. Oft mit der Folge von Hinzuschätzungen, da die Prozesse nicht nachvollziehbar sind. 

Und wie finde ich als Unternehmen die richtige Software?

Das ist eine gute Frage. Ich persönlich sehe den Steuerberater als Digitalisierungsberater. Diese Tätigkeit bringt u.a. die Software-Beratung als Disziplin mit sich. Elementar hierfür ist die Bestandsaufnahme der Unternehmensprozesse und die damit verbundene Bedarfsanalyse auch mit Blick in die Zukunft. Denn nichts erzeugt höhere Kosten, Stress und Unmut als ein Systemwechsel. Wer einen Systemwechsel bereits erlebt bzw. begleitet hat, weiß wovon ich spreche. 

Ich selbst biete solche Beratungen bereits an und habe schon für einige Unternehmen die nach meiner Auffassung passende Software empfohlen. Ich muss aber auch dazu sagen, dass ich mich seit meiner Jugend mit Software in den verschiedensten Formen auseinandergesetzt habe. Daher kann ich relativ schnell begreifen, wozu Software in der Lage ist. Zusätzlich arbeite ich mich in die technischen (Verfahrens-)Dokumentationen des Softwareherstellers ein und kann durch meine Erfahrung sehr schnell die Stärken und Schwächen feststellen – auch aus steuerrechtlicher Perspektive. Wichtig ist dabei die Fähigkeit, sich sowohl in die Lage des Unternehmens zu versetzen, als auch die rechtlichen und organisatorischen Rahmenbedingungen nicht außer Acht zu lassen. Aber da schweifen wir jetzt vom Thema ab…

Machen die Maßnahmen des Gesetzebers Sinn bzw. beugen diese Manipulationen wirksam vor? Und wenn nein: Was fehlt dir?

Mit dieser Frage habe ich mich ausgiebig in der RET 03/2021, 61 „Das KassenG auf dem Prüfstand“ beschäftigt.

Aber kurz zusammengefasst kann man sagen, dass weiterhin Manipulationsspielräume bestehen. Man kann durch simple Gestaltung dem sachlichen Anwendungsbereich des § 146a AO entfliehen; Lösung: (Registrier-)Kassenpflicht. Die fehlenden Sanktionierungen der Belegausgabe- und Meldepflicht sind meiner Meinung nach unverständlich, da es an einem rechtlichen Durchsetzungsmittel fehlt und dadurch in der Wahrnehmung nicht ernst genommen werden. Aber die größte Schwachstelle ist in meinen Augen die Belegausgabepflicht. Essentiell für risikominimierende Maßnahmen ist die Akzeptanz dieser selbst. Die Belegausgabepflicht ist schon aus prozessualer Sicht eine Katastrophe und führt zu Frustration bei den Unternehmen. Zusätzlich fördert sie Insellösungen zur Bereitstellung digitaler Belege – einfach zu kurz gedacht. Eine Belegannahmepflicht wäre in meinen Augen sinnvoller gewesen und hätte als Innovationstreiber im Bereich der elektronischen Belegausgabe fungiert.

Viktor, vielen Dank für dieses spannende Interview und den tiefen Einblick in bestehende Unklarheiten. Gerade bei dem unbestimmten Begriff Datenverarbeitungssystem und den vielfältigen individuellen Nutzungsmöglichkeiten besteht vielfältiger Klärungs- und Dokumentationsbedarf, um die steuerlich relevanten Daten auf sachliche Richtigkeit prüfen zu können. Die Orientierung an dem PH GoBD-Compliance kann dabei eine Hilfe sein, jedoch sollten individuelle –oftmals nicht dokumentierte – betriebliche Besonderheiten Berücksichtigung finden.