Und immer wieder die EuCaSoft und ihre Sessionlücken
Aus einem BP-Fall. Da schreibt der Kassenprüfer:
„Sessionlücken:
Die in den Journal Daten, zahlreichen Sessionlücken wurden bereits im Kassenvermerk dargestellt. Vorweg möchte ich jedoch klarstellen, dass die Sessionslücken jedweder Art keinesfalls, wie von Herrn Dr. Jörg Burkhard ausgeführt, normale, seriöse Vorgänge darstellen. Es gibt grundsätzlich keinen, in den Einzeltaten nicht darstellbaren Vorgang, der eine Sectionslücke rechtfertigen würde.
16 Lücken widersprechen in eklatanter Maße den gesetzlichen Vorgaben bezüglich Vollständigkeit und Unveränderbarkeit der Daten. Denn das Wesen einer solchen Lücke in Kastendaten ist gerade, dass nach Erstellung dieser digitalen Grundaufzeichnungen Teile der Aufzeichnungen so entfernt werden, dass kein Rückschluss auf den tatsächlichen Inhalt mehr möglich ist.
D.h., dass hinter jeder einzelnen Zwischendecke grundsätzlich die Löschung von Umsätzen in beliebiger Höhe stehen kann. In diesem Zusammenhang sollte auch erwähnt werden, dass bei der umsatzmäßigen Quantifizierung der letztendlich als manipulativ verordneten 16 Lücken eine deutliche Gewichtung zugunsten der Beschuldigten vorgenommen wurde.
Es scheint im Zuge einer Manipulation sinnvoll, nachträgliche Eingriffe in das Kassensystem aufgrund des Entdeckungsrisikos zu minimieren. Hierdurch steigt die Wahrscheinlichkeit, dass für eine Manipulation vorrangig betragsmäßig höhere Summen nachträglich gelöscht werden, da bei einer dadurch erfolgten Umsatzreduzierung so weniger Sessions nachträglich gelöscht werden müssen. Gleichwohl wurde zur Quantifizierung der manipulierten Umsätze lediglich der durchschnittliches Herrchen Betrag als absolute, betragsmäßige Untergrenze verwendet.
Das Vorbringen der Herstellerfirma des Kassensystems, der ITAS GmbH im Hinblick auf die gefundenen zwischen Lücken erscheint bestenfalls zweifelhaft. Die Löschung von Journal Daten ist nachträglich nicht als ein weitverbreitetes, seriöses Verfahren bei der Speicherung von Kassendaten zu betrachten.
Nicht umsonst wurde die programmtechnisch standardisierte Löschung von vermeintlich (also nach der ganz persönlichen Einschätzung der Programmierer) steuerlich nicht relevanten Vorgängen in späteren Versionen des Kassensystems und der ITAS GmbH abgestellt.“
Die Itas GmbH, die Herstellerin des EuCaSoft-Programms veröffentlicht dazu als Herstellerangabe folgendes Merkblatt:
„Die SessionID ist eine intern verwendete Nummer, um zusammengehörige Buchungen zu identifizieren. In der Regel wird im Gastro-Modus beim Eröffnen eines Tisches bzw. Gastes eine SessionID erzeugt, die bis zum Abschluss des Tisches oder Gastes unverändert bleibt. Bei POS-Buchungen wird pro Buchung eine SessionID verwendet.
Bis zur EuCaSoft-Version 4.9.1 gibt es verschiedene Umstände, die dazu führen können, dass Lücken in den SessionIDs sind. Im Gastronomiebetrieb wird beim Umbuchen eines Artikels von einem Tisch/Gast auf einen anderen lediglich die SessionID des Artikels geändert, sodass der Artikel dann einer anderen Session angehört.
Wenn dadurch nun die ursprüngliche Session keine Artikel mehr beinhaltet, dann wird sie gelöscht, weil sie nicht mehr gebraucht wird. In diesem Fall war zwar irgendwann eine Session mit der ID vorhanden, sie wurde aber vom System entfernt. In der Journal.dbf ist in den Feldern ORaum, OTisch und OGast derjenige Tisch eingetragen, auf dem die Buchung ganz ursprünglich gemacht wird. Beim Umbuchen werden diese Informationen nicht verändert, sodass daran in den meisten Fällen erkannt werden kann, ob ein Artikel umgebucht worden ist oder nicht.
Aber nicht in jedem Fall:
Wenn ich einen Artikel von Tisch1/Gast1 auf Tisch1/Gast2 (evtl. versehentlich) umbuche, und ihn wieder zurückbuche, dann habe ich eine (oder zwei) fehlende Session-Nummer, der Artikel ist aber wieder auf dem ursprünglichen Tisch. Bei der Betrachtung des Umbuchens ist zu beachten, dass nicht nur vollständige Tische, sondern auch einzelne Artikel umgebucht werden können, insbesondere auch auf andere offene Tische die bereits Buchungen enthalten. Dadurch können dann natürlich Buchungen von unterschiedlichen Tischen aus auf einem anderen Tisch zusammengefasst werden und somit zusammen in einer Session abgerechnet werden.
Im POS-Modus und im Gastro-Modus kann es vorkommen, dass ein Artikel nicht gebucht werden kann, z.B. weil er gesperrt ist, sein Lagerbestand unterschritten ist oder Ähnliches. Bei bestimmten Abläufen wird dies erst festgestellt, wenn die SessionID bereits reserviert wurde. In diesem Fall wird die Session nicht geschrieben, die SessionID ist aber trotzdem benannt Frau Burghard bereits erhöht worden. In diesem Fall gab es nie eine Session mit der betreffenden ID.
Es gibt Abläufe, bei denen es sich nicht verhindern lässt, dass Lücken in den Session-Nummern entstehen: Wenn eine neue Buchung in einem leeren Tisch durchgeführt werden soll, dann wird als erstes eine neue Session-Nummer vergeben (reserviert). In der Folge werden verschiedene Bedingungen geprüft, bevor die Session in die Datenbank geschrieben wird. Z.B. wird geprüft ob der Druck-Manager der Kasse erreichbar ist. Falls nicht wird die Buchung verworfen und es wird eine Fehlermeldung ausgegeben. Die Session-Nummer wird in diesem Fall ebenfalls verworfen.“
In den neueren Itas-technischen Beschreibungen heißt es dazu wie folgt:
„Jede Buchung und jede Rechnung wird in dem Moment wo sie in die interne Datenbank geschrieben wird gleichzeitig in der Fiskaldatei erfasst. Die Daten der Fiskaldatei werden insbesondere nicht erst im Zeitpunkt des Z-Abschlusses erstellt, sondern fortlaufend. Dabei wird eine fortlaufende, lückenlose Sequenznummer vergeben, die nicht änderbar oder rückstellbar ist.“
Den Programmierern bei ITAS ist natürlich aufgefallen, dass die Betriebsprüfer oder dem Kassenprüfer den Kassen- Kunden erhebliche Schwierigkeiten bereiteten, bloß weil Lücken in den Sessionsnummern waren.
Und weiter die ITAS-Beschreibung:
„Durch die Vergabe von fortlaufenden Sequenznummern ist gewährleistet, dass keine Datensätze unbemerkt aus der Protokolldatei entfernt werden können. Durch die Vergabe von Checksummen ist gewährleistet, dass keine Daten innerhalb einer Zeile manipuliert werden können. Dadurch, dass in die Checksumme jeder Zeile auch die Checksumme der vorhergehenden Zeile mit eingeht, ist gewährleistet, dass die zu prüfende Zeile nicht aus einer anderen Aufzeichnung (z.B. einer anderen Installation) stammt. Dadurch, dass die Checksumme der ersten Zeile einer Fiskaldatei auch die Checksumme der letzten Zeile der zeitlich unmittelbar vorhergehenden Fiskaldatei beinhaltet, ist gewährleistet, dass es zwischen den einzelnen Dateien keine Lücken oder Manipulationen gab.“
Und dann weiter die ITAS:
„Dabei schreibt das Programm eine Schecksumme in jeder Zeile. In dieser Schecksumme gehen alle vorhergehenden Daten der Zeile ein. Außerdem geht die Schecksumme der vorhergehenden Zeile ein. Falls die Zeile die erste ist, geht stattdessen die Schecksumme die im Header als firstcrc eingetragen ist ein. Diese firstcrc ist wiederum identisch mit der letzten CRC der vorhergehenden Fiskaldatei.“
Ein Mogeln ist daher nicht möglich – bzw. wäre leicht enttarnbar.
Schließlich kann die fiskalische Datei geprüft werden. Dies erfolgt durch die Taste prüfen und dann müssten theoretisch alle Überprüfungen ein O. K. zeigen. In diese Prüfungen kann man also sofort sehen, ob es CRC Fehler ergibt. Fehler werden entsprechend ausgeworfen und als fehlerhaft markiert. Während also alle anderen Dateien ein o. k. haben, haben die fehlerhaften Dateien den Hinweis auf CRC fehlerhaft.
Solche Fehler können allerdings nicht nur durch Manipulationen entstehen, sondern auch durch Stromausfälle. Defekte Festplatten oder schwere Bedien- und Systemfehler zurückzuführen sein. Dass solche Fehler (hoffentlich) nicht allzu häufig vorkommen, sind also häufige CRC Fehler zwar kein Beweis für Manipulationen aber möglicherweise sollten Sie den Gastronom hellhörig machen und Untersuchungen der Kassenprogrammierung und der Beginn und Speichervorgänge auslösen. Und natürlich sollte möglichst ein solcher Vorgang dokumentiert werden, wenn er vorkommt. Danach ist natürlich auch ein Besuch des Kassenaufstellers oder eine Fernwartung durch ihn erforderlich, um den Fehler zu beseitigen. Auch das lässt sich natürlich anhand der entsprechenden Rechnungen dokumentieren.
Die Fiskaldatei ist auch bei den älteren Versionen der EucaSoft eine Datei, die unveränderbar unverwischbar für die Finanzverwaltung zur Verfügung steht.
Was ist aber, wenn in der fiskalische Datei keine Veränderungen sind, lediglich Sessionlücken vorhanden sind?
Bei den älteren Versionen schreibt die ITAS zu den Sessionlücken:
„Die Sessionnummer 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 Journal Tages eindeutig. Dieses Feld diente ausschließlich der einfacheren Zuordnung von Rechnungszeilen zu Buchungszahlungen bei der Auswertung der fiskalische Datei.“
Und dann hatte sich der Prüfer zu den Checksummen gar nicht geäußert.
Diese sind doch ein ganz wichtiges Verprobungsinstrument. Dass er hier Fehler oder Lücken festgestellt hätte, behauptete er nicht einmal selbst. Diese Checksummen, deren Zusammensetzung geheim ist, verknüpfen aber doch die Umsätze davor und danach und sind ein maßgebendes Verprobungsinstrument.
Wenn also die These der Hinterziehung doch richtig wäre, müssten sich doch in der Fiskaldatei Fehler finden. Denn die verschiedenen Umsätze sind miteinander verzahnt und verklausuliert und versteckt miteinander verwoben, sodass gerade Umsätze nicht heimlich gelöscht werden können. Wäre also Ihre These richtig, müssten Sie ja nun massenhafte Lücken finden.
Um das einfach zu erklären: Eine Zeile sagt verklausuliert:
43 „Hallo, ich bin eine Cola und davor gab es ein Bier.“
Die Teile danach sagt:
44 „Hallo ich bin ein Schnitzel und davor gab es eine Cola.“
Und die nächste Zeile sagt:
45 „Hallo, ich bin ein Fleischkäse und davor gab es ein Schnitzel.“
Und die nächste Zeile sagt:
46 „Hallo, ich bin ein Frühlingssalat und davor gab es einen Fleischkäse.“
Beweis: Sachverständigengutachten, Auskunft der Itas GmbH.
Würden Sie jetzt eine Zeile heraus löschen, wäre die Verknüpfung nicht mehr möglich und damit würde die Löschung auffallen. Denn wenn sie jetzt beispielsweise Zeile 45 löschen würden, wurden Zeile 44 und 46 nicht zusammenpassen.
Die EuCaSoft-Kasse ist daher eigentlich eine sehr sichere und sehr fälschungssichere Kasse. Wenn die Checksummen stimmen und die Verknüpfungen untereinander zu den einzelnen Bestellzeilen passen, ist damit nachgewiesen, dass gerade nicht manipuliert wurde.
Kann man den wirklich der ITAS vorhalten, dass sie auf die Prüfer-Vorstöße reagiert und die Leersessions abschafft, dass dies die Hinterziehung früher beweist, wie dies unser Kassennachschauer bzw., Kassenpüfer verargumentiert?
Würde nicht jeder vernünftigerweise sein Programm ändern, wenn die Finanzverwaltung daran Anstoß nimmt? Damit man Schaden, Ärger und Kosten von seinen Kindern abwendet, ohne dass damit gesagt ist, dass dies ein Eingeständnis ist, wie der Kassenprüfer meint?
Fragen dazu? Dann rufen Sie an: 069-8700510-0 RA Dr. Jörg Burkhard, Fachanwalt für Steuerrecht, Fachanwalt für Strafrecht, der Spezialist für streitiges Steuerrecht, Betriebsprüfungen, Fahndungsprüfung, Zollfahndung, Steuerstrafrecht, Selbstanzeige, Tax Compliance – bundesweit tätig. Selbst der weiteste Weg lohnt sich.
