Kassen in der Betriebsprüfung, Probleme mit fehlenden Sessions bei der EuCaSoft
Bei der EuCaSoft Kasse gibt es immer wieder Probleme in den Betriebsprüfungen, da einigen Prüfern noch nicht bekannt ist, dass einzelne Sessionsnummern bei der Kasse leer sind. Das hat aber nichts mit illegalen nach- oder Nacht- Stornos zu tun.
Häufig schließen jedoch die Prüfer von fehlenden Sequenznummern auf ein heimliches Löschen der Buchungszeile zu nächtlicher Stunde und gehen dann davon aus, dass diese Kostenaufzeichnungen manipulativ bearbeitet wurden und einzelne Umsätze gelöscht wurden.
Sie kennen nicht einmal den Unterscheid zwischen Session und Sessionnummer einerseits und Sequenzen und Sequenznummern in der Sprachwelt der Kassenprogrammierung.
Die Annahme, eine fehlende Session bedeute eine illegale Löschung ist falsch.
Man muss die EuCaSoft Kassen verstehen, um die fortlaufenden Sequenznummern und Sessionnummern richtig einschätzen zu können.
Das gilt natürlich erst einmal für alle Kassen und nicht nur für die EuCaSoft. In der Bedienungsanleitung sind die Feldfunktionen definiert.
Wichtige Vorfrage ist natürlich, welche Version die Software hat und was sie zu welchem Zeitpunkt mit welcher Versionsnummer kann. Hier muss man natürlich verstehen, dass die Kassen bzw. deren Software permanent weiterentwickelt werden und der Versionsstand von vor 25 Jahren nicht mit dem heutigen vergleichbar ist.
Alle Kassenhersteller bzw. Programmhersteller beobachten den Markt und folgen den Vorstellungen und Wünschen der Finanzverwaltung und entwickeln stetig ihre Produkte weiter
- Felder (zutreffend für Versionen ab EuCaSoft 4.9.9.xxxx, Stand: 24.01.2017):
- Die Fiskaldatei beinhaltet die folgenden Felder:
- Datum: Das Systemdatum des Buchenden Systems
- Zeit: Die Systemuhrzeit des Buchenden Systems
- Seq: Die fortlaufende Sequenznummer
- ReplSeq: Wenn ein Datensatz für eine Buchung oder Rechnung in der Fiskaldatei geschrieben wird, für die bereits ein anderer Datensatz in der Fiskaldatei existiert, dann steht in diesem Feld die Sequenznummer des ursprünglichen Datensatzes. Das ist dann notwendig, wenn z.B. eine bestehende Buchung aufgeteilt wird (Split, Checkout), der Preis einer Buchung geändert wird, Rabatte vergeben werden o.ä.
- PLU: Bei Buchungen: Die Nummer des gebuchten Artikels. Bei Rechnungen ist dieses Feld leer.
- Artikel: Bei Buchungen: Die Bezeichnung des gebuchten Artikels. Bei Rechnungen ist dieses Feld leer.
- Menge: Bei Buchungen: Die Menge des gebuchten Postens. Bei Rechnungen ist dieses Feld leer.
- Gpreis: Der Gesamtwert des gebuchten Postens, mit dem dieser in die Rechnung eingeht. Aufgrund der verschiedenen Rabattierungsmöglichkeiten der Kasse, wird dieser Betrag unter Umständen mit mehreren Nachkommastellen ausgegeben, um Rundungsdifferenzen zu vermeiden.
- Terminal: Die Identifikation des Gerätes an dem die Buchung ausgelöst wurde. Im Allgemeinen hat dieses Feld die Form /. Falls die Buchung an einem mobilen Buchungsterminal ausgelöst wurde, ist das Format /:OM:, wobei dann die Geräte-Seriennummer des Buchungsterminals enthält.
- Der Name des Kellners, den die Buchung bzw. die Rechnung ausgelöst hat.
- Tisch: Raum-/Tisch-/Gastnummer
- Session: Die Session-Nummer ist eine interne Nummer, durch die die Zusammengehörigkeit von Buchungen kenntlich gemacht wird. Sie ist nicht zwingend fortlaufend, kann also nicht zur Erkennung von Lücken in den Aufzeichnungen verwendet werden. Sie ist innerhalb eines Journaltages eindeutig. Dieses Feld dient ausschließlich der einfacheren Zuordnung von Rechnungs-Zeilen zu Buchungs-Zeilen bei der Auswertung der Fiskal-Datei.
- Rechnung: Bei Rechnungen: Die Rechnungsnummer. Bei Buchungen ist dieses Feld leer.
- RechBetrag:
- Bei Rechnungen: Der Gesamtbetrag der Rechnung. Bei Buchungen ist dieses Feld leer.
- MwSt: (FileVersion 01.02*)
- Für Buchungen: Der Mehrwertseuersatz dieser Buchung (PLU)
- AusHaus: (FileVersion 01.02*)
- Für Buchungen: AußerHaus-Buchungen Mögliche Werte sind:
- 1 = AußerHaus-Buchung
- 0 = normale Buchung
Es bedarf detaillierter Informationen über die Geschäftsvorfälle und die Lage des Unternehmens, um prüfen zu können, ob die Umsätze vollständig erfasst sind. Aus Betriebsprüfersicht werden an die Unternehmensinformationen relativ einfach zu erfüllende Anforderungen gestellt – die Umsatzaufzeichnungen müssen die Umsätze vollständig und richtig wiedergeben. Anhand dieser Aufzeichnungen muss es Betriebsprüfern innerhalb angemessener Zeit möglich zu sein, zu prüfen, ob die Buchungen und sonstigen Aufzeichnungen die Umsätze vollständig und richtig widerspiegeln. Die Daten müssen ein nachweisbares, vollständiges und korrektes Bild der Umsätze zeichnen.
Die Daten können aus der EuCaSoft Kasse für Finanzberichte ausgedruckt werden, aber auch auf andere Formate -etwa Excel- überragen werden. Der Export von Umsätzen aus EuCaSoft-Kasse etwa in ein Excelformat geht schon relativ lange. Zu finden ist die Funktion unter Chef/Tagestatistiken“EXPORT“. Hier kann die Berichtsart der Zeitraum und die gewünschte Ausgabe gewählt werden. Es können folgende Berichte exportiert werden:
- Finanzenliste
- Artikelliste
- Artikel Änderungen
- Durchlaufartikel
- Kellnerliste
- ** NEU ** Kellnerabrechnungen
- Warengruppen
- Sparten
- Wareneinsatz
- Frequenzenliste
- Rechnungsliste
- RabattListe
- Tagesjournal
- ProfRechArtList
- Arbeitszeit
- IHKK-Konto
- Rechnungsliste Fehlende Buchungen
- Rechnungsliste Alle Sessions
- Rechnungsliste Wiedergeöffnete Tische
- Einzelliste
- Einzelliste.Umbuchung
- Rezepturliste
- Stornoliste
Die Berichte werden dann in einem frei lesbaren Format und einem für den Export vorgesehenen Unterordner abgespeichert. Diese Berichte („Berichts Export“) können dann mit einem Tabellenkalkulationsprogramm geöffnet werden bzw. Dorthin überragen werden.
Damit kann man aber auch an Ihnen arbeiten. Für interne Vergleiche und statistische Auswertungen ist das wunderbar. Hier kann man auch nahezu unendlich lange Zeilen und Spalten verknüpfen und alles berechnen, was etwa Excel bietet. 3-Jahres oder 5-Jahresvergleiche sind da möglich, die Geschäftsentwicklung unter allen Aspekten betriebswirtschaftlich auswertbar.
Da die Daten aber damit die Unveränderbarkeitszone verlassen haben, genügen sie aber nicht mehr den Anforderungen der Finanzverwaltung. Denn die Unveränderbarkeit der Kassendaten ist Grundlage dafür, da diese der Besteuerung zugrunde gelegt werden. Auch die Erklärung des Steuerpflichtigen, die Auswertungen haben nichts mit einer Manipulation zu tun und die Daten auf den Exceldateien entsprächen den Rohdaten, dürfte das Misstrauen des Prüfers so erhöhen, dass er sich auch die Daten nicht verlassen wird und die Buchführung verwerfen wird. Dabei genügt dem Prüfer die Möglichkeit der Datenveränderung zur Verwerfung.
Ob etwas und was geändert wurde, ist ihm dabei gleichgültig.
Darauf kommt es aus Sicht der Finanzverwaltung nicht an. Die bloße Möglichkeit der Änderung genügt. Und indem die Daten in ein nicht festschreibendes Programm überführt werden, könnte die Manipulation erfolgt sein. Allein bei jedem Export, könnte ein Eingriff auf die ursprünglichen Rohdaten erfolgen.
Also exportieren in eine andere Datenwelt und das Rückspielen wirft die Frage auf, ob die Daten verändert wurden. Auch hier genügt die Möglichkeit für die Finanzverwaltung um diesen Daten nicht mehr zu trauen. Das Gebot der Festschreibung der Daten ist also Spiegelbild die Grundlage für das Vertrauen des Prüfers, dass diese sofort festgeschriebenen Daten jedenfalls seit dem Zeitpunkt der Erfassung nicht mehr verändert und nicht etwaigen Wunschergebnissen des Unternehmers angepasst wurden.
Solche Berichte, die in andere Formate exportiert wurden, sind nicht dem Fiskal-Export zu verwechseln. Beim Fiskal Export werden auch frei lesbare Dateien ausgegeben, diese Datensätze sind jedoch mit einer Prüfziffer versehen. Somit ist anhand der Prüfziffer nachvollziehbar, ob umsatzrelevante Daten im System geändert wurden.
Sodann stellen sich in der BP folgende weitere Fragen: ist das die einzige Kasse oder gibt es eine 2., schwarze inoffzielle Kasse/2. schwarzes Kassensystem (etwa im Keller, Nebenraum, in der Privatwohnung?)? Hier könnte dem Kassennachschauer oder Prüfer im Gastraum vorgespielt werden, dass alle Umsätze boniert werden und in Wahrheit wird entweder auf einer 2. Kasse im Keller oder auf dem Dachboden nur der Wunschumsatz gebucht oder abwechselnd mal auf der einen und mal auf der anderen Kasse boniert und nur eine Kasse schreibt die Zahlen auf den Gesamtumsatzzähler.
Die nächste Frage ist: Werden alle Umsätze boniert oder ein Teil eben nicht?
Das lässt sich nur durch Beobachtungen, Testkäufe, Kontrollmaterial herausbekommen.
Wenn diese beiden Vorfragen geklärt sind, und es nur eine einzige Kasse gibt bzw. alle Mobilgeräte angeschlossen sind und alle Umsätze in der Gesamtsumme der Tagesumsätze enthalten sind, gilt es noch ein paar Feinheiten zu klären: dafür ist die Kassenprogrammierung wichtig. Sind alle Mobilgeräte bzw. alle Kellner mit der Kasse verbunden und laufen deren Umsätze auf das Gesamtsummenzählwerk? Sind alle Uhrzeiten und alle Tische erfasst oder gibt es ein Lochmuster ähnlich den alten Lochkarten und wo sind die Löcher? Wird also der Umsatz auf jedem Tisch während der gesamten Öffnungszeit auf die Gesamtsumme geschrieben? Oder gibt es einzelne Tische, die nicht auf den Gesamtsummenzähler laufen? Ist also Tisch 17 der Lieblingstisch des Gastwirts, da in der Programmierung nur Tisch 1 bis Tisch 16 plus Tisch 18 bis Tisch 36 auf den Gesamtsummenzähler laufen? Aber auch das lässt sich in der digitalen BP herausfinden: man lässt die Tisch schichten nach deren Häufigkeit der Buchungen oder nach den Uhrzeiten der Buchungen. Bester Tisch ganz oben, schlechtester ganz unten. Dan müsste auffallen, wenn Tisch 16 der Beste mit 33.000 Buchungen im Prüfungszeitraum war und Tisch 17 der Schlechteste mit 0 Buchungen… Und wenn Tisch 17 nie auftaucht, gibt es den vielleicht gar nicht oder es ist ein Nottisch an der Tür oder an der Toilette, an den sich freiwillig nie jemand setzt, solange man nur ausweichen kann? … und wenn der Prüfer bei der Betriebsbesichtigung feststellt, dass das der schönste Tisch mit der besten Aussicht ist, wird er staunen, warum der nie belegt ist …
Oder sind beispielsweise nur Schulstunden statt Zeitstunden für die Umsatzaddition programmiert, so dass nur der Umsatz während 45 Minuten statt über 60 Minuten auf dem Gesamtsummenzähler addiert wird? Findet also z.B. die Buchung auf dem Fiskalspeicher nur von 19:00 bis 19:45 statt und ist die Zeit von 19:46 bis 19:59 ohne Beteiligung des Fiskus …und in den übrigen Zeitsunden genauso oder gibt es andere, feinere Muster? Ist also nie ein Umsatz in der Zeit von 19:17 bis 19:36 und von 20:20-20:42 und von 21:17-21.31 Uhr in der Kasse zu sehen? Solche Zeitfensteranalysen (Zeitzonenanalysen) könnten die Frage aufwerfen, ob dies hier Zufall ist oder ein „Programmierfehler“? Dafür braucht derPrüfer die Programmierprotokolle, wobei die nur aussagekräftig sind, wenn sie Lückenlaos sind, also verbindlich und unmanipulierbar mitteilen, wann die letzte Änderung war und sie dann alle lückenlos vorliegen. Denn sonst könnte man natürlich ein Ersteinrichtungsprotokoll und ein paar wenige Änderungsprotokolle vorlegen und die bösartigen Änderungsprotokolle und die Rücksetzungen auf den letzten ordnungsgemäßen Programmierungsstand einfach weglassen und nicht vorlegen.
Wenn auch diese Vorfragen geklärt sind, stellt sich also die Frage, ob der bonierte Umsatz später wieder gelöscht wird. Indizien dafür sind beispielsweise:
Unterdrückung von bestimmten Positionen im Journal oder Kassenbericht oder im Tagesendsummenausweis (Z-Bon, Tagesendsummenbon), wie zum Beispiel Erstattungen, Stornos und anderen negativen Transaktionen: insoweit ist das extrem auffällig, wenn ein Z-Bon keine Stornos, Erstattungen, Rücknahmen ausweist.
Danach werden die harmlosen Einmalstornos, Rücknahmen usw. nicht ausgewiesen, aber auch nicht die hinterzieherischen Nach- oder Nachtstorns. Und dabei geht es doch nicht um die 3-5 normalen Stornos oder Erstattungen oder Rücknahmen, die den Tag über verteilt anfallen —- es sind die Nachstornos oder nachträglichen Erstattungen oder Rücknahmen, die ebenfalls nicht ausgewiesen werden, die aber den Umsatz und damit auch den Gewinn illegal reduzieren … wenn aber die normalen Stornos (Erstattungen, Rücknahmen) nicht ausgewiesen werden, werden auch die illegalen nächtlichen Stornos (Erstattungen, Rücknahmen) nicht ausgewiesen.
Also kommen beim Prüfer Zweifel auf, warum die normalen Stornos nicht ausgewiesen und die einzige und naheliegende Erklärung für den Prüfer ist die, dass auch die heimlichen Stornos sonst it ausgewiesen werden würden und nur deswegen der Gastwirt (Unternehmer die Stornos (Erstattungen, Rücknahmen) nicht zeigen will und sie deswegen nicht aufgezeichnet werden. Also fordert die Finverw, dass immer alle Stornos (Erstattungen, Rücknahmen) ausgewiesen werden. Folglich sind die Z-Bons, die keine Stornos (Erstattungen, Rücknahmen) ausweisen, erst einmal dubios.
Und die Behauptung des Gastwirts, bei ihm gäbe es keine Stornos, ist auch kaum glaubhaft.
Ein Vertippen durch die Servicekraft oder ein Versprechen oder Umentscheiden und Umbestellen des Gastes ist völlig normal und kommt immer wieder vor. So gesehen ist die Aussage eines Gastwirts „bei mir kommt so was nicht vor“ nicht glaubhaft. Rein theoretisch könnte der Gastwirt dem sich umentscheidenden Kunden natürlich nach dem alten römisch-rechtlichen Grundsatz bei einer gewünschten Umbestellung an den Kopf werfen: „pacta sunt servanda“, was nichts anders bedeutet als „geschlossene Verträge sind einzuhalten“. So könnte der Gastwirt zum Gast sagen: „Sie müssen jetzt das bestellte Bier nehmen und die Umbestellung auf den Rotwein nehme ich gerne als weitere Bestellung auf. Was Sie dann mit dem Bier machen ist mir egal. Ob Sie es einfach abziehen oder in die Blumen gießen, interessiert mich nicht: sie haben es bestellt, jetzt bekommen Sie es auch und Sie können es notfalls auch stehen lassen, wir schütten es dann unentgeltlich für Sie weg“ … aber habe Sie das schon mal erlebt? Und würde der Gast bleiben oder gar wirklich gerne wiederkommen? Und würde er das georderte Getränk wirklich trinken und bezahlen? Und jetzt machen wir das Ganze mal mit einer Essensbestellung: der Gast bestellt erst die Lende und entscheidet sich dann doch um auf den Gänsebraten …. „Eins zum hier essen und eins zum Mitnehmen …?“ Würde der Gastwirt fragen, denn „Sie wissen ja: pacta sunt servanda…“ Natürlich darf der Gast sich Umentscheiden und natürlich wird die ursprüngliche Bestellung storniert. Und das hält das Finanzamt auch für normal und will das auf dem zusammenfassenden Transaktionsbericht, de Z-Bon sehen.
Die Verwendung eines Trainingsmodus für den Normalbetrieb, wobei die Trainingsbuchungen natürlich programmgemäß keinen echten Umsatz darstellen. Wird der Trainer unterdrückt, schließt die verwaltung daraus, dass der Wirt etwas zu verbergen hat und Echtumsätze über den Trainingskellner buchte, die dann natürlich nicht auf den Fiskalspeicher, also die offizielle Gesamtsumme liefen.
Letztendlich geht es bei der Kassenbetriebsprüfung um die Frage, ob die Einnahmen vollständig erfasst wurden. Dabei gibt es natürlich erst einmal 2 grundlegende Fragen:
Ist die Kasse die Denn wenn die Trainingsstunden durch eine anzulernende Servicekraft offen ausgewiesen werden, kann man anhand der Zeitschiene (innerhalb oder außerhalb der Öffnungszeiten) und der Buchungen (typisches 70:30 Verhältnis, nicht fortlaufende Buchungen im Sekunden- oder Minutentakt sondern mit größeren Unterbrechungen und Zeitabständen wie typisch bei Echtbetrieb und den dortigen Bestellungen, kurze intensive Übungsphase über etwa eine halbe Stunde oder Stunde oder verteilt über eine ganze Schicht von 6-8 Stunden?) Rückschlüsse auf einen echten Trainingskellner oder eine normale Schicht als angeblicher Trainingsgelände ohne Aufzeichnung in den Umsätzen schließen.
Und dann gehen die Prüfer bei der Kassenprüfung weiteren Prüfungsfragen nach, die hier aber den Rahmen sprengen würden und die ich daher in einem anderen Beitrag im Detail bespreche:
- Sind die Zähler der Tagesendsummen und anderer Zähler auf null, bzw. in manchen Fällen auf einen beliebig eingegebenen Wert mit dem Master-Schlüssel zurückgesetzt worden?
- Werden bestimmte Einzelpositionen programmiert, so dass diese nicht im Kassenbericht bzw. im Journal erfasst werden.
- Auffallend ist auch, wenn die Programmoptionen zur Auswahl dieser Funktionen nicht im Programmiermenü offen beschrieben sind. Dann scheinen diese Schritte nicht zum offiziellen seriösen teil der Porgrammieranleitung zu gehören … denn Alls was versteckt ist (wie dies bei Phantomware der Fall ist), soll ja offenbar vor dem Prüfer versteckt werden – doch warum nur, wenn an nichts zu verbergen hat? Und sind also Funktionen oder Schritte nicht im Programmier- bzw. Her- stellerhandbuch dokumentiert, sind sie spezielle, nachträglich eingerichtet Schritte, die besonderen Argwohn bei den Prüfern erregen.
- Programmier- bzw. Herstellerhandbuch wird dem Endkunden jedoch in der Regel nicht ausgehändigt und im Allgemeinen nur den Vertragshändlern zur Verfügung gestellt. Der Endkunde erhält nur die einfache Bedienungsanleitung. Diese befähigt ihn nicht zum Programmieren. Wenn der Endkunde nicht das Programmierheft hat, kann er kaum umprogrammieren. Es sei denn er kennt jemanden, der programmieren und ein solches Programmier- und Herstellerhandbuch hat. Bei der Mehrzahl der Registrierkassen erfolgt die Programmierung durch die Eingabe von Codes, was gewisse technische Kenntnisse des Programmierers erforderlich macht. Die meisten computergestützten POS-Systeme enthalten ebenfalls ähnliche Funktionen, der Unternehmenseigentümer benötigt jedoch weniger technische Kenntnisse, um diese zu nutzen. Vor diesem Hintergrund ist die Rechtsprechung interessant, die eine Verwerfung zulässt, es sei denn, der Steuerpflichtige weist nach, er habe nicht manipulieren. Damit ist aber nicht gemeint, dass er nur nachweisen können muss, dass er das Hersteller- und Programmierhandbuch nicht hat bzw. darauf keinen Zugriff hat. Der BFH hatte in den Beschluss v. 23.2.2018, X B 65/17 folgenden Fall zu entscheiden: Der Inhaber eines Friseursalons erfasste seine Bareinnahmen über eine PC-Kassensoftware, die auf die speziellen Bedürfnisse des Friseurhandwerks zugeschnitten war. Trinkgelder konnten die Kunden jeweils in eigene Sparschweine sowohl des Inhabers als auch der Arbeitnehmer einwerfen. Die Trinkgelder, die der Inhaber erhielt, sind nicht als Einnahmen erfasst worden (Das ist sosowie unproblematisch, vgl. FG Köln …). Der Betriebsprüfer nahm dies zum Anlass, die Ordnungsmäßigkeit der Kassenführung zu verneinen. Außerdem beanstandete der Betriebsprüfer, dass die zur Kasse gehörenden Organisationsunterlagen nicht in Schriftform vorgelegt werden konnten. Dass die steuerlich erforderlichen Dokumentationen in elektronischer Form in der Kasse abgelegt und vorhanden waren, reichte dem Betriebsprüfer nicht aus. Neben den Trinkgeldern schätze er deshalb Beträge hinzu, die nach der Art und Weise des Betriebs nicht hätten erzielt werden können. Der Inhaber des Friseurbetriebs machte geltend, dass es sich um eine grundsätzliche Frage handle, wie ein weitestgehend frei programmierbares PC-Kassensystem zu beurteilen sei. Die grundsätzliche Bedeutung bejahte der BFH in seinem Beschluss v. 23.2.2018, X B 65/17 zu und hob die Entscheidung auf und verwies die Sache zurück an das FG zur erneuten Entscheidung im 2. Rechtsgang. Allein die Tatsache, dass zwei Sachverständige festgestellt haben, dass jedes PC-Kassensystem manipulierbar ist, reicht nicht aus, um von einer tatsächlichen Manipulation ausgehen zu können. Im vorliegenden Fall ergaben sich nach Aussage der Sachverständigen keine Anhaltspunkte für eine Manipulation. Sie führten aus, dass schon die Manipulation für einen kurzen Zeitraum von einer Woche die Arbeitskraft eines IT-Spezialisten für ein ganzes Wochenende binden würden. Vor diesem Hintergrund ist es eher unwahrscheinlich, dass tatsächlich manipuliert worden ist. Und der Antrag des Steuerpflichtigen auf Einholung eines Sachverständigengutachtens, dass das von ihm genutzte PC-Kassensystem die gemäß § 147 Abs. 1 Nr. 1 AO aufzubewahrenden Organisationsunterlagen zur Kassenprogrammierung vollständig speichert und sein Antrag, über diese Behauptung u.a. durch Vorlage der entsprechenden Datenbank, durch Einholung eines Sachverständigengutachtens sowie durch die Zeugenaussage eines Vertreters des Kassenherstellers Beweis zu erheben, handelt es sich nicht um einen unzulässigen Ausforschungsbeweis, sondern um einen erheblichen Beweisantrag, den das FG nicht übergehen durfte.
- Das vom FG und den Beteiligten herangezogene Senatsurteil in BFHE 249, 390, BStBl II 2015, 743 betraf eine Registrierkasse eher einfacherer Bauart. Auf derartige Systeme bezog sich die in Rz 28 jener Entscheidung enthaltene Aussage, das Gewicht des in der Nichtaufbewahrung der Bedienungsanleitungen und Programmdokumentationen liegenden Mangels trete zurück, wenn der Steuerpflichtige für den konkreten Einzelfall darlege, dass die von ihm verwendete Kasse trotz ihrer Programmierbarkeit ausnahmsweise keine Manipulationsmöglichkeiten eröffne. Für Registrierkassen einfacher Bauart hält der Senat trotz der vom FG und in Teilen der Literatur (z.B. Henn, Der Betrieb 2016, 254, 255) erhobenen Kritik an dieser Aussage fest. Bei derartigen Kassen, die im Allgemeinen nur sehr eingeschränkte Programmiermöglichkeiten bieten, erscheint es zumindest nicht als grundsätzlich ausgeschlossen, dass ein Steuerpflichtiger den Nachweis führen kann, die vorhandene —eingeschränkte— Programmiermöglichkeit eröffne keine Manipulationsmöglichkeiten, so der BFH in de Entscheidung v. 23.2.2018, X B 65/17. Er lässt damit trotz formeller Mängel quasi den Gegenbeweis oder Entlastungsbeweis zu, das nicht manipuliert wurde.
- Der BFH befindet sich mit dieser Entscheidung auf dem richtigen Weg, nicht wegen bloß formeller Mängel generell und ohne Entlastungsmöglichkeit die Kassenbuchführung zu verwerfen.