TSE-Signatur jedes Kassenvorgangs
Signiert Beleg, Bestellung und Tagesabschluss beim Buchen; Ergebnis landet am Beleg
Funktionen · Geld & Recht
In Deutschland muss jede Kasse ihre Vorgänge von einer zertifizierten Sicherheitseinrichtung unterschreiben lassen, damit nachträglich niemand etwas ändern kann. Genau das passiert hier: jeder Verkauf, jede Bestellung, jeder Tagesabschluss wird beim Buchen signiert, und die Unterschrift landet zusammen mit einem Prüfcode auf dem Bon. Dazu kommen die Pflichten drumherum — die Kasse dem Finanzamt melden, dem Prüfer bei einer Kassennachschau auf Knopfdruck das komplette Datenpaket geben und dem Gast ermöglichen, seinen Beleg selbst nachzuprüfen. Der Betrieb hat die Wahl zwischen einer Sicherheitseinrichtung als USB-Stick am Gerät und einer in der Cloud. Alles hier gilt nur für Deutschland — Spanien läuft über einen eigenen Weg (siehe 12 Fiskal Spanien & International).
Die technische Sicherheitseinrichtung konfigurieren.
Echte Oberfläche
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Signiert Beleg, Bestellung und Tagesabschluss beim Buchen; Ergebnis landet am Beleg
Lokale Hardware-TSE am Gerät, über die native WORM-API angesprochen
TSE als Dienst, kein Gerät vor Ort; mandantenweise konfiguriert. Status, TAR-Export, Einrichtungscheck und Geräte-Dashboard laden die aktuelle Mandantenkonfiguration vor dem Verfügbarkeits-Gate nach
Satellitenkassen signieren über die TSE des Host-Servers. Für private HTTPS-IP-Ziele wird dessen Zertifikat gegen genau die synchronisierte Standort-CA geprüft; Namensfehler und fremde CAs bleiben gesperrt, andere Ziele erhalten keine Custom-Root-Ausnahme
Wählt automatisch fiskaly → Proxy → lokale Swissbit, je nach Verfügbarkeit. fiskaly steht bewusst vorn — deshalb wird die Cloud-TSE seit 05.09.2026 nur noch geladen, wenn der Provider sie auch meint (FiskalyLoaderGate, Review H3).
Bestimmt laufend, welcher Server die TSE hält, und fängt dessen Ausfall ab
Ein Server vergibt die fortlaufende Belegnummer für alle Kassen, inkl. Ausfall-Lane
Erkennt fabrikneue, bereits von DiKAS eingerichtete und fremde TSE automatisch. Der atomare Endpunkt hält den Backend-Fiskalpfad bis zum vollständigen Erfolg aus, richtet ein, registriert und publiziert danach den Host — seit 05.09.2026 nur nach dem lokalen Swissbit-Zweig (Review H1). Die Verwaltung zeigt dafür genau einen primären Knopf ohne Bestätigungsdialog; in der Cloud-Ansicht (fiskaly) gibt es diesen Knopf nicht — dort ist nichts zu aktivieren (Review H2).
Bestehende Initialisierungswege bleiben für alte Clients und Support erhalten, verwenden aber dieselbe Herkunfts- und Anmeldesperre. USB-Hotplug bewertet nur über direkten Loopback neu.
Kassen-ID (TSESerialId), PIN/PUK-Zugangsdaten und lokalen Pfad pflegen. Nur tatsächlich geänderte Zugangsdaten erlauben genau einen automatischen Folgeversuch; unverändertes Speichern kostet keinen Geräteversuch.
Erkennt die eigene lokale Swissbit-TSE ausschließlich anhand einer passenden Seriennummer in bereits signierten Altbelegen und vollständiger DiKAS-Zugangsdaten. Setzt Herkunftsnachweis, lokalen TSE-Schalter und eine fehlende lizenzierte Kassen-ID; explizite Proxy-/fiskaly-Auswahl bleibt unangetastet.
Providerabhängiger Status: Swissbit mit Hardware-, Laufzeit- und Kapazitätswerten; fiskaly klar als Cloud-TSE mit Seriennummer/Zertifikat und ohne erfundene Hardwarefehler. Bei deaktiviertem Backend löst ein Seitenaufruf keinen lokalen Gerätezugriff aus.
Secret-freies Statusabbild für die Fernwartung (/rest/tse)
Zeigt ausschließlich Erklärung und Zugangsdatenmaske, validiert die bisherigen PINs genau einmal und schreibt PUK, Admin-PIN und Time-Admin-PIN anschließend physisch auf die DiKAS-Werte um. Erst danach werden Tresor und Host aktualisiert.
Eine bereits eingerichtete TSE wird nur angesprochen, wenn ihre Seriennummer bereits erfolgreich provisioniert wurde oder der Bediener gerade geänderte Zugangsdaten für genau diese Seriennummer gespeichert hat. Sonst wird ohne PIN-Versuch angehalten.
Der alte Endpunkt bleibt für Support und ältere Clients erhalten, ist aber kein Bestandteil des normalen Verwaltungsablaufs mehr. Die Ein-Klick-Oberfläche zeigt diese Aktion nicht.
Ein Authentifizierungsfehler (falsche PIN, PIN gesperrt) legt die Sperre in der TseConfig an und persistiert sie sofort, der nächste Health-Zyklus geht nicht ans Gerät; nach Erfolg wird ProvisionedSerial persistiert. Fehlerklasse und Buchführung liegen plattformunabhängig in TseAuthAttemptOutcome (Domäne, beide Schreibweisen der WormError-Namen)
Was gerade eine Anmeldung verhindert, an welcher Seriennummer, wie viele Versuche bleiben, und dass automatische Versuche gestoppt sind — reines Lesen, kostet keinen Fehlversuch
Rohdatenexport der TSE (vollständig oder zeitgefiltert) für den Prüfer
Erzeugt das amtliche CSV-Paket (20 Dateien + index.xml) als ZIP
Klassischer Datenzugriffsexport neben DSFinV-K
Ein Knopf: DSFinV-K + TSE-TAR + Kassenmeldungs-Protokoll (PDF) in einem ZIP für den Prüfer vor Ort
Liest das DSFinV-K-Archiv eines Wettbewerbers ein und schlägt Artikel/Stammdaten vor
Meldet die Kasse nach § 146a Abs. 4 AO elektronisch ans Finanzamt
Baut die XML-Nachricht und übergibt sie an die ERiC-Bibliothek
Zertifikatsdatei hochladen, ersetzen, löschen; Zertifikats-Anhang und Statusfelder werden revisionssicher am selben CouchDB-Dokument gespeichert. Scheitert die Ablage, antwortet der Upload 500 SAVE_FAILED, und HasCertificate bleibt false (seit 08.09.2026 — vorher meldete die Kasse sich als zertifiziert, obwohl die certificate.pfx nirgends lag, und der Ausfall fiel erst Wochen später beim Senden an ELSTER auf)
Validiert die Meldedaten ohne zu übermitteln
Historie aller Übermittlungen mit Ergebnis
Bon trägt einen QR-Code, mit dem der Gast seinen Beleg digital öffnet
Öffentlicher Beleg + PDF, abgesichert über den Schlüssel im QR, nicht über die Belegnummer
Prüft den signierten QR-Inhalt und rekonstruiert den Beleg, auch wenn er nie repliziert wurde
Die Seite hinter dem QR-Code (/r)
Legt fest, ob Trinkgeld dem Arbeitnehmer (§3 Nr. 51 EStG steuerfrei, DSFinV-K TrinkgeldAN) oder dem Unternehmer (steuerpflichtiges Entgelt, TrinkgeldAG) gehört; Default Arbeitnehmer. Einstellbar in den DATEV-Einstellungen, beim Kassieren am Beleg eingefroren
Die AN/AG-Wahl aus der Zeile darüber wird am Beleg eingefroren und vom personenbezogenen Trinkgeld-Konto je Zeile ausgewiesen (Lohnexport: „AN steuerfrei" / „AG steuerpflichtig"). Das Konto ist eine eigene Auswertung neben DSFinV-K und DATEV. Der Owner-Entscheid „Trinkgeld gehört nicht in den DATEV-Export" (20.07.2026) gilt in beide Richtungen: ExportTrinkgeld (Einnahme) bleibt unberührt, und die Auszahlung fällt ebenfalls aus dem Stapel — auch bei IncludeSpendings, siehe die Zeile darunter. Details: Katalog 14 Personal, Zeit & Dienstplan
Die Kassenbuch-Ausgabe „Trinkgeld-Auszahlung" ist ein durchlaufender Posten und wird nicht als Betriebsaufwand gebucht (Vorgabe aus). Einschaltbar mit eigenem Gegenkonto: ExportTrinkgeldAuszahlung + TrinkgeldAuszahlungKonto (kein Vorgabewert — welches Konto richtig ist, entscheidet die/der StB). Schalter an + Konto 0 ⇒ keine Zeile
Nimmt den reinen, vorab online bezahlten Fernverkauf (Webshop/Ticketshop) von der TSE-Signatur aus — Beleg, Nummernkreis, Z-Bericht, DSFinV-K und DATEV bleiben unverändert. Gilt fest ohne Schalter (Owner 08.08.2026); alles mit Vor-Ort-Bezug bleibt signaturpflichtig
Erfasst Beginn und Ende jeder Phase ohne TSE als Nachweis
Findet Belege ohne TSE-Signatur über den fiscalstate-View und signiert nach
Führt durch Steuerdaten, TSE-Einrichtung und Kassenmeldung
Eine Maske mit fünf Reitern: TSE Info, Kassennachschau, TSE Export, GDPdU, DSFinV-K
Bucht eine fiskaly-TSE über den Lizenzserver und provisioniert sie
Bündelt TSE-Daten + DSFinV-K und legt sie für den Kunden ab
Gekündigte Kunden holen ihre TSE-Sicherung über einen Token-Link ab
Der Betrieb ruft die bei Kündigung abgelegte Sicherung auch später noch einmal aus der Verwaltung ab (Metadaten + ZIP-Download)
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Weiterstöbern
Marketing-Cookies erlauben?
Wir würden gerne mit Google Ads messen, welche Anzeigen zu einer Anmeldung führen. Dafür werden Cookies gesetzt und Daten an Google (USA) übertragen — nur mit deiner Einwilligung. Unsere anonyme Reichweitenmessung (Matomo) läuft davon unabhängig. Details und Widerruf in der Datenschutzerklärung.