Clearance vs Reporting Models in E-Invoicing: How ZATCA, MyInvois, FIRS, MTD, and Peppol Differ

Every e-invoicing mandate in the world fits one of two architectural families. In a clearance model, the tax authority validates and stamps each invoice before it is legally valid — ZATCA, MyInvois, GST IRN, NRS MBS, and Mexico's CFDI live here. In a reporting model, the invoice is valid at issuance and the regulator receives the data after the fact for reconciliation — UK MTD, Spain SII, and the EU's ViDA Digital Reporting Requirements live here. A handful of regimes (ZATCA Phase 2 B2C, France from 2026) operate in a hybrid space.

Why the model matters before the mandate matters

Most implementation pain comes from misreading the model, not from misreading the schema.

Most implementation pain comes from misreading the model, not from misreading the schema. A clearance regime makes the tax authority a runtime dependency of your billing process — uptime, latency, and rejection handling become first-class concerns. A reporting regime keeps invoicing on your timeline and pushes the regulator's controls to reconciliation. Pick the wrong mental model and you will under-engineer queues, retries, and operator visibility.

The clearance model

In a clearance model the seller transmits the structured invoice to the tax authority's portal, the portal validates schema and content, returns an identifier (IRN, UUID, cleared XML with cryptographic stamp), and only then is the invoice legally valid.

In a clearance model the seller transmits the structured invoice to the tax authority's portal, the portal validates schema and content, returns an identifier (IRN, UUID, cleared XML with cryptographic stamp), and only then is the invoice legally valid. The buyer typically receives the cleared document with the regulator's stamp or QR embedded.

Live clearance regimes:

• ZATCA Phase 2 (Saudi Arabia, B2B) — XAdES signature with CSID, cleared via Fatoora.
• GST IRN (India) — 64-char IRN hash from one of six NIC-authorised IRPs.
• NRS MBS (Nigeria) — IRN issued by the NRS.
• MyInvois (Malaysia) — UUID issued by LHDN with a 72-hour rejection window.
• Italy SDI, Mexico CFDI, Türkiye e-Fatura — the historical reference architectures.

The reporting model

In a reporting model the seller continues to issue invoices on their own systems and transmits the data to the tax authority — sometimes per invoice, sometimes aggregated periodically — for reconciliation against the VAT return. The invoice is legally valid at issuance; clearance is not required.

In a reporting model the seller continues to issue invoices on their own systems and transmits the data to the tax authority — sometimes per invoice, sometimes aggregated periodically — for reconciliation against the VAT return. The invoice is legally valid at issuance; clearance is not required.

Live reporting regimes:

• UK MTD for VAT — digital records + 9-box periodic submissions to HMRC's VAT API.
• Spain SII — near-real-time transactional reporting (4 working days for most flows).
• EU ViDA DRR from 2030 — mandatory digital reporting for intra-community B2B, EN 16931 syntaxes.
• ZATCA Phase 2 B2C — invoice valid at issuance, reported to ZATCA within 24 hours.
• SARS (South Africa), ZIMRA (Zimbabwe) — reporting flows layered on existing VAT returns.

The hybrid space

Some regimes split by transaction type.

Some regimes split by transaction type. ZATCA Phase 2 is clearance for B2B and reporting for B2C. France's reformed regime (from September 2026) routes invoices through certified Plateformes de Dématérialisation Partenaires that both clear the invoice and report it to the tax authority. Italy applies clearance via SDI domestically but reporting via the cross-border esterometro for non-resident counterparties.

Peppol as a network layer

Peppol is not a regulator — it is a four-corner exchange network.

Peppol is not a regulator — it is a four-corner exchange network. A Peppol document can carry either a clearance flow (France: Peppol via PDP into the public portal) or a reporting flow (most B2B in Belgium, Germany, the Nordics). The model is determined by what the receiving country does with the document, not by Peppol itself. See Peppol vs national portals for the network-vs-clearance comparison and what is a Peppol Access Point for the transport details.

Side-by-side comparison

Side-by-side comparison — ZATCA Phase 2 B2B (KSA): Clearance — Cleared XML + CSID stamp.

Operational consequences

What changes for clearance?

The regulator is a runtime dependency. Your platform must queue submissions when the portal is down, retry with backoff, and surface clearance status to the operator.

The regulator is a runtime dependency. Your platform must queue submissions when the portal is down, retry with backoff, and surface clearance status to the operator. You cannot "ship and reconcile later" — without clearance there is no invoice. Build observability for portal latency and rejection rates from day one.

What changes for reporting?

Invoicing flows normally. Failures show up at reconciliation, not at issuance, so the platform's job is to keep clean digital records and submit accurate aggregates on the cadence the regulator expects.

Invoicing flows normally. Failures show up at reconciliation, not at issuance, so the platform's job is to keep clean digital records and submit accurate aggregates on the cadence the regulator expects. Tolerance for batch retries is higher; the operator's eye is on month-end and quarter-end, not on every transaction.

What changes for hybrid?

Both controls in the same tenant. The platform must route by transaction type and surface clearance status only for the clearance leg.

Both controls in the same tenant. The platform must route by transaction type and surface clearance status only for the clearance leg. France's PDP model adds the lifecycle status flow, which is an extra reporting obligation layered on top of the clearance flow.

How to route your transactions

Routing is determined by three things: (1) the seller's tax residence, (2) the buyer's tax residence and type (B2B / B2C / B2G), and (3) the goods or services classification.

Routing is determined by three things: (1) the seller's tax residence, (2) the buyer's tax residence and type (B2B / B2C / B2G), and (3) the goods or services classification. The Invoicemonk mandate matrix resolves all three for every supported jurisdiction; for a checklist when picking a platform, see choosing an e-invoicing platform checklist.

Key takeaways

Key takeaways includes: Clearance puts the regulator on the critical path of every invoice; reporting keeps invoicing on the seller's timeline. Hybrid regimes mix both — route by transaction type in a single tenant.

• Clearance puts the regulator on the critical path of every invoice; reporting keeps invoicing on the seller's timeline.
• Hybrid regimes mix both — route by transaction type in a single tenant.
• Peppol is a transport network, not a model; the receiving country decides whether the flow is clearance or reporting.
• The single biggest engineering decision is queue-retry-resubmit for clearance vs reconciliation cadence for reporting.
• Picking the wrong mental model is the leading cause of go-live failure.

Related reading

For the artefact at the heart of clearance, see what is an IRN and what is a CSID. For the network-style alternative, see Peppol vs national portals.

For the artefact at the heart of clearance, see what is an IRN and what is a CSID. For the network-style alternative, see Peppol vs national portals. For the live country regimes, see ZATCA Phase 2 explained, FIRS MBS Nigeria explained, and Peppol EU explained.

Authority sources

• ZATCA — E-Invoicing Detailed Technical Guideline v2
• NRS Merchant Buyer Solution portal — Nigeria
• NIC IRP — India IRN attribute mapping
• HMRC Developer Hub — VAT (MTD) API
• European Commission — VAT in the Digital Age (ViDA)
• OpenPeppol — Peppol BIS Billing 3.0
• HMRC — VAT Notice 700/22: Making Tax Digital for VAT