- Saudi Arabia runs ZATCA's FATOORA clearance model — Wave 23 (above SAR 750,000) integrates by 31 March 2026 and Wave 24 (above SAR 375,000) by 30 June 2026, effectively reaching all VAT registrants.
- The UAE has chosen a five-corner Peppol exchange (DCTCE) on PINT AE, delivered through Accredited Service Providers — appointment by 30 October 2026, live 1 January 2027.
- Oman's Fawtara combines Peppol with OTA clearance: roughly the 100 largest taxpayers from 1 August 2026, all VAT-registered businesses by August 2027. Bahrain is designing; Qatar approved a draft law on 6 May 2026; Kuwait has no VAT and no mandate.
- A group in two or more GCC states should build one architecture — validated master data plus one integration layer — with per-country activations, not country-by-country projects.
The Gulf states agreed on the destination — every B2B invoice visible to the tax authority in structured form — and then chose four different roads to get there. For a business operating in one country, that is trivia. For a group operating in two or more, it is an architectural decision that most are getting wrong by default.
Here is the map as it stands in June 2026, and what we think it implies.
Saudi Arabia: clearance, nearly complete
ZATCA's FATOORA platform is the region's incumbent and its strictest model. Invoices above the simplified threshold are cleared — cryptographically validated by the authority before they are legally issued. The Phase 2 integration rollout has proceeded in waves since 2023, and the waves have now reached the bottom of the register: Wave 23 covers businesses above SAR 750,000 in VAT-relevant revenues, integrating by 31 March 2026, and Wave 24 reaches those above SAR 375,000 by 30 June 2026. In practical terms, that is everyone. If you hold a Saudi VAT registration and you are not integrated, you are not late for a future deadline — you are past one.
The UAE: exchange, not clearance
The UAE made a deliberately different choice: a Decentralised Continuous Transaction Control and Exchange (DCTCE) model — five-corner Peppol, on the PINT AE specification, with Accredited Service Providers as the exchange layer. Invoices flow between trading parties through ASPs, with the tax data reported to the authority rather than cleared by it in advance. Phase 1 firms must appoint their ASP by 30 October 2026, with live exchange from 1 January 2027.
The distinction matters operationally. In a clearance model the authority can stop your invoice; in an exchange model it sees your invoice. Different failure modes, different latency characteristics, different conversations with your counterparties — but, and this is the point of this article, not different data.
Oman: both at once
Oman's Fawtara programme is the hybrid: Peppol as the transport and interoperability framework, combined with clearance by the Oman Tax Authority. The sequencing starts with roughly the 100 largest taxpayers from 1 August 2026 and extends to all VAT-registered businesses by August 2027. Anyone who assumed Oman would simply copy one neighbour or the other now has a third pattern to support.
Bahrain, Qatar, Kuwait: the queue
Bahrain's National Bureau for Revenue is in design; no dates have been published. Qatar's Shura Council approved a draft e-invoicing law on 6 May 2026 — a law, not yet a technical specification. Kuwait has no VAT and therefore, for now, nothing to mandate. The honest summary is that three more regimes are coming, on unknown timelines, with unknown technical choices.
Which is precisely why designing around any single country's endpoint is a mistake.
The government endpoint is the part of your architecture you control least and change most. Build around the part that stays constant: your own data.
Build once, activate per country
The default behaviour we see in multi-country groups is serial panic: a Saudi project in 2024, a UAE project in 2026, an Oman project in 2027, each with its own vendor, its own mapping exercise, and its own rediscovery of the same master data problems. Each project is rational in isolation. The sum is waste.
The alternative is to recognise what the four models share. Every one of them — FATOORA clearance, PINT AE exchange, Fawtara's hybrid, and whatever Bahrain and Qatar publish — consumes the same underlying substance: a structured invoice built from accurate counterparty identifiers, correct tax registration numbers, clean item and unit-of-measure data, and valid tax-code logic. The schemas differ at the edges. The substrate does not.
That suggests a specific architecture. One canonical invoice data layer, fed by validated master data, sitting between your ERPs and the outside world. One integration layer that transforms the canonical record into each jurisdiction's dialect — ZATCA's XML and clearance handshake, PINT AE over Peppol, Fawtara's requirements as they finalise. Country go-lives then become activations: configure the legal entity, map the local fields, certify the connection, switch on. Weeks of work at the edge, not a fresh project at the core.
What the common layer buys you
Three things, in our experience. First, the master data work — the genuinely hard part of every e-invoicing implementation — is done once and reused, instead of being re-litigated per country with three different vendors finding the same defects. Second, regulatory change is absorbed at the edge: when a jurisdiction revises its specification, you update one transformation, not your finance processes. Third, you keep optionality on providers. A group whose canonical data layer is its own can change its ASP in the UAE or its integration vendor in Riyadh without touching the core — which connects directly to the exit questions we have written about elsewhere.
The discipline, not the endpoint, is the asset. Four clearance models is an annoyance. Four copies of your own invoice architecture is a choice — and it is the one choice in this programme that remains entirely yours.