If you run a cash register in Germany — any cash register, from a bakery counter in Munich to a full-service restaurant terminal in Berlin — the government wants to know that every transaction you ring up is cryptographically tamper-proof. That is the short version of the Kassensicherungsverordnung, the regulation that requires all electronic record-keeping systems, including point-of-sale terminals, to be connected to a certified Technical Security System, or TSS. The law is not new, but the enforcement teeth are very real, and any business running POS software that cannot prove a live TSS connection during an audit is staring down fines and uncomfortable questions from the Finanzamt.
Odoo’s answer to the mandate is a cloud-first integration with Fiskaly, a Vienna-based fintech whose cloud TSS has become one of the go-to solutions for German retailers who do not want to bolt a hardware dongle onto every terminal. The integration is lean — two modules, a handful of configuration fields, and a requirement for working internet — but it covers the full compliance chain from transaction signing to audit export.
What the Kassensicherungsverordnung Actually Requires
The regulation sits on top of Germany’s broader fiscal digitalization push. At its core, it mandates that every electronic recording system used in a commercial setting must be equipped with a Technical Security System that signs each transaction with a cryptographic certificate. The TSS creates an unbroken chain of signed records that an auditor can verify independently, making it functionally impossible to delete or alter a sale after the fact without leaving a visible gap in the chain.
For POS operators, that translates into a concrete technical requirement: the register software must talk to a certified TSS for every transaction, and the resulting signed data must be exportable in the DSFinV-K format — the standardized digital interface that tax auditors use to ingest cash register data. Miss either piece, and the system is non-compliant regardless of how diligently the books are kept elsewhere.
Why Fiskaly, and Why It Lives in the Cloud
Traditional TSS implementations involved physical security modules installed at each terminal — essentially smartcards or USB devices that performed the cryptographic signing locally. Fiskaly took a different approach: a cloud-hosted TSS that handles the signing over an API call, eliminating the need for specialized hardware at the point of sale. For multi-location retailers or restaurants with dozens of terminals, the difference in deployment complexity is enormous.
The trade-off is connectivity. Because Fiskaly’s TSS lives in the cloud, every terminal needs a working internet connection to sign transactions. That is a non-negotiable requirement, not a nice-to-have. If the connection drops, the signing cannot happen, and the register enters a state that needs to be reconciled once connectivity returns. For most urban retail environments, this is a non-issue. For a food truck at an outdoor market with spotty mobile signal, it is a factor worth weighing before choosing a cloud TSS over a hardware alternative.
Odoo chose Fiskaly as its TSS partner for the German localization, and the integration ships through two modules: l10n_de_pos_cert for standard POS deployments and l10n_de_pos_res_cert for restaurant-mode POS, where the additional complexity of table service, split bills, and tips requires its own certification path.
Setting Up: Company Details, Credentials, and TSS Creation
Getting from a fresh Odoo installation to a compliant German POS is a three-phase process, and the order matters. The first step is purely administrative: the company record in Odoo must carry accurate legal details, including the company name, full street address, VAT identification number, Steuernummer (the domestic tax number issued by the local Finanzamt), and the W-IdNr (the economic identification number). These fields are not optional decorations — they flow directly into the Fiskaly registration and appear on the signed transaction records.
Once the company data is clean, the second phase is Fiskaly registration itself. This step creates an organization on Fiskaly’s side and returns an organization ID along with the API key and API secret that Odoo will use to authenticate every signing request. The credentials get stored in the company settings, and from that point forward, the Odoo instance has a live handshake with Fiskaly’s infrastructure.
The third phase ties everything to the actual POS hardware: creating a TSS entry in the Point of Sale configuration. Each POS terminal needs its own TSS binding so that the signed transaction chain is register-specific, which is exactly how the regulation expects the data to be structured. Once the TSS is created and active in the POS config, transactions start getting signed automatically — no cashier interaction required, no extra button to press.
What Happens at the Register
From the cashier’s perspective, the Fiskaly integration is invisible. Every sale, refund, and voided transaction flows through the signing API in the background, and the signed receipt data is stored alongside the order record in Odoo’s database. The cashier rings up a coffee and a croissant, takes payment, and moves on. Behind the scenes, the transaction has been hashed, signed by Fiskaly’s certified TSS, and chained to the previous transaction in a sequence that an auditor can independently verify.
The real compliance payoff comes when POS sessions close. At that point, Odoo automatically transmits the session’s transaction data to the DSFinV-K service — no manual export, no file download, no email to the accountant. The data just flows. This automatic transmission is a critical detail because the Kassensicherungsverordnung does not just require that the data exist; it requires that the data be readily available in the standardized format on demand. By pushing it to the DSFinV-K pipeline at session close, Odoo ensures that the audit trail is always current rather than depending on someone remembering to run an export before the tax inspector arrives.
Pulling the Audit Export When the Finanzamt Comes Knocking
When an audit does happen — and in Germany, POS audits are neither rare nor informal — the DSFinV-K export is the artifact the inspector will ask for. Odoo surfaces this through a straightforward export interface that takes three inputs: a name for the export (something human-readable like “Q2-2026-Audit”), a start datetime, and an end datetime. Fill those in, run the export, and the system produces the standardized data package covering every signed transaction in the selected window.
The simplicity of that workflow is deceptive. Under the hood, every record in the export traces back to a cryptographically signed transaction that Fiskaly certified at the moment of sale. The chain is complete, the format is standardized, and the data matches what was already transmitted automatically when each session closed. An auditor who cross-references the export against Fiskaly’s own records will find a perfect match — which is precisely the point of the entire regulatory apparatus.
The Bigger Picture for German Retailers on Odoo
Germany’s fiscal compliance stack for POS is among the more demanding in Europe, and the Kassensicherungsverordnung is just one layer. But it is the layer that touches the register directly, and getting it wrong has immediate consequences. The Fiskaly integration gives Odoo a clean path through the regulation: cloud-based signing that requires no hardware procurement, automatic data transmission that does not depend on manual discipline, and an export pipeline that produces exactly what the Finanzamt expects to see.
For businesses already running Odoo or evaluating it for a German retail deployment, the takeaway is that the compliance plumbing is built in, not bolted on. Install the right module — or both, if the POS runs in restaurant mode — fill in the company details that the tax authority already requires you to have on file, register with Fiskaly, and the system handles the rest. No third-party middleware, no nightly batch jobs, no spreadsheet of manually exported receipts.
The internet connectivity requirement is the one constraint worth flagging. Fiskaly’s cloud TSS is elegant precisely because it eliminates hardware, but that elegance comes with a dependency on a stable connection. For the vast majority of brick-and-mortar operations, that is a solved problem. For edge cases — pop-up shops, seasonal markets, locations with unreliable infrastructure — it is a factor to evaluate before committing to the cloud path. But for any retailer with a reliable internet connection and a desire to stay on the right side of the Kassensicherungsverordnung, Odoo’s Fiskaly integration is about as frictionless as German tax compliance gets.