GCC e-invoicing models compared

GCC e-invoicing models compared

GCC and wider Middle East e-invoicing runs on at least three different technical models, not one regional standard: Saudi Arabia clears invoices through a government platform, the UAE routes them through a decentralised five-corner Peppol network, and Jordan and Egypt issue them through a national tax-authority platform. It matters because the model, not just the country, decides what an ERP or invoicing system has to build or buy to comply.

A business that only knows Saudi Arabia's ZATCA cannot assume the same integration pattern will work in the UAE or Jordan; each model puts a different party between the invoice and the tax authority, and getting that party wrong means a compliant Saudi setup that still fails a UAE or Jordanian audit.

The three models below are not simply different paperwork requirements layered on the same VAT return; they are different answers to the same underlying question, who validates an invoice and when, and that question shapes the software contract, the vendor relationship and the go-live timeline a finance team has to plan around.

Saudi Arabia: the clearance model

Fatoora Phase 1, the Generation Phase, became enforceable on 4 December 2021 for resident taxpayers, requiring e-invoices to be generated in a structured electronic format from the start. Phase 2, the Integration Phase, has been enforceable since 1 January 2023 and rolls out by taxpayer group in waves; ZATCA notifies each wave at least six months before its integration date, and the most recent, Wave 25, covers taxpayers with revenue above SAR 187,500, with integration due no later than 1 February 2027.

Under Phase 2, a taxpayer's own e-invoicing solution integrates with ZATCA's Fatoora platform by API in real time, issuing invoices in a specific XML format with a UUID, a cryptographic stamp from a ZATCA-issued certificate, a hash chaining each invoice to the one before it, and, on a simplified invoice, a QR code. This is a clearance model: the taxpayer's system does the compliance work and reports to or is cleared by the government platform as part of issuing the invoice, not through a separate third-party network.

The UAE: the five-corner Peppol network

The UAE's national programme, run jointly by the Ministry of Finance and the Federal Tax Authority, uses a decentralised five-corner, Peppol-based continuous transaction control model. Corner 1 is the supplier, Corner 2 the supplier's Accredited Service Provider (ASP), Corner 3 the buyer's ASP, Corner 4 the buyer, and Corner 5 the FTA; both ASPs independently report invoice data to the FTA as transactions happen, rather than the supplier's own system talking to the government directly.

Invoices must use the PINT AE format, a UAE localisation of the Peppol International invoice standard, and must be transmitted only through an MOF-accredited service provider; an unstructured PDF, Word file or scanned image does not qualify. The voluntary pilot opened 1 July 2026. Phase 1 covers businesses with annual revenue of AED 50 million or more, which must appoint an ASP by 30 October 2026 and go live from 1 January 2027; Phase 2 covers remaining taxpayers, with an ASP appointment deadline of 31 March 2027 and mandatory e-invoicing from 1 July 2027.

Jordan and Egypt: platform issuance

Jordan's JoFotara, live since December 2022 and mandatory for all taxpayers by 31 May 2024, and Egypt's ETA e-invoicing system, rolled out in seven waves to reach effectively all VAT-registered B2B issuers by April 2023, both work by issuing the invoice through the national platform itself. In Jordan, Phase 2 of JoFotara, live since 1 April 2025, means an invoice issued outside the platform is invalid for the buyer's tax-deductible expense recognition and input VAT credit; in Egypt, every e-invoice is digitally signed and assigned a unique UUID by the ETA platform before it is handed to the customer, and a separate e-receipt system covers point-of-sale and B2C transactions.

The practical effect is that the national platform, not the taxpayer's own software and not a network of accredited third parties, is the single point every invoice passes through to become legally valid. A supplier's system submits the invoice data to the platform, and only the validated, stamped result is a real invoice.

What each model demands of an ERP

The three models place the compliance work in three different places, which changes what a business actually has to build, buy or integrate.

• Clearance (Saudi Arabia): the taxpayer's own e-invoicing solution generates, cryptographically stamps and hash-chains the invoice, then calls ZATCA's API directly; the compliance logic lives inside the business's own software
• Five-corner Peppol (UAE): the taxpayer's system produces PINT AE data and hands it to an Accredited Service Provider; the ERP itself never talks to the FTA, and choosing the right ASP matters as much as the ERP's own capability
• Platform issuance (Jordan, Egypt): the taxpayer's system submits invoice data to the national platform (JoFotara, ETA) and receives back the validated, UUID-stamped document that is the legal invoice
• Every model needs the same underlying discipline first: clean, unique invoice numbering, accurate VAT category codes on every line, and archiving of the structured file, regardless of which party does the clearing

What's coming next in Bahrain and Oman

Neither Bahrain nor Oman has a live e-invoicing mandate as of September 2026, but both have signalled which model they are likely to follow. Bahrain's National Bureau for Revenue is building a phased B2B mandate expected to be modelled on Saudi Arabia's clearance approach, though exact effective dates are not yet published. Oman's programme, named Fawtara and led by the Oman Tax Authority, is explicitly built on a Peppol-based interoperability model, closer in spirit to the UAE's network, with a pilot expected from August 2026, large VAT-registered businesses in scope from February 2027, and the remaining VAT-registered businesses by August 2027.

Worked example: the same sale, three different technical journeys

A distributor with entities in Saudi Arabia, the UAE and Jordan sells an identical batch of goods, worth 10,000 in local currency, to a local business customer in each country. In Saudi Arabia the invoice is drafted at SAR 10,000 plus 15 percent VAT of SAR 1,500, a total of SAR 11,500; the taxpayer's own e-invoicing solution stamps it, chains its hash to the previous invoice, and calls ZATCA's Fatoora API, and only then is it handed to the customer. In the UAE the invoice is drafted at AED 10,000 plus 5 percent VAT of AED 500, a total of AED 10,500, built in PINT AE format and passed to the supplier's Accredited Service Provider, which transmits it across the Peppol network to the buyer's ASP while both ASPs report the data to the FTA. In Jordan the invoice is submitted to JoFotara for validation; once the platform returns a UUID, that validated document, not the draft the distributor first produced, is what the Jordanian customer can use to claim its input credit.

• Saudi Arabia: SAR 10,000 + 15% VAT (1,500) = SAR 11,500, cleared through ZATCA's Fatoora API
• UAE: AED 10,000 + 5% VAT (500) = AED 10,500, transmitted via the supplier's and buyer's ASPs on the Peppol network
• Jordan: submitted to JoFotara for validation; the platform-issued, UUID-stamped invoice is the one the customer can use for its input credit

Operating across two of these countries

A group with entities in two of these markets is really running two separate compliance projects, not one e-invoicing project applied twice. A Saudi-and-UAE group needs a ZATCA-facing clearance integration on one side and a relationship with an accredited service provider on the other, two different technical architectures rather than one system pointed at two endpoints. A Saudi-and-Jordan group needs a ZATCA API integration and a separate JoFotara submission path, and must treat a Jordanian invoice as legally incomplete until the platform's UUID comes back, a step Saudi Arabia's own workflow does not impose in the same way.

The safest planning approach is to map each entity to its country's model first, budget the integration, whether direct API, ASP relationship or platform submission, separately for each, and only then look for a system that can run more than one of these models at once rather than assuming one country's approach transfers to the next.

Timing adds a further complication: Saudi Arabia's waves, the UAE's two phases and Jordan's own rollout schedule rarely line up on the calendar, so a group's e-invoicing programme is really several overlapping deadlines rather than one project with a single go-live date. Building in the slower country's lead time, rather than assuming the fastest deadline applies everywhere, avoids a last-minute scramble in whichever entity was assumed to have more time.

Common mistakes across GCC e-invoicing models

Most cross-border e-invoicing problems come from assuming one country's rules generalise.

• Assuming a ZATCA-compliant solution is automatically ready for the UAE, when the UAE model requires an Accredited Service Provider, not a direct government API call
• Treating a JoFotara or ETA-validated invoice as optional paperwork, when an invoice issued outside the platform can be invalid for the buyer's input credit or deductible expense
• Building a PDF invoice and assuming it satisfies any of these mandates, when all three require structured, machine-readable data, not a picture of an invoice
• Skipping master-data discipline, unique numbering and VAT category codes because 'the platform will catch errors', when a rejected invoice still delays payment and compliance either way

GCC e-invoicing models and Skyline Nexus ERP

Skyline Nexus ERP already runs live e-invoicing through its ZATCA module for Saudi Arabia: onboarding through compliance certificate issuance, compliance checks, clearance and reporting of invoices, and XML and QR output, all inside the same Fiscal Authority ledger that posts the sale. Invoice numbering is set per branch, tax rates carry a VAT or excise category, and sales returns are issued as credit notes, with a ZATCA-filed invoice locked from further edits, the disciplines every one of the three models above depends on.

National e-invoicing connectors for the UAE's five-corner Peppol network, Jordan's JoFotara and Egypt's ETA are being rolled out market by market: tell us your country and we will confirm your go-live date. Until a given country's connector is live, the workable route is an accredited service provider or the national platform fed with Skyline Nexus sales data through the same REST API that already exposes sales, sales returns, contacts and taxes.