TSE Compliance — Documentation for Tax Auditors¶

This document is intended for tax auditors, fiscal authorities, and tax advisors and describes how the DiKAS POS system technically implements the legal requirements for proper cash register record-keeping.

In Brief

Every fiscally relevant transaction is digitally signed by a certified Technical Security Device (TSE) (§ 146a AO, KassenSichV).
DiKAS supports a Swissbit hardware TSE (USB, on-site) and the fiskaly cloud TSE.
All receipts run in a single, continuous receipt number sequence (POS and online orders combined).
Voids are never deleted — they are recorded as a signed counter-receipt.
For the audit, DiKAS provides the DSFinV-K export, the TSE TAR export, and a GDPdU export.
The chapter "How a Cash Register Inspection (Kassennachschau) Works with DiKAS" describes the audit process step by step.

Note on the Purpose of This Document

This document describes exclusively the functions implemented in the POS system. Business-specific details such as the serial number of your TSE, the POS serial number, or the data reported to the tax office are specific to your business and can be found in your DiKAS installation under Settings → TSE or in your registration records — not in this general document.

1. Legal Framework¶

DiKAS is designed to meet the following regulations:

Regulation	Content
§ 146a AO	Proper cash register record-keeping, obligation to use a certified TSE, obligation to issue receipts
KassenSichV	Cash Register Anti-Tampering Ordinance — technical requirements for the TSE
AEAO on § 146a AO	Application decree with detailed specifications for ProcessTypes, ProcessData, and the QR code
DSFinV-K	Digital interface of the fiscal administration for POS systems (DiKAS generates version 2.3)
BSI TR-03153	Technical guideline for the TSE (signature, export, certification)
GoBD / GDPdU	Principles for the proper keeping and retention of books, records, and documents (digital tax audit)
§ 14 UStG	Mandatory information on invoices/receipts (VAT breakdown)

Reporting Obligation Lies with the POS Operator

Reporting the POS system and TSE in use to the tax office (§ 146a para. 4 AO, since 2025 via Mein ELSTER) is an obligation of the operator. DiKAS provides the necessary information (TSE serial number, POS serial number, purchase date) within the system, but does not automatically submit the report to the tax office.

2. The TSE in DiKAS¶

A Technical Security Device (TSE) is a certified security module. It provides every POS transaction with a digital signature and a continuous signature counter. This makes it possible to determine beyond doubt, at a later date, whether POS data has been altered after the fact.

DiKAS can be operated with different TSE variants:

Variant	Description
Swissbit hardware TSE	BSI-certified hardware TSE, connected directly to the POS via USB. Signs and stores data on-site. Detected automatically by DiKAS (mounted under `/mnt/tse/`).
fiskaly cloud TSE	Certified cloud TSE (fiskaly SIGN DE). DiKAS signs receipts via the fiskaly interface over the internet. No USB device required.
TSE network (pool)	Several POS terminals of a business can share one TSE: one POS acts as the TSE host, and the other POS terminals sign through it over the local network.

Which TSE Is Active for You

DiKAS automatically selects the available TSE (order: fiskaly cloud → network TSE → local Swissbit hardware). The TSE actually used can be identified on every receipt from the QR code and the printed TSE serial number, and can also be viewed in the system under Settings → TSE.

Demo and Test Systems

Pure demo/test installations of DiKAS deliberately run without a TSE. In this operating mode, no receipt is signed; such receipts are clearly marked as not fiscalized (see Section 9). For tax-relevant live operation, a real TSE is always active.

3. Which Transactions Are Signed¶

In accordance with the AEAO on § 146a AO, DiKAS signs all fiscally relevant transactions — not just sales receipts. It uses the three transaction types (ProcessTypes) defined in the DSFinV-K:

ProcessType	Used for
`Kassenbeleg-V1`	Every completed payment transaction: direct sale, table payment, void, and return/credit (with negative amounts)
`Bestellung-V1`	Orders in table service (order ticket before payment)
`SonstigerVorgang`	Shift opening, shift closing, end-of-day report, cash deposits/withdrawals, and cash transfers

Within SonstigerVorgang, DiKAS additionally tags the specific transaction with its own code:

Code	Transaction
`AVSichOpen`	Shift opening (cash drawer started with float)
`AVSichClose`	Shift closing (cash count at end of shift)
`AVKassenschnitt`	End-of-day report (Z-report)
`AVSonstAusgabe`	Cash withdrawal / expense / owner's drawing
`AVSonstEinlage`	Cash deposit / owner's contribution
`AVTransfer`	Cash transfer (e.g. moving cash from the cash register to the bank)

Important for the Audit

In DiKAS, a void is not a SonstigerVorgang — it is a full, TSE-signed Kassenbeleg-V1 with negative amounts (see Section 7). This means every void is recorded in a tamper-proof way, exactly like the original sale.

4. How a Receipt Is Fiscally Created¶

For every payment transaction, DiKAS passes the tax-relevant receipt data to the TSE. The TSE signs this data and returns a unique transaction number, a signature counter, and the cryptographic signature. These values are stored inseparably with the receipt and printed on it.

4.1 Signed Transaction Data (ProcessData) — Kassenbeleg-V1¶

For a sales receipt, DiKAS builds the signed transaction data in the following format:

Beleg^<19%>_<7%>_<10,7%>_<5,5%>_<0%>^<Zahlungen>

The tax portion consists of exactly five gross amounts, separated by an underscore _, in a fixed order of tax classes:

Position Tax class

1 19% (standard rate)

2 7% (reduced rate)

3 10.7% (average rate, § 24 UStG)

4 5.5% (average rate, § 24 UStG)

5 0% (zero rate)

Each position holds the gross revenue for that tax class. Unused classes are filled with 0.00.
The payment portion lists each payment as <Amount>:<Bar|Unbar> (Bar = cash, Unbar = non-cash); cash payments come first. The payment amounts add up to the receipt's total amount. Change given and tips are not part of the payment amount.

Example — receipt for €60.00 (of which €47.60 at 19% and €12.40 at 7%), paid in cash:

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

Example — €100.00 at 19%, split into €40.00 cash and €60.00 card:

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

Cash or Non-Cash Is Fixed at the Time of Payment

Whether a payment counts as cash (Bar) or non-cash (Unbar) is derived from the configured payment method at the point of sale and frozen on the receipt. It is never inferred retroactively from the payment method's name — the same classification applies consistently to both the TSE signature and the DSFinV-K export.

4.2 Signed Transaction Data (ProcessData) — Bestellung-V1¶

Orders in table service (the order ticket before payment) are signed per line item as follows:

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

(<Quantity>;"<Description>";<Gross unit price>)

Individual line items are separated by a line break; the description is enclosed in quotation marks (quotation marks contained within it are doubled). Example:

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

4.3 Signed Transaction Data (ProcessData) — SonstigerVorgang¶

Other transactions are signed in the format <Vorgang>^<Daten> (<Transaction>^<Data>), e.g.:

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

Number Format

In the signed transaction data and the QR code, amounts are shown with a period as the decimal separator and two decimal places (60.00). The DSFinV-K CSV export, by contrast, uses a comma (60,00) — both conform to their respective specification.

5. The QR Code on the Receipt¶

Every receipt contains a QR code with the TSE data in the format specified by the DSFinV-K (Appendix I, "Receipt Verification"). This allows any receipt to be verified against the TSE signature using a common verification app (e.g. the official receipt/fiscal verification app).

The QR code contains the following twelve fields, separated by semicolons:

Pos.	Field	Meaning
1	Version	Always `V0`
2	POS serial number	Unique identifier of the POS
3	ProcessType	e.g. `Kassenbeleg-V1`
4	ProcessData	The signed transaction data (see Section 4)
5	Transaction number	Sequential number of the TSE transaction
6	Signature counter	Monotonically increasing TSE counter
7	Start time	Start of signing
8	End time	End of signing
9	Signature algorithm	e.g. `ecdsa-plain-SHA256`
10	Log time format	Time format used by the TSE
11	Signature	The cryptographic signature
12	Public key	The TSE's verification key

Verification Without POS Access

By simply scanning the QR code on a paper receipt, you can read out the ProcessType, transaction data, transaction number, signature counter, and timestamps, and verify the signature mathematically — even without access to the POS system.

6. Tax Rates and VAT Keys¶

In the DSFinV-K export, DiKAS assigns every sale to a VAT key. Only the following keys are used:

VAT key	Tax rate	Meaning
1	19%	Standard tax rate
2	7%	Reduced tax rate
3	10.7%	Average rate under § 24 para. 1 no. 3 UStG (agriculture and forestry)
4	5.5%	Average rate under § 24 para. 1 no. 1/2 UStG
5	0%	Zero rate
6	(special rate)	Special tax rate (a rate above 0% and below 5%)
7	—	No VAT (pass-through item, e.g. tips for staff)

Average Rates for Agriculture and Forestry (§ 24 UStG)

The flat-rate average rates 10.7% and 5.5% have their own keys (3 and 4) and are not mixed with the reduced rate (7%). This mapping is defined at one central place in the POS system and is consistent between the TSE signature and the DSFinV-K export.

Temporary Tax Rate Reductions

Reductions such as 16% or 5% (e.g. during time-limited legal measures) are automatically mapped to the standard rate (key 1) or the reduced rate (key 2) respectively.

7. Void and Correction (Append-Only)¶

DiKAS consistently follows the principle of immutability (§ 146a AO, GoBD): once recorded, a receipt is never overwritten or deleted.

When a receipt is voided, the following happens:

A new counter-receipt of type Void is created — with negative amounts and its own, sequential receipt number from the same number sequence.
This counter-receipt is signed by the TSE (as a Kassenbeleg-V1 with negative values).
It references the original receipt via a reference (in the export: references.csv, reference type "transaction").
The original receipt remains unchanged in content and is merely marked as "voided."

This makes every void traceable, gap-free, and tamper-proof. A receipt that has already been voided cannot be voided again, and a void receipt itself cannot be voided.

Void vs. Return

A void always corrects a specific receipt and is shown in the export as a void (BON_STORNO = 1) with a reference.
A return/credit only counts as a formal void if it refers to a specific original receipt; a return without such a reference is a stand-alone negative receipt.

8. Receipt Number Sequence (One Continuous Sequence)¶

DiKAS assigns receipt numbers using a single, continuous, and gap-free counter. This counter is managed centrally and is protected against duplicate assignment (locking plus retry on concurrent access).

POS receipts and online orders draw their number from the same number sequence. There is no longer a separate "online counter" — every receipt number per POS is unique and sequential (§ 146a requirement for completeness and uniqueness).
On the receipt, the receipt number appears as R + a six-digit number, e.g. R000123. Shifts and end-of-day reports are numbered analogously with E… and Z….
When a POS becomes the TSE host in a network pool (at startup or on a switch), DiKAS automatically advances the counter to the current overall maximum of all existing receipts. This keeps the number sequence gap-free and free of collisions, even after a switch.

Audit Tip

A continuous, gap-free receipt number sequence is a key indicator of completeness. Any missing numbers must be explainable by documented voids or TSE outages.

9. TSE Outage and Recovery¶

If the TSE fails (e.g. USB device unreachable, certificate expired, network problem with the cloud TSE), POS operations must not be blocked, per the GoBD. DiKAS therefore proceeds as follows:

The POS transaction continues to be processed and saved, but with an error flag set (the reason is noted on the receipt).
An outage log (TseOutageLog) is created or updated: with start time, reason, and the number of affected transactions. A single outage is consolidated into one log entry.
The affected receipt clearly prints *** TSE-AUSFALL *** ("TSE OUTAGE") along with the reason for the error (or *** KEINE TSE *** / "NO TSE" if no TSE is active at all).
As soon as the TSE is reachable again (DiKAS checks this regularly), the open outage log entry is closed with an end time and signing resumes automatically.

Gaps in the Signature Counter Must Be Explainable

The signature counter assigned by the TSE increases monotonically. Gaps in the counter are a normal indicator of an outage — they must be explainable by a matching entry in the outage log. DiKAS does not silently disable a failed TSE; instead, it visibly continues operating "without TSE protection" until the device becomes available again.

10. Mandatory Receipt Information¶

Every printed receipt contains the information required under § 146a AO and § 14 UStG:

Company header: business name, address, and tax number or VAT ID (from the stored master data).
Receipt number (R…) plus date and time.
Operator/server and, where applicable, table.
Individual line items (description, quantity, amount).
VAT breakdown by tax rate, showing net, VAT amount, and gross (§ 14 UStG).
Payment method(s), plus change given and tip, where applicable.
TSE block: QR code, TSE transaction number, signature counter, TSE serial number, and — if signing was not possible — the notice TSE-AUSFALL (TSE outage).

Tax Number and VAT ID

DiKAS holds the business's VAT ID in the master data. If no separate tax number is stored for the business, the corresponding field remains blank in the export — this is permitted, provided at least one of the two identifiers is present.

11. Data Export for the Tax Audit¶

DiKAS provides three exports. All are triggered within the POS system and made available for download as a ZIP archive.

11.1 DSFinV-K Export (POS Data)¶

The DSFinV-K export is the authoritative format for the tax audit. DiKAS generates a complete DSFinV-K data set, version 2.3, containing:

an index.xml file (description of all tables and columns) and the associated DTD,
20 CSV tables (see below),
comma as the decimal separator, semicolon as the column separator, quotation marks as the text delimiter, UTF-8 without BOM — compliant with the DSFinV-K and therefore readable by common audit software (e.g. IDEA).

Overview of the 20 tables:

Area	File	Content
Master data	`cashpointclosing.csv`	Cash point closing (header, payment/cash totals)
	`location.csv`	Location/business premises
	`cashregister.csv`	POS (brand, model, serial number, software version, base currency)
	`slaves.csv`	Connected terminals
	`pa.csv`	Agencies (empty in DiKAS, as this is not used)
	`tse.csv`	TSE master data (serial number, signature algorithm, time format, public key)
	`vat.csv`	VAT keys and rates used
Cash point closing	`businesscases.csv`	Business cases per tax rate (revenue, tips)
	`payment.csv`	Payment methods per closing
	`cash_per_currency.csv`	Cash balance per currency (DiKAS: EUR)
Individual receipts	`transactions.csv`	Receipt header (receipt number, type, void flag, times, operator, gross amount, customer)
	`datapayment.csv`	Payments per receipt
	`lines.csv`	Receipt line items (article, quantity, price, tip)
	`itemamounts.csv`	Pricing per line item (base price, discount/surcharge)
	`subitems.csv`	Additional information per line item (e.g. extras/sides)
	`transactions_tse.csv`	TSE data per receipt (transaction no., start/end, transaction type, signature counter, signature, error, transaction data)
	`transactions_vat.csv`	VAT breakdown per receipt
	`lines_vat.csv`	VAT breakdown per line item
	`allocation_groups.csv`	Billing group (e.g. table number)
	`references.csv`	References (e.g. void → original receipt)

The export covers a specific period (start/end date). The POS's tax number or VAT ID must be configured — otherwise DiKAS refuses the export with a corresponding message.

Tips in the Export

Tips for staff are recorded as a separate business case, TrinkgeldAN, under VAT key 7 ("no VAT"). This keeps the sum of receipts reconcilable with the payment totals of the cash point closing, without the tip appearing as taxable revenue.

11.2 TSE TAR Export (Raw TSE Data)¶

DiKAS exports the original log data of the TSE as a TAR archive (per BSI TR-03153). This archive contains the transaction and signature data secured by the TSE itself and can be validated independently using the tax administration's audit tools.

A full export of all stored transactions, or
a filtered export by period. (For older TSE firmware versions that no longer support a filtered export, DiKAS automatically delivers the complete export — a valid superset of the requested period.)

11.3 GDPdU Export (Classic Tax Audit)¶

DiKAS also provides a GDPdU export — a machine- and human-readable CSV data set with index.xml/DTD and four tables:

File	Content
`Kassenbuch.csv`	End-of-day reports (no., day, first/last receipt number, total revenue, employee)
`BonKopf.csv`	Receipt headers (receipt no., date/time, table, payment method, revenue, employee, Z-report)
`BonPos.csv`	Receipt line items (article, quantity, unit price, gross, VAT rate, VAT)
`Stornos.csv`	Voided transactions with reason

12. End-of-Day Report and Cash Count¶

The end-of-day report (Z-report) summarizes the business day and is signed by the TSE as AVKassenschnitt. Ahead of it, shifts are signed with AVSichOpen (opening) and AVSichClose (closing/cash count).

The end-of-day report includes, among other things:

Revenue gross/net/VAT, plus the breakdown by tax rate,
payment method totals (cash, card, other) and tips,
the first and last receipt number of the closing,
the cash balance (see below) and the counting variance.

Voided Receipts Are Netted Out (Void Netting)

Only non-voided receipts flow into the daily and shift totals. A voided original receipt and its negative counter-receipt are not counted again on top — otherwise revenue, tax, and cash balance would be inflated twice over. This keeps the reported revenue consistent with actual payments received (§ 146 AO, ability to reconcile cash on demand).

Continuous Cash Balance¶

DiKAS maintains the cash balance as an unbroken chain:

The opening balance for a day is the closing balance of the previous day's end-of-day report (fallback: the entered starting balance of the first shift).
The closing balance results from the opening balance + cash revenue + cash deposits − cash withdrawals − cash transfers (e.g. skimming cash to the bank).
The counting variance (counted actual balance versus the calculated target) is recorded per shift and summed into the daily variance.

Cash Deposits/Withdrawals Are Also TSE-Signed

Cash deposits, cash withdrawals, and cash transfers are signed by the TSE as SonstigerVorgang (AVSonstEinlage / AVSonstAusgabe / AVTransfer) and affect the recorded cash balance.

13. Retention¶

All tax-relevant data — receipts, end-of-day reports, TSE signatures, and logs — are stored by DiKAS permanently and in an unalterable way. The statutory retention periods apply (typically ten years under § 147 AO). The operator is obliged to keep the data (or the export archives and the TSE) available and readable for the entire retention period — even after the TSE or the hardware has been replaced.

14. How a Cash Register Inspection (Kassennachschau) Works with DiKAS¶

The following guide describes a typical course of an unannounced cash register inspection (Kassennachschau, § 146b AO) or a tax audit with a DiKAS POS.

Step 1 — Receipt Verification (Without System Access)¶

Ask for a current receipt or have a test receipt created.

Check the mandatory information (company header, receipt number R…, date/time, VAT breakdown).
Scan the QR code. It contains the ProcessType, transaction data, transaction number, signature counter, timestamps, and signature.
Verify the signature using a receipt verification app. If the QR code is missing or the receipt bears the note TSE-AUSFALL (TSE outage), clarify the documented outage (Section 9).

Step 2 — Establish TSE and POS Identity¶

Open Settings → TSE in the system:

Note the TSE serial number and POS serial number and compare them with the details reported to the tax office (§ 146a para. 4 AO).
Check the signature algorithm and the TSE's status (certificate validity period, remaining signatures).

Step 3 — Pull the Data Export¶

Trigger the export for the audit period in the system:

DSFinV-K export (Settings → Export → DSFinV-K): select start/end date, download the ZIP.
TSE TAR export (Settings → TSE → Export): raw TSE data.
If needed, also the GDPdU export.

Step 4 — Evaluate the Data in Audit Software¶

Import the DSFinV-K data set into your audit software (e.g. IDEA) — the index.xml describes all columns.
Check the completeness of the receipt numbers (transactions.csv) — the sequence must be gap-free; any gaps must be explainable by voids (references.csv) or outages.
Check the signature counters (transactions_tse.csv) for monotonicity.
Reconcile the revenue by tax rate (transactions_vat.csv) against the end-of-day reports (businesscases.csv).
Independently validate the raw TSE data from the TAR export using the tax administration's tools.

Step 5 — Cash Count / Cash Reconciliation¶

Reconcile the counted cash balance against the calculated target balance shown in the last end-of-day report. DiKAS reports the counting variance per shift and per day (Section 12).

15. Checklist for the Cash Register Audit¶

16. Technical Summary¶

Property	Value
Supported TSE	Swissbit hardware TSE (USB) · fiskaly cloud TSE · TSE network (pool)
Signature method	ECDSA with SHA-256 (`ecdsa-plain-SHA256`, depending on the TSE)
ProcessTypes	`Kassenbeleg-V1`, `Bestellung-V1`, `SonstigerVorgang`
QR code	DSFinV-K Appendix I, version `V0` (12 fields)
VAT keys	1=19%, 2=7%, 3=10.7%, 4=5.5%, 5=0%, 6=special rate, 7=no VAT
Receipt numbers	One continuous, gap-free number sequence (format `R000000`)
DSFinV-K export	Version 2.3, 20 CSV tables + `index.xml`, UTF-8 without BOM, decimal comma
Additional exports	TSE TAR (BSI TR-03153), GDPdU
Immutability	Append-only; voids as signed counter-receipts; no deletion
Outage behavior	Non-blocking, automatic logging, visible receipt marking
Retention	Per § 147 AO (typically 10 years)

Position	Tax class
1	19% (standard rate)
2	7% (reduced rate)
3	10.7% (average rate, § 24 UStG)
4	5.5% (average rate, § 24 UStG)
5	0% (zero rate)