23

Fiskalisierung, TSE und Kassenregistrierung

1. Wozu dient das?#

Die Technische Sicherheitseinrichtung (TSE) zeichnet alle steuerlich relevanten Kassenvorgänge — wie Bestellungen, Bar- und Kartenzahlungen, Belegstornierungen, Wechselgeldbuchungen sowie Schichtabschlüsse — lückenlos und unveränderbar auf. Jeder Vorgang wird mit einer kryptografischen digitalen Signatur, einem fortlaufenden Signaturzähler und Zeitstempeln versehen. Dies schützt das Kassensystem vor nachträglicher Datenmanipulation und erfüllt die Anforderungen von § 146a AO sowie der Kassensicherungsverordnung (KassenSichV) in Deutschland. Ergänzend erfasst und verwaltet das System die Stammdaten für die gesetzliche Kassenmeldepflicht.

Wichtiger Hinweis zum Anwendungsbereich & Vertragsstatus: In der Standardauslieferung ist das Kassensystem im Simulationsmodus (Testen) (mock) konfiguriert. Ein rechtlich wirksamer Produktivbetrieb mit echter digitaler Signierung erfordert zwingend den vorherigen Abschluss eines separaten Vertrages mit einem zugelassenen Cloud-TSE-Anbieter (z. B. Fiskaly) oder den Anschluss einer zertifizierten Hardware-TSE. Das System selbst garantiert keine rechtliche Konformität oder BSI-Zertifizierung; die Verantwortung für den ordnungsgemäßen Betrieb und die Einhaltung aller steuerlichen Pflichten verbleibt vollumfänglich beim Betriebsinhaber.

2. Rollen und Berechtigungen#

Die Verwaltung der Fiskaleinstellungen und Kassenregistrierung ist im System über Berechtigungsstufen geregelt:

• Inhaber (admin): Vollzugriff auf alle Fiskaleinstellungen, Anbieterkonfigurationen, Kassenregistrierungsdaten sowie den Export der Anmeldedateien.
• Manager (manager): Lese- und Bearbeitungsrechte für Kassenregistrierungsdaten, Einsehen des TSE-Status und Export von Registrierungs-JSONs. Keine Berechtigung zum Ändern grundlegender Datenbank-Mandantentypen.
• Bediener / Servicekraft (waiter): Kein Zugriff auf das Fiskal-Dashboard oder die Einstellungen im Backoffice. Im Bedarfsfall wird der TSE-Ausfallstatus am Kassenplatz als Warnbanner angezeigt.
• Betriebsprüfer (auditor): Schreibgeschützter Lesezugriff auf das Fiskal-Compliance-Dashboard, Registrierungsdaten und TSE-Ausfallprotokolle (tse_outage_logs).

3. Voraussetzungen#

Before configuring or verifying fiscal settings, ensure:

• Sie sind mit einem Konto der Rolle Inhaber (admin) oder Manager (manager) im Backoffice angemeldet.
• Bei Cloud-TSE (Fiskaly): Ein aktiver Vertrag mit Fiskaly liegt vor und die Zugangsdaten (fiskaly_api_key, fiskaly_api_secret, fiskaly_tss_id) sind vorhanden.
• Bei Hardware-TSE: Eine zugelassene USB-/SD-TSE ist am lokalen Station Controller (Sidecar-Dienst) angeschlossen und netzwerktechnisch erreichbar.
• Die Unternehmensstammdaten (Standortname, Standortadresse, Steuernummer) sind im System erfasst.

4. Bildschirm für Bildschirm#

4.1. Fiskalanbieter (Seite FISKAL)#

Im Backoffice öffnen Sie FISKAL. Oben stehen der Titel Fiskal und die Zeile Wählen Sie Ihre lokale Fiskal-Compliance-Engine aus und konfigurieren Sie diese. Darunter folgen der Fiskalanbieter, die Kassenmeldepflicht (4.2) und der DSFinV-K Export (→ Kapitel 23b).

• 1 FISKALANBIETER: drei Karten, mock (Simulation), fiskaly (Cloud-TSE) und hardware (TSE am Station Controller). Die gewählte Karte ist hervorgehoben.
• 2 Fiskaly API-Key. Der Wert ist verdeckt; ein Auge zeigt ihn nach Eingabe der PIN.
• 3 Fiskaly API-Secret, ebenfalls verdeckt.
• 4 TSE-ID Ihrer Cloud-TSE.
• 5 UMGEBUNG: sandbox zum Testen oder production für den echten Betrieb.
• 6 Bei production erscheint die Warnung: Der Produktionsmodus ist aktiv. Echte Fiskaltransaktionen werden signiert und an die Behörden übermittelt.
• 7 ANBIETEREINSTELLUNGEN SPEICHERN.

Bei hardware zeigt die Seite statt der Zugangsdaten die Sidecar Service-URL und die Schaltfläche Gerät in Betrieb nehmen. Danach erscheint die Aktive Gerätekonfiguration mit Seriennummer, Anbieter, Zertifikatsablauf und In Betrieb genommen am.

4.2. Kassenmeldepflicht (modules/backoffice/KassenRegistrationSection.tsx)#

Hier werden die Stammdaten für die behördliche Registrierung nach § 146a Abs. 4 AO gepflegt:

• Kopfzeile: Titel **Kassenmeldepflicht** und Beschreibung "Pflichtige Registrierung Ihrer Registrierkasse beim Finanzamt (§ 146a AO)." sowie Status-Badge (Draft — not submitted / Submitted / Acknowledged).
• Eingabemaske (Linke Spalte):
  • **Geschäfts-/Standortname** (Textfeld)
  • **Standortadresse** (Mehrzeiliges Textfeld)
  • **Steuernummer** (Textfeld / Monospace)
• Informationskarte Systeminformationen (Rechte Spalte):
  • **Systemtyp**: Elektronisches Kassensystem
  • **Software**: Kasse POS v1.0.0
  • **TSE-Typ**: cloud oder hardware
  • **TSE-Seriennummer**: Eindeutige Seriennummer der TSE
  • Button **JSON exportieren**: Lädt kassenmeldung_<location_id>.json herunter.
• Fußzeile: Button **Registrierungsdaten aktualisieren** speichert geänderte Stammdaten im Backend.

5. Schritt für Schritt (mit Verzweigungen)#

Verzweigung A: Einrichtung & Überprüfung des TSE-Providers#

1. Öffnen Sie im Backoffice den Bereich **Fiskal-Compliance**.
2. Prüfen Sie das Feld **Fiskal-Umgebung**:
   • Falls "Mock" angezeigt wird: Das System befindet sich im Testmodus. Es werden simulierte Signaturen erzeugt.
   • Falls "Live" angezeigt wird: Das System übermittelt echte Transaktionen an die konfigurierte Cloud- oder Hardware-TSE.
3. Wenn Sie auf Cloud-TSE (Fiskaly) umstellen möchten:
   • Hinterlegen Sie die API-Schlüssel in der Systemkonfiguration.
   • Wenn ein Schlüssel fehlt, bricht das System mit einer Fehlermeldung ab.
4. Wenn Sie eine Hardware-TSE nutzen:
   • Stellen Sie sicher, dass der Sidecar-Dienst unter der konfigurierten URL (z. B. http://localhost:9100) erreichbar ist.

Verzweigung B: Stammdatenpflege & Export für die Kassenmeldepflicht#

1. Navigieren Sie zu **Kassenmeldepflicht**.
2. Überprüfen Sie die Eingabefelder **Geschäfts-/Standortname**, **Standortadresse** und **Steuernummer**.
3. Falls Sie Änderungen vornehmen:
   • Das Feld **Registrierungsdaten aktualisieren** wird aktiv.
   • Klicken Sie auf **Registrierungsdaten aktualisieren**. Bei Erfolg erscheint die Meldung "Registration data updated".
4. Klicken Sie auf **JSON exportieren** (oder im Dashboard auf **Export fürs Finanzamt**).
5. Die Datei kassenmeldung_<location_id>.json wird heruntergeladen.
6. Reichen Sie diese Datei gemäß den Vorgaben Ihrer Finanzbehörde (z. B. über das ELSTER-Portal) ein.

Verzweigung C: Behebung von Ausfällen & Nachbearbeitung (Degraded Mode)#

1. Wenn der Gesundheitscheck fehlschlägt, wechselt der Status auf **Unreachable**.
2. Auf allen aktiven Kassenterminals wird sofort das rote Banner *** TSE AUSFALL *** eingeblendet.
3. Verhalten beim Kassieren je nach konfigurierter Policy (degraded_policy):
   • Modus block: Bei Versuch, eine Zahlung abzuschließen, bricht der Vorgang mit der Meldung "Fiscal provider degraded" ab. Kassieren ist gesperrt. Zuerst prüft das System die Berechtigung, erst danach die TSE: Wer einen Vorgang gar nicht ausführen darf (z. B. eine Servicekraft bei einer Rückerstattung), erhält auch während eines Ausfalls die Meldung keine Berechtigung (403), nicht die TSE-Sperre. Für solche Versuche wird die TSE nicht abgefragt und kein Ausfall protokolliert.
   • Modus unsigned_emergency: Das Kassieren bleibt möglich. Auf dem Ausdruck wird die Zeile *** TSE AUSFALL *** gedruckt. In der Datenbank wird die Transaktion mit unsigned_emergency = True markiert.
4. Verhalten bei Offline-Betrieb via POS Bridge:
   • Fällt die Cloud-Verbindung aus, schaltet die lokale POS Bridge auf LAN-Betrieb um.
   • Belege werden lokal mit dem Hinweis *** TSE AUSFALL *** gedruckt.
5. Nach Wiederherstellung der Verbindung:
   • Das System führt automatisch die Reintegration durch (/api/v1/gateway/reconcile-orders).
   • Die offline erfassten Transaktionen werden nachträglich an der Cloud-TSE signiert. Die originalen Erfassungszeiten (started_at / finished_at) bleiben erhalten.
   • Das System schließt den Ausfalleintrag in tse_outage_logs mit der end_time ab.
   • Das rote Warnbanner in der Kassenoberfläche verschwindet automatisch.

6. Tiefeneinblick: TSE-Ausfall (Degraded Policy)#

Der Ausfall der TSE ist der betrieblich kritischste Zustand. Das System steuert diesen Zustand strikt nach den gesetzlichen Vorgaben der KassenSichV:

6.1. Was sieht das Kassenpersonal?#

Sobald das Backend einen TSE-Ausfall feststellt (Polling alle 30 Sekunden oder Realtime-Event fiscal.status_changed), wird in der POS-AppShell ein unübersehbares rotes Banner eingeblendet: *** TSE AUSFALL ***.

6.2. Darf weiterverkauft werden?#

• Standard-Konfiguration (degraded_policy = "block"): NEIN. Das Kassensystem verweigert das Abschließen von Bestellungen. Diese Einstellung garantiert, dass kein ununterzeichneter Beleg in Umlauf gerät, blockiert jedoch den Geschäftsbetrieb.
• Notfall-Konfiguration (degraded_policy = "unsigned_emergency"): JA. Das Kassenpersonal kann weiter kassieren. Jeder gedruckte Beleg enthält zwingend den sichtbaren Aufdruck *** TSE AUSFALL ***.

6.3. Was wird während des Ausfalls aufgezeichnet?#

• Ein automatischer Eintrag in der Tabelle tse_outage_logs mit start_time, tenant_id, location_id und dem Fehlergrund (reason).
• Jede Einzelbestellung wird in fiscal_transactions mit dem Flag unsigned_emergency = True und der Policy unsigned_emergency gespeichert.

6.4. Was geschieht bei Rückkehr der TSE?#

1. Sobald die TSE wieder erreichbar ist, wird der Ausfalleintrag in tse_outage_logs mit der aktuellen Zeit als end_time geschlossen.
2. Wenn die POS Bridge im Einsatz war, sendet sie die ununterzeichneten Bestellungen an /api/v1/gateway/reconcile-orders.
3. Das Backend signiert die nachgeforderten Transaktionen nachträglich an der TSE. Die ursprünglichen Erstellungs- und Schließzeitpunkte (created_at, closed_at) werden unverändert in started_at und finished_at der FiscalTransaction übernommen.
4. Fortlaufende Belegnummern (Belegnummer) und Signaturzähler werden chronologisch pro Standort vergeben.
5. Das Warnbanner erlischt automatisch.

6.5. Pflichten des Betreibers bei Ausfall#

1. Dokumentation: Der Ausfall muss im Kassenbuch mit Start- und Endzeit vermerkt werden.
2. Reparaturauftrag: Der Betreiber ist gesetzlich verpflichtet, den Ausfall unverzüglich zu melden und innerhalb von 24 Stunden eine Reparatur oder Entstörung beim TSE-Anbieter zu beauftragen.
3. Nachweisführung: Bei einer Kassennachschau müssen die Ausfallprotokolle aus dem Backoffice vorgelegt werden können.

Sicherheitseinrichtung außer Betrieb nehmen#

Wird die TSE eines Standorts nicht mehr genutzt, etwa beim Wechsel des Anbieters oder der Aufgabe des Standorts, muss sie außer Betrieb genommen werden. Auch dafür gibt es keine Bedienoberfläche: Im Backoffice unter FISKAL steht keine Schaltfläche dafür. Der Vorgang steht Administratoren und Managern nur über die Schnittstelle der Plattform zur Verfügung (→ Kapitel 37). Der Standort muss dafür eine Adresse hinterlegt haben (→ Kapitel 20). Die Kasse ruft dann beim TSE-Anbieter die Deaktivierung des Sicherheitsmoduls des Standorts auf. Wenden Sie sich für die Außerbetriebnahme an Ihren Betreuer.

7. Was passiert im Hintergrund#

Das System verwendet ein asynchrones Outbox-Pattern zur Entkopplung des Checkout-Prozesses vom Signaturdienst. Beim Bezahlen wird ein Ereignis in Redis-Streams geschrieben. Ein Hintergrund-Subscriber (subscriber.py) verarbeitet die Signierung an der TSE.

Zusätzlich laufen automatisierte Sicherheitskontrollen:

• NTP Clock Guard: Bei jedem Signaturaufruf wird die Uhrzeit der TSE geprüft. Wenn die TSE-Uhr auf die Unix-Epoche 1970 zurückgesetzt ist, bricht das System ab (TSE clock reset to 1970 epoch detected. Transaction blocked until time synchronisation.).
• TSE-Time-Update-Log: Manuelle oder automatische Zeitsynchronisationen der TSE werden in der Tabelle tse_time_updates protokolliert.
• Unveränderbarkeit: Eine einmal im Status FINISHED befindliche FiscalTransaction lässt sich über die API weder abändern noch löschen (Fiscal transaction already finalized and immutable).

8. Häufige Probleme & Fehlerbehebung#

Nachfolgend finden Sie die exakten Fehlermeldungen des Backends, deren Ursachen und die passenden Lösungen:

1. Fiscal provider degraded. Details: {health.details}#

• Ursache: Die TSE (Cloud oder Hardware) antwortet nicht oder meldet eine Netzunterbrechung. Die eingestellte Degraded-Policy blockiert den Vorgang.
• Lösung: Internetverbindung bzw. Verkabelung der Hardware-TSE prüfen. Wenn die Störung andauert, in den Einstellungen die Notfall-Policy prüfen oder den TSE-Support kontaktieren.

2. TSE clock reset to 1970 epoch detected. Transaction blocked until time synchronisation.#

• Ursache: Die interne Uhr der Hardware- oder Cloud-TSE hat ihre Synchronisation verloren und steht auf dem Epochen-Jahr 1970. Signierungen mit diesem Datum sind steuerlich ungültig.
• Lösung: Führen Sie eine Zeitsynchronisation der TSE durch den Administrator durch oder warten Sie, bis der NTP-Dienst die Uhrzeit abgeglichen hat.

3. Receipt cannot be issued in live mode: Mock TSE provider is not permitted#

• Ursache: Der Mandant ist im Produktionsmodus (environment_type = "production"), aber als Fiskalanbieter ist noch der mock-Provider eingestellt.
• Lösung: Stellen Sie den Fiskalanbieter im Backoffice auf fiskaly oder hardware um und hinterlegen Sie gültige Zugangsdaten.

4. Receipt cannot be issued in live mode: Sandbox/Test TSE endpoint ({url}) is not permitted#

• Ursache: Die Kasse läuft im Produktivmodus, verwendet aber eine Test- oder Sandbox-URL des Cloud-TSE-Anbieters.
• Lösung: Ändern Sie die Konfigurations-URL in den Fiskaleinstellungen auf den offiziellen Produktiv-Endpunkt von Fiskaly.

5. Tenant is not configured for hardware TSE mode#

• Ursache: Der Mandant versucht, eine Hardware-TSE anzusprechen, obwohl in den Mandanteneinstellungen keine Hardware-Konfiguration hinterlegt ist.
• Lösung: Prüfen Sie die Mandanteneinstellungen und hinterlegen Sie die URL des lokalen Station Controllers.

6. Cannot start a transaction for an already finalized order#

• Ursache: Es wurde versucht, eine TSE-Transaktion für eine Bestellung zu starten, die bereits abgeschlossen und bezahlt ist.
• Lösung: Keine Maßnahme erforderlich. Die Bestellung ist bereits geschützt. Erstellen Sie bei Korrekturen eine Stornobuchung.

7. Fiscal transaction already finalized and immutable / Transaction is already in FINISHED state#

• Ursache: Eine Schreib- oder Aktualisierungsanforderung wurde an eine TSE-Transaktion gesendet, die sich bereits im Endzustand FINISHED befindet.
• Lösung: Dies verhindert Datenmanipulationen. Die Transaktion ist unveränderbar im Fiskalspeicher abgelegt.

8. Registration not found#

• Ursache: Für den aktuellen Standort wurden noch keine Stammdaten zur Kassenmeldepflicht in der Datenbank angelegt.
• Lösung: Öffnen Sie im Backoffice den Bereich Kassenmeldepflicht, geben Sie Standortname, Adresse sowie Steuernummer ein und klicken Sie auf Registrierungsdaten aktualisieren.

9. Only production tenants can use live fiscal mode#

• Ursache: Es wurde versucht, den Live-Fiskalmodus für einen Demo- oder Test-Mandanten zu aktivieren.
• Lösung: Der Live-Fiskalmodus ist geschützten Produktions-Mandanten vorbehalten. Schalten Sie den Mandanten in den Produktionsstatus um.

9. Grenzen#

• Das Kassensystem nimmt keine automatische Datenübermittlung der Kassenmeldung an das Finanzamt vor; die Abgabe der exportierten JSON-Datei liegt beim Betreiber.
• Der mitgelieferte Simulationsmodus (mock) schützt vor keinerlei steuerlichen Konsequenzen bei einer Betriebsprüfung.
• Das System kann Ausfälle der TSE erfassen und Notfall-Belege drucken, entbindet den Betreiber jedoch nicht von der rechtlichen Pflicht zur unverzüglichen Störungsbeseitigung.

10. Standorte in Österreich (RKSV)#

Einen Standort in Österreich können Sie noch nicht anlegen: Das System weist das Land ab. In Österreich gilt statt der KassenSichV die Registrierkassensicherheitsverordnung (RKSV). Die Anbindung an fiskaly SIGN AT ist vorbereitet, freigegeben wird das Land aber erst, wenn der Vertrag mit fiskaly steht und die Registrierkasse (mit Startbeleg und Anmeldung bei FinanzOnline) im Programm in Betrieb genommen werden kann.

11. Standorte in der Schweiz#

Die Schweiz kennt keine Pflicht zur Kassensignatur. An einem Standort in der Schweiz arbeitet die Kasse deshalb ohne TSE und ohne Fiskalanbieter.

• Währung: Sie folgt dem Land. Ein Schweizer Standort rechnet in CHF; eine frei wählbare Hauswährung gibt es nicht.
• Kein TSE-Weg: Es gibt keine Signatur, keine TSE-Ausfallsperre und keinen TSE-Block auf Bon und Z-Bon. Die Belege bleiben fortlaufend nummeriert.
• Pflichtangaben (Art. 26 MWSTG): Der Bon zeigt die UID mit dem Zusatz „MWST“, den Steuersatz je Position und die Mehrwertsteuer nach Sätzen.
• 5-Rappen-Rundung: Barzahlungen in CHF werden auf 0,05 CHF gerundet. Die Differenz steht als eigene Zeile Rundung im Zahlungsblock des Bons, nicht als Ware.
• Abschluss: Schichtabschluss und Z-Bon laufen in CHF.
• Exporte: DSFinV-K und DATEV gibt es nur für deutsche Mandanten bzw. Standorte; für die Schweiz weist das System sie mit einer Meldung ab.

Dieses Kapitel gehört zum Merkuron-Handbuch für Inhaber und Servicepersonal.