“We support fiscalization” is a sentence missing its clause
Ask a payments vendor whether they handle fiscalization and almost all of them say yes. The honest answer has a second half: in which countries. Strip that away and “we support fiscalization” tells you only that the capability exists somewhere in the abstract — nothing about whether it works in the markets where your chargers actually sit.
That missing clause is the whole game. Fiscalization is not a setting. It is a contract with a specific tax authority, in a specific market, expressed in that market’s format, sequence, and provider rules. Support it in one place and you have supported it in exactly one place. The moment a second border enters the picture, you have not extended a feature — you have started a second project.
For a charge point operator (CPO) running sites across more than one country, that distinction decides whether compliance is a line item or a standing cost. This piece is about why the line item is a fiction, and what to ask for instead.
What the fiscal round trip actually contains
A fiscal receipt is not a PDF. It is a document carrying a cryptographic signature that a tax authority will recognize, issued in the right order, through whatever channel that jurisdiction mandates. The round trip runs roughly like this: the charging session ends, the settled amount and line items go to an invoicing provider, the provider returns a signed fiscal payload, and that signature has to land back at the unattended terminal — or wherever the receipt is rendered — so the driver leaves with something legally valid.
None of that is carried by the roaming layer. OCPI gives you the Charge Detail Record (CDR): the final settled total and its cost breakdown, and then it stops. There is no field for a fiscal signature, no notion of a provider hand-off, no sequence guarantee. That is by design — OCPI standardizes how a CPO and an eMSP exchange session and billing data, not how a national tax office wants its receipts signed. The extension that does reach toward unattended card payments, OCPI DirectPayment, defines the terminal object and the financial-advice confirmation for an ad-hoc charge. It is genuinely useful work, and it still stops short of fiscalization. The signed legal receipt lives outside the protocol entirely, bridged both ways by whatever sits between the charger network and the invoicing layer.
That is already non-trivial for one country. Now multiply it.
The multiplication nobody quotes you on
Cross a border and four things change at once:
- The signature format. One regime signs with one scheme and field set; the next uses a different algorithm, a different canonical ordering, different mandatory attributes. A receipt that validates in one market is malformed in the next.
- The sequence rules. Some jurisdictions require the fiscal signature before the receipt is shown — the signed figure is the only figure the driver may ever see. Others tolerate post-hoc fiscalization, where receipt and signature reconcile after the fact. That constraint reaches back into capture logic, not just print logic.
- The mandated provider. Several markets do not let you pick an invoicing vendor at all. You route through a designated provider, or a government endpoint directly. Your integration is not to “an invoicing API”; it is to that market’s channel, with its own auth, uptime, and failure modes.
- The receipt contents. What must legally appear — which tax breakdown, which identifiers, which language, which retention period — is set locally. A compliant receipt is a per-country document, not a template with the address swapped.
None of these are configuration values. Each is a distinct integration with its own happy path and, more importantly, its own unhappy ones. Picture the mandated provider in one market timing out mid-signature: the session is settled, the driver is standing at the terminal, and the one thing that proves the charge was legal has not come back. Do you retry and risk a duplicate fiscal document, or render an unsigned receipt and reconcile later — and does this regime even permit “later”? Or the signed payload returns, but the terminal has already cleared its screen for the next driver. Or the charger and the CDR disagree on the final amount, so the figure you are about to sign is wrong before it is signed. Every one of those failure modes is country-shaped, with a different legal answer in each market.
So a multi-country operator is not solving fiscalization once. They are solving it N times — once per regime — and the engineering cost does not amortize, because the regimes share no spec.
And the same rulebook guarantees that N keeps climbing. The mandate pushing ad-hoc, card-present contactless payment onto high-power public chargers — no app, no account, just a card or a mobile wallet at the point of charge — is exactly what drives those chargers into market after market. Under AFIR, new high-power sites must accept payment cards at the charger, with a retrofit obligation reaching back to existing fast chargers. The rule that creates the demand also widens the compliance surface: every new site is a new charge that has to fiscalize correctly under whichever regime it landed in.
And then it doesn’t stay solved
N is the easy version. The real number is N solved plus N maintained.
Tax regimes move. A signature scheme gains a new mandatory field. A grace period for an old format expires. A government endpoint version-bumps and deprecates its predecessor with a deadline. A provider that was optional becomes mandatory, or the reverse.
Walk one of these through. A bulletin lands in one of your markets: as of a fixed date, the fiscal signature must include an additional identifier in a specific position. Someone has to notice the bulletin — it will not arrive as an API error. Someone has to read the spec delta and work out that “one extra field” actually changes the canonical ordering, which changes the bytes that get signed. The fix reaches into capture logic, because the figure now has to be assembled differently before it is signed. It has to be built, tested against that market’s provider, and shipped before the date — while the other N-minus-one regimes keep running untouched. Miss it, and receipts keep generating and look fine, right up until an auditor decides they no longer are.
A pre-authorization strategy that ages badly costs you a worse decline rate. A fiscalization that ages badly costs you a non-compliant receipt with the operator’s name on it.
This is the same drift that haunts the whole money flow — acquirer APIs change, OCPP and OCPI versions advance, CSMS releases ship. But fiscalization has the sharpest edge, because the counterparty is a tax authority and the failure is legal, not merely a declined transaction. So the burden is not a one-time port followed by quiet. It is N concurrent subscriptions to N regulatory change-streams, each demanding a watcher who notices the bulletin, reads the delta, and ships the fix before the deadline. Forever.
Why this is the pain — and also the moat
For a single operator, this math is punishing. A charge-point business wants to sell electricity, not staff a standing compliance-engineering function in every country it enters. A high-power DC site represents serious capital, and it earns nothing the moment its receipts stop validating. The operator expanding across borders inherits a fresh regulatory change-stream with every market — never a copy-paste of the last one.
That same difficulty is precisely why the problem is worth solving once, centrally. The architecture of the bridge is identical everywhere — settled amount in, signed legal receipt out — even though the contents differ per country. Build it as a pluggable, regime-by-regime layer, maintain each market as a unit, watch every change-stream from one place, and the per-country cost is paid once for the whole market rather than once per operator. None of this is a criticism of the fiscalization providers themselves; they are partners, and the good ones are excellent at their own jurisdiction. The gap is not their competence. It is that no one has built the path that strings the jurisdictions together and keeps them current.
Crucially, solving it this way does not touch who holds the money. The operator stays the merchant of record; settlement lands at their own acquirer on card-present economics; nothing routes through the payments layer. Fiscalization is bridged alongside the money, not in its path — and because the receipt bridge never sees or stores card data, it stays outside PCI-DSS scope by construction rather than by certification. The operator keeps their CSMS over OCPI and can swap terminal, acquirer, or country whenever they like, and the receipt that comes out the other end is still one the local tax office accepts.
The clause to always ask for
When a vendor says they handle fiscalization, the only useful follow-up is whether they can name the countries, the formats those receipts are signed in, the mandated providers they route through, and who watches each of those for the next change.
If the answer is a single market, you have bought a feature. If the answer is a pluggable, regime-by-regime layer maintained per market — and the vendor has a seat where the rules get written, the way Optechain holds an OCPI Full-Contributor position at the EV Roaming Foundation — you have bought your way out of running N compliance projects yourself.
A protocol can standardize the handshake. Solving fiscalization N times, and re-solving it every time a regime moves, is not protocol work. It is product work, and it never finishes.