Saudi ZATCA vs UAE Peppol: E-Invoicing Differences for GCC Groups

A group that invoices from both Riyadh and Dubai is dealing with two of the most different e-invoicing designs in the world. Saudi Arabia built a government clearance platform where the tax authority stamps invoices before they reach the buyer. The UAE chose Peppol, where invoices move between licensed service providers and the tax authority receives a copy of the tax data.

Both countries use UBL 2.1 XML and both require structured data, so it is tempting to treat them as one project. They are not. The integration pattern, failure modes, consumer rules and penalties differ, and your ERP has to respect each. This comparison is written for finance, tax and IT teams designing one architecture for both, with facts as of October 2026.

What Is the Core Difference Between ZATCA and UAE E-Invoicing?

Saudi Arabia uses clearance: a standard tax invoice must be validated and stamped by the Zakat, Tax and Customs Authority (ZATCA) before it is shared with the buyer. The UAE uses a decentralised exchange: Accredited Service Providers send invoices to each other over Peppol and report tax data to the Federal Tax Authority (FTA).

In clearance, the tax authority sits in the critical path. If your connection to ZATCA's FATOORA platform fails, you cannot issue a valid standard invoice. In the UAE's five-corner model, the exchange happens between corners 2 and 3 (the two providers), and corner 5, the FTA, receives a tax data document. Our article on the five-corner model explains each role.

This has a direct effect on system design. A Saudi integration has to be real-time, highly available and able to queue and retry. A UAE integration has to produce clean data and a reliable hand-off to one ASP, with status messages flowing back.

How Do the Two Systems Compare Side by Side?

The table below is the short version. The sections after it explain the parts that matter most for architecture.

How Does Saudi Clearance Actually Work?

For a standard tax invoice, your system builds the UBL 2.1 XML, submits it to FATOORA, and ZATCA validates it, applies its cryptographic stamp and returns the cleared invoice. Only the cleared version may go to the buyer.

Simplified invoices, which cover most consumer sales, follow a reporting flow instead. According to Fiscal Solutions' summary, the business issues the invoice with a QR code and cryptographic stamp immediately and reports it to ZATCA within 24 hours. This lets a till or online checkout keep trading during a short outage.

ZATCA has rolled out Phase 2 in waves by taxpayer group, and its roll-out page commits to notifying each group at least six months in advance. Wave 24 covered taxpayers with VAT-subject revenue above SAR 375,000 in 2022, 2023 or 2024, with a 30 June 2026 deadline. EY reports that wave 25, announced on 24 July 2026, covers taxable turnover above SAR 187,500 in any year from 2022 to 2025, with a 1 February 2027 deadline.

How Does the UAE Peppol Model Work?

Your ERP hands the invoice to your ASP, which converts and validates it as PINT AE, sends it over Peppol to the buyer's ASP, and both providers report tax data to the FTA. The taxpayer does not connect to the FTA directly.

The rules come from Ministerial Decisions 243 and 244 of 2025. Businesses with revenue of AED 50 million or more go live on 1 January 2027 and those below on 1 July 2027, with government entities on 1 October 2027. Business-to-consumer (B2C) transactions are excluded for now. Our UAE e-invoicing guide covers the full timeline and obligations, and PINT AE explained covers the data model.

Because the UAE routes invoices by Peppol participant identifier, buyer data quality matters more than in Saudi Arabia. A wrong or missing buyer identifier means the invoice cannot be delivered to the right receiving ASP.

Which Differences Cause the Most Implementation Problems?

Consumer scope, real-time dependency and cryptography cause most rework. Teams that copy a Saudi design into the UAE, or the reverse, usually trip on one of these.

• B2C scope: Saudi POS and ecommerce systems must produce compliant simplified invoices. In the UAE those same channels are out of scope for now, so building UAE B2C transmission adds cost with no current obligation.
• Real-time dependency: Saudi clearance blocks invoice delivery until ZATCA responds. The UAE allows up to 14 days from the transaction date, so batch processing is possible.
• Cryptography: Saudi invoicing units hold ZATCA-issued certificates and stamp invoices. In the UAE, signing and transport security sit with the ASP and the Peppol network.
• Corrections: ZATCA penalises deletion or alteration of issued invoices, starting from SAR 10,000. Both countries expect credit notes rather than edits, so lock invoices once issued.
• Buyer identifiers: missing buyer VAT numbers are a listed ZATCA violation; in the UAE they break Peppol routing.

How Do You Architect One ERP for Both Countries?

Build one canonical invoice model inside the ERP, then attach a country adapter for each regime. The canonical model holds the superset of fields both countries need; each adapter handles format, transport, security and status.

1. Separate legal entities and tax registrations in the ERP, each with its own invoice sequences, tax codes and country flag.
2. Define a canonical UBL-based invoice covering seller, buyer, line, tax and payment data. Since both regimes are UBL 2.1, most fields map one-to-one.
3. Saudi adapter: applies ZATCA business rules, signs with the unit's certificate, generates the QR code, submits standard invoices for clearance and queues simplified invoices for reporting within 24 hours.
4. UAE adapter: maps to PINT AE, validates against UAE rules, resolves the buyer's Peppol identifier and hands the invoice to your ASP's API.
5. Shared validation layer that blocks an invoice before posting if mandatory data is missing, so neither regime receives bad data.
6. Unified monitoring: one dashboard for clearance responses, ASP status messages, rejections and retries, with alerts before deadlines.
7. Retention and audit: store the cleared or exchanged XML, responses and credit note links per entity.

If Oman is also on your map, the UAE adapter is a strong starting point, because Oman's Fawtara also uses a Peppol five-corner model with PINT specialisations; see our Oman Fawtara guide. For connector options in common platforms, read connecting your ERP to UAE e-invoicing, and if you are weighing a rebuild, custom ERP vs SAP, Odoo or Dynamics.

How Do Penalties Compare in Practice?

Saudi penalties are per violation and escalate with repetition; UAE penalties are mostly monthly or per invoice with caps. Both are designed to make non-compliance more expensive than the project.

ZATCA's published fines start at SAR 5,000 for not issuing electronic invoices and SAR 10,000 for deleting or altering invoices after issuance, while missing QR code elements, missing buyer VAT numbers and failure to notify ZATCA of technical malfunctions begin with a warning. Deloitte notes these can rise to SAR 50,000 on repeat violations, and that it was not clear whether penalties apply per invoice or per tax period.

In the UAE, Cabinet Decision 106 of 2025 sets AED 5,000 per month for failing to implement the system or appoint an ASP, AED 100 per invoice or credit note not issued electronically (capped at AED 5,000 per month), and AED 1,000 per day for failing to notify the FTA of a system failure. Our guide to UAE e-invoicing penalties has the detail.

Which Deadlines Should a multi-GCC Group Track Now?

As of October 2026, the near-term dates are the UAE's 1 January 2027 go-live for large businesses and Saudi wave 25's 1 February 2027 deadline. Both fall within the same quarter, so resource planning matters.

• UAE, revenue of AED 50 million or more: ASP appointed by the end of October 2026; live 1 January 2027.
• Saudi wave 25: integration with FATOORA by 1 February 2027 for taxpayers above SAR 187,500.
• UAE, revenue below AED 50 million: ASP by 31 March 2027; live 1 July 2027.
• Oman: 1 April 2027 above OMR 5 million; 1 October 2027 for others.

How VEATEX Helps

VEATEX is a Shopify, web and software development agency that also builds Peppol e-invoicing platforms for the GCC, working with clients in the US, UK and the Gulf for over 11 years. We built a Peppol platform for a client that passed OpenPeppol testing and is now on the UAE pre-approved ASP list. For multi-country groups, we design canonical invoice models, country adapters and monitoring, drawing on ERP work such as NexCore ERP and FinLedger. See our e-invoicing services and custom software development.