Every provider in this market demos well. The interface is clean. The sandbox works. Someone walks you through a signed receipt and a structured invoice, and the whole thing takes forty minutes.
None of that is where the pain shows up.
It shows up months later in the most unexpected moment. When a format version changes. A certificate comes up for renewal. A market you just entered turns out to be on the roadmap rather than in production. Or the till loses its connection on a Saturday afternoon.
So here are the questions worth asking first. Ask every provider the same ones, including us.
TL;DR
Six questions separate providers in this space. Which markets are live today rather than planned? Who holds the certification and what it covers? What happens when the connection drops? Who absorbs the cost when a rule changes? Do fiscalization and e-invoicing come from one integration or several? How do you exit? Ask all six of every vendor and write down the answers. The pattern that matters isn't who says yes to everything. It's who gives you specifics, and who gives you adjectives.
What does "we cover Europe" actually mean?
Coverage is the easiest thing to overstate and the easiest thing to check.
Ask for the list. Not the marketing map with the coloured countries, but which markets are in production today, when each one went live, and how many customers run on each. A provider who has been live in a market for years and one who added it last quarter will both say they cover it.
Then ask what covered means per market. Issuing only, or issuing and receiving? Fiscalization only, or fiscalization and e-invoicing? B2B, B2G and B2C, or one of the three? Cash register rules and e-invoicing mandates are separate obligations, and a provider can be strong on one and absent on the other.
The follow-up that gets you the real answer: what's the process for adding a market, and how long did the last one take? A vendor who has genuinely done it recently will tell you a number. A vendor who hasn't will describe a methodology.
Who holds the certification, and what does it actually cover?
"We're certified" is not an answer. Certification is specific. It has a scope, and it expires.
Ask which certificate, issued by whom, covering which components, valid until when. Ask to see the document. Ask what happens at renewal, who runs the process, and what you have to do while it's running.
Then ask the question people forget: whose name is on it? If the certification sits with the provider, they carry the renewal work. If it sits with you, or with a hardware component you bought, the work lands somewhere in your team and nobody has budgeted for it.
Ask what happens if a certificate lapses or a certification body changes its requirements mid-term. You want to hear a plan instead of reassurance.
What happens when the connection drops?
Every cloud provider quotes uptime. Uptime is the wrong question.
Ask what the till does when it can't reach the service. Does the sale complete? What gets queued? How does the catch-up work when connectivity returns, and does it preserve the numbering, the tax data and the transaction order?
Ask how long the offline window can be before there's a problem. And what the customer has to do afterwards. Ask whether the offline path is certified, or just implemented.
A provider who has thought about this will answer in detail. A provider who hasn't will go back to talking about their uptime figure. That contrast tells you most of what you need.
Who pays when the rules change?
This is the question with the most money attached to it, and the one buyers ask last.
The rules in this market change constantly. Germany's e-invoicing issuing obligation phases in across 2027 and 2028. France's mandate is rolling out now. ViDA brings cross-border digital reporting at the end of the decade. Between those headline dates sit dozens of smaller changes: a format version, a new mandatory field, a schema update, a changed transmission channel.
So ask: when a format version changes, who does the work? Is it in the subscription, or is it a project? Ask for an example from the last two years, with what changed, what the provider did, and what their customers had to do.
Ask how you find out about changes. You want to know whether the provider tells you before or after they've handled it, and how much lead time you get when something needs work at your end.
One integration, or several?
"Single platform" is a claim about marketing architecture as often as it is a claim about software.
Ask specifically: is fiscalization the same API as e-invoicing? Are all markets on the same API, or does each one have its own? Do the products share a transaction record, or do they each keep their own copy?
If the receipt and the invoice come from different systems, someone has to keep them consistent. If each market has its own integration, your second market costs almost what the first one did.
Ask to see the documentation for two products, or two markets, side by side. Two sets of docs with different conventions tell you more than the architecture slide does.
And how do you get out?
Nobody enjoys this question during a sales process, which is exactly why it's a good one.
Ask what happens to your archived data if you leave. What format does it come back in, how long does the export take, and is it usable by another provider or only by theirs? Ask who holds the retention obligation afterwards, because it doesn't move with the contract.
Ask about notice periods, and what happens mid-certification-cycle. Ask whether they've done a migration away, and how it went. A provider who has handled departures gracefully will say so. A provider who has never lost a customer either has excellent retention or a short memory.
The six questions, and what the answers sound like
A rough scorecard. The right-hand column isn't proof of a bad provider, but it's a reason to keep asking.
| Ask this | A good answer sounds like | Start worrying if you hear |
|---|---|---|
| Which markets are live today? | A list, with the date each one went live and who runs on it. | "We support all of Europe." |
| Who holds the certification? | A named certificate, its scope and its expiry, plus what happens at renewal. | "We’re fully certified." No document. |
| What happens when the connection drops? | A described offline mode: what the till does, what queues, how it catches up. | "Our uptime is 99.9%." |
| Who pays when a rule changes? | Included in the service, with an example of a past change they absorbed. | "We’ll scope that when it happens." |
| One integration or several? | A straight answer per product and per market, including the awkward ones. | "It’s all one platform." Followed by two sets of docs. |
| How do we leave? | Export format, archive handover, notice period, all in the contract. | "Nobody has ever asked us that." |
Key takeaways
-
Ask what’s live, not what’s supported. A market list with go-live dates and customer counts separates production from roadmap in about thirty seconds.
-
Certification has a scope and an expiry. Ask which certificate, covering what, valid until when, and whose name is on the renewal work.
-
Uptime is the wrong resilience question. Ask what the till does when the customer's connection drops, and how the catch-up preserves numbering and tax data.
-
Regulatory change is the real cost line. Ask who does the work when a format version changes, and get an example from the last two years.
-
Test "one platform" against the documentation. Two sets of docs with different conventions answer the question more honestly than the architecture slide.
-
Ask how you leave before you join. Export format, archive handover and notice period belong in the contract, not in a future conversation.
Our answers: fiskaly provides fiscalization in seven European markets—Germany, Austria, Spain, Portugal, Italy, France, and Sweden. In Germany, fiskaly SIGN DE is the leading Cloud TSS, certified by the BSI until 2033, and fiskaly carries the certification and renewal work. As of September 2026, fiskaly E-INVOICE is live in Germany, Italy, and Belgium. Regulatory updates are part of the service, not a separate project.





