The four models people name — real-time reporting, clearance, centralised exchange, five-corner CTC — aren’t four inventions. They’re points on two independent axes, and once you see the axes the design decisions fall out.
Axis one: is validation constitutive? When the state’s platform rejects your invoice, does the invoice cease to exist, or is it just a failed report against a perfectly valid document?
Axis two: is the state in the delivery path? Does the invoice reach your buyer through the government’s platform, or do you deliver it yourself and send the state a copy?
Those two questions produce four quadrants, and one of them is routinely mislabelled.
Two axes, four models
- Real-time reporting — not constitutive, not in the path. Hungary’s RTIR, Spain’s SII. You issue and deliver; you report.
- Clearance without exchange — constitutive, not in the path. India’s IRP. The state must stamp it, then hands it back to you to deliver.
- Centralised exchange — constitutive and in the path. Italy’s SdI. The state validates and delivers.
- Five-corner CTC — not constitutive, not in the path, but your provider is licensed. France from September 2026.
The second quadrant is the one that gets lost, because “clearance” and “centralised exchange” are used interchangeably and they are not the same thing. India clears without delivering: Sigitek’s SAP implementation documentation for Indian e-invoicing runs SAP → GSP → IRP, the portal validates and signs and returns the JSON with an IRN, forwards the data to the GST and E-Way Bill systems — and the last step in the vendor’s own architecture is “Print or Email Invoice”. The buyer is not on the network. Italy’s SdI, by contrast, routes the invoice to the recipient’s registered channel and reports a delivery receipt back.
Same word, two architectures, completely different integration.
Validation: the same rejection, opposite consequences
This is the axis that matters most and the one that’s easiest to get wrong, because every model returns something that looks like a validation result.
Hungary’s NAV validates. Invoice data goes to the Online Számla system in XML, immediately via machine-to-machine connection where invoicing software is used, and NAV replies per invoice with accept, reject with error, or warning. It issues an electronic reference number — which notably does not need to be printed on the invoice, because it’s only a reference for potential future audits.
And yet: RTIR is not a clearance model. The invoice is not legally valid because NAV approved it. The supplier remains responsible for issuing a compliant invoice and separately for reporting it. A NAV rejection means your report failed. The invoice is untouched.
Now Italy. A notifica di scarto from the SdI means the invoice is legally treated as never issued. Same act — a state platform returning a negative validation result over a healthy connection — and the opposite legal consequence.
For a product team this is the single most important distinction in the space, and it’s not visible in any topology diagram:
- Non-constitutive (Hungary, Spain): a rejection is an operational problem. The invoice is out, the buyer can pay it, and you fix the report.
- Constitutive (Italy, India): a rejection is a commercial problem. There is no invoice. Nobody owes you anything yet.
If your data model has one rejected state serving both, it is telling two different lies in two different countries.
The receipt: who keeps the proof
Ask where the evidence lives and the models diverge again — in ways that are almost the reverse of what people assume.
India: you keep it, and the state doesn’t. The IRP allows cancellation only within 24 hours, and the reason commonly given is that the IRP does not store e-invoices for longer than that. The clearance platform is close to stateless. The digitally signed JSON with the IRN that comes back to your system is the artefact, and retaining it is your problem.
Italy: both, with obligations attached. The SdI parks undeliverable invoices in the recipient’s reserved area on the tax authority’s portal, and Italian rules require ten years of compliant electronic preservation — with audits checking delivery receipts, rejection notifications and resubmission logs alongside the invoices themselves.
Greece: printed on paper. SAP Hellas’s August 2024 implementation guide requires the MARK, the UID, the authentication code and the QR code to appear on the invoice printout. The proof of reporting is rendered as ink.
Hungary: held by the authority, and you don’t have to show it. The reference number exists for audit and isn’t printed.
Four models, four different answers to “where is the evidence” — and only one of them (Italy) puts a copy somewhere the state maintains for you.
Failure: what stops when the hub stops
Blast radius is a function of axis two.
Centralised exchange: the government platform is a single point of failure for commerce itself. If the SdI can’t route, the invoice can’t reach the buyer, because an invoice sent directly to the customer isn’t a legally valid document. Commentary on the rise of decentralised models makes exactly this argument — pre-clearance submission undermines established billing processes and makes the authority’s portal a single point of failure.
Clearance without exchange: narrower. If India’s IRP is unreachable you have no IRN, but the delivery channel — print, email — is untouched. The failure is legal, not logistical.
Real-time reporting: narrower still. A NAV outage doesn’t stop you invoicing anyone. It creates a reporting backlog with a three-day correction clock.
Five-corner: failure is distributed and, importantly, has more than one domain. Greece’s guide is explicit about this: it prints one message for a transmission failure between issuer and service provider, and a different one for a failure between the service provider and the tax authority — with an offline QR code minted on the fly during the legal printing process either way. Two failure domains, two messages, one fallback. The API endpoint that issues the fallback identifier is named TransmissionFailure.
That’s the design lesson: in decentralised models you own a failure taxonomy, not a boolean.
Retries and corrections: whose job, and on what clock
Every model gives you a different answer, and none of them is “edit the record”.
- Hungary: errors must be resubmitted within three days of the original submission. Note the submission token is live for roughly five minutes — a detail that quietly rules out certain queue designs.
- Italy: a rejected invoice must be corrected and resubmitted within five days, reusing the same invoice number and date.
- India: cancel within 24 hours, or issue a credit note referencing the original IRN — and you must not reuse the invoice number. Also, if an e-way bill is active against the IRN, cancellation is blocked entirely.
- Greece: on the service-provider route, the cancel function isn’t available at all; credit notes substitute for it.
Italy requires number reuse. India forbids it. Both are mandatory, both are penalised, and they are the same engineering decision. Any global policy on document numbering is wrong in at least one of these markets.
The axis the diagrams miss: who holds the licence
There’s a third axis, and it doesn’t appear in any corner diagram because it isn’t topological.
In France, invoices flow through accredited private platforms registered by the tax administration for renewable three-year periods, with software that merely creates invoices unable to connect to the public portal directly. Greece’s provider framework does the same, and choosing that route removes an operation — cancellation — from your state machine. Spain’s forthcoming regime is heading the same way: reporting suggests the government will approve agents against interoperability, digital security and continuity-planning criteria, with the private operator responsible for signing the invoice before forwarding it to both the customer and the tax authority.
So the real question in a five-corner market isn’t how many hops there are. It’s whether your provider holds a current licence, and what that licence obliges them to do about you.
Using this
Classify before you build. For each market, answer the two questions — is validation constitutive, is the state in the path — before looking at any API documentation. They determine your error semantics and your delivery architecture, and no amount of integration work fixes a wrong answer.
Model rejection twice. One state for “the report failed”, one for “the invoice does not exist”. They need different UI, different notifications and different accounting consequences.
Treat the receipt as a first-class record. Especially where the state doesn’t keep one for you, which includes the biggest clearance system in the world.
Expect countries to move between quadrants. Hungary has confirmed structured domestic B2B e-invoicing in phases from 2028, replacing RTIR — a move from the reporting quadrant to a mandate. Spain is running SII alongside a new regime that reporting suggests will offer a choice between a hybrid five-corner private network and direct state platforms, with the two likely consolidated later. The quadrant is not a permanent property of a country.
Frequently asked questions
What’s the difference between clearance and real-time reporting?
Whether the validation is constitutive. Under clearance, the authority or its platform must validate and return a confirmation — an identifier, a signature, a QR code — before the invoice is legally issued. Under real-time reporting, you issue a valid invoice and separately transmit data; the authority may still validate and reject, but the invoice stands. Hungary’s RTIR and Spain’s SII are reporting regimes. Italy’s SdI and India’s IRP are clearance.
Is clearance the same as centralised exchange?
No, and conflating them is the most common error here. India’s IRP clears an invoice and hands it back to the supplier, who then prints or emails it — the buyer never touches the government platform. Italy’s SdI clears and delivers. Same legal category, different delivery architecture, different integration.
Which model does ViDA use?
Real-time reporting, decentralised. From 1 July 2030 data is transmitted per transaction at the moment the invoice is issued, and the authority isn’t placed between supplier and buyer. Member states with domestic real-time systems in place on 1 January 2024 have until 1 January 2035 to align.
Where does my architecture actually differ between models?
Three places. Error semantics — is a rejection commercial or operational. Delivery — do you own the channel or does the state. And evidence — who retains the proof and for how long. Everything else is a schema mapping.
Can one country run more than one model?
Yes, and several do. Spain has run SII reporting since July 2017 and is layering an e-invoicing mandate on top, with consolidation expected later rather than at launch. France separates exchange through accredited platforms from reporting through the public portal. Assume overlap is the normal state, not a transitional one.