Reading a new country mandate: seven questions that shape the roadmap

A mandate lands as a press release, a decree, or a slide in a tax conference deck. What it almost never lands as is a specification you can build from. The gap between "country X will require e-invoicing" and a costed roadmap is filled by seven questions — and the answers, not the announcement, are what determine whether this is six weeks of work or eighteen months.

1. Which model — clearance, reporting or exchange?

This single answer drives more of the architecture than everything else combined, because it decides whether the tax authority sits in your send path or beside it.

Plenty of regimes are hybrids — an exchange network for the invoice plus a reporting obligation on top, or clearance for domestic and reporting for cross-border. Write down which model applies to each transaction type, not to the country as a whole.

2. Who is in scope, and from when?

Scope is rarely "everyone on day one". It is usually sliced by some combination of turnover threshold, taxpayer category, transaction type (B2B, B2G, B2C, export) and, increasingly, by whether you are receiving or issuing.

The receive-first pattern is worth calling out: several regimes require all businesses to be able to accept structured invoices well before they are required to issue them. That is a much cheaper obligation to satisfy, and it is frequently missed on roadmaps that focus only on the issuing date.

3. Which format, at which layer?

"The mandate requires UBL" is an incomplete sentence. What you need is the full stack: the semantic model, the syntax, the country specification that narrows it, and the version of each. A mandate that adopts a Peppol-based specification behaves very differently from one that defines a bespoke national XML schema, even if both are "XML invoices".

Ask specifically:

• Is there a published CIUS or country specification, and where does its Schematron live?
• Which code lists are mandated, and are they versioned separately from the rules?
• Are other document types in scope — credit notes, self-billing, corrective invoices, debit notes, dispatch or receipt advices?
• Is a human-readable rendering required, and must it match the structured data field for field?

That last one catches people out. Where a rendering is mandated, presentation stops being cosmetic and becomes a compliance artefact with its own test cases.

4. How are parties identified and registered?

Every regime needs to know who is who. The identifier scheme — VAT number, national tax ID, a scheme-qualified network identifier, or a platform-issued code — determines what master data work you are signing up for, and master data is almost always the long pole.

Two sub-questions matter more than they look:

• Is there a registration or accreditation step? Registering as a taxpayer on a portal, or being accredited as a service provider, can carry lead times measured in months and is not something you can compress with engineering effort.
• How do you discover a counterparty's capability? On a network there is a lookup. In a bilateral or portal regime there may be nothing, which means onboarding is a manual, per-customer process you must staff.

Technical build is rarely the critical path. Accreditation lead times and counterparty master data usually are.

5. What must come back, and what must you keep?

In clearance and network regimes, the response is part of the obligation. Work out precisely which artefacts you must capture and be able to reproduce later: a clearance identifier, a signed authority receipt, a network-level acknowledgement, a business-level acceptance or rejection from the buyer.

Then decide where those live. Storing them next to the invoice in your own system, keyed so they can be retrieved on demand years later, is dull work that is very expensive to retrofit.

6. Archiving, signature and integrity

Requirements here vary far more than the invoice format does. The dimensions to check are always the same:

• Retention period and whether it starts at issue, at clearance or at the end of the tax year.
• Where the archive may physically sit — some jurisdictions restrict storage location or require notification of foreign storage.
• Integrity mechanism — an electronic signature or seal, a hash chain, or business controls creating a reliable audit trail. This is a legal choice with an engineering consequence, so get it decided formally rather than assumed.
• What exactly is archived — the structured file, the rendering, the response artefacts, or all three.

7. What happens when it fails?

The last question is the one most often deferred, and it is where operational cost hides. For each failure mode, you want a defined owner and a defined recovery:

1. Rejected by validation — who sees the error, in what language, and how does a business user fix and resubmit?
2. Rejected by the counterparty — is a structured dispute or credit note required, or is a resend acceptable?
3. Platform unavailable — is there a documented offline procedure and a grace period, and does your system implement it?
4. Late or missing submission — what is the penalty regime, and does anything in your monitoring detect it before the authority does?

Answer those and the roadmap almost writes itself: the model gives you the architecture, scope and phasing give you the dates, format and identifiers give you the build, and the failure modes give you the operational runbook — the part that is still running long after the project team has moved on.