Compliance-Anforderungen
jotti ist ein elektronisches Aufzeichnungssystem (§ 1 KassenSichV) und unterliegt nach § 146a AO der TSE-Pflicht, unabhängig von Rechtsform, Gemeinnützigkeit oder Veranstaltungsdauer. Umgesetzte Funktionen: anforderungen.md; Architektur-Entscheidungen: handbuch.md §3.13.
2. Rechtliche Grundlagen
2.1 Abgabenordnung (AO): § 146a
§ 146a Abs. 1 AO verpflichtet jeden Betreiber eines elektronischen Aufzeichnungssystems zu zwei Dingen. Er erfasst jeden Geschäftsvorfall einzeln, vollständig, richtig, zeitgerecht und geordnet. Er schützt die Aufzeichnungen durch eine zertifizierte TSE. Das gilt unabhängig von Rechtsform, Gemeinnützigkeit, Betriebsdauer oder Gewinnerzielungsabsicht. [1]
Für jottis Direktverkauf (K-24) gilt die Einzelaufzeichnung strikt pro Event. direktverkauf-getaetigt:v1 und direktverkauf-storniert:v1 sind eigenständige Geschäftsvorfälle. Der Storno korrigiert durch Gegeneintrag, nie durch Änderung des Verkaufsdatensatzes. Der fiskalische Beleg entsteht wie am Tisch on-demand. POST /service/beleg-drucken mit verkaufId erzeugt genau einen Kassenbeleg-Druckauftrag auf Basis des referenzierten Events. Der Geschäftsvorfall bleibt 1:1 referenzierbar.
2.2 Kassensicherungsverordnung (KassenSichV)
Die KassenSichV konkretisiert § 146a AO. § 1 KassenSichV definiert als Aufzeichnungssysteme „elektronische oder computergestützte Kassensysteme oder Registrierkassen”. jotti fällt als browserbasiertes Kassensystem eindeutig darunter.
Für mobile Geräte gilt: Kann ein Gerät Zahlungsvorgänge eigenständig und offline erfassen, braucht es eine eigene TSE-Anbindung. Fungiert es nur als Eingabeterminal mit sofortiger Weiterleitung an ein TSE-gesichertes Backend, genügt die Backend-TSE. In jottis BYOD-Modell sind die Smartphones der Servicekräfte reine Eingabegeräte, rechtlich nicht mehr als eine Tastatur. Konsequenzen:
- Die Smartphones benötigen keine eigene TSE; TSE-Absicherung, Protokollierung und DSFinV-K-Speicherung erfolgen zentral im Backend.
- Architektonische Eigenschaft: Jeder Vorgang ist ein synchroner Backend-Request. Das Frontend hat keinen Service Worker, keine optimistischen Updates und keinen Offline-Speicher für Vorgangsdaten (verifiziert über
frontend/src/). Ohne Verbindung schlägt jede Erfassung fehl. Eine Offline-Erfassung von Barzahlungen ist damit technisch ausgeschlossen. Die Einordnung als reines Eingabegerät ist so rechtlich haltbar. [2, 11, 15]
2.3 GoBD
Die GoBD (BMF-Schreiben 28.11.2019) fordern Nachvollziehbarkeit, Vollständigkeit, Richtigkeit, Zeitgerechtigkeit, Ordnung und Unveränderbarkeit. Sie gelten für alle Steuerpflichtigen, einschließlich gemeinnütziger Vereine im wirtschaftlichen Geschäftsbetrieb. [4]
2.4 Belegausgabepflicht (§ 146a Abs. 2 AO, § 6 KassenSichV)
§ 146a Abs. 2 AO und § 6 KassenSichV verpflichten zur Belegausgabe nach jedem Kassiervorgang, in unmittelbarem zeitlichen Zusammenhang. Der Beleg kommt in Papierform oder (mit Zustimmung des Kunden) elektronisch. [1] Details und Festzelt-Befreiung: Abschnitt 5.
2.5 DSFinV-K
§ 4 KassenSichV verlangt eine einheitliche digitale Schnittstelle für den Datenexport an die Finanzverwaltung; die DSFinV-K definiert das Format. [5] Verbindliche Version, Dateiaufbau und Felder: Abschnitt 6.
2.6 Elektronische Kassenmeldepflicht (§ 146a Abs. 4 AO)
Elektronische Aufzeichnungssysteme sind dem zuständigen Finanzamt zu melden. Fristen, Meldeweg und Daten: Abschnitt 7. [1, 11]
2.7 Sonderfall: Source-Available Self-hosted (Pflichten des Entwicklers)
jotti ist kein SaaS: Der Code ist öffentlich auf GitHub, die Vereine betreiben das System eigenverantwortlich (VPS, Docker). Das trennt die Rechtspflichten von Entwickler (Hersteller) und Betreibern (Vereinen).
Pflichten des Entwicklers: Kassensoftware, die keine zertifizierte TSE anbinden kann, darf niemand gewerbsmäßig bewerben oder gewerbsmäßig in den Verkehr bringen. Das verbietet § 146a Abs. 1 Satz 5 AO i.V.m. § 379 Abs. 1 Nr. 6 AO. Vorsorglich behandelt jotti auch das kostenlose Bereitstellen des Codes auf GitHub wie ein In-Verkehr-Bringen. Daraus folgt:
- TSE-Schnittstelle (
TSEClient-Interface) und DSFinV-K-Export müssen im Code vorhanden und nutzbar sein. - Entscheidet ein Verein, keinen TSE-API-Key einzutragen, liegt das rechtliche Risiko ausschließlich beim Verein.
- Der Entwickler hat keine Meldepflicht für fremdbetriebene Installationen, mitteilungspflichtig ist nur, wer das System tatsächlich verwendet.
- Eine Muster-Verfahrensdokumentation liegt im Repository bereit (verfahrensdokumentation.md). Die Vorlage deckt Architektur, Datenmodell, TSE-Anbindung und Aufbewahrung ab. Der Verein passt sie an seine Instanz an und legt sie Betriebsprüfern vor.
Pflichten der Betreiber: → Abschnitt 8.
3. TSE-Integration (Technische Sicherheitseinrichtung)
3.1 Hintergrund
Die TSE ist die kryptografische Kernkomponente eines konformen Kassensystems. Sie besteht aus drei Modulen: Sicherheitsmodul (SMAERS-Datenaufbereitung + CSP-Signatur), Speichermedium (lokale Sicherung der signierten Daten) und Einheitliche Digitale Schnittstelle (EDS, Export). [3]
3.2 Protokollierungs-Ablauf (Transaktions-Lebenszyklus)
jotti nutzt das atomare Muster (→ §3.6): Jeder Vorgang wird mit StartTransaction eröffnet und sofort mit FinishTransaction abgeschlossen. Beide Aufrufe adressieren die Transaktion über die von jotti erzeugte txID (UUIDv4). Die optionale UpdateTransaction (Zwischenaktualisierung eines offen gehaltenen Vorgangs) nutzt jotti nicht; das TSEClient-Interface bildet nur Start und Finish ab.
| Operation | Wann | Request | Response |
|---|---|---|---|
StartTransaction | Unmittelbar bei Vorgangsbeginn (keine maximale Transaktionsdauer in BSI TR-03153) | txID; processType und processData sind bei Start immer leer (DSFinV-K Anhang I) | Fortlaufende Transaktionsnummer, logTime, TSE-Seriennummer, Signaturzähler |
FinishTransaction | Bei Abschluss des Vorgangs | txID, finale processType und processData (Summen nach Steuersätzen und Zahlungsarten) | Signatur, logTime, finaler Signaturzähler |
3.3 Offizielle processType-Werte
Die processType-Werte sind in der DSFinV-K, Anhang I, festgelegt; der AEAO zu § 146a, Nr. 2.2.3.6 verweist darauf. Die -V1-Endung ist nur bei Kassenbeleg-V1 und Bestellung-V1 Bestandteil des offiziellen Strings, der dritte Typ heißt SonstigerVorgang (ohne Suffix).
| processType | Verwendung |
|---|---|
Kassenbeleg-V1 | Zahlungsbeleg (Rechnung), der dem Kunden ausgehändigt wird; auch Eigenbelege über Ein-/Auszahlungen wie Geldtransit und Kassendifferenz (AEAO 2.2.3.6.1) |
Bestellung-V1 | Zwischenabsicherung einer Bestellung ohne sofortige Zahlung (Gastronomie) |
SonstigerVorgang | Alle anderen abzusichernden Vorgänge, die weder belegartig noch TSE-Systemfunktion oder TSE-Audit-Ereignis sind, z. B. der Tagesabschluss (AEAO 2.2.3.6.3) |
Mapping auf jotti-Events:
| jotti-Event | processType | Anmerkung |
|---|---|---|
bestellung-aufgenommen:v1 | Bestellung-V1 | Sofort geschlossen (Festzelt-Muster, §3.6) |
zahlung-kassiert:v1 | Kassenbeleg-V1 | Tisch-Teilzahlung oder Vollzahlung |
direktverkauf-getaetigt:v1 | Kassenbeleg-V1 | Atomar, keine vorgelagerte Bestellung-V1, da Bestellung und Zahlung zeitgleich stattfinden |
direktverkauf-storniert:v1 | Kassenbeleg-V1 | Stornobeleg mit negativem Betrag, REF_BON_ID auf den Ursprungsverkauf |
stornierung-erteilt:v1 | Kassenbeleg-V1 | Warenrücknahme bezahlter Positionen, negative Beträge, REF_BON_ID auf die Zahlung |
bestellung-korrigiert:v1 | Bestellung-V1 | Geldneutrale Korrektur unbezahlter Positionen, ohne Zahlungszeile |
bestellung-umgebucht:v1 | Bestellung-V1 | Geldneutrale Umbuchung unbezahlter Positionen zwischen Tischen, ohne Zahlungszeile |
kassensitzung-eroeffnet:v1 | Kassenbeleg-V1 | Eigenbeleg über die Bareinlage, nur bei Anfangsbestand > 0 |
geldtransit-gebucht:v1 | Kassenbeleg-V1 | Eigenbeleg über die Ein- oder Auszahlung |
differenz-soll-ist-gebucht:v1 | Kassenbeleg-V1 | Eigenbeleg über die Kassendifferenz |
tagesabschluss-erstellt:v1 | SonstigerVorgang | Tagesabschluss (Z-Bon), aggregierte Tagessummen |
kassensturz-durchgefuehrt:v1 | — | Nicht signaturpflichtig |
3.4 Datenformat-Vorgaben (processData)
- Encoding: UTF-8 oder ASCII, kein BOM
- Dezimaltrennzeichen: ausschließlich Punkt (
.); keine Tausendertrennzeichen, keine Exponentialschreibweise, kein+; mindestens eine Stelle vor dem Punkt (0.5, nicht.5) - Format
Kassenbeleg-V1:Beleg^<Betraege>^<Zahlungen>. Die fünf Brutto-Steuerbeträge sind_-getrennt in fester Reihenfolge: 1. Allgemeiner Steuersatz (19 %) · 2. Ermäßigter Steuersatz (7 %) · 3.–4. land-/forstwirtschaftliche Durchschnittssätze nach § 24 Abs. 1 Nr. 3 und Nr. 1 UStG [17] · 5. 0 %. jotti belegt nur die Positionen 1, 2 und 5; die Durchschnittssatz-Positionen bleiben stets0.00. Mehrere Zahlungen ebenfalls_-getrennt als<Betrag>:<Zahlungsart>; Zahlungen von0.00entfallen.Kombi-Positionen (70/30): Speisen-Anteil (70 %) → Position 2 (ermäßigt), Getränke-Anteil (30 %) → Position 1 (allgemein); steuerbefreite Positionen → Position 5 (0 %).
- Format
Bestellung-V1: CSV-Darstellung, pro Position eine Zeile<Menge>;"<Bezeichnung>";<Brutto-Einzelpreis>, Zeilentrenner\r(U+000D), Bezeichnung in Anführungszeichen (innere"werden verdoppelt), Preis mit exakt 2 Nachkommastellen. Beispiel aus DSFinV-K Anhang I:2;"Eisbecher ""Himbeere""";3.99
3.5 TSE-Varianten und Anbieter-Entscheidung
| Variante | Beschreibung | Beispiel-Anbieter |
|---|---|---|
| Hardware-TSE | Physisches Gerät (USB-Stick, microSD-/SD-Karte) | Swissbit, Epson, cryptovision (für D-Trust) |
| Cloud-TSE | TSE als Cloud-Service, Kommunikation via HTTPS-API | fiskaly, Deutsche Fiskal, Swissbit, Diebold Nixdorf |
jotti bindet die Cloud-TSE von fiskaly an (API-first, BSI-zertifiziert nach TR-03153, unterstützt alle drei processTypes); Entscheidung und Gründe: decisions.md, D09. Das Backend-Interface TSEClient bleibt anbieter-agnostisch (Adapter-Pattern); Credentials und die Einrichtung sind auf fiskaly zugeschnitten, ein zweiter Anbieter wäre mehr als ein Adapter-Austausch.
3.6 Das Festzelt-Muster: Atomare TSE-Transaktionen
Im Festzelt-Betrieb laufen an einem Tisch über Stunden Bestellrunden und Teilzahlungen auf. Eine einzige TSE-Transaktion so lange offenzuhalten wäre technisch riskant und ist laut BMF-FAQ nicht erforderlich. Die DSFinV-K dokumentiert in Nr. 2.7 und Anhang H eine Vereinfachungsregelung für langanhaltende Bestellvorgänge („Erleichterungsregelung beim Durchbedienen”). Danach ist jede atomare Aktion eine eigene, sofort geschlossene TSE-Transaktion. [13]
- Schicht 1 (Bestellabsicherung): jede Bestellrunde als
StartTransaction(processType="Bestellung-V1")→ sofortFinishTransaction;processDataenthält die Positionen. - Schicht 2 (Zahlungsabsicherung): jede Teil- oder Vollzahlung als
StartTransaction(processType="Kassenbeleg-V1")→ sofortFinishTransaction;processDataenthält Gesamtbetrag, Steuersätze, Zahlungsart. - Verknüpfung: Alle Transaktionen eines Tisches teilen im DSFinV-K-Export denselben
ABRECHNUNGSKREIS(→ §6.5).
Szenario Maihock, Tisch 42: jeder Vorgang eine eigene, sofort geschlossene Transaktion, alle mit ABRECHNUNGSKREIS = "Tisch 42":
| Zeit | Vorgang | TSE-Transaktion |
|---|---|---|
| 18:01 | Bestellung 4× Bier, 2× Weißwurst | Bestellung-V1 (Nr. 1001) |
| 19:30 | Nachbestellung 4× Bier | Bestellung-V1 (Nr. 1002) |
| 20:00 | Teilzahlung 14,00 € bar (2 Gäste) | Kassenbeleg-V1 (Nr. 1003) |
| 21:00 | Restzahlung 18,00 € bar (2 Gäste) | Kassenbeleg-V1 (Nr. 1004) |
Jeder Zahlungsbeleg trägt zusätzlich den Startzeitpunkt der ersten Bestellung in Klarschrift (Durchbedienen-Pflicht → §5.3). Der Betriebsprüfer rekonstruiert den vollständigen Tischverlauf über den gemeinsamen ABRECHNUNGSKREIS (Vergabe und Verhalten bei mehreren Gästegruppen am selben Tisch → §6.5).
3.7 Seriennummer-Generierung bei Self-hosted Docker-Instanzen
Ohne physische Kassenhardware gibt es kein Typenschild, die gesetzlich geforderte eindeutige Seriennummer (§ 146a AO, § 6 KassenSichV, DSFinV-K) wird softwareseitig erfüllt:
- Beim allerersten Start (Datenbank-Initialisierung) generiert jotti eine UUID als Kassen-Seriennummer. Sie ist herstellerunabhängig und weltweit eindeutig, eine zentrale Registrierung ist nicht nötig. jotti speichert sie dauerhaft und überschreibt sie nie, auch nicht bei Updates oder Neustarts.
- Die Seriennummer wird im Admin-Bereich unter „Finanzamt & TSE” angezeigt (für ELSTER-Meldung und DSFinV-K-Export).
- Disaster Recovery: Geht die Datenbank ohne Backup verloren, muss die alte Seriennummer beim Finanzamt abgemeldet werden. Die neue Instanz wird dann neu angemeldet. Datenbank-Backups sichern die Seriennummern-Kontinuität.
| Verwendungsort | Feld / Kontext |
|---|---|
| ELSTER-Meldung | „Seriennummer des elektronischen Aufzeichnungssystems” |
DSFinV-K Export (cashregister.csv) | Feld KASSE_SERIENNR |
| Kassenbon (Pflichtfeld nach § 6 KassenSichV) | Angedruckter String, z. B. Kassen-ID: 7f3a9d12-... |
| TSE-Kommunikation | serial_number des fiskaly-Clients (Client-Registrierung) |
3.8 Asynchrone Signierung (Outbox und Signatur-Worker)
Die TSE-Signierung ist vom Kassier-Pfad entkoppelt, das Buchen wartet nie auf die TSE. Die Mechanik steht in handbuch.md §3.13: transaktionale Outbox tse_signaturauftraege, Signatur-Worker, Störungsprotokoll, Abschluss-Gate.
Konformitätsbedingungen dieses Pfades:
- Keine still unsignierten Vorgänge: Der Auftrag entsteht atomar mit dem Event, auch ohne TSE-Konfiguration. Ein Vorgang ohne Signatur ist immer ein offener oder endgültig markierter Auftrag, nie ein verlorener. Bei TSE-Ausfall, Signatur-Rückstand oder fehlender Konfiguration verzögert sich die Signatur; der Vorgang bleibt gebucht.
- Ausfalldokumentation: Das Störungsprotokoll (
tse_stoerungen) dokumentiert jede TSE-weite Störung als Zeitraum mit Grund (AEAO zu § 146a, 1.14.1). Die Auftragstabelle hält den Status jedes einzelnen Vorgangs. - Belegausweisung: Ein nach dem Ausfall nachsignierter Beleg trägt den Vermerk „Nachsigniert am …”; die TSE-Zeitpunkte weichen dann vom Belegdatum ab. Ein Vorgang ohne konfigurierte TSE trägt den Vermerk „keine TSE konfiguriert”. Im DSFinV-K-Export erhalten noch unsignierte Vorgänge eine
TSE_TA_FEHLER-Zeile.
Einordnung zur Protokollierungspflicht (AEAO zu § 146a, Nr. 2.2.2): Die Norm verlangt einen frühen Start der Protokollierung. Sie beginnt in der TSE „unmittelbar mit Beginn des aufzuzeichnenden Vorgangs”. jotti startet die TSE-Transaktion nicht im Kassier-Request. Der Signatur-Worker startet sie wenige Sekunden später (Start und Finish unmittelbar nacheinander, §3.2).
Diese Entkopplung ist eine bewusste Architekturentscheidung:
- Der Vorgang selbst ist ab dem Commit unveränderlich erfasst (Kassenjournal und Signaturauftrag in einer Datenbanktransaktion).
- Das Buchen hängt nicht an der Verfügbarkeit der Cloud-TSE.
- Jede Verzögerung ist nachweisbar statt verdeckt:
- Störungszeiträume im Störungsprotokoll
- verspätete Signaturen mit Nachsigniert-Vermerk auf dem Beleg
- unsignierte Vorgänge mit
TSE_TA_FEHLER-Zeile im Export
Die typische Latenz liegt im Sekundenbereich (Ziel: p95 unter fünf Sekunden). Die gemessenen Werte stehen in handbuch.md §3.13.
4. GoBD-Konformität
4.1 Umsetzung der GoBD-Grundsätze
Die Event-Sourcing-Architektur erfüllt die GoBD-Grundsätze:
| GoBD-Grundsatz | Umsetzung in jotti |
|---|---|
| Unveränderbarkeit | Kassenjournal ist append-only, kein UPDATE/DELETE |
| Nachvollziehbarkeit | Lückenloses Kassenjournal pro Tisch-Session |
| Vollständigkeit | Jeder Geschäftsvorfall wird als Event erfasst |
| Zeitgerechte Buchung | Events mit Echtzeit-Zeitstempel |
| Ordnungsmäßigkeit | Strukturiertes Datenmodell, typisierte Events |
| Kryptografische Verkettung | TSE-Signatur (fiskaly Cloud-TSE) für alle Geschäftsvorfälle; Signaturdaten am Signaturauftrag (Outbox tse_signaturauftraege), Ausfälle dokumentiert und nachsigniert (§3.8) |
| 10-Jahres-Aufbewahrung | DSFinV-K-Export (F-04) und DB-Backup decken die Daten ab (F-10); Aufbewahrungsstrategie in §4.3. Die Aufbewahrung selbst ist Betreiberpflicht (§8) |
4.2 Anforderungen gemäß §§ 146, 147 AO und GoBD
- Aufbewahrungspflicht: § 147 Abs. 3 AO staffelt die Fristen. Bücher und Aufzeichnungen (§ 147 Abs. 1 Nr. 1) sind zehn Jahre aufzubewahren, Buchungsbelege (Nr. 4) acht Jahre. Für die sonstigen Unterlagen gelten sechs Jahre. Das Kassenjournal ist eine Aufzeichnung und fällt damit unter die Zehnjahresfrist, die jotti deshalb durchgehend ansetzt. Die Daten müssen jederzeit verfügbar, unverzüglich lesbar, vollständig und unveränderbar sein. [16]
- Elektronisches Radierverbot: Kein
UPDATEoderDELETEnach der Erfassung. - Stornierungen: Immer als neue Buchungssätze (neuer Zeitstempel, neue TSE-Signatur), die den alten Wert ausgleichen.
- Verfahrensdokumentation: Wie das System Daten erzeugt, verarbeitet und archiviert, muss dokumentiert sein. [4] jotti stellt dafür eine anpassbare Muster-Verfahrensdokumentation bereit (verfahrensdokumentation.md, F-11); das Führen und Anpassen der eigenen Verfahrensdokumentation bleibt Betreiberpflicht (§8).
4.3 Aufbewahrungsstrategie (F-10)
Die aufzubewahrenden Daten entstehen in offenen, ohne proprietäre Software lesbaren Formaten; ein zusätzliches Roh-Exportformat ist nicht nötig. Der DSFinV-K-Export ist die maschinell auswertbare Standardform, das Datenbank-Backup enthält das vollständige Kassenjournal im Rohformat samt TSE-Signaturen und Stammdaten. Die Aufbewahrung selbst (Speicherung, Lesbarkeit über 10 Jahre, Zugriffsschutz) bleibt Betreiberpflicht (§8).
| Artefakt | Format | Quelle | Aufbewahrung | Wiederherstellung / Lesbarkeit |
|---|---|---|---|---|
| DSFinV-K-Export je Kassensitzung | CSV, index.xml, DTD (ZIP) | Admin-Bereich → „Berichte & Export” → „Archiv herunterladen (ZIP)” | 10 Jahre, an mindestens zwei getrennten Orten | mit jeder Tabellenkalkulation oder Prüfsoftware (IDEA) lesbar |
| Datenbank-Backup (rohes Kassenjournal samt TSE-Signaturen und Stammdaten) | pg_dump (.sql) | automatisch vor jedem Update; Server: make prod-backup | 10 Jahre | jotti-restore.cmd (Standardweg) bzw. make prod-restore (Server) |
| Z-Bons (Tagesabschlüsse) | im Kassenjournal und DSFinV-K-Export enthalten | Tagesabschluss (K-22) | 10 Jahre | Teil von Export und Backup |
| Zählprotokolle (Kassensturz) | Papier oder digital | manuell beim Kassensturz (K-21) | 10 Jahre | Betreiber |
| Kassen-Seriennummer | UUID | Admin-Bereich; im DB-Backup enthalten | dauerhaft | aus Admin-Bereich oder Backup |
Laienverständliche Anleitung für Vereine: Leitfaden, Datenaufbewahrung.
5. Belegausgabepflicht
5.1 Gesetzliche Grundlage
Gemäß § 146a Abs. 2 AO und § 6 KassenSichV muss für jeden Kassiervorgang ein Beleg erzeugt werden. Er wird dem Kunden zur Verfügung gestellt, gedruckt oder (mit Zustimmung) elektronisch. [1, 2]
Befreiung für Vereinsfeste (§ 146a Abs. 2 Satz 2 AO): Das Finanzamt kann von der Pflicht zur Aushändigung befreien. Voraussetzung ist ein „Verkauf von Waren an eine Vielzahl nicht bekannter Personen”. Das ist der typische Festzelt-Tatbestand. Zu beachten:
- Die Befreiung betrifft nur die Aushändigung, TSE-Absicherung, Erfassung und Belegerzeugung bleiben Pflicht; der Beleg muss jederzeit erstellbar sein.
- Sie wird nicht automatisch gewährt: schriftlicher Antrag beim Finanzamt, widerruflich.
- Verlangt ein Gast einen Beleg, ist er auszuhändigen.
Ohne bewilligte Befreiung muss der Verein für jeden Kassiervorgang einen Beleg erstellen und ihn dem Gast anbieten. Erst mit bewilligter Befreiung genügt der Druck auf Verlangen. jotti druckt den Kassenbeleg deshalb nicht automatisch, sondern auf Anforderung (→ anforderungen.md F-03); erstellbar ist er jederzeit.
Arbeitsbon ≠ Kassenbeleg: Der automatische Arbeitsbon (Küche/Theke, ohne Preise) ist rein operativ, kein Beleg i. S. v. § 146a AO, keine TSE-Transaktion. Nur der Kassenbeleg (auf Anforderung pro Kassiervorgang) ist der fiskalische Beleg mit den Pflichtangaben aus §5.2. Details: handbuch.md §4.5.
5.2 Pflichtangaben auf dem Beleg
Standard-Kassendaten:
- Vollständiger Name und Anschrift des leistenden Unternehmens (Verein)
- Datum der Belegausgabe
- Menge und Art der gelieferten Gegenstände / Umfang der Dienstleistung
- Entgelt und darauf entfallender Steuerbetrag, oder Hinweis auf Steuerbefreiung
- Bonnummer (fortlaufende Belegnummer des Kassensystems). Die Transaktionsnummer nach § 6 Satz 1 Nr. 4 KassenSichV ist die TSE-Transaktionsnummer; sie steht unten bei den TSE-Pflichtdaten.
- Pro Position: Steuerkennzeichen (z. B.
Afür 19 %,Bfür 7 %). Beikombi-Positionen (70/30): zwei Teilzeilen oder gemeinsamer Positionstext mit Verweis auf die Steuermatrix. - Im Belegfuß, Steuermatrix: Brutto, Netto und Steuerbetrag je Steuersatz;
kombi-Anteile fließen anteilig in die 7-%- und 19-%-Zeilen ein.
TSE-Pflichtdaten (§ 6 KassenSichV):
- Zeitpunkt des Vorgangsbeginns und der Vorgangsbeendigung (TSE-
logTimeaus Start/Finish) - Seriennummer des Aufzeichnungssystems (Kassen-ID) und der TSE
- TSE-Transaktionsnummer, Signaturzähler, kryptografischer Prüfwert (Signatur)
- Die TSE-Daten dürfen platzsparend als QR-Code aufgedruckt werden; das Format muss der DSFinV-K (Anhang I) entsprechen.
Beleg-Archivierung: Die fiskalischen Daten liegen im Kassenjournal (Event samt TSE-Signatur) und im DSFinV-K-Export; der Beleg ist daraus jederzeit reproduzierbar.
5.3 Besondere Anforderung beim Festzelt-Muster (Durchbedienen)
Manche Bestellungen werden mit Bestellung-V1 abgesichert und erst später bezahlt (→ §3.6). Für sie gilt laut BMF-FAQ: „Zusätzlich ist auf den Bon der Startzeitpunkt der ersten Bestellung in Klarschrift aufzudrucken.” [11, 13]
Der Zahlungsbeleg trägt also zwei Zeitstempel:
- den TSE-
logTimeder aktuellenKassenbeleg-V1-Transaktion - den Erfassungszeitpunkt der ersten Bestellung der Tisch-Session in Klarschrift (Event-Zeit, weil die TSE-Signatur asynchron entsteht)
Beispiel (Tisch 42, Maihock):
KASSENBELEG
Volksverein Musterstadt e.V.Musterstrasse 179100 Musterstadt
Datum: 01.05.2026 20:00Bon-Nr: 1003Kassen-ID: 7f3a9d12-...Erste Bestellung: 01.05.2026 18:01:07 ← Pflichtfeld beim Durchbedienen---2x Maß Bier 7,00 x 2 = 14,00 EUR (A)---GESAMT: 14,00 EURZahlungsart: bar
Steueraufteilung: A (19 %): Netto 11,76 EUR, Steuer 2,24 EUR, Brutto 14,00 EUR
TSE-Daten: TSE-Transaktion: 1003 Signaturzaehler: 5871 TSE-Seriennummer: 3b1f... TSE-Start: 01.05.2026 20:00:12 TSE-Ende: 01.05.2026 20:00:14 Signatur: ...[QR-Code mit TSE-Daten]5.4 Umsetzung der Belegausgabe im BYOD-Setup
Die Servicekräfte nutzen private Smartphones ohne mobile Bondrucker. Die Belegausgabe läuft über einen zentralen Bondrucker an der Theke:
- Die Servicekraft kassiert auf dem Smartphone.
- Im Regelfall sendet das Backend den Druckbefehl erst nach erfolgreichem TSE-Abschluss (
FinishTransaction). Erst dann stehen die Prüfwerte fest. - Ist die Signatur noch ausstehend, wird der Druck zurückgestellt.
- In einem dokumentierten TSE-Ausfall wird der Beleg mit Ausfallvermerk statt TSE-Daten gedruckt. Die Belegausgabepflicht bleibt vom Ausfall unberührt (AEAO zu § 146a, Nr. 1.14.2 f. → §3.8).
- Die Servicekraft bietet dem Gast den Bon an.
Lehnt der Gast ab, ist die Pflicht dennoch erfüllt. § 146a Abs. 2 AO verlangt das „Ausstellen und Zur-Verfügung-Stellen”, nicht die Annahme.
6. DSFinV-K Export-Schnittstelle
6.1 Verbindliche Version und Prüfsoftware
Bei Kassen-Nachschau oder Betriebsprüfung verlangt die Finanzverwaltung einen genormten Export nach DSFinV-K, lesbar durch die Prüfsoftware IDEA. Verbindlich ist v2.4, Stand Dezember 2023. [5] jotti hält den Versionsstring deshalb in einer einzigen Konstante (dsfinvk.Version) fest. Eine künftige DSFinV-K-Version ändert ihn an einer Stelle im Code.
Das Test-Paket backend/dsfinvkpruefung prüft in einem Integrationstest die Exporte des Seed-Szenarios gegen die Struktur- und Inhaltsregeln der DSFinV-K 2.4. Es parst CSV und index.xml unabhängig vom Erzeuger (api/fiskal/dsfinvk), damit ein beiderseits geteilter Formatfehler auffällt. Beträge plausibilisiert es nicht; das leisten die Golden-File-Tests des Erzeugers.
6.2 Dateiformat und Grundregeln
- Gesamtstruktur: ZIP-Archiv mit CSV-Dateien, einer
index.xml(Metadaten für das Prüftool) und der zugehörigengdpdu-01-09-2004.dtd(Beschreibungsstandard nach GoBD-Anlage „Ergänzende Informationen zur Datenträgerüberlassung”) [20]. Dieindex.xmldeklariert die vorhandenen Tabellen samt Spalten, Feldtypen und Trennzeichen; sie ist zwingend, ebenso die DTD. Das ZIP enthält nurindex.xml, die DTD und CSV-Dateien, alle flach im Wurzelverzeichnis. Die GDPdU-Beschreibung lässt im ElementURLnur relative Dateinamen zu. - CSV-Regeln:
- Header-Zeile zwingend
- Semikolon-Trennung, CRLF
- Komma als Dezimaltrennzeichen (in der amtlichen
index.xmlalsDecimalSymboldeklariert) - keine Tausendertrennzeichen, mindestens eine Stelle vor dem Komma, keine führenden Nullen
- Spaltenreihenfolge exakt nach Spezifikation
- Dateinamen: englisch und kleingeschrieben (
transactions.csv,lines.csv,cashregister.csv,tse.csv, …), nicht abänderbar. Die deutschen Begriffe der Spezifikation („Bonkopf”, „Bonpos”) sind logische Bezeichnungen, keine Dateinamen: WerBonkopf.csvexportiert, erzeugt eine nicht konforme Datei. - Custom-Felder: Zusätzliche Spalten am Ende erlaubt, müssen in
index.xmldefiniert sein
6.3 Modul-Struktur und offizielle Dateinamen
Drei Module; jeweils offizieller Dateiname (englisch) und logische DSFinV-K-Bezeichnung (deutsch). Die DSFinV-K erlaubt, nicht befüllte Dateien wegzulassen. Die offizielle index.xml deklariert aber alle 20 Dateien, daher exportiert jotti nicht befüllte header-only.
A. Stammdatenmodul
| Dateiname (offiziell) | Logische Bezeichnung | Inhalt |
|---|---|---|
cashpointclosing.csv | Stamm_Abschluss | Metadaten zum Z-Bon: Unternehmensname, Steuernummer, Start-/End-Vorgangs-ID |
location.csv | Stamm_Orte | Standortdaten der Betriebsstätte |
cashregister.csv | Stamm_Kassen | Kassendaten: Hersteller, Seriennummer, Software-Typ und -Version |
slaves.csv | Stamm_Terminals | Slave-/Terminal-Kassen. Für jotti gegenstandslos (eine Kasse), header-only exportiert |
pa.csv | Stamm_Agenturen | Stammdaten bei Agenturgeschäft. Für jotti gegenstandslos, header-only exportiert |
vat.csv | Stamm_USt | Stammdaten der USt-Schlüssel 1–7 (→ §6.7) |
tse.csv | Stamm_TSE | TSE-Daten: TSE-Referenz-ID (nur innerhalb eines Kassenabschlusses), Signaturalgorithmus, TSE-Seriennummer (64-stelliger Hexadezimalstring), Public Key und Zertifikat (Base64) |
B. Einzelaufzeichnungsmodul (Bonmodul)
| Dateiname (offiziell) | Logische Bezeichnung | Inhalt |
|---|---|---|
transactions.csv | Bonkopf | Ein Datensatz pro Kassenbon: BON_ID, BON_NR, BON_TYP, BON_START, BON_ENDE (ISO 8601), Gesamtbruttoumsatz, BON_STORNO |
transactions_vat.csv | Bonkopf_USt | USt-Aufschlüsselung pro Bon nach Steuerschlüsseln (Brutto, Netto, USt) |
allocation_groups.csv | Bonkopf_AbrKreis | Zuordnung eines Bons zu einem ABRECHNUNGSKREIS (Tisch-Verknüpfung im Festzelt) |
datapayment.csv | Bonkopf_Zahlarten | Zahlungsarten pro Bon (Bar, EC-Karte, Kreditkarte) |
references.csv | Bon_Referenzen | Referenzen auf andere Bons, u. a. REF_BON_ID bei Stornos |
lines.csv | Bonpos | Einzelne Artikel: POS_ZEILE, ART_NR, MENGE, EINHEIT, STK_BR (Stückpreis brutto) |
lines_vat.csv | Bonpos_USt | USt-Aufschlüsselung pro Artikelzeile |
itemamounts.csv | Bonpos_Preisfindung | Preisfindung je Position (Rabatte, Zu-/Abschläge). Für jotti gegenstandslos, header-only exportiert |
subitems.csv | Bonpos_Zusatzinfo | Zusatzinformationen je Position (z. B. Pfand). Für jotti gegenstandslos, header-only exportiert |
transactions_tse.csv | TSE_Transaktionen | Kritisch: TSE-Transaktionsnummer (TSE_TANR), Signaturzähler (TSE_TA_SIGZ), Krypto-Signatur (TSE_TA_SIG) |
C. Kassenabschlussmodul (Z-Bon)
| Dateiname (offiziell) | Logische Bezeichnung | Inhalt |
|---|---|---|
businesscases.csv | Z_GV_Typ | Aggregierte Beträge pro Geschäftsvorfall-Typ nach Steuersätzen |
payment.csv | Z_Zahlart | Aggregierte Summen der Zahlungsarten (Bar vs. unbar) |
cash_per_currency.csv | Z_Waehrungen | Bargeldbestand je Währung zum Abschluss |
6.4 Schlüsselfelder (Relationale Verknüpfung)
Fast jede CSV-Datei führt in den ersten Spalten: Z_KASSE_ID (Kassen-ID), Z_ERSTELLUNG (Zeitstempel des Kassenabschlusses), Z_NR (fortlaufende Z-Bon-Nummer), BON_ID (Vorgangs-ID).
Der Bonkopf (transactions.csv) führt zusätzlich BEDIENER_ID und BEDIENER_NAME. Die DSFinV-K definiert BEDIENER_NAME (Feldlänge 50) als „unternehmensinternen Namen der Person, die den Vorgang erfasst”. jotti füllt BEDIENER_ID mit der stabilen Benutzer-ID (user_id) und BEDIENER_NAME mit dem zum Buchungszeitpunkt eingefrorenen Benutzernamen (kassenjournal.user_name), nicht mit dem bürgerlichen Klarnamen. Der unternehmensinterne Benutzername erfüllt die Felddefinition vollständig; der Klarname wird bewusst nicht exportiert (Datenminimierung nach Art. 5 Abs. 1 lit. c DSGVO) [19]. Die Zuordnung Benutzername → Person hält die Benutzerverwaltung (users.name) als Bedienerliste für die Betriebsprüfung vor (→ verfahrensdokumentation.md).
6.5 Abrechnungskreis: Tisch-Verknüpfung für Festzelt
Das Feld ABRECHNUNGSKREIS (in allocation_groups.csv, je BON_ID) verknüpft Bestellungen und Zahlungen eines Tisches zu einer logischen Einheit, Beispieltabelle und Ablauf: → §3.6.
- Vergabe: pro Tisch und Kassensitzung, Wert = Tischname (z. B.
Tisch 42), intern Subjectkassensitzung-{nr}/tisch-{id}. Das Format erlaubt beliebige Strings bis 50 Zeichen;Tisch {Name}ist eine jotti-interne Konvention. Jeder Tisch erhält seinen eigenen Abrechnungskreis, ein Gesamt-Schlüssel für alle Tische verstieße gegen die GoBD-Nachvollziehbarkeit. Der Tagesabschluss schließt die Kassensitzung und damit alle Tisch-Sessions. - Mehrere Gästegruppen am selben Tisch: teilen sich einen Abrechnungskreis — zulässig, solange alle Bons korrekt verknüpft sind.
- Direktverkauf: sofort geschlossene Transaktion ohne Tisch, im Export ohne
ABRECHNUNGSKREIS(das Feld ist optional). KeineBestellung-V1nötig, direkt alsKassenbeleg-V1abgesichert.
6.6 Storno-Handling in DSFinV-K
Stornierungen erzeugen immer neue Datensätze (GoBD-Radierverbot), nie Änderungen am Ursprungsbon:
- Positions-Storno (vor Zahlung): neuer Bon mit negativer Menge,
REF_BON_IDinreferences.csvauf den Ursprungsbon, eigene TSE-Signatur, gleicherABRECHNUNGSKREIS. - Bon-Storno (nach Zahlung): neuer Bon mit negativem Gesamtbetrag,
REF_BON_IDauf den Original-Zahlungsbeleg, eigeneKassenbeleg-V1-Transaktion. BON_STORNO: bleibt in allen Fällen0. jotti nutzt die zulässige Negativ-Darstellung, das Vorzeichen des neuen Bons trägt die Korrektur.BON_STORNO = 1kennzeichnet die vollständige Aufhebung eines ganzen Belegs; diesen Vorgang gibt es in jotti nicht.- Direktverkauf:
direktverkauf-getaetigt:v1(positiver Geschäftsvorfall) unddirektverkauf-storniert:v1(negativer Geschäftsvorfall) sind je eigene Belegvorgänge. Jedes Event wird 1:1 auf einen Belegvorgang abgebildet. Der Storno verweist perREF_BON_IDauf den Ursprungsverkauf. - Abgrenzung: Ein Storno ist ein negativer
Beleg-Bon mitGV_TYP = Umsatzinlines.csv. Negative Bargeldabflüsse (GV_TYP = GeldtransitoderDifferenzSollIst) sind keine Stornos und brauchen keine Referenz. - Rechtsgrundlage: Warenrücknahme und Positionskorrektur folgen der Negativ-Darstellung nach DSFinV-K Tz. 4.2.5 und Tz. 4.2.3. Die Korrektur negiert
MENGE, stattP_STORNOzu setzen. Die Referenz auf den Ursprungsbon folgt Tz. 4.2.2. - Umbuchung: Abgang und Zugang sind je ein geldneutraler
AVBestellung-Bon. Der Abgang trägt dieumbuchungIdalsBON_ID, der Zugang verweist perREF_BON_IDdarauf. references.csv:REF_TYPistTransaktion,POS_ZEILEbleibt leer (Verweis aus dem Bonkopf). Ursprung und Verweis liegen in derselben Kassensitzung. Daher tragenREF_DATUM,REF_Z_KASSE_IDundREF_Z_NRdie Werte dieses Abschlusses.
6.7 Steuersatz-Verwaltung
USt-Sätze als Stammdaten:
- 19 % (Regelsteuersatz, z. B. Getränke)
- 7 % (ermäßigt, z. B. Speisen)
- 0 % / steuerbefreit (Kleinunternehmer nach § 19 UStG)
- Kombi 70/30 (Kombinationsangebote nach Abschn. 10.1 Abs. 12 UStAE) [18]
Produkte erhalten einen konfigurierbaren Steuersatz-Schlüssel. Bei kombi-Positionen entfaltet der Export den Pauschalpreis in zwei Steueranteile (70 % → 7 %, 30 % → 19 %): zwei VAT-Einträge in lines_vat.csv, beide Anteile in transactions_vat.csv. Steuerregeln: steuerrecht.md.
vat.csv führt alle USt-Schlüssel 1–7 der DSFinV-K-Anlage 2, nicht nur die verwendeten, weil Prüfsoftware sie erwartet. Die historischen Sätze ab ID 11 entfallen. UST_SATZ trägt für 1–4 den bei Erfassung geltenden Satz, für 5–7 fest 0,00.
6.8 Bontypen und Geschäftsvorfälle
- Umsatz bei Zahlung: Umsatz entsteht erst mit der Zahlung (DSFinV-K Tz. 2.7.2, Durchbedienen mit Bestell-Absicherung).
BON_TYP(Anhang B): Zahlung, Warenrücknahme, Direktverkauf samt Storno und Bargeldbewegungen sindBeleg. Bestellung, Korrektur und Umbuchung sindAVBestellung. Der Tagesabschluss istAVSonstige.- Geldneutrale Bons:
AVBestellungundAVSonstigesind TSE-gesichert, tragen aber keinen Umsatz (UMS_BRUTTO0,00). Sie haben weder USt- noch Zahlart- noch Kassenbestandswirkung. Die Positionen einerAVBestellungstehen informativ inlines.csv, ohneGV_TYP. Sonst wiese eine Summe der Bonpos jeGV_TYPmehr Umsatz aus als der Kassenabschluss. - Bargeldbewegungen (Anhang C): Anfangsbestand, Geldtransit und
DifferenzSollIstsindBelegmit genau einer Position.ARTIKELTEXTundGV_TYPtragen den GV-Typ,UST_SCHLUESSEList 5 (nicht steuerbar). Sie haben keinenABRECHNUNGSKREIS. Ein Anfangsbestand von 0 erzeugt keinen Bon (Anhang C: Erfassung nicht zwingend). - Tagesabschluss: Der Tagesabschluss ist ein
AVSonstige-Bon ohne Positionen mitBON_NAME„Tagesabschluss“. BeiAVSonstigeistBON_NAMEPflicht (Anhang B, Tz. 4.1.2). Er steht im Export, damit seine TSE-Signatur eine Zeile intransactions_tse.csverhält. So geht der Abgleich TSE ↔ Export je Kassensitzung auf.
7. Elektronische Meldepflicht (ELSTER)
7.1 Gesetzliche Grundlage und Fristen
Nach § 146a Abs. 4 AO müssen elektronische Aufzeichnungssysteme beim zuständigen Finanzamt gemeldet werden; das Mitteilungsverfahren ist seit dem 1. Januar 2025 aktiv. [1, 12]
| Datum | Ereignis |
|---|---|
| 1. Januar 2025 | Meldeportal öffnet; Mitteilungsverfahren ist aktiv |
| 31. Juli 2025 | Abgabefrist für alle Systeme, die vor dem 1. Juli 2025 angeschafft wurden |
| Innerhalb 1 Monat nach Anschaffung | Abgabefrist für Systeme, die ab dem 1. Juli 2025 neu angeschafft werden |
| Innerhalb 1 Monat nach Außerbetriebnahme | Abgabefrist bei Stilllegung eines Systems |
7.2 Übermittlungswege und gewählter Ansatz
Die Finanzverwaltung stellt die Übermittlung über zwei Wege bereit (BMF-Schreiben vom 28.06.2024) [6, 12]:
- die Direkteingabe im Portal „Mein ELSTER” (manuell)
- die programmatische Übermittlung über ERiC (ELSTER Rich Client), die offizielle Komponente der Finanzverwaltung mit lokaler Vorab-Validierung und Bestätigungsprotokoll
Gewählter Ansatz für jotti (Self-hosted, ehrenamtliche Betreiber): die manuelle Meldung über das ELSTER-Webportal (F-05). Der Admin-Bereich stellt dazu alle meldepflichtigen Daten strukturiert bereit; der Vorstand überträgt sie einmalig ins Portal.
Nicht-Ziel: Eine programmatische Übermittlung (ERiC-C-Library oder fiskaly-Submission-API) ist bewusst nicht vorgesehen. Die Meldung fällt pro Instanz nur einmal an (Inbetriebnahme, Außerbetriebnahme). Der Automatisierungsaufwand steht in keinem Verhältnis zu diesem einmaligen Vorgang (→ anforderungen.md, Nicht-Ziele).
7.3 Meldepflichtige Daten (Payload)
- Name und Steuernummer des Steuerpflichtigen
- Art des Kassensystems (Softwaretyp, Versionsnummer)
- Seriennummer des Kassensystems
- Anzahl der insgesamt je Betriebsstätte eingesetzten elektronischen Aufzeichnungssysteme (§ 146a Abs. 4 Satz 1 Nr. 5 AO, AEAO Nr. 1.16.2.4)
- Zertifizierungs-ID der TSE (Format
BSI-K-TR-nnnn-yyyy) - Seriennummer der TSE (64-stelliger Hexadezimalstring, 0–9/A–F, nicht zu verwechseln mit dem Base64-Public-Key in
tse.csv) - Anschaffungs- bzw. Inbetriebnahmedatum
- Betriebsstättenadresse
7.4 Meldestatus
Der Meldestatus ist manuell setzbar („Noch offen” / „Gemeldet am TT.MM.JJJJ”) und in den Stammdaten persistiert.
7.5 BYOD-Smartphones: keine Meldepflicht
Die Smartphones der Servicekräfte müssen nicht gemeldet werden. Der AEAO zu § 146a AO stellt klar: Bei Systemen ohne eigene Kassenfunktion (Eingabegeräte) ist nur das Hauptsystem mitteilungspflichtig. Voraussetzung ist, dass sie mit einem Aufzeichnungssystem mit Kassenfunktion verbunden sind. Vereine melden also ausschließlich ihre jotti-Instanz, nicht die Handys der Helfer. [15] Die vollständige Pflichtenverteilung Entwickler/Betreiber: → Abschnitt 8.
8. Betreiberpflichten
Die Vereine tragen als Betreiber die volle operative und rechtliche Verantwortung für ihre jotti-Instanz. Anleitungen für die Betreiber:
- Leitfaden: laienverständliche Anleitung
- TSE einrichten: die TSE-Einrichtung Schritt für Schritt (fiskaly-Konto, Wizard, PUK/PIN-Verwahrung, TEST→LIVE)
- Leitfaden, Checkliste: die abhakbare Praxisliste
Pflichtenverteilung Entwickler / Betreiber:
| Pflicht | Entwickler (jotti) | Verein (Betreiber) |
|---|---|---|
| TSE-Schnittstelle im Code implementieren | ✅ Pflicht | — |
| DSFinV-K-Export im Code implementieren | ✅ Pflicht | — |
| Verfahrensdokumentation (GoBD) | ✅ Vorlage bereitgestellt | ✅ Pflicht (anpassen, führen) |
| Cloud-TSE-Vertrag abschließen | — | ✅ Pflicht |
| TSE-API-Keys konfigurieren (Admin-UI) | — | ✅ Pflicht |
| ELSTER-Meldung (§ 146a Abs. 4 AO) | ❌ Keine Pflicht | ✅ Pflicht (Frist: 1 Monat) |
| BYOD-Smartphones melden | — | ❌ Nicht erforderlich |
| 10-Jahres-Archivierung (GoBD) | — | ✅ Pflicht |
| Server-Betrieb und Datensicherung | — | ✅ Pflicht |
| AVV mit dem Hoster (Art. 28 DSGVO) | — | ✅ Pflicht (nur bei gemietetem Server, → Leitfaden) |
Zwei Betreiberpflichten, die sich aus jottis Bauweise ergeben:
- TSE-Zugangsdaten: API-Key und Secret werden über den geführten Einrichtungs-Assistenten im Admin-Bereich hinterlegt. Beide liegen danach in der Datenbank und sind über die API nicht auslesbar. Ihr Schutz hängt am Zugriffsschutz für Server und Backups. jotti legt TSS und Client selbst an, das Anbieter-Dashboard kann das nicht (→ TSE einrichten).
- Kassensturz und Z-Bon: Beim Kassensturz den gezählten Ist-Bestand in einem Zählprotokoll festhalten. Nach jedem Veranstaltungstag einen Z-Bon erstellen (ein X-Bon/Zwischenbericht ersetzt ihn rechtlich nicht). Differenzen ehrlich buchen. Eine Kasse, die „immer auf den Cent genau stimmt”, gilt der Finanzverwaltung als manipulationsverdächtig (IDEA-Prüfung). Z-Bons und Zählprotokolle fallen unter die 10-Jahres-Aufbewahrung.
9. Quellenverzeichnis
Verweise im Text (z. B. [1]) beziehen sich auf die Nummern dieser Liste.