Most GCC compliance articles are written about deadlines that are still coming. Saudi Arabia is the opposite problem: the deadlines that matter most have already passed, quietly, in waves, and a large number of businesses selling into the Kingdom are non-compliant without having noticed the moment it happened.
Three separate regimes now shape how you invoice, how you handle customer data and where that data is allowed to live. They are run by three different authorities, on three different clocks, and each one lands on a different part of your business. This is what they actually require, in plain terms, and the order I would fix them in.
E-invoicing: the threshold that keeps halving
The Zakat, Tax and Customs Authority has been rolling out Phase 2 of e-invoicing in waves since 2023, each one pulling smaller businesses into scope. The pattern is simple and relentless: the revenue threshold halves, and another tier of the economy has to integrate.
Wave 23 covered businesses with VAT-subject revenue above SAR 750,000, with an integration deadline of 31 March 2026. Wave 24 halved that to SAR 375,000 and closed on 30 June 2026. ZATCA’s Wave 25 announcement halves it again to SAR 187,500, using 2022, 2023, 2024 or 2025 as reference years, with an integration deadline of 1 February 2027.
Read that reference-year detail carefully, because it catches people out. It is not your current revenue. If your VAT-subject revenue crossed the threshold in any one of those years, you are in scope — including a business that has since shrunk. In practice, if you invoice in Saudi Arabia at any meaningful scale, assume Wave 25 applies to you and work backwards from February.
What Phase 2 actually changes
Phase 1 asked you to produce electronic invoices. Phase 2 is a different order of thing: your system has to talk to ZATCA’s Fatoora platform over an API, and for business-to-business invoices, ZATCA is now in the middle of the transaction rather than reviewing it afterwards.
Standard invoices — B2B and B2G — must be cleared by ZATCA in real time before they are issued to the buyer. Simplified invoices, the B2C ones, may be handed over immediately but must be reported within 24 hours. Both carry a cryptographic stamp tied to a Cryptographic Stamp Identifier issued to your system, and both have to be produced in ZATCA’s structured XML format rather than as a PDF someone designed in a word processor.
The practical consequence is the part businesses underestimate. If your invoicing lives in a spreadsheet, in an old accounting package with no Saudi support, or in a custom system nobody maintains, there is no configuration that makes it compliant. The system itself has to change, and that is a project with a lead time — which is why starting in January for a February deadline is how businesses end up paying for an emergency migration. The full technical specifications sit on ZATCA’s e-invoicing portal.
Data protection: enforcement is live, and it is being used
Saudi Arabia’s Personal Data Protection Law moved from grace period to full enforcement on 14 September 2024, regulated by the Saudi Data and Artificial Intelligence Authority. This is the part I find businesses in Kuwait and the UAE are least prepared for, because it is easy to assume a data protection law is aspirational until someone is actually fined under it. Dozens of enforcement decisions have already been issued across a range of sectors, and penalties reach SAR 5 million, doubled for repeat violations.
The obligations are recognisable if you have dealt with any modern privacy regime: a lawful basis for processing, honouring data subject requests within statutory deadlines, a tested breach response plan with notification duties to both the regulator and affected individuals, and controls on transferring personal data outside the Kingdom. The SDAIA publishes the law and its implementing regulations in English, including an English translation of the PDPL itself, which is worth reading rather than relying on a summary.
What makes this expensive is not usually the policy document. It is that nobody can answer the operational questions: which systems hold Saudi customers’ personal data, who has access, how long it is kept, and what happens in the first 72 hours after a breach. Those answers exist in your architecture, not in a legal template, which is why this lands on engineering as much as on legal.
Cloud and data residency: where the data is allowed to live
The third regime is the Cloud Computing Regulatory Framework, run by the Communications, Space and Technology Commission. Cloud service providers serving the Saudi market register with the CST and are assigned a class that determines which data classifications and sectors they are permitted to serve.
For most commercial businesses this is a procurement question rather than a licensing one, but the residency rules bite in specific sectors. Government data must stay in the Kingdom, with narrow exceptions. Financial institutions face similar constraints, and hosting outside Saudi Arabia generally requires prior approval from the Saudi Central Bank — which is why many providers simply host everything in-Kingdom rather than manage the approval risk. Details and registration categories are published by the CST.
If you are selling software or services into Saudi Arabia, expect to be asked where your data sits, and expect “AWS, somewhere in Europe” to be an unsatisfactory answer for a bank or a ministry.
Three regulators, three owners inside your business
The most common failure I see is treating this as a single compliance project with a single owner. It is not. ZATCA lands on finance and whoever owns the ERP. SDAIA lands on legal, marketing and engineering simultaneously, because consent, retention and access controls are all implemented in software. CST lands on IT and procurement. A business that assigns all three to one person, usually the most junior available, discovers the gaps during an audit.
If you sell into Saudi Arabia from Kuwait or the UAE
Being based elsewhere in the GCC does not exempt you. If you have a Saudi VAT registration, ZATCA’s e-invoicing rules apply to your Saudi invoicing. If you process personal data of individuals in the Kingdom, PDPL is in play regardless of where your servers are — and the cross-border transfer provisions are precisely the part that applies to you.
This also runs in the opposite direction. The UAE has its own set of technology deadlines arriving on a similar timetable, which I have set out in the guide to the UAE’s 2027 deadlines for Dubai and Abu Dhabi. If you operate across both markets, the sensible move is to build once to the stricter standard rather than maintaining two half-compliant setups.
The order I would fix these in
First, establish whether Wave 25 applies to you. Check VAT-subject revenue across 2022 to 2025, not just last year. This takes an afternoon and determines whether you have a February deadline or not.
Second, find out what your invoicing system can actually do. Not what the vendor’s marketing page claims — whether it holds a valid CSID, clears through Fatoora, and produces compliant XML today. If the answer is no or unclear, that is your critical path and everything else waits.
Third, map where Saudi personal data lives. Every system, every export, every marketing tool, every spreadsheet on someone’s laptop. You cannot comply with PDPL, or answer a data subject request, without this map, and producing it usually surfaces two or three things nobody knew were happening.
Fourth, check residency against your sector. If you serve government or financial clients, verify your hosting arrangement before a client’s procurement team does it for you.
Fifth, and only then, automate. There is real value in using AI to reconcile invoices, triage data subject requests and monitor retention — but automating a process that is not yet compliant simply produces non-compliance faster. The sequencing argument is the same one I make in the piece on using AI in operations.
Why this is a technology decision, not a paperwork one
Every one of these regimes is enforced against your systems rather than against your intentions. ZATCA does not read your invoicing policy; it reads your API calls. SDAIA does not audit your privacy notice in isolation; it asks what your systems actually do with the data. That makes compliance an architecture question, and architecture questions are decided badly when they are delegated to whoever is free.
For most mid-sized businesses in the region the gap is not knowledge, it is that nobody senior owns the decision. That is the case I make on the Fractional CTO page, and it applies with particular force here, because the cost of getting it wrong now arrives as a fine rather than as a missed opportunity. If the AI and automation layer on top is what interests you, that work is described on the AI consulting page.
One last thing worth saying plainly: none of this is a reason to avoid the Saudi market. It is the largest economy in the GCC and it is digitising deliberately rather than accidentally. The regulation is a cost of entry, and the businesses that treat it as an engineering problem now will find it a one-off. The ones that treat it as paperwork will pay for it repeatedly. And if your Arabic customer experience is an afterthought while your compliance is immaculate, you have solved the wrong half of the problem — the guide to Arabic UX in the GCC covers the other half.
Dates move. I keep a tracker of every dated compliance obligation across the GCC, each one checked against the regulator’s own source.
Frequently asked questions
How do I know whether ZATCA Wave 25 applies to my business?
Check your VAT-subject revenue in each of 2022, 2023, 2024 and 2025 separately. If it exceeded SAR 187,500 in any one of those years, you fall into Wave 25 and must integrate with the Fatoora platform by 1 February 2027 — even if your revenue has fallen since. ZATCA notifies targeted taxpayers directly, but waiting for the notification rather than checking yourself leaves you very little lead time to change systems.
Can I keep issuing PDF invoices in Saudi Arabia?
Not as your compliance mechanism. Under Phase 2 the invoice must be generated in ZATCA’s structured XML format, carry a cryptographic stamp, and pass through the Fatoora platform — cleared in advance for B2B and B2G invoices, or reported within 24 hours for B2C. A human-readable PDF can accompany that, but a PDF produced in a word processor is not a compliant invoice on its own.
Does Saudi PDPL apply to a company based in Kuwait or Dubai?
It can. The law is concerned with the processing of personal data relating to individuals in the Kingdom, so location of your office or servers is not by itself a defence. If you market to, sell to or support Saudi customers, work on the assumption that it applies and pay particular attention to the rules on transferring that data outside Saudi Arabia. This is a question worth putting to a Saudi-qualified lawyer rather than settling internally — I am not one.
What are the penalties for getting this wrong?
Under PDPL, fines reach SAR 5 million and may be doubled for repeat violations, and SDAIA has already issued enforcement decisions across multiple sectors. ZATCA operates its own penalty regime for e-invoicing non-compliance, and has run periodic initiatives waiving or reducing fines — the terms and end dates of those change, so check ZATCA’s current position rather than relying on a figure quoted in an article, including this one.
Does my data have to be hosted inside Saudi Arabia?
It depends on your sector and your customers. Government data must remain in the Kingdom, with narrow exceptions, and financial institutions face tight constraints with offshore hosting generally requiring prior Saudi Central Bank approval. For an ordinary commercial business there is no blanket residency requirement, but if you sell to regulated sectors their procurement will impose one on you contractually — so the practical answer is often yes, whatever the strict legal position.
How long does it take to become compliant?
The determining factor is your invoicing system, not the paperwork. If you already run an ERP with a supported Saudi e-invoicing module, integration is weeks. If you are moving off spreadsheets or an unsupported legacy system, it is a migration project and should be planned in months. The data protection side runs in parallel and is usually gated by how quickly you can produce an honest map of where personal data currently sits.