Selling Into Saudi: Two E-Invoicing Regimes, One System

A Dubai trading company wins a supply contract in Riyadh. The commercial team is delighted. Six months later there is a Saudi LLC, a warehouse in the industrial city, three staff, and a finance manager in Dubai who has just been told by the Saudi accountant that invoices cannot be issued from the group system, because they have to be cleared by the tax authority first, and the group system does not do that.

The proposal that follows is always the same: a separate accounting package in Riyadh, bought locally, already compliant. It solves this month's problem and creates a decade of them. Two item masters. Two customer masters. Two versions of what the group sold. An intercompany reconciliation performed by hand. A consolidated view assembled in a spreadsheet by the one person who understands both.

The premise of that proposal — that two regimes need two systems — is wrong, but only if you understand precisely what the Saudi regime requires and where it genuinely differs from the UAE one. That is what this piece is about.

First, establish whether you are actually in scope

This is the question most often answered wrongly, in both directions, and getting it right saves a great deal of money.

The Saudi e-invoicing regulation applies to taxable persons resident in the Kingdom who are registered or required to be registered for VAT, and to third parties issuing tax invoices on behalf of such persons. Non-resident taxable persons are outside it.

So: a UAE company that ships goods from Jebel Ali to a Saudi buyer, with no establishment in the Kingdom, is generally not the party obliged to issue a cleared Saudi e-invoice. That supply is an export from the UAE under UAE rules, and the Saudi buyer deals with the import under Saudi rules. Your commercial invoice still matters — it is the document their accounts payable and their customs process work from — but it is not a ZATCA document.

The moment that changes is the moment you have a Saudi resident presence: a subsidiary, a branch, a fixed establishment, or local supplies that require Saudi VAT registration in your own name. Then the entity making the supply is in scope, and every tax invoice and every credit or debit note it issues has to pass through the regime.

Confirm your own position with a Saudi tax adviser rather than with this article. Residence and fixed establishment are fact-dependent, and a warehouse with staff who conclude contracts is a different answer from a freight-forwarder's bonded space. But do it early, because the answer determines whether the work below is a project or a footnote.

Clearance and reporting are two different obligations

Under Phase 2 — the integration phase — Saudi invoices split into two types with genuinely different lifecycles.

	Standard tax invoice	Simplified tax invoice
Who it is for	Business and government buyers	Consumers
What happens before the buyer gets it	Transmitted to ZATCA, validated, returned cleared	Nothing — it is issued directly
When the authority sees it	Before the buyer does	Within 24 hours of issue
The mechanism	Clearance	Reporting
What proves validity	The authority's cryptographic stamp on the returned document	The seller's own stamp and QR code
What happens if the platform is unreachable	The invoice cannot be legally shared	The invoice is issued and reported when connectivity returns

The word to sit with is clearance. For a business-to-business invoice, the tax authority is inside the transaction, in real time, before the document reaches your customer. That is a structurally different arrangement from the UAE model, where an accredited provider carries the document across a network and the authority receives the data from the network rather than standing in the path.

The operational consequence is the one people underestimate. In a clearance regime, the authority's platform is a dependency of your ability to invoice. Not of your ability to report, or file, or reconcile — of your ability to hand a customer a valid tax invoice at all. Your system needs a queue, a retry, a status and an escalation for the case where clearance is slow or unavailable, and your finance team needs to know what they are allowed to do in the meantime. Most implementations build the happy path and discover the rest during the first outage.

Credit and debit notes follow the type of the invoice they correct: those relating to standard invoices are cleared, those relating to simplified invoices are reported. And as in any structured regime, the correcting document references the original in a field, which means the habit of cancelling and reissuing is finished on both sides of the border.

What actually changes inside the invoice

A compliant Phase 2 document is not a PDF with a QR code stapled to it. Several technical artefacts have to be generated by whatever system issues the invoice.

A structured XML document, in UBL 2.1 form, carrying the invoice as data rather than as layout. For standard invoices, what is shared with the buyer is a PDF/A-3 file with that XML embedded inside it, so a single file is both human-readable and machine-readable.

A UUID, distinct from your invoice number. Your sequential number remains and remains meaningful. The UUID is a separate globally unique identifier for the document.

A hash chain. Each document carries a hash of the previous one. This is the mechanism that makes the sequence tamper-evident: you cannot quietly remove document 4,471 from history, because 4,472 contains its fingerprint.

An invoice counter value, incrementing without gaps, per issuing unit.

A cryptographic stamp, produced using a certificate the issuing unit obtains by onboarding with the authority. For standard invoices, the authority applies its own stamp on clearance, and that stamp is what makes the document valid.

A QR code, encoded in a defined binary structure and carrying the seller's identity, the timestamp, the totals, the VAT amount and the stamp.

Each of these is a capability, not a field. This is why "our ERP supports Saudi VAT" is not an answer to the question — VAT support is a tax code and a return; this is a signing, chaining and clearance pipeline attached to the moment of posting.

The EGS unit is why branches multiply the work

The regime treats each issuing unit as a separate onboarded solution: it generates a certificate request, receives a cryptographic identity, and maintains its own counter and hash chain.

If your Saudi entity issues everything from one instance of one system, that is one onboarding and one chain. If it has three branches issuing independently, or a set of point-of-sale terminals in retail outlets, each becomes its own unit with its own identity, its own counter, and its own reporting obligation. Certificates expire and have to be renewed. A unit that is decommissioned has to be handled properly rather than switched off.

For a group that assumed Saudi compliance was a connector, this is the surprise: the operational burden scales with how many places you issue documents from, and nobody counts those places until somebody asks.

Arabic is not a translation project

Saudi tax invoices must be issued in Arabic. Other languages may appear alongside it, but Arabic is the required language and it applies to more than the template's headings.

The part that costs time is the item master. A UAE trading company's product descriptions are in English, written by whoever created the record, frequently abbreviated, occasionally meaningless outside the warehouse. Every item that the Saudi entity sells needs an Arabic description that is a real description of the goods, and somebody with product knowledge and Arabic has to write them. That person is not the implementation consultant.

There are second-order effects worth planning for. Your ERP has to hold a genuinely multilingual item master rather than a single description field, so the same product record serves both entities with the right language on the right document. Your reports and your printed layouts have to render right-to-left properly, which is a real technical concern and one where a numeric fraction or a ratio inside Arabic text can display reversed to the reader while being entirely correct in the underlying data. And your users in Riyadh will want the interface in Arabic, which is a language pack decision but also a training and documentation decision.

Names and addresses matter too: the seller's and buyer's legal names in Arabic, national addresses in the structured Saudi format. That format is more prescriptive than the UAE's, and it is not satisfied by a text blob with line breaks.

The two regimes, side by side

	UAE	Saudi Arabia
Model	Decentralised network with accredited providers	Centralised authority platform
Where the authority sits	Receives data from the network	Inside the transaction for standard invoices
Who you contract with	An Accredited Service Provider you appoint	ZATCA directly, plus whatever tooling you use
B2C treatment	Outside the mandate	Inside it, as simplified invoices reported within 24 hours
Language	English acceptable	Arabic required
Document artefact	Structured document transmitted across the network	Signed XML, and PDF/A-3 with embedded XML for standard invoices
Failure mode	Rejected by a provider, retried	Not cleared, therefore not issuable to the buyer
What proves a document is valid	The network's acknowledgement	The authority's cryptographic stamp

Read that table as a design brief rather than a comparison. The columns differ in almost every row, which is why the naive response is two systems. But look at what they have in common: both need a clean counterparty master with correct registration numbers, both need item-level tax classification, both need a document that is final at posting, both need a status lifecycle with a queue and an owner, and both need arithmetic that reconciles under someone else's rounding rules.

The common part is the majority of the work, and it is the part that lives in your data.

One system, two regimes

The architecture that works is unremarkable once stated: one ERP database, one item master, one customer master, separate legal entities inside it, and a per-entity localisation layer that decides how a document leaves the building.

What stays common. Products and services, with descriptions in both languages and a classification that supports tax determination in either regime. Customers and suppliers, deduplicated, each attached to the entity or entities that trade with them. The chart of accounts structure, even where account codes differ by statutory requirement. Approval rules, roles, and the definition of when a document is final.

What stays separate. The tax configuration, which is not a shared code list with an extra column — a UAE zero-rated export and a Saudi zero-rated export are different rules with different evidence requirements. The document sequences, per entity and per issuing unit. The transmission path: an accredited provider for the UAE entity, a clearance integration for the Saudi one. The statutory reporting and the local chart of accounts mapping. And the currency, with all that implies for how intercompany balances are held and revalued.

What has to be designed rather than defaulted. The moment of posting. In both regimes, posting is the point of no return, but the consequences differ: in the UAE the document leaves for the network, in Saudi it goes for clearance and comes back changed. Your users need to understand that the document they see after posting is not the document they created, and your system needs to store what came back rather than what went out.

This is the same discipline that makes a UAE group with mainland and free zone entities workable in one database rather than several: hold the entity boundary rigidly, share the master data deliberately, and let the statutory layer differ. The reasoning is set out at more length in what free zone versus mainland actually changes in your ERP, and it generalises across borders better than most people expect.

The traps that only appear in a group

Intercompany flows now have two audiences. When the Dubai entity sells stock to the Riyadh entity, that is an export from one and an import into the other, and it is also a related-party transaction that both tax authorities may examine. The transaction has to exist as documents on both sides at a price you can defend, not as a monthly journal. That connects directly to the transfer pricing evidence that corporate tax now expects you to hold, and the discipline is identical: every intercompany flow is a document, never a narration.

Two mandates, two dates, one team. The UAE waves and the Saudi waves are set by different authorities on different schedules. A group can easily face a Saudi integration deadline and a UAE go-live within a few months of each other, resourced by the same finance function. Sequencing that is a planning exercise, and the sequence usually wants to be Saudi first — a clearance regime is stricter, and the data discipline it forces makes the UAE work easier rather than harder.

Your Saudi wave is not your choice. ZATCA has rolled Phase 2 out in waves defined by prior-year turnover, announcing each with several months of notice, and the thresholds have descended over successive waves to the point where the great majority of VAT-registered residents are now covered. Confirm which wave your Saudi entity falls into with ZATCA directly, and do it before you assume you have time.

The person in Riyadh is not the person in Dubai. Clearance failures happen locally, in Arabic, in local business hours, on documents a Dubai finance team cannot read. The failure queue needs an owner in the right time zone and the right language, and their work needs to be visible to group finance without being blocked by them.

What to do, in order

Establish scope first: is the Saudi entity resident and registered, and which wave applies. That single answer determines whether everything below is urgent or theoretical.

Then do the data, because it is the part that is slow and the part that no vendor will do for you. Arabic descriptions for every item the Saudi entity sells. Saudi customers with correct VAT registration numbers and structured national addresses. Tax determination by rule rather than by convention, tested on real transactions including the ugly ones. This is the same work described in the UAE readiness plan, and doing it once for both regimes is the whole argument for one system.

Then count your issuing units and plan the onboarding and certificate lifecycle for each. Then build the failure loop — status, queue, owner, daily routine — before go-live rather than after, in both entities.

And resist the local package. The saving is real and it is a one-off; the cost is a permanent seam through the middle of your group's data, which is exactly the failure pattern examined in the integration paradox. A group that runs two countries in one system has one version of what it sold. A group that runs two systems has an argument every month about which version is right.

If you are weighing that decision now, the honest starting point is a written view of what your current platform can and cannot carry across both regimes before anyone signs anything — which is where an ERP implementation with a multi-country scope should begin, not where it should end.