| ZATCA requirement | CRM that hands off to ERP or accounting | CRM that issues invoices itself |
|---|---|---|
| Clearance of standard invoices before sharing | The ERP calls it; the CRM shows the status | The CRM must call the API and block sending until cleared |
| Reporting of simplified invoices in 24 hours | The ERP; the CRM reads the result | A queue with retries and an alert on the 24-hour limit |
| Hash chain, UUID, QR code, signing | Not the CRM’s job | Built in, with one chain per generation unit |
| Certificates (CSID) per unit | Held by the invoicing system | Onboarding flow and secure key storage |
| No editing or deleting issued invoices | Corrections arrive as credit notes | Lock the invoice; “cancel” means a credit note and a new invoice |
| Arabic invoice content, records kept at least six years | Customer data supplied in Arabic | Arabic output and archive both inside the CRM |
Why the hand-off usually wins
For most Riyadh sales teams the hand-off is the better design. The CRM is where a customer is created, a quote is approved and an order is won. It should store the buyer’s VAT number and address as structured fields. Then it passes a clean order to the system that signs invoices and shows the invoice status on the account. By contrast, a signing and clearance engine inside a CRM means owning key custody, retry logic and every ZATCA schema change. ZATCA also bars anyone from modifying or deleting an issued invoice. So an “edit invoice” button in a CRM is a defect, however convenient it looks in a demo.
Arabic data in a custom CRM in Riyadh
Mirroring the screen is the visible part and the easy one. In a CRM the harder Arabic work sits in the records. A salesperson types the same company name three ways and still expects to find it.
Search that finds the customer
Arabic writers use several forms of one letter, and diacritics are optional. For example, a search with a bare alef will miss a customer saved with a hamza above it. The index has to fold the two together. Apache Lucene’s Arabic normaliser is a good reference list. It maps hamza-seated alefs to a bare alef, dotless yeh to yeh and teh marbuta to heh. It also strips diacritics and the stretching tatweel character. The teh marbuta fold is a judgement call, so test it on real customer names before you switch it on. Fold in the search index and the duplicate check, but keep the original spelling for display. Likewise, give each account an English name field and a separate Arabic one.
Mixed text and direction
An RTL page scrambles email addresses, phone numbers and English product names unless you isolate their direction. HTML’s bdi element behaves as if dir="auto" is set, and the Unicode bidirectional algorithm has isolate characters for the same job. Use them on every user-supplied field. Spacing and padding should use CSS logical properties, so that one attribute mirrors the layout.
Digits and dates
We measured the defaults in Node 22 on 11 October 2026. The ar-SA locale formats numbers with Arabic-Indic digits, while plain ar uses Western ones. ZATCA’s guidance accepts either set on an invoice. However, the invoice itself must be in Arabic, with other languages allowed beside it. So make the digit style a per-user setting, and have exports, PDFs and the numbers pasted into WhatsApp follow it. Dates in a CRM mostly mean renewal dates and follow-up reminders. Keep them in Gregorian. If a team wants Hijri on screen, request the islamic-umalqura calendar by name, because ar-SA on its own came back Gregorian in the same test.
PDPL: consent, rights and what moves abroad
The Personal Data Protection Law took effect on 14 September 2023. It became fully enforceable a year later, as Clyde and Co noted in September 2024. For a CRM, the Implementing Regulation turns into field-level behaviour:
- Consent per purpose. Article 11 asks for documented consent, separate for each purpose. So a “newsletter” flag and a “may call about offers” flag are two records, each with a timestamp and a source.
- Marketing evidence. Articles 28 and 29 cover advertising and direct marketing: name the sender, make opting out as easy as opting in, and keep evidence of consent. Under Article 12, withdrawing consent must be as easy as giving it. After a withdrawal, Article 29 says marketing stops without undue delay.
- Rights as features. Articles 4 to 8 cover being informed, access, correction and destruction. In a CRM that means an export of everything held on a person, and a delete that reaches notes, attachments and backups.
- Breach notice. Article 24 gives 72 hours from becoming aware of a breach that could cause harm. A CRM that cannot say who exported which list last Tuesday will struggle to meet it.
- Processing records. Article 33 expects records kept throughout the processing and for five years after it ends.
The regulation itself is the text to hand your lawyer. The transfer rules allow data to leave the Kingdom with safeguards such as standard contractual clauses and a risk assessment. A vendor outside the Kingdom, like us, is a processor you contract with. That contract is where the safeguard gets written down.
A pending change to the rules
One change is on the way, and for now it is only a proposal. On 8 October 2026 the Saudi Press Agency reported that SDAIA’s draft amendments to the Implementing Regulation are open for comment on the Istitlaa platform. Comments close on 5 November 2026. Draft text is not law, and the final wording may differ, so read the draft itself rather than summaries. Either way, a CRM with separate consent records and a map of every copy of a person’s data will absorb most changes without a redesign.
Hosting a custom CRM in Riyadh
Where the database sits is a separate decision from where the engineers sit. Check what exists before you write a region into the contract. When we looked, two of the best-known clouds were still announcing a Saudi region rather than running one:
| Provider | Status when we checked, 11 October 2026 | Source |
|---|---|---|
| Oracle Cloud | Jeddah available since 1 February 2020; Riyadh since 31 July 2024 | Jeddah, Riyadh release notes |
| Google Cloud | Dammam region opened 15 November 2023 | Google Cloud |
| Microsoft | Saudi Arabia East announced for November 2026; check its status before you sign | Microsoft |
| AWS | Saudi region “on track to launch in December 2026”; check its status before you sign | Amazon |
If you are buying rather than building, the same question applies to the CRM vendor. Zoho says its Jeddah and Riyadh data centres were fully operational by March 2024. For HubSpot we found no official statement of Saudi hosting. For Salesforce we found a February 2025 plan, but no go-live date we could confirm. Ask any vendor for the region in writing.
The leaks a CRM adds
A CRM collects more side channels than most systems. Each one can carry personal data out of a well-hosted database. Email sync stores copies of customer threads. Call recordings and uploaded ID scans sit in file storage, which is easy to put in another region by accident. Error trackers can capture form fields, and analytics scripts can capture page URLs that hold names. So put file storage, backups and logs in the database’s region. Our engineers then reach production only through accounts you own.
Messaging and the rest of the integrations
A Riyadh sales team lives in WhatsApp and SMS, so the CRM should log both against the account. Business texts go out under a sender name that your SMS provider registers. Ask the provider for its current fee and naming rules early in the project. Before any marketing message goes, the CRM should check the consent records described above. We have not verified WhatsApp rates, the National Address service or Nafath access for this post. So we leave them out rather than guess.
What to ask before you build a custom CRM in Riyadh
- Does the CRM issue tax invoices, or hand off? Get the answer in the scope, with the boundary drawn.
- Which fields exist twice, in Arabic and English, and how does search treat them?
- Where do the database, backups, logs, file storage and email relay sit?
- Can it export and delete everything held on one person?
Our first release for a CRM usually takes six to 14 weeks, and we answer these four questions before any code is written. Ask for that scope on the CRM development page. We will put the invoicing boundary and the hosting region in writing before we price a custom CRM in Riyadh.




A custom CRM in Riyadh has to pass clean data to ZATCA e-invoicing, find Arabic names however they are spelled and record consent the way the PDPL asks. Templates designed for other markets ask for none of that. Get those three right and the rest is an ordinary sales pipeline. Get them wrong and the rebuild starts after launch.
We build for Gulf clients from Ahmedabad. We have no office or entity in the Kingdom, as our Riyadh page says plainly. This post sticks to what a Saudi build changes in the CRM itself: invoices, Arabic records, consent and where the data sits. If the build-or-buy question is still open, read weighing a build against a Salesforce, HubSpot or Zoho licence first. When you are ready to scope, our CRM development service page shows how we work.
ZATCA e-invoicing and a custom CRM in Riyadh
ZATCA, the Zakat, Tax and Customs Authority, splits e-invoicing into two phases. Phase 1, generation, has applied since 4 December 2021. It ended handwritten invoices and those made in a text editor or spreadsheet. Phase 2, integration, began on 1 January 2023 and reaches taxpayers in waves. ZATCA’s roll-out page says it will tell each taxpayer its wave at least six months ahead.
Meanwhile the waves keep reaching further down. Wave 24 covered taxpayers whose revenue subject to VAT passed SAR 375,000 in 2022, 2023 or 2024. Their deadline was 30 June 2026. Wave 25, announced on 24 July 2026, halves the threshold to SAR 187,500 across 2022 to 2025. Its deadline is 1 February 2027. So a Riyadh distributor that assumed it was too small to be in scope may now be inside it.
Clearance and reporting are different calls
Phase 2 splits invoices into two models. ZATCA has to clear a standard tax invoice before the seller shares it with the buyer. That is usually the B2B kind, and until clearance it is not valid. A simplified invoice, the B2C kind, goes to the customer first. The seller then reports its XML to ZATCA within 24 hours. Credit and debit notes follow the same route as the invoices they correct.
Every invoice also carries a UUID and a QR code. Its XML holds the previous invoice’s hash, so the invoices form a single chain. ZATCA’s security standard lists nine QR tags in TLV, Base64 form. The first five (seller, VAT number, time, total, VAT amount) date from Phase 1. Phase 2 added the other four: XML hash, signature, public key and, on simplified invoices, a signature from ZATCA’s certificate authority.
ZATCA calls the software that signs and sends all this an e-invoice generation solution. You onboard each unit of it through the Fatoora portal. In practice, a one-time password and a certificate request get you a compliance certificate. Once the test documents pass, you get a production one.
Where the CRM stops and the invoicing system starts
Whether your CRM has to do any of this turns on one question. Does it issue tax invoices, or does it hand deals to something that does? We found no ZATCA text on quotations, so treat what follows as our reading. A quote that is not a tax invoice sits outside clearance and reporting. Even so, ask your accountant to confirm that for your case.