Clearance, reporting, exchange, periodic: the four CTC models, and why the label decides the build

One question decides more of your architecture than scope, format and thresholds combined: where does the tax authority sit relative to your invoice? Is it standing in the send path, waiting beside it, or reading a report weeks later? The answer sorts every mandate into one of four control models — and the model, not the country, is what tells you whether you are building a synchronous dependency or a batch export. Get the label right first; everything else hangs off it.

1. Why the model comes first

"Continuous transaction controls" (CTC) is the umbrella term for tax authorities collecting invoice data at or near the moment of the transaction, rather than through a periodic return. But CTC is not one thing, and treating "the country is CTC" as an architecture is where roadmaps go wrong. What you actually need to know is how close the authority sits to the invoice, because that distance is the difference between a system that cannot issue when a platform is down and one that runs a report on Sunday night.

This expands the very first question from our guide to reading a new country mandate — which model applies — into the detail you need to actually size the build.

2. The four models

Read the table top to bottom and the authority walks steadily further from the invoice: inside the send path, then next to it on a clock, then off the path entirely, then reading a summary later. That distance is the whole story.

3. What each one costs to build

The model maps almost directly onto the dominant engineering cost:

• Clearance — a synchronous dependency in your critical path. The cost is everything that implies: response handling, retries, timeouts, idempotency and an outage story, because if the platform is unavailable you may be unable to issue a valid invoice at all. (We wrote a whole piece on this: designing for clearance outages.)
• Near-real-time reporting — a second, decoupled data path that must stay reconciled with the invoice and meet a deadline. Lighter than clearance because it does not block issuance, but it is a genuine parallel obligation, not a field on the invoice.
• Exchange / network — the cost is onboarding, routing and capability discovery rather than authority latency. Who can receive, under what identifier, over which access point. (See counterparty onboarding and master data.)
• Periodic reporting — extraction and mapping from data you already hold, on a schedule. The least latency-sensitive, but the format and completeness rules can still be demanding.

4. Hybrids, and reading per transaction

Few real regimes are pure. The ones that catch people out combine models — and, crucially, apply different models to different transaction types within the same country:

• Exchange plus reporting. France's reform pairs a four-corner e-invoicing exchange for domestic B2B with an e-reporting obligation for B2C and cross-border — two models, one mandate. Its cross-border leg also has to meet the ViDA reporting layer.
• Clearance domestic, reporting cross-border. A regime can clear domestic invoices while capturing cross-border transactions through a separate report.
• Exchange now, reporting later. Germany's decentralised model is exchange today, with a transaction-reporting layer deferred pending the EU framework — so "exchange" is a snapshot, not a permanent classification.

Write down which model applies to each transaction type, not to the country as a whole. "Germany is exchange" is true today and incomplete tomorrow.

The corollary: a classification has a date attached. Belgium is four-corner exchange in 2026 and a five-corner reporting regime from 2028; Italy is clearance now but converges toward the ViDA layer by 2035. Treat the model as a property of "this country, this transaction type, this year" — the France, Germany, Italy and Hungary pages each state which model is in force and when it moves.

5. Placing a new mandate

When a new announcement lands, resist the urge to jump to format or dates. Place it on the model map first, per transaction type:

1. Is the authority's response a precondition of validity? If yes, it is clearance — budget for a synchronous dependency and an outage design.
2. Is there a short reporting deadline beside a normal exchange? Near-real-time reporting — budget a reconciled second data path.
3. Is it delivery over a network with no authority in the loop (yet)? Exchange — budget onboarding and discovery, and watch for a reporting layer arriving later.
4. Is it a scheduled, aggregated submission? Periodic — budget extraction and mapping.

Do this and the rest of the analysis falls into place: the model gives you the architecture and the failure modes, scope and phasing give you the dates, and format and identifiers give you the build. Skip it, and you risk scoping a batch export for what is actually a synchronous dependency — the most expensive misread in the field.