A customer pays for a flat white at a café in Munich. The tablet on the counter sends the sale to a signing service, gets a signature back and prints it on the receipt before the milk has finished steaming. Nobody at the counter thinks about it, but that one-second step involves all four fiscalization stakeholders: the café, the company that built the tablet's POS software, the provider of the security component that signed the sale, and the tax authority enforcing the rules that made the signature necessary.
Each of them carries a different part of the job, and the law hands out those parts differently from one country to the next. Knowing who owns what matters most if you build POS software, because your product is where the other three meet.
TL;DR
The business records the sale and keeps the legal duty for its records, even when it buys in every technical piece. The EPOS or MPOS supplier ships the system and, in several markets, carries legal duties of its own. The security component provider signs each transaction so it can't be changed unnoticed. The tax authority gets the data either by transmission (daily in Italy, record by record in Spain's Verifactu mode) or on request at an inspection (Germany, Austria, France, Sweden).
Who are the stakeholders in fiscalization?
Fiscalization has four stakeholders: the business that records sales, the EPOS or MPOS supplier that builds its point-of-sale system, the security component provider whose signature makes each sale tamper-evident, and the tax authority, which enforces the rules and receives the data. The first three are linked by contracts and integrations; the law places obligations on each of them directly.
It helps to picture a triangle. The business, the supplier and the security component provider sit on the corners, connected by licenses and API calls. The tax authority sits in the middle, because the rules it enforces reach every corner on their own rather than passing down the chain.
There's a reason for the split: no single party can make a sales record trustworthy alone. A record the business controls from end to end proves little to an auditor, since the business is the one paying tax on it. The supplier writes the software but can't vouch for every sale made with it. The security mechanism adds the proof that a record hasn't been changed since it was made: in most markets, a signature from a component the business doesn't control.
The business: owns the duty and the records
Most fiscalization laws address the business first. Germany's § 146a of the Fiscal Code (Abgabenordnung, AO) says whoever records business transactions with an electronic system must protect it with a TSS certified by the BSI and keep the records available for tax inspections. The same section requires that business to notify its tax office of the systems it uses. Austrian businesses register their signature units with FinanzOnline, and Swedish businesses register their cash registers with Skatteverket and report changes within two weeks.
Short version: the business owes the tax, so it owns the evidence.
It holds even when every technical piece is bought in. A restaurant can license its POS from one company and its signing service from another, but when an inspector turns up and asks for the transaction data, the request goes to the restaurant. Outsourcing the technology doesn't outsource the obligation.
That shapes what the business needs from the other two corners. It needs a system that records every sale the way the rules require. And it needs that system to hand over whatever the business has to file or produce: registration details, exports, receipts. fiskaly's guides to KassenSichV in Germany and the RKSV in Austria cover those duties market by market.
The EPOS or MPOS supplier: builds the system the others plug into
Suppliers build and ship the point-of-sale system: an EPOS (electronic point of sale) on a fixed till or back-office server, or an MPOS (mobile point of sale) on a phone or tablet. It's the corner that turns a legal requirement into a button a cashier presses. It's also where the other two corners connect, since the business works in the system and the security component runs inside it.
It's easy to assume the duty stops with the merchant. In several markets, the law says otherwise:
- Germany: § 146a(1) AO prohibits commercially advertising or placing on the market systems, software or TSSs that don't meet the requirements.
- Spain: under Article 13 of Royal Decree 1007/2023, the producer certifies each version of its invoicing software in a declaración responsable, a signed statement of compliance it gives to customers. Producers have had to offer adapted software since July 29, 2025. Businesses' own obligations are set to start in October 2028, official confirmation pending as of October 2026.
- France: the POS software itself has to prove compliance, either through third-party certification or a two-part attestation. The publisher signs the first part, and the merchant signs the second. The attestation is valid only with both.
- Sweden: the cash register itself is covered by a manufacturer declaration under SKVFS 2014:9, Skatteverket's regulation on cash register requirements.
Retailers that build their own POS hold two corners at once, with the merchant's duties and the supplier's in the same company. France shows what that can mean: a publisher selling to third parties may attest its own compliance, but software built only for internal use needs third-party certification.
The security component provider: signs every transaction
A security component is the part of the system that makes a record provable. It signs each transaction as it's recorded and, in several markets, chains it to the one before, so a later edit or deletion breaks the chain and shows up in an audit. Depending on the market, it's a hardware module, a smartcard or a cloud service the POS calls over an API.
Germany's BSI (Federal Office for Information Security) describes the division of labor plainly: POS manufacturers usually integrate an existing certified TSS instead of developing and certifying one themselves, and the certification covers the TSS only, not the POS or its software. Where a market has a separate component, the pattern repeats: the POS integrates it, and whatever approval the market requires comes with the component rather than with the POS.
What that approval is varies more than the word "certified" suggests, from a BSI certificate in Germany to no product certification at all in Austria, and in Spain and France the law has no separate component. The table further down lines up six markets.
For the supplier, that usually means a separate set of requirements and paperwork in every market. For the business, it means the component is usually invisible: it shows up as a code or signature on the receipt and, where registration is required, in the details filed with the tax authority.
The tax authority: enforces the rules and receives the data
In most markets, the fourth stakeholder is a national tax authority: Austria's Ministry of Finance through FinanzOnline, the Agenzia delle Entrate (AdE) in Italy, the AEAT in Spain, the DGFiP in France and Skatteverket in Sweden. Spain has regional exceptions: the Basque provincial tax authorities (Haciendas Forales) run TicketBAI, and Navarra's Hacienda Foral runs NaTicket.
Germany splits the role further. The Federal Ministry of Finance (BMF) issues the KassenSichV regulation, the BSI sets the technical requirements in consultation with it (§ 5 KassenSichV), and the tax offices run by the federal states (Finanzämter) receive each business's notification and carry out inspections.
How the data reaches the authority follows one of two models. In the transmission model, the authority gets the data without asking for it. Italy's registratore telematico (RT) devices send the day's sales data to the AdE once a day. In Spain, software running in Verifactu mode sends every invoice record to the AEAT, while systems that don't use that mode store the records instead.
In the on-request model, the data stays with the business until an inspector asks. Under Austria's RKSV (§ 7 and § 19), the business exports its data capture log (DEP) for the requested period. Germany, France and Sweden also check records at inspections.
The two models put the weight in different places. On request, the signature carries everything, because the authority sees the data months or years later and relies on it to prove nothing changed in between. Transmission needs connectivity and proper resend handling.
How the four roles look in six markets
The four roles are the same everywhere; what changes is the form of the security component, who vouches for it and how the data travels.
| Market | Security component | Who vouches for it | How the tax authority gets the data |
|---|---|---|---|
| Germany | Technical Security System (TSS), hardware or cloud | BSI certification | On request, at inspections |
| Austria | Signature creation unit, smartcard or cloud | Qualified certificate from an eIDAS trust service provider; the unit must meet eIDAS requirements, no separate fiscal certification | On request, as a DEP export (§ 7, § 19 RKSV) |
| Italy | Registratore telematico (RT) | RT model approved by the AdE | Daily transmission to the AdE |
| Spain | Requirements built into the invoicing software | Producer's declaración responsable (Art. 13, RD 1007/2023) | Every record in Verifactu mode; otherwise stored for inspection (business obligations from 2028) |
| France | Requirements built into the POS software | Third-party certification (LNE or InfoCert) or publisher self-attestation (reinstated from February 21, 2026) | On request, in a DGFiP audit |
| Sweden | Control unit (kontrollenhet, hardware) or cloud control system (kontrollsystem) | Accredited certification body | On request, at Skatteverket control visits |
Read down the middle column and one thing stands out: the tax authority rarely approves the security component itself. Italy is the clear case where it does, through the AdE's approval of RT models. Everywhere else, the vouching sits with a certification body, a trust service provider or the producer's own signed statement. fiskaly's guides to third-party versus self-certification and to hardware versus cloud components go deeper on both questions.
What this means if you build POS software
"Compliance is the merchant's job, not ours." Legally, that's mostly right: the duty sits with the business, and in Germany, Austria and Sweden it's the business that registers with the tax authority.
But the merchant can only meet that duty through the system you ship, so three decisions land on your side of the triangle:
- Which security component to use in each market, and whether its approval covers the way you deploy it.
- Whether every transaction passes through it. A sale that skips the signing step, because of an untested code path or an outage the software doesn't handle, leaves a gap in the merchant's records that the merchant can't see.
- What the business needs from you to file. An Austrian merchant registering with FinanzOnline has to report the certificate serial number, the type of signature unit and the cash register IDs. If your system doesn't surface them, or your provider doesn't automate the registration, the merchant can't complete it.
For POS vendors, compliance is the merchant's legal duty and a feature of your product at the same time.
Key takeaways
- The duty stays with the business. Buying POS software and a signing service moves the technical work, not the legal obligation or the records.
- Suppliers carry duties of their own. In several markets, the party that makes or sells the system has obligations in law, so "the merchant is responsible" is never the whole answer.
- "Certified" needs a qualifier. Check what vouches for the security component in each market before relying on the word.
- The data model drives the engineering. Where data is transmitted, plan for outages and resends; where it waits for an inspector, the signature and the export have to hold up for years.
How fiskaly fits in
fiskaly is a cloud fiscalization and VAT compliance API provider: the security component corner of the triangle. It doesn't sell POS systems or process payments.
In Germany, SIGN DE is the market-leading and BSI-certified cloud TSS. SIGN SE is a cloud control system (kontrollsystem) under SKVFS 2020:9, certified by an accredited certification body, and SIGN ES covers Verifactu, TicketBAI and NaTicket through one API. SIGN AT signs receipts, produces the DEP and automates the registration with FinanzOnline.
The corners stay the same in every market; the rulebook in the middle is what changes.
