What the auditor actually pulls from your POS

Most owners never see the DSFinV-K. It is not a receipt, not a report, and you do not submit it anywhere on a schedule. It only appears on one occasion: when someone from the Finanzamt stands at your counter, or sits in your office for a Betriebsprüfung, and asks your register for "the export".

Since 1 July 2022, that export must follow version 2.3 of the standard. The 2022 transition period for old, non-upgradable registers also ends on 31 December this year — so from 2023 there is no such thing as a German electronic register without TSE and DSFinV-K.

What DSFinV-K stands for

Digitale Schnittstelle der Finanzverwaltung für Kassensysteme — the tax administration's digital interface for cash register systems. It defines a single, vendor-neutral data format so that an auditor can read data from any register with the same tool. The auditor loads your export into audit software, typically IDEA, and runs automated checks: gaps in receipt numbers, breaks in the TSE signature chain, suspicious cancellation patterns, VAT inconsistencies, daily totals that do not match the Z-reports.

In other words: the export is your register's testimony. It needs to be complete, consistent and produced on demand.

What an inspection looks like

A Kassen-Nachschau is unannounced. An inspector can arrive during opening hours, ask to see the register, observe how it is used, and request the DSFinV-K export on the spot, on a USB stick. If the export does not work, or takes hours, that is already a finding.

Three things owners should be able to do without calling a technician:

1. Trigger the DSFinV-K export for any date range from the register or back office.
2. Show the Verfahrensdokumentation — who configured what, which TSE is in use, how outages are handled.
3. Show that daily closings — Tagesabschlüsse, Z-Bons — are run every day and match the export.

If any of those three is a "let me call someone", ask your vendor to fix it now.

For developers and integrators

DSFinV-K is a set of CSV files plus an index.xml describing them, delivered as a package per register and date range. There are three structural layers.

Master data. The Stamm_ tables carry the context a transaction belongs to: Stamm_Abschluss, Stamm_Orte, Stamm_Kassen, Stamm_Terminals, Stamm_Agenturen, Stamm_USt, Stamm_TSE. Each daily closing — Z_KASSE_ID, Z_ERSTELLUNG, Z_NR — is the key that every other row hangs off.

Receipt data. The Bon tables hold one row per receipt in Bonkopf, with child tables Bonkopf_USt for the VAT breakdown, Bonkopf_Zahlarten for payments, Bonkopf_AbrKreis, and Bonpos for line items with Bonpos_USt, Bonpos_Preisfindung and Bonpos_Zusatzinfo. BON_TYP distinguishes a sale — a Beleg — from training, cancellation, and the non-fiscal "AVBelegabbruch" types.

TSE transaction data. TSE_Transaktionen is the bridge between your receipts and the signatures: transaction number, start and end times, process type and data, signature counter and value, and the TSE ID from Stamm_TSE. Every Bonkopf row must reference exactly one TSE transaction.

Plus the cash register closing tables — Z_GV_Typ, Z_Zahlart, Z_Waehrungen — that reconcile totals by business-case type, payment method and currency.

Practical rules we have learned the hard way:

• Model first, export second. If your transaction table cannot answer "which TSE transaction signed this receipt, and what was the VAT split at line level", no amount of CSV formatting will save you. The export is a projection of a correct data model.
• Immutability. Never update or delete a receipt row. Corrections are new receipts with a cancellation reference. Auditors look for edits.
• Numbering. Receipt numbers must be gapless per register. Test what happens on a crash between the TSE FINISHED response and your own commit.
• Closings are mandatory. A day without a Stamm_Abschluss row is a day the auditor cannot reconcile. Automate the closing; do not rely on staff remembering.
• Encoding and format. UTF-8, semicolon-separated, quoted text fields, dates in ISO 8601 with timezone. The index.xml must describe every file precisely — validation tools reject packages on trivial mismatches.
• Use the TSE provider's export where you can. Cloud providers such as fiskaly generate the TSE_Transaktionen file and the TAR log export from their side; you merge it with your business data. That removes the single most error-prone part.
• Test with the official validator — the DFKA and several vendors publish checkers — and with a real date range from production, not a synthetic day.

Version 2.3 brought stricter field definitions and clarifications rather than new tables. If you were already producing 2.2 exports cleanly, the upgrade is mostly validation. If you were not, this is the moment.

This is general information, not legal or tax advice.

Daleenda audits DSFinV-K implementations and builds export layers for custom POS systems. Send us a sample package and we will tell you what a Betriebsprüfer would find.

Have your export reviewed