Hintergrundinformation
Vorbemerkung: Ich bin weder Jurist noch BWLer oder Steuerberater - also bitte beim Lesen beachten!
Elektronische Kassen müssen seit 2020 über eine manipulationssichere technische Sicherheitseinrichtung verfügen, die mit dem ersten Tastendruck alle Eingaben in das System unveränderlich und verschlüsselt erfasst.
Fehler im DSFinV-K Export
Folgende Eigenarten besitzt OrderSprinter:
- In OrderSprinter verwende ich eigene Nummernkreise für die IDs von Bons für Barein-/auslagen, bezahlte Trinkgelder und für Gäste, die erst später bezahlen müssen (z.B. Anwendungsfall Hotel, bei dem die Gäste erst beim Auschecken die aufgelaufenen Gastrorechnungen bezahlen). Mit diesen eigenen Nummernkreisen kann ich diese Bons in der Kassenbonansicht darstellen und für den Anwender eindeutig kennzeichnen. Im DSFinV-K Export exportiere ich diese Bons mit einem für den Nummernkreis verwendeten Buchstaben (G für Gästebon bzw. V für Einlagen/Trinkgeld).
- Desweiteren entsprach die dem DSFinV-K Export beiliegende index.dtd in der OrderSprinter-Version, die zum Zeitpunkt der Prüfung eingespielt war, nicht mehr den Vorgaben. Eine korrigierte Version der dtd-Datei ist in OrderSprinter seit Version 2.9.9 (16.11.2025) enthalten.
In der Vergangenheit gab es verschiedene Kassennachschauen bei Anwendern von OrderSprinter, bei denen jedoch nie über Probleme mit OrderSprinter berichtet wurde. Im Oktober/November 2025 erfolgte bei einem Anwender eine sehr detaillierte Kassennachschau, bei dem dies nun anders aussieht. Ein Prüfbericht mit Datum 11.11.2025 wurde dem Anwender zugeschickt. Diesen durfte ich einsehen. Daraus geht hervor, dass die oben erwähnten Eigenarten zu Problemen im DSFinV-K-Export führen.
Die Kommentare des Prüfers, die sich aus der ersten der beiden oben aufgeführten Eigenarten ergeben, möchte ich hier gerne wiedergeben:
Gemäß dem DSFinV-K-Beschreibungsstandart soll die BON_ID als von der eingesetzten Kasse vergebene, stetig fortlaufende und eindeutige Kennzeichnung aller Vorgänge dienen. Im vorliegenden Kassensystem wird die BON_ID für die Tabellen Bonpos und Bonkopf getrennt und nicht fortlaufend vergeben. Es handelt sich daher nicht um einen Primärschlüssel. Mangels der fortlaufenden Vergabe, kann nicht kontrolliert werden, ob die eingereichten Daten vollständig sind. Das Feld „BON_ID“ ist auf Ebene der Vorgänge sowie der Einzelpositionen identisch zu füllen.
Der Zusammenhang zwischen den Tabellen „Bonkopf‘ und „Bonpos“ kann nur über die Tabelle „BON_VorgangsNr“ nachvollzogen werden. Dies entspricht nicht dem DSFinV-K-Beschreibungsstandard. Die Unterscheidung zwischen Bestellungen und Belegen hat über die Zuordnung eines „GV-TYP" zu erfolgen.
Verwendung verschiedener Bonnummernkreise
Vom verwendeten Kassensystem werden sowohl „normale“ Bonnummern als auch Bonnummern mit vorangestelltem "G-" vergeben. Die normalen Bonnummern werden fortlaufend vergeben. Die „G-"-Bonnummern nicht.
In der Spalte „BON_NR“ dürfen lediglich rein numerische Werte eingetragen werden. Nicht alle der vergebenen "G-"-Bonnummern gehen abschließend in normale Bonnummern ein. Aus den Kasseneinzeldaten ist nicht ersichtlich, wie diese schlussendlich abgerechnet werden.
Bei den mit „G-" beginnenden Bonnummern sind viele Datensätze doppelt im Export enthalten. Ein Abgleich zwischen den in der Kasse erfassten und den tatsächlichen Umsätzen ist dadurch nicht möglich.
Aufgrund fehlender Zeit konnte ich die Aussagen nicht im Detail nachprüfen. Ich gehe jedoch davon aus, dass die Einschätzung des Prüfers korrekt ist. Aktuell habe ich keine Information darüber, ob dem Anwender durch die Fehler im DSvinV-K Export Nachteile entstanden sind. Nichtsdestoweniger finde ich es fair, die Anwender zu informieren.
Auch ohne DSFinV-K Export bietet OrderSprinter die verschiedensten Exportmöglichkeiten an, so dass prinzipiell alle Daten, die für eine Prüfung relevant sind, aus dem System hervorgeholt werden können. Aber die bei den Finanzämtern eingesetzte Software erwartet halt einen DSFinV-K Export und der muss natürlich auch stimmen.
Daher werde ich natürlich versuchen, den DSFinv-K Export von OrderSprinter zu korrigieren. Da die Verwendung der Nummernkreise bzw. das Konzept für Einlagen/Gäste- und Trinkgeldbons sehr tief im Source verankert ist, ist das eine sehr zeitintensive Maßnahme. Es ist absolut unmöglich, abzuschätzen, wann ich das abschließen kann.
Stefan Pichel, November 2025