Skip to content
v26.3

TSE Compliance — Documentation for Tax Auditors

This document is intended for tax auditors, fiscal authorities, and tax advisors and describes the technical implementation of the TSE integration in the DiKAS POS system in accordance with the applicable legal requirements.

DiKAS meets the requirements of the following regulations:

Regulation Content
§ 146a AO Proper cash management, obligation to use a TSE
KassenSichV Cash Register Anti-Tampering Ordinance — technical requirements for the TSE
AEAO on § 146a AO Application decree with detailed specifications for ProcessTypes, ProcessData, QR code
DSFinV-K Digital interface of the fiscal administration for POS systems
GDPdU / GoBD Principles for the proper keeping and retention of books (digital tax audit)

2. Signed Process Types (ProcessTypes)

DiKAS signs all fiscally relevant transactions in accordance with the AEAO on § 146a AO — not just receipts. Three ProcessTypes are used as defined by DSFinV-K:

2.1 Kassenbeleg-V1

Property Value
ProcessType Kassenbeleg-V1
Triggering transactions Every completed payment (direct sale, table payment, void)
Entities Receipt (DocumentType: Receipt2)

ProcessData format: 

Beleg^{BruttoGesamt}_{MwStSatz1}:{MwStBetrag1}_{MwStSatz2}:{MwStBetrag2}_...

Examples: 

Beleg^119.00_19.00:19.00                          # Ein Steuersatz (19%)
Beleg^50.00_19.00:5.00_7.00:2.00                  # Zwei Steuersätze (19% + 7%)
Beleg^0.00_0.00:0.00                              # Nullbeleg

All amounts are formatted with two decimal places and a dot as the decimal separator (Invariant Culture), compliant with the DSFinV-K specification.

2.2 Bestellung-V1

Property Value
ProcessType Bestellung-V1
Triggering transactions Every order placed in table service
Entities OpenBon (DocumentType: OpenBon)

ProcessData format: 

{Menge}^{Artikeltext}^{BruttoBetrag};{Menge}^{Artikeltext}^{BruttoBetrag};...

Example: 

2.00^Cola^7.00;1.00^Pizza^11.50

For batch orders, the TSE signature is stored on the first receipt of the batch. The ProcessData contains all line items of the entire order.

2.3 SonstigerVorgang

Property Value
ProcessType SonstigerVorgang
Triggering transactions Shift opening, shift closing, end-of-day report, expenses
Entities Exchange, DayClose, Spending

ProcessData format: 

{Vorgangstyp}^{Vorgangsdaten}

Specific transaction types:

Transaction type Description Example ProcessData
AVSichOpen Shift opening AVSichOpen^Schichteroeffnung^200.00
AVSichClose Shift closing AVSichClose^Schichtschliessung^350.00
AVKassenschnitt End-of-day report (Z-report) AVKassenschnitt^Tagesabschluss^1500.00
AVBelegabbruch Void transaction AVBelegabbruch^Storno
AVSons662 Expense/cash withdrawal AVSonstige^Ausgabe^50.00

3. TSE Data Fields on Documents

Every signed document stores the following 9 TSE fields (implemented via the ITseDataHolder interface):

Field Type Description
TseTransactionNumber String Unique transaction number of the TSE
TseSignature String Digital signature (Base64-encoded)
TseStartTime DateTime Start of signing (UTC)
TseEndTime DateTime End of signing (UTC)
TseSignatureCounter UInt64 Monotonically increasing signature counter
TseProcessData String Signed transaction data (see Section 2)
TseProcessType String ProcessType identifier
TseSerialNumber String Serial number of the TSE used
TseError String Error message on signing failure (null on success)

These fields are stored on the following entities:

  • Receipt — Receipts (sale, void, return)
  • OpenBon — Order line items (lead receipt for batch orders)
  • Exchange — Shift openings and closings
  • DayClose — End-of-day reports (Z-reports)
  • Spending — Expenses and cash withdrawals

4. QR Code Format (DSFinV-K Appendix I)

Every receipt contains a QR code with the TSE data in the standardized format according to DSFinV-K Appendix I:

V0;{KassenSeriennummer};{ProcessType};{ProcessData};{TransaktionsNr};{SignaturZähler};{StartZeit};{EndZeit};{SigAlgorithmus};{LogZeitformat};{Signatur};{PublicKey}

Concrete example: 

V0;KASSE-001;Kassenbeleg-V1;Beleg^29.30_19.00:4.68;12345;67890;2026-03-13T18:30:00.000Z;2026-03-13T18:30:01.000Z;ecdsa-plain-SHA256;unixTime;a8f3c2d1e5b7...;PK123...

Position Field Source
1 Version Always V0
2 POS serial number CashPointSerialNumber from BackendConfig
3 ProcessType TseProcessType from the receipt
4 ProcessData TseProcessData from the receipt
5 Transaction number TseTransactionNumber from the receipt
6 Signature counter TseSignatureCounter from the receipt
7 Start time TseStartTime (ISO 8601, UTC)
8 End time TseEndTime (ISO 8601, UTC)
9 Signature algorithm SigAlg from TseConfig (default: ecdsa-plain-SHA256)
10 Log time format LogTimeFormat from TseConfig (default: unixTime)
11 Signature TseSignature from the receipt
12 Public key PublicKey from TseConfig

5. POS Identification (ClientId)

POS identification follows a three-stage fallback chain:

Priority Source Description
1 CashPointSerialNumber Explicitly configured POS serial number (license)
2 BonIdServer Receipt server identifier from BackendConfig
3 "1" Fallback default value

This ClientId is passed as the POS identifier on every TSE signing and appears in the QR code as the POS serial number.

6. TSE Configuration

The TSE configuration is stored in the document configTSE (TseConfig):

Field Description
PublicKey Public key of the TSE
Serial Serial number of the TSE
SigAlg Signature algorithm (default: ecdsa-plain-SHA256)
LogTimeFormat Time format of the TSE logs (default: unixTime)
LocalPath Local path to the hardware TSE
SetupDate Date the TSE was put into operation
DecomissionDate Date the TSE was decommissioned
TSESerialId Internal serial ID

Supported TSE Connections

Type Implementation Description
Hardware (Swissbit) SwissbitTseService Direct USB access to the Swissbit TSE
Proxy (Network) TseProxyService TSE via HTTP proxy (e.g. Fiskaltrust)
Router TseServiceRouter Automatic routing: proxy preferred, fallback to hardware

7. Resilience and Logging

TSE Outage Log (TseOutageLog)

In accordance with the AEAO on § 146a AO, DiKAS automatically documents every TSE outage:

Field Description
StartTime Start of the outage (UTC)
EndTime End of the outage (UTC, null if still ongoing)
Reason Cause (e.g. "TSE not available", "TSE timeout")
AffectedTransactions Number of affected transactions

Process in the event of a TSE outage:

  1. TSE signing fails → the TseError field on the document is set
  2. A new TseOutageLog entry is created (with StartTime and Reason)
  3. The POS transaction is not blocked — the transaction is saved without a signature
  4. On the next successful signing, all open outage entries are closed (EndTime is set)

Timeout: Every TSE signing has a timeout of 5 seconds. If exceeded, TseError = "TSE timeout" is set.

Verification During an Audit

For every document with TseError != null, there is a documented signing error. The associated TseOutageLog entry proves the period and cause of the outage.

8. Data Export for the Tax Audit

8.1 DSFinV-K Export

DiKAS exports all POS data in DSFinV-K format (digital interface of the fiscal administration for POS systems):

  • All required CSV files according to the DSFinV-K specification
  • Period-based export possible
  • Contains: individual records, master data, TSE data, cash cuts

8.2 TSE TAR Export

Direct export of the TSE log data as a TAR archive:

  • Full export: All transactions stored on the TSE
  • Filtered export: By period (startDate/endDate)
  • API endpoint: GET /api/v1/tse/export/tar

8.3 GDPdU Export

For the digital tax audit in accordance with GDPdU/GoBD:

  • Structured export file with all tax-relevant data
  • Machine-readable for audit software (IDEA, AIS, etc.)

8.4 DATEV Export

For ongoing bookkeeping at the tax advisor:

  • 7 export modes (end-of-day report, ProBon, ProÖffnungstag, WGR, WGR2, NachRechnung, expenses)
  • EXTF format v13 with correct BU keys (VAT 3/2/40, input VAT 9/8/40)
  • Optionally encrypted (AES-256 ZIP) and sendable by email

9. Signing Process in Detail

9.1 Flow of a Signing

Kassenvorgang → TseSigningHelper → ITseService → TSE (Hardware/Proxy)
                     │                                    │
                     │  1. BackendConfig laden             │
                     │  2. Prüfen: TSE verfügbar?          │
                     │  3. ProcessData aufbauen             │
                     │  4. ClientId auflösen                │
                     │  5. SignReceiptAsync aufrufen ───────→│
                     │  6. Ergebnis auf Entity speichern ←──│
                     │  7. OutageLog aktualisieren          │
                     └──────────────────────────────────────┘

9.2 Which Handlers Sign?

Handler Transaction ProcessType
ProcessDirectSaleCommand Direct sale Kassenbeleg-V1
ProcessTablePaymentCommand Table payment Kassenbeleg-V1
VoidReceiptCommand Void Kassenbeleg-V1
CreateOpenBonCommand Single order Bestellung-V1
CreateOpenBonsBatchCommand Batch order Bestellung-V1
OpenExchangeCommand Shift opening SonstigerVorgang
CloseExchangeCommand Shift closing SonstigerVorgang
PerformDayCloseCommand End-of-day report SonstigerVorgang
CreateSpendingCommand Expense/cash withdrawal SonstigerVorgang

9.3 Error Handling

TSE signing is implemented as non-blocking:

  • TSE errors are documented in the TseError field, and the transaction is saved anyway
  • A try/catch around the entire signing process prevents TSE problems from disrupting POS operation
  • The HandleOutageLogAsync method updates the outage log after every signing (success or failure)

10. Completeness of Records

Gapless Signing

DiKAS ensures the gapless signing of all fiscally relevant transactions through:

  1. Central signing logic: All signings run through TseSigningHelper — there is no way to complete a fiscally relevant transaction without a TSE call
  2. Monotonic signature counter: The TseSignatureCounter is managed by the TSE and increases monotonically. Gaps in the counter indicate outages that are documented in the TseOutageLog
  3. Transaction numbers: Every TSE transaction receives a unique TseTransactionNumber
  4. Timestamps: The start and end time of every signing are stored

Tamper Protection

  • Signature algorithm: ECDSA with SHA-256 (ecdsa-plain-SHA256)
  • The TSE hardware is BSI-certified (Common Criteria)
  • The public key of the TSE is stored in the TseConfig and can be used to verify signatures
  • Subsequent changes to signed documents are detectable via the cryptographic signature

11. Audit Notes for Tax Auditors

Where Do You Find the TSE Data?

Data source Access
TSE fields on receipts In every Receipt/OpenBon/Exchange/DayClose/Spending document
QR codes On printed receipts
TSE outage log TseOutageLog documents in the database
TSE configuration Document configTSE
DSFinV-K export Admin → Settings → Export → DSFinV-K
TSE TAR export Admin → Settings → TSE → Export
GDPdU export Admin → Settings → Export → GDPdU

How Do You Verify the Signatures?

  1. Scan the QR code: Every receipt contains a QR code in V0 format (DSFinV-K Appendix I)
  2. Export the TSE TAR: The TAR file contains all TSE log data and can be validated with audit tools
  3. Check the signature counter: The monotonically increasing counter must not have any unexplained gaps
  4. Outage log: Gaps in the signature counter must be explained by TseOutageLog entries
  5. Public key: Located in the TseConfig and can be used for the computational verification of individual signatures

Checklist for the POS Audit

  • TSE serial number matches the one reported to the tax office
  • Signature counter is gapless (gaps explainable by outage logs)
  • ProcessTypes comply with the AEAO requirements (Kassenbeleg-V1, Bestellung-V1, SonstigerVorgang)
  • ProcessData formats are DSFinV-K-compliant
  • QR code format complies with DSFinV-K Appendix I (V0 format)
  • Timestamps are plausible (start < end, chronologically ascending)
  • TSE outage times are documented and traceable
  • All fiscally relevant transaction types are signed (not just receipts)
  • DSFinV-K export is complete and machine-readable
  • TSE certificate was valid during the audit period

12. Technical Specifications

Property Value
Signature algorithm ECDSA with SHA-256 (ecdsa-plain-SHA256)
QR code format DSFinV-K Appendix I, Version V0
Time format ISO 8601, UTC (yyyy-MM-ddTHH🇲🇲ss.fffZ)
Amount format Invariant Culture, 2 decimal places (e.g. 119.00)
TSE timeout 5 seconds per signing
Supported TSE Swissbit (USB), network proxy
Outage behavior Non-blocking, automatic logging
Database CouchDB or SQLite/SQL Server (configurable)
API base .NET 10, Clean Architecture, CQRS with MediatR
Test coverage 17 dedicated TSE tests (signing, ProcessData, QR code, fallback)

Appendix: Mapping Transaction Type → Document → Database

POS transaction ProcessType Entity DocumentType Database collection
Direct sale (cash/card) Kassenbeleg-V1 Receipt Receipt2 receipt2
Table payment Kassenbeleg-V1 Receipt Receipt2 receipt2
Void Kassenbeleg-V1 Receipt Receipt2 receipt2
Order (table) Bestellung-V1 OpenBon OpenBon openbon
Batch order Bestellung-V1 OpenBon OpenBon openbon
Shift opening SonstigerVorgang Exchange Exchange2 exchange2
Shift closing SonstigerVorgang Exchange Exchange2 exchange2
End-of-day report (Z-report) SonstigerVorgang DayClose DayClose2 dayclose2
Expense/cash withdrawal SonstigerVorgang Spending CashPointSpending cashpointspending