Zum Inhalt
v26.3

TSE-Compliance — Dokumentation für Steuerprüfer

Dieses Dokument richtet sich an Steuerprüfer, Finanzbehörden und Steuerberater und beschreibt, wie das Kassensystem DiKAS die gesetzlichen Anforderungen an eine ordnungsmäßige Kassenführung technisch umsetzt.

In aller Kürze

  • Jeder kassenrelevante Vorgang wird von einer zertifizierten Technischen Sicherheitseinrichtung (TSE) digital signiert (§ 146a AO, KassenSichV).
  • DiKAS unterstützt eine Swissbit-Hardware-TSE (USB, vor Ort) und die fiskaly-Cloud-TSE.
  • Alle Belege laufen in einem einzigen, fortlaufenden Belegnummernkreis (Kasse und Online-Bestellungen gemeinsam).
  • Stornos werden nicht gelöscht, sondern als signierter Gegenbeleg festgeschrieben.
  • Für die Prüfung stehen der DSFinV-K-Export, der TSE-TAR-Export und ein GDPdU-Export bereit.
  • Kapitel „So läuft eine Kassennachschau mit DiKAS ab" beschreibt den Prüfungsablauf Schritt für Schritt.

Hinweis zum Zweck dieses Dokuments

Dieses Dokument beschreibt ausschließlich die im Kassensystem umgesetzten Funktionen. Konkrete Angaben wie die Seriennummer Ihrer TSE, die Kassen-Seriennummer oder die beim Finanzamt gemeldeten Daten sind betriebsindividuell und finden Sie in Ihrer DiKAS-Installation unter Einstellungen → TSE bzw. in Ihren Meldeunterlagen — nicht in diesem allgemeinen Dokument.


1. Gesetzliche Grundlagen

DiKAS ist auf die Erfüllung folgender Vorschriften ausgelegt:

Vorschrift Inhalt
§ 146a AO Ordnungsgemäße Kassenführung, Pflicht zur Nutzung einer zertifizierten TSE, Belegausgabepflicht
KassenSichV Kassensicherungsverordnung — technische Anforderungen an die TSE
AEAO zu § 146a AO Anwendungserlass mit Detailvorgaben zu ProcessTypes, ProcessData und QR-Code
DSFinV-K Digitale Schnittstelle der Finanzverwaltung für Kassensysteme (DiKAS erzeugt Version 2.3)
BSI TR-03153 Technische Richtlinie für die TSE (Signatur, Export, Zertifizierung)
GoBD / GDPdU Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern (digitale Betriebsprüfung)
§ 14 UStG Pflichtangaben auf Rechnungen/Belegen (USt-Aufschlüsselung)

Meldepflicht liegt beim Kassenbetreiber

Die Mitteilung der eingesetzten Kasse und TSE an das Finanzamt (§ 146a Abs. 4 AO, seit 2025 über Mein ELSTER) ist eine Pflicht des Betreibers. DiKAS stellt die dafür nötigen Angaben (TSE-Seriennummer, Kassen-Seriennummer, Anschaffungsdatum) im System bereit, übernimmt die Meldung an das Finanzamt aber nicht automatisch.


2. Die TSE in DiKAS

Eine Technische Sicherheitseinrichtung (TSE) ist ein zertifiziertes Sicherheitsmodul. Sie versieht jeden Kassenvorgang mit einer digitalen Signatur und einem fortlaufenden Signaturzähler. Dadurch lässt sich später zweifelsfrei feststellen, ob Kassendaten nachträglich verändert wurden.

DiKAS kann mit unterschiedlichen TSE-Varianten betrieben werden:

Variante Beschreibung
Swissbit-Hardware-TSE BSI-zertifizierte Hardware-TSE, per USB direkt an der Kasse. Signiert und speichert vor Ort. Wird von DiKAS automatisch erkannt (Einbindung unter /mnt/tse/).
fiskaly-Cloud-TSE Zertifizierte Cloud-TSE (fiskaly SIGN DE). DiKAS signiert die Belege über die fiskaly-Schnittstelle im Internet. Kein USB-Gerät erforderlich.
TSE-Verbund (Netzwerk) Mehrere Kassen eines Betriebs können sich eine TSE teilen: Eine Kasse ist der TSE-Host, die übrigen Kassen signieren über diesen im lokalen Netz.

Welche TSE bei Ihnen aktiv ist

DiKAS wählt automatisch die verfügbare TSE (Reihenfolge: fiskaly-Cloud → Netzwerk-TSE → lokale Swissbit-Hardware). Die tatsächlich verwendete TSE ist auf jedem Kassenbon am QR-Code und an der aufgedruckten TSE-Seriennummer erkennbar sowie im System unter Einstellungen → TSE einsehbar.

Demo- und Testsysteme

Reine Demo-/Testinstallationen von DiKAS laufen bewusst ohne TSE. In diesem Betriebsmodus wird kein Beleg signiert; entsprechende Belege sind deutlich als nicht fiskalisiert erkennbar (siehe Abschnitt 9). Für den steuerlich relevanten Echtbetrieb ist stets eine echte TSE aktiv.


3. Welche Vorgänge signiert werden

DiKAS signiert alle kassenrelevanten Vorgänge gemäß AEAO zu § 146a AO — nicht nur Verkaufsbelege. Dabei werden die drei in der DSFinV-K vorgesehenen Vorgangsarten (ProcessTypes) verwendet:

ProcessType Wird verwendet für
Kassenbeleg-V1 Jeder abgeschlossene Zahlvorgang: Direktverkauf, Tischzahlung, Storno und Retoure/Gutschrift (mit negativen Beträgen)
Bestellung-V1 Bestellungen im Tischbetrieb (Bestellbon vor der Bezahlung)
SonstigerVorgang Schichteröffnung, Schichtschließung, Tagesabschluss, Bar-Ein-/Auszahlungen und Geldtransit

Innerhalb von SonstigerVorgang kennzeichnet DiKAS den konkreten Vorgang zusätzlich mit einem eigenen Kürzel:

Kürzel Vorgang
AVSichOpen Schichteröffnung (Kassenlade wird mit Wechselgeld gestartet)
AVSichClose Schichtschließung (Kassensturz am Schichtende)
AVKassenschnitt Tagesabschluss (Z-Bericht)
AVSonstAusgabe Barauszahlung / Ausgabe / Privatentnahme
AVSonstEinlage Bareinlage / Privateinlage
AVTransfer Geldtransit (z. B. Geld von der Kasse zur Bank)

Wichtig für die Prüfung

Ein Storno ist in DiKAS kein SonstigerVorgang, sondern ein vollwertiger, TSE-signierter Kassenbeleg-V1 mit negativen Beträgen (siehe Abschnitt 7). Dadurch ist jede Stornierung genauso manipulationssicher festgeschrieben wie der ursprüngliche Verkauf.


4. Wie ein Kassenbeleg fiskalisch entsteht

Bei jedem Zahlvorgang übergibt DiKAS die steuerlich relevanten Daten des Belegs an die TSE. Die TSE signiert diese Daten und liefert eine eindeutige Transaktionsnummer, einen Signaturzähler und die kryptografische Signatur zurück. Diese Werte werden untrennbar am Beleg gespeichert und auf den Bon gedruckt.

4.1 Signierte Vorgangsdaten (ProcessData) — Kassenbeleg-V1

Für einen Verkaufsbeleg baut DiKAS die signierten Vorgangsdaten in folgendem Format auf:

Beleg^<19%>_<7%>_<10,7%>_<5,5%>_<0%>^<Zahlungen>
  • Der Steuerteil besteht aus genau fünf Brutto-Beträgen, durch Unterstrich _ getrennt, in einer festen Reihenfolge der Steuerklassen:

    Position Steuerklasse
    1 19 % (allgemeiner Satz)
    2 7 % (ermäßigter Satz)
    3 10,7 % (Durchschnittssatz § 24 UStG)
    4 5,5 % (Durchschnittssatz § 24 UStG)
    5 0 % (Nullsatz)

    In jeder Position steht der Brutto-Umsatz dieser Steuerklasse. Nicht belegte Klassen werden mit 0.00 gefüllt.

  • Der Zahlungsteil listet je Zahlung <Betrag>:<Bar|Unbar>; Barzahlungen stehen zuerst. Die Zahlbeträge summieren sich zum Gesamtbetrag des Belegs. Wechselgeld und Trinkgeld sind dabei nicht Teil des Zahlungsbetrags.

Beispiel — Beleg über 60,00 € (davon 47,60 € zu 19 % und 12,40 € zu 7 %), bar bezahlt:

Beleg^47.60_12.40_0.00_0.00_0.00^60.00:Bar

Beispiel — 100,00 € zu 19 %, geteilt in 40,00 € bar und 60,00 € Karte:

Beleg^100.00_0.00_0.00_0.00_0.00^40.00:Bar_60.00:Unbar

Bar oder Unbar wird festgeschrieben

Ob eine Zahlung als Bar oder Unbar gilt, wird beim Kassieren aus der konfigurierten Zahlart abgeleitet und am Beleg eingefroren. Es wird nicht nachträglich aus dem Zahlart-Namen geraten — dieselbe Einordnung gilt einheitlich für die Signatur und für den DSFinV-K-Export.

4.2 Signierte Vorgangsdaten (ProcessData) — Bestellung-V1

Bestellungen im Tischbetrieb (der Bestellbon, bevor kassiert wird) werden je Position wie folgt signiert:

<Menge>;"<Bezeichnung>";<Brutto-Einzelpreis>

Die einzelnen Positionen sind durch einen Zeilenumbruch getrennt; die Bezeichnung steht in Anführungszeichen (enthaltene Anführungszeichen werden verdoppelt). Beispiel:

2;"Cola";3.50
1;"Pizza Salami";11.50

4.3 Signierte Vorgangsdaten (ProcessData) — SonstigerVorgang

Sonstige Vorgänge werden im Format <Vorgang>^<Daten> signiert, z. B.:

AVSichOpen^Schichteroeffnung^200.00
AVSichClose^Schichtschliessung^845.30
AVKassenschnitt^Tagesabschluss^1523.90

Zahlenformat

In den signierten Vorgangsdaten und im QR-Code werden Beträge mit Punkt als Dezimaltrennzeichen und zwei Nachkommastellen dargestellt (60.00). Im DSFinV-K-CSV-Export wird dagegen das Komma verwendet (60,00) — beides entspricht der jeweiligen Spezifikation.


5. Der QR-Code auf dem Beleg

Jeder Kassenbon enthält einen QR-Code mit den TSE-Daten im Format der DSFinV-K (Anhang I, „Belegprüfung"). So kann jeder Beleg mit einer gängigen Prüf-App (z. B. der offiziellen Beleg-/Fiskal-Prüf-App) gegen die TSE-Signatur verifiziert werden.

Der QR-Code enthält (durch Semikolon getrennt) folgende zwölf Felder:

Pos. Feld Bedeutung
1 Version Immer V0
2 Kassen-Seriennummer Eindeutige Kennung der Kasse
3 ProcessType z. B. Kassenbeleg-V1
4 ProcessData Die signierten Vorgangsdaten (siehe Abschnitt 4)
5 Transaktionsnummer Fortlaufende Nummer der TSE-Transaktion
6 Signaturzähler Monoton steigender Zähler der TSE
7 Startzeitpunkt Beginn der Signierung
8 Endzeitpunkt Ende der Signierung
9 Signaturalgorithmus z. B. ecdsa-plain-SHA256
10 Log-Zeitformat Zeitformat der TSE
11 Signatur Die kryptografische Signatur
12 Öffentlicher Schlüssel Prüfschlüssel der TSE

Prüfung ohne Kassenzugang

Allein durch Scannen des QR-Codes auf einem Papierbon können Sie ProcessType, Vorgangsdaten, Transaktionsnummer, Signaturzähler und Zeitstempel auslesen und die Signatur rechnerisch prüfen — auch ohne Zugriff auf das Kassensystem.


6. Steuersätze und USt-Schlüssel

Im DSFinV-K-Export ordnet DiKAS jeden Umsatz einem USt-Schlüssel zu. Verwendet werden ausschließlich die folgenden Schlüssel:

USt-Schlüssel Steuersatz Bedeutung
1 19 % Allgemeiner Steuersatz
2 7 % Ermäßigter Steuersatz
3 10,7 % Durchschnittssatz nach § 24 Abs. 1 Nr. 3 UStG (Land- und Forstwirtschaft)
4 5,5 % Durchschnittssatz nach § 24 Abs. 1 Nr. 1/2 UStG
5 0 % Nullsatz
6 (Sondersatz) Besonderer Steuersatz (ein Satz über 0 % und unter 5 %)
7 Keine Umsatzsteuer (durchlaufender Posten, z. B. Trinkgeld für das Personal)

Durchschnittssätze der Land- und Forstwirtschaft (§ 24 UStG)

Die pauschalen Durchschnittssätze 10,7 % und 5,5 % erhalten eigene Schlüssel (3 und 4) und werden nicht mit dem ermäßigten Satz (7 %) vermischt. Diese Zuordnung ist im Kassensystem an einer zentralen Stelle festgelegt und stimmt zwischen der TSE-Signatur und dem DSFinV-K-Export überein.

Zeitweilige Steuersatz-Absenkungen

Absenkungen wie 16 % bzw. 5 % (z. B. während befristeter gesetzlicher Maßnahmen) werden automatisch dem allgemeinen (Schlüssel 1) bzw. ermäßigten Satz (Schlüssel 2) zugeordnet.


7. Storno und Korrektur (Append-only)

DiKAS folgt konsequent dem Grundsatz der Unveränderbarkeit (§ 146a AO, GoBD): Ein einmal erfasster Beleg wird niemals überschrieben oder gelöscht.

Wird ein Beleg storniert, geschieht Folgendes:

  1. Es wird ein neuer Gegenbeleg vom Typ Storno erzeugt — mit negativen Beträgen und einer eigenen, fortlaufenden Belegnummer aus demselben Nummernkreis.
  2. Dieser Gegenbeleg wird von der TSE signiert (als Kassenbeleg-V1 mit negativen Werten).
  3. Er verweist über eine Referenz auf den ursprünglichen Beleg (im Export: references.csv, Referenztyp „Transaktion").
  4. Der ursprüngliche Beleg bleibt inhaltlich unverändert und wird lediglich als „storniert" gekennzeichnet.

Dadurch ist jede Stornierung lückenlos und manipulationssicher nachvollziehbar. Ein bereits stornierter Beleg kann nicht erneut storniert werden, und ein Storno-Beleg selbst kann nicht storniert werden.

Storno vs. Retoure

  • Ein Storno (Void) korrigiert immer einen konkreten Beleg und wird im Export als Storno (BON_STORNO = 1) mit Referenz ausgewiesen.
  • Eine Retoure/Gutschrift (Return) gilt nur dann als formaler Storno, wenn sie sich auf einen konkreten Ursprungsbeleg bezieht; eine bezuglose Retoure ist ein eigenständiger negativer Beleg.

8. Belegnummernkreis (ein durchgehender Kreis)

DiKAS vergibt Belegnummern über einen einzigen, fortlaufenden und lückenlosen Zähler. Dieser wird zentral geführt und ist gegen Doppelvergabe abgesichert (Sperre plus Wiederholung bei gleichzeitigem Zugriff).

  • Kassenbelege und Online-Bestellungen ziehen ihre Nummer aus demselben Nummernkreis. Es gibt keinen getrennten „Online-Zähler" mehr — jede Belegnummer je Kasse ist eindeutig und fortlaufend (§ 146a-Anforderung an Vollständigkeit und Eindeutigkeit).
  • Auf dem Bon erscheint die Belegnummer als R + sechsstellige Nummer, z. B. R000123. Schichten und Tagesabschlüsse tragen analog E… bzw. Z….
  • Wird eine Kasse in einem Verbund zum TSE-Host (beim Start oder bei einem Wechsel), hebt DiKAS den Zähler automatisch auf das aktuelle Gesamtmaximum aller vorhandenen Belege an. So bleibt die Nummernfolge auch nach einem Wechsel lückenlos und ohne Kollision.

Prüfhinweis

Eine fortlaufende, lückenlose Belegnummernfolge ist ein Kernindiz der Vollständigkeit. Fehlende Nummern müssen sich durch dokumentierte Stornos oder TSE-Ausfälle erklären lassen.


9. TSE-Ausfall und Wiederanlauf

Fällt die TSE aus (z. B. USB-Gerät nicht erreichbar, Zertifikat abgelaufen, Netzwerkproblem bei der Cloud-TSE), darf der Kassenbetrieb nach den GoBD nicht blockiert werden. DiKAS geht daher folgendermaßen vor:

  1. Der Kassenvorgang wird weiterhin ausgeführt und gespeichert, jedoch mit gesetztem Fehlerkennzeichen (der Grund wird am Beleg vermerkt).
  2. Ein Ausfallprotokoll (TseOutageLog) wird angelegt bzw. fortgeschrieben: mit Beginn, Grund und der Anzahl betroffener Vorgänge. Ein einzelner Ausfall wird zu einem Protokolleintrag zusammengefasst.
  3. Auf dem betroffenen Bon wird deutlich sichtbar *** TSE-AUSFALL *** samt Fehlergrund gedruckt (bzw. *** KEINE TSE ***, falls gar keine TSE aktiv ist).
  4. Sobald die TSE wieder erreichbar ist (DiKAS prüft dies regelmäßig), wird das offene Ausfallprotokoll mit einem Endzeitpunkt geschlossen und die Signierung automatisch fortgesetzt.

Signaturzähler-Lücken müssen erklärbar sein

Der von der TSE vergebene Signaturzähler steigt monoton. Lücken im Zähler sind ein normales Ausfall-Indiz — sie müssen sich durch einen passenden Eintrag im Ausfallprotokoll erklären lassen. DiKAS deaktiviert eine ausgefallene TSE nicht stillschweigend, sondern führt den Betrieb sichtbar „ohne TSE-Sicherung" fort, bis das Gerät wieder verfügbar ist.


10. Beleg-Pflichtangaben

Jeder gedruckte Kassenbon enthält die nach § 146a AO und § 14 UStG erforderlichen Angaben:

  • Firmenkopf: Firmenname, Anschrift und Steuernummer bzw. USt-IdNr. des Betriebs (aus den hinterlegten Stammdaten).
  • Belegnummer (R…) sowie Datum und Uhrzeit.
  • Bediener und ggf. Tisch.
  • Einzelpositionen (Bezeichnung, Menge, Betrag).
  • USt-Aufschlüsselung je Steuersatz mit Netto, USt-Betrag und Brutto (§ 14 UStG).
  • Zahlart(en), ggf. Rückgeld und Trinkgeld.
  • TSE-Block: QR-Code, TSE-Transaktionsnummer, Signaturzähler, TSE-Seriennummer sowie — falls nicht signiert werden konnte — der Hinweis TSE-AUSFALL.

Steuernummer und USt-IdNr.

DiKAS führt in den Stammdaten die USt-IdNr. des Betriebs. Ist beim Kunden keine separate Steuernummer hinterlegt, bleibt das entsprechende Feld im Export leer — das ist zulässig, sofern eine der beiden Kennungen vorhanden ist.


11. Datenexport für die Betriebsprüfung

DiKAS stellt drei Exporte bereit. Alle werden im Kassensystem angestoßen und als ZIP-Archiv zum Download bereitgestellt.

11.1 DSFinV-K-Export (Kassendaten)

Der DSFinV-K-Export ist das maßgebliche Format für die Betriebsprüfung. DiKAS erzeugt einen vollständigen DSFinV-K-Datensatz Version 2.3 mit:

  • index.xml (Beschreibung aller Tabellen und Spalten) und der zugehörigen DTD,
  • 20 CSV-Tabellen (siehe unten),
  • Komma als Dezimaltrennzeichen, Semikolon als Spaltentrenner, Anführungszeichen als Text-Umschließer, UTF-8 ohne BOM — konform zur DSFinV-K und damit einlesbar in gängige Prüfsoftware (z. B. IDEA).

Die 20 Tabellen im Überblick:

Bereich Datei Inhalt
Stammdaten cashpointclosing.csv Kassenabschluss (Kopf, Summen Zahlungen/Barzahlungen)
location.csv Standort/Betriebsstätte
cashregister.csv Kasse (Marke, Modell, Seriennummer, Software-Version, Basiswährung)
slaves.csv Angeschlossene Terminals
pa.csv Agenturen (in DiKAS leer, da nicht genutzt)
tse.csv TSE-Stammdaten (Seriennummer, Signaturalgorithmus, Zeitformat, öffentlicher Schlüssel)
vat.csv Verwendete USt-Schlüssel und -Sätze
Kassenabschluss businesscases.csv Geschäftsvorfälle je Steuersatz (Umsatz, Trinkgeld)
payment.csv Zahlarten je Abschluss
cash_per_currency.csv Barbestand je Währung (DiKAS: EUR)
Einzelbelege transactions.csv Bonkopf (Belegnummer, Typ, Storno-Kennzeichen, Zeiten, Bediener, Brutto, Kunde)
datapayment.csv Zahlungen je Beleg
lines.csv Belegpositionen (Artikel, Menge, Preis, Trinkgeld)
itemamounts.csv Preisfindung je Position (Basispreis, Rabatt/Zuschlag)
subitems.csv Zusatzinformationen je Position (z. B. Extras/Beilagen)
transactions_tse.csv TSE-Daten je Beleg (Transaktionsnr., Start/Ende, Vorgangsart, Signaturzähler, Signatur, Fehler, Vorgangsdaten)
transactions_vat.csv USt-Aufschlüsselung je Beleg
lines_vat.csv USt-Aufschlüsselung je Position
allocation_groups.csv Abrechnungskreis (z. B. Tischnummer)
references.csv Referenzen (z. B. Storno → Ursprungsbeleg)

Der Export erfolgt zeitraumbezogen (Von-/Bis-Datum). Die Steuernummer bzw. USt-IdNr. der Kasse muss konfiguriert sein — andernfalls verweigert DiKAS den Export mit einer entsprechenden Meldung.

Trinkgeld im Export

Trinkgeld für das Personal wird als eigener Geschäftsvorfall TrinkgeldAN unter USt-Schlüssel 7 („keine Umsatzsteuer") geführt. So bleibt die Summe der Belege mit den Zahlungssummen des Kassenabschlusses abstimmbar, ohne dass Trinkgeld als steuerbarer Umsatz erscheint.

11.2 TSE-TAR-Export (Rohdaten der TSE)

DiKAS exportiert die originalen Protokolldaten der TSE als TAR-Archiv (gemäß BSI TR-03153). Dieses Archiv enthält die von der TSE selbst gesicherten Transaktions- und Signaturdaten und kann mit den Prüfwerkzeugen der Finanzverwaltung unabhängig validiert werden.

  • Vollexport aller gespeicherten Transaktionen oder
  • gefilterter Export nach Zeitraum. (Bei älteren TSE-Firmwares, die keinen gefilterten Export mehr unterstützen, liefert DiKAS automatisch den vollständigen Export — eine gültige Obermenge des angefragten Zeitraums.)

11.3 GDPdU-Export (klassische Betriebsprüfung)

Zusätzlich steht ein GDPdU-Export bereit — ein maschinen- und menschenlesbarer CSV-Datensatz mit index.xml/DTD und vier Tabellen:

Datei Inhalt
Kassenbuch.csv Tagesabschlüsse (Nr., Tag, erste/letzte Belegnummer, Gesamtumsatz, Mitarbeiter)
BonKopf.csv Belegköpfe (Bon-Nr., Datum/Uhrzeit, Tisch, Zahlart, Umsatz, Mitarbeiter, Z-Bon)
BonPos.csv Belegpositionen (Artikel, Menge, Einzelpreis, Brutto, MwSt-Satz, MwSt)
Stornos.csv Stornobuchungen mit Grund

12. Tagesabschluss und Kassenschnitt

Der Tagesabschluss (Z-Bericht) fasst den Geschäftstag zusammen und wird als AVKassenschnitt von der TSE signiert. Vorgelagert werden Schichten mit AVSichOpen (Eröffnung) und AVSichClose (Schließung/Kassensturz) signiert.

Der Tagesabschluss enthält u. a.:

  • Umsätze brutto/netto/USt sowie die Aufschlüsselung je Steuersatz,
  • Zahlarten-Summen (Bar, Karte, Sonstige) und Trinkgeld,
  • erste und letzte Belegnummer des Abschlusses,
  • den Bar-Kassenbestand (siehe unten) und die Zähldifferenz.

Stornierte Belege werden herausgerechnet (Storno-Netting)

In die Tages- und Schichtsummen fließen nur nicht stornierte Belege ein. Ein stornierter Ursprungsbeleg und sein negativer Gegenbeleg werden nicht zusätzlich mitgezählt — andernfalls würden Umsatz, Steuer und Kassenbestand doppelt aufgebläht. So stimmt der ausgewiesene Umsatz mit den tatsächlichen Zahlungen überein (§ 146 AO, Kassensturzfähigkeit).

Fortlaufender Bar-Kassenbestand

DiKAS führt den Bar-Bestand als lückenlose Kette:

  • Der Anfangsbestand eines Tages ist der Endbestand des vorangegangenen Tagesabschlusses (Fallback: der eingegebene Startbestand der ersten Schicht).
  • Der Endbestand ergibt sich aus Anfangsbestand + Barumsätze + Bareinlagen − Barauszahlungen − Geldtransit (z. B. Abschöpfung zur Bank).
  • Die Zähldifferenz (gezählter Ist-Bestand gegenüber rechnerischem Soll) wird je Schicht erfasst und zur Tages-Differenz summiert.

Bar-Ein-/Auszahlungen sind ebenfalls TSE-signiert

Bareinlagen, Barauszahlungen und Geldtransit werden als SonstigerVorgang (AVSonstEinlage / AVSonstAusgabe / AVTransfer) von der TSE signiert und wirken sich auf den geführten Bar-Kassenbestand aus.


13. Aufbewahrung

Alle steuerlich relevanten Daten — Belege, Tagesabschlüsse, TSE-Signaturen und Protokolle — werden von DiKAS dauerhaft und unveränderbar gespeichert. Für die Aufbewahrung gelten die gesetzlichen Fristen (regelmäßig zehn Jahre nach § 147 AO). Der Betreiber ist verpflichtet, die Daten (bzw. die Export-Archive und die TSE) über die gesamte Aufbewahrungsfrist verfügbar und lesbar zu halten — auch nach einem Austausch der TSE oder der Hardware.


14. So läuft eine Kassennachschau mit DiKAS ab

Die folgende Anleitung beschreibt einen typischen Ablauf einer Kassen-Nachschau (§ 146b AO) oder Betriebsprüfung mit einer DiKAS-Kasse.

Schritt 1 — Belegprüfung am Bon (ohne Systemzugang)

Lassen Sie sich einen aktuellen Kassenbon geben oder einen Testbeleg erstellen.

  1. Prüfen Sie die Pflichtangaben (Firmenkopf, Belegnummer R…, Datum/Uhrzeit, USt-Aufschlüsselung).
  2. Scannen Sie den QR-Code. Er enthält ProcessType, Vorgangsdaten, Transaktionsnummer, Signaturzähler, Zeitstempel und Signatur.
  3. Prüfen Sie die Signatur mit einer Beleg-Prüf-App. Fehlt der QR-Code oder trägt der Bon den Vermerk TSE-AUSFALL, klären Sie den dokumentierten Ausfall (Abschnitt 9).

Schritt 2 — TSE- und Kassen-Identität feststellen

Öffnen Sie im System Einstellungen → TSE:

  • Notieren Sie TSE-Seriennummer und Kassen-Seriennummer und gleichen Sie sie mit den beim Finanzamt gemeldeten Angaben ab (§ 146a Abs. 4 AO).
  • Prüfen Sie den Signaturalgorithmus und den Status der TSE (Zertifikatslaufzeit, verbleibende Signaturen).

Schritt 3 — Datenexport ziehen

Stoßen Sie im System den Export für den Prüfungszeitraum an:

  • DSFinV-K-Export (Einstellungen → Export → DSFinV-K): Von-/Bis-Datum wählen, ZIP herunterladen.
  • TSE-TAR-Export (Einstellungen → TSE → Export): Rohdaten der TSE.
  • Bei Bedarf zusätzlich den GDPdU-Export.

Schritt 4 — Daten in der Prüfsoftware auswerten

  1. Lesen Sie den DSFinV-K-Datensatz in Ihre Prüfsoftware (z. B. IDEA) ein — die index.xml beschreibt alle Spalten.
  2. Prüfen Sie die Vollständigkeit der Belegnummern (transactions.csv) — die Folge muss lückenlos sein; Lücken müssen durch Stornos (references.csv) oder Ausfälle erklärbar sein.
  3. Prüfen Sie die Signaturzähler (transactions_tse.csv) auf Monotonie.
  4. Stimmen Sie die Umsätze je Steuersatz (transactions_vat.csv) mit den Kassenabschlüssen (businesscases.csv) ab.
  5. Validieren Sie die TSE-Rohdaten aus dem TAR-Export unabhängig mit den Werkzeugen der Finanzverwaltung.

Schritt 5 — Kassensturz / Bar-Abgleich

Gleichen Sie den gezählten Bar-Bestand mit dem im letzten Tagesabschluss ausgewiesenen rechnerischen Soll-Bestand ab. DiKAS weist die Zähldifferenz je Schicht und je Tag aus (Abschnitt 12).


15. Checkliste für die Kassenprüfung

  • TSE-Seriennummer und Kassen-Seriennummer stimmen mit den beim Finanzamt gemeldeten Angaben überein
  • TSE-Zertifikat war im gesamten Prüfungszeitraum gültig
  • Kassenbons enthalten alle Pflichtangaben inkl. QR-Code (§ 146a, § 14 UStG)
  • QR-Code-Signaturen sind gültig (Stichprobe mit Prüf-App)
  • Belegnummernfolge ist lückenlos; Lücken sind durch Stornos/Ausfälle erklärbar
  • Signaturzähler steigt monoton; Lücken sind im Ausfallprotokoll dokumentiert
  • Stornos sind als signierte Gegenbelege mit Referenz vorhanden (nicht gelöscht)
  • Alle kassenrelevanten Vorgänge sind signiert (auch Schichten, Tagesabschluss, Bar-Bewegungen)
  • DSFinV-K-Export (v2.3) ist vollständig und in der Prüfsoftware einlesbar
  • Umsätze je Steuersatz stimmen mit den Kassenabschlüssen überein
  • Bar-Kassenbestand ist lückenlos geführt; Zähldifferenzen sind ausgewiesen
  • TSE-Ausfallzeiten sind dokumentiert und nachvollziehbar

16. Technische Eckdaten (Zusammenfassung)

Eigenschaft Wert
Unterstützte TSE Swissbit-Hardware-TSE (USB) · fiskaly-Cloud-TSE · TSE-Verbund (Netzwerk)
Signaturverfahren ECDSA mit SHA-256 (ecdsa-plain-SHA256, je nach TSE)
ProcessTypes Kassenbeleg-V1, Bestellung-V1, SonstigerVorgang
QR-Code DSFinV-K Anhang I, Version V0 (12 Felder)
USt-Schlüssel 1=19 %, 2=7 %, 3=10,7 %, 4=5,5 %, 5=0 %, 6=Sondersatz, 7=keine USt
Belegnummern Ein fortlaufender, lückenloser Nummernkreis (Format R000000)
DSFinV-K-Export Version 2.3, 20 CSV-Tabellen + index.xml, UTF-8 ohne BOM, Dezimalkomma
Weitere Exporte TSE-TAR (BSI TR-03153), GDPdU
Unveränderbarkeit Append-only; Stornos als signierte Gegenbelege; keine Löschung
Ausfallverhalten Nicht blockierend, automatische Protokollierung, sichtbare Beleg-Kennzeichnung
Aufbewahrung Gemäß § 147 AO (regelmäßig 10 Jahre)