A charge ends. The driver wants a receipt — not a PDF, but a receipt the tax authority will accept, with a valid fiscal signature on it. That signature does not exist yet at the moment the charger stops drawing power. It has to be created, somewhere else, and then it has to come back.
That “come back” is the part nobody budgets for. Fiscalization is not a step you tack on at the end of a charge. It is a round trip — and the standard the industry is building on doesn’t carry the return leg.
What “fiscalized” actually means
A fiscal receipt is not a formatted document. It’s a document that has been signed by an authorized fiscalization path, so the tax office recognizes it as a legal record of sale. In most fiscal regimes the signing happens at a fiscalization provider: the certified component — sometimes the same one that handles invoicing — that stamps the transaction with a signature, a sequence number, a hash chain, and whatever else that regime mandates.
So the flow has two halves, not one:
- Issue. The session data — energy delivered, the amount captured, the VAT breakdown, the timestamp — goes up to the fiscalization provider. The provider fiscalizes it and produces the signed artifact.
- Confirm. That signed artifact, or proof of it, has to come back down to where the sale physically happened — the charger, the terminal, the driver standing there — and the system has to record that the fiscal step closed successfully.
Skip the second half and you don’t have fiscalization. You have an invoice you hope got registered. When an auditor asks you to reconcile every captured payment against a signed fiscal record, “I sent it upstream” is not an answer.
That’s why this is a round trip. Issue, then confirm. One direction is a notification. Two directions is a contract.
Why the unattended terminal makes it hard
In a shop, the round trip is invisible because a human and a single box absorb it. The terminal talks to the till, the till talks to the fiscal module, the printer spits out the signed receipt, the cashier hands it over. Everything lives within arm’s reach, and someone is watching it.
A charger has none of that.
The terminal bolted to a charger on a forecourt is unattended. There is no cashier to retry a failed print, no screen anyone reads, no operator to notice that the fiscal module timed out. The driver is back in the car. The “shop” is a roadside enclosure that has to behave correctly with nobody present — in weather, on flaky connectivity, hundreds of times a day. And the receipt isn’t printed there anyway: in an ad-hoc charge the legal receipt typically arrives as a link, an SMS, or a page the driver opens, because you don’t want a thermal printer rotting in a cabinet outdoors. AFIR put millions of those ad-hoc charges on the roadmap; every one of them needs a receipt that counts.
Here’s where “harder than it looks” earns itself. The fiscal artifact has to travel from the provider, back to the system that owns the session, and out to the driver — while the terminal that took the card needs to know the financial side closed cleanly. That’s several systems, no human, and exactly one transaction that has to converge to one consistent final state. The pieces don’t fail together; they fail apart.
Picture the worst case. The data goes up, the provider issues the signature — and the confirmation is lost on the way back. Upstream, the sale is fiscalized and recorded. Downstream, the terminal and the session think the fiscal step never closed. Now you have a signed receipt that the system on the forecourt doesn’t know exists, and no cashier to spot the mismatch. Resend blindly and you risk a duplicate fiscal record, which is its own kind of audit problem. The system has to be idempotent — able to recover and reconcile to the single correct outcome without a person reading a screen — because the one thing it can’t do is leave the charge in two states at once. Retries, timeouts, and dedup on an unattended box are the whole job, not an edge case you handle later.
Now do that country by country. The signature format, the sequence rules, the data the regime demands, the provider you’re required to use — all of it changes when you cross a border. The round trip isn’t one integration. It’s one per fiscal regime, each with its own definition of “done.”
Where the standard stops — again
OCPI is the protocol the charging industry runs on, and its payments module is genuinely useful. It standardizes the connection: a terminal object, a pre-authorization tied to a tariff, start and stop, a financial advice confirmation. It gets a terminal and a charging network speaking the same language, and it does that job well.
It defines nothing for fiscalization. Not a field, not a flow, not a place to put a signature.
That isn’t an oversight you can patch with a custom extension — and here’s the part that matters: OCPI isn’t shaped for the job. Its payment exchange is built to report — the session happened, here’s the financial advice, here’s the confirmation. Fiscalization needs that same data to make a round trip to an external provider and come back bound to the same transaction: send the data up, get a signature back down, and prove the loop closed before you call the charge finished. That’s an exchange OCPI doesn’t model — and shouldn’t. Fiscalization is a tax-regime concern, not a roaming one. OCPI’s job is to make networks interoperate; it has no business growing a per-country tax engine to satisfy an audit it never sees.
This is the same pattern the standard repeats everywhere it touches money, in its sharpest form: the standard leaves the slot, not the flow. It marks where money belongs and stops. Pre-authorization strategy, the non-happy paths, multi-acquirer routing — all left to you. Fiscalization is the slot the standard doesn’t even draw, because the exchange it requires is one the spec isn’t built to express.
Why a connection protocol will never solve this
It’s tempting to think the next OCPI version will “add fiscalization.” It won’t, and it shouldn’t — for the same reason a handshake doesn’t become an engine by adding fields.
Fiscalization is a cross-system, stateful, country-specific exchange between a payment terminal and a fiscalization provider — two parties OCPI doesn’t sit between. OCPI connects terminals to charging networks; it does not connect them to the tax-fiscalization world. Wedging that in would mean every CSMS vendor implementing a fiscal round trip they have no reason to own, inside a protocol whose job is roaming and reporting. You’d be asking the interoperability layer to grow a tax engine. That’s how you fragment a clean standard.
The same logic kills the other shortcut: don’t solve fiscalization by bolting it onto the charger. A charger is a superb piece of hardware, but it is not a cash register. It talks to the CSMS over OCPP and was never designed to hold a fiscal exchange — and that’s a feature, not a flaw. Push the round trip into a bespoke charger-to-terminal-to-CSMS integration and you’ve built something that violates the open protocols, needs custom extensions, and only ever works for one charger model from one vendor — while real operators run mixed fleets. Picture a regional operator with three charger vendors across two countries — two fiscal regimes — and a custom integration that covers exactly one of them.
That’s not a solution. That’s debt with a deadline.
The right place to close the loop
The fiscal round trip belongs in a payments layer that sits beside the open protocols, not inside them — bridged over OCPI so it works with any charger, any CSMS, and any terminal, and connected directly to the fiscalization provider on the other side.
That’s what Bolt does. We bridge the unattended terminal and the fiscalization provider both ways, per country. The session data goes up, the signature comes back, the loop is confirmed closed — idempotently, so a lost confirmation reconciles to one outcome instead of two — and the driver gets a receipt the tax office accepts, delivered as a link, not a PDF you’re hoping counts. When the regime changes across a border, the bridge changes; the operator’s charger, CSMS, and terminal don’t.
And it stays neutral. The operator is still the merchant. Funds settle to their own acquirer; the money never routes through Bolt. We carry the fiscal signature, not the cash.
That’s the whole point. A receipt the tax authority accepts is the difference between a charge that happened and a charge that counts. The standard will hand you a clean connection and a confirmation that the payment cleared. It will not carry the signature home.
That last mile is a round trip. Build for the return leg, or don’t call it fiscalized.