Tax authorities have two fundamentally different ways to enforce indirect tax: check every invoice as it's issued (clearance) or sample them later and rely on aggregated returns (post-audit). The choice has profound architectural implications for any company building or buying invoicing infrastructure.
Clearance: the authority is on the critical path
In a clearance regime, an invoice is not legally an invoice until the tax authority says so. The seller submits XML to a government endpoint, receives a UUID and a digital stamp, and only then can deliver the invoice to the buyer. Mexico's CFDI, Brazil's NF-e, Italy's SDI, and KSA's ZATCA Phase-2 all work this way.
The implications:
- Latency matters. If the gov API is slow or down, your sales pause. Build retries with exponential backoff and a clear distinction between transient and permanent errors.
- The invoice number is the authority's, not yours. UUIDs flow back from the government and your downstream systems must accommodate that.
- Cancellation is hard. Once cleared, invoices typically need a credit note rather than a deletion. Plan for it.
Post-audit: you keep the records, the authority asks later
Post-audit regimes — most of North America, the UK, much of Asia — let you issue invoices freely and compute VAT/GST on aggregated returns. The authority can audit retroactively, often years later, and demand proof.
Architecturally simpler, but it puts the burden of integrity on you: long retention (5–10 years), tamper-evident storage, and the ability to reconstruct any invoice from any point in time. Hash chains help even when the authority doesn't require them.
Interoperable: the third way
Peppol and similar 4-corner networks are post-audit at the tax authority but clearance at the network. Your AP signs and validates every invoice in real time before it leaves your domain — so you get most of the integrity benefits without the latency hit on the gov critical path.