Skip to content

CRMOct 19, 2026 · 9 min read

Custom CRM in Riyadh: ZATCA, Arabic and PDPL

Abidhusain ChidiFounder and CEO

Custom CRM in Riyadh: hand-drawn chalk sketch of a customer card, a ZATCA invoice with a QR square and an in-Kingdom server

Key takeaways

  • Decide first whether the CRM issues tax invoices or hands deals to an ERP or accounting system; the hand-off keeps ZATCA signing, keys and schema changes out of the CRM.
  • Standard B2B invoices are cleared by ZATCA before the buyer sees them; simplified B2C invoices are reported within 24 hours; issued invoices are never edited, only corrected by credit notes.
  • Wave 25 lowers the threshold to SAR 187,500 of revenue subject to VAT, with integration due by 1 February 2027, so smaller Riyadh firms may now be in scope.
  • Arabic work lives in the data: fold letter variants in search, keep Arabic and English names as separate fields, isolate mixed-direction text and make digits a user setting.
  • Build the PDPL into fields: separate consent per purpose with proof, an export and delete per person, and an audit trail good enough for a 72-hour breach notice.
  • Check Saudi cloud regions before you sign: Oracle and Google run them today; Microsoft announced November 2026 and AWS December 2026.

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.

Flow for a custom CRM in Riyadh: standard invoices are cleared by ZATCA before the buyer sees them, simplified invoices are reported within 24 hours
Two routes for a Phase 2 invoice: clear first, or report within 24 hours

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.

ZATCA requirementCRM that hands off to ERP or accountingCRM that issues invoices itself
Clearance of standard invoices before sharingThe ERP calls it; the CRM shows the statusThe CRM must call the API and block sending until cleared
Reporting of simplified invoices in 24 hoursThe ERP; the CRM reads the resultA queue with retries and an alert on the 24-hour limit
Hash chain, UUID, QR code, signingNot the CRM’s jobBuilt in, with one chain per generation unit
Certificates (CSID) per unitHeld by the invoicing systemOnboarding flow and secure key storage
No editing or deleting issued invoicesCorrections arrive as credit notesLock the invoice; “cancel” means a credit note and a new invoice
Arabic invoice content, records kept at least six yearsCustomer data supplied in ArabicArabic 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.

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:

ProviderStatus when we checked, 11 October 2026Source
Oracle CloudJeddah available since 1 February 2020; Riyadh since 31 July 2024Jeddah, Riyadh release notes
Google CloudDammam region opened 15 November 2023Google Cloud
MicrosoftSaudi Arabia East announced for November 2026; check its status before you signMicrosoft
AWSSaudi region “on track to launch in December 2026”; check its status before you signAmazon

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.

TagsCloud hostingCRM DevelopmentCustom CRM DevelopmentCustomer Data Security

Written by

Abidhusain Chidi

Founder and CEO

Founder of QalbIT Infotech and the engineer who still scopes most of its projects. Writes about what custom software really costs, how build-versus-buy decisions play out two years in, and the delivery habits that keep a product shipping, drawn from CRM, ERP, SaaS and MVP work Abid has been building since 2014 and the products QalbIT runs itself today.

FAQ


Frequently asked questions

Only if it issues tax invoices or credit and debit notes. Then it must generate Phase 2 XML, sign it, and clear or report each invoice through ZATCA's Fatoora platform. A CRM that only holds customers, quotes and orders and hands them to an invoicing system leaves that duty with the invoicing system. Confirm the boundary with your accountant.
Clearance applies to standard tax invoices (B2B and B2G): ZATCA must clear them before you share them with the buyer. Reporting applies to simplified invoices (B2C): you issue them first and report the XML to ZATCA within 24 hours.
ZATCA tells each taxpayer its wave at least six months ahead. Wave 25, announced on 24 July 2026, covers taxpayers whose VAT-subject revenue exceeded SAR 187,500 in 2022, 2023, 2024 or 2025, with integration due by 1 February 2027. Check your notification on the ZATCA portal.
The PDPL allows transfers abroad under safeguards such as standard contractual clauses and a risk assessment, so it is not an automatic ban. SDAIA's draft amendments to the Implementing Regulation are open for public comment until 5 November 2026 and are not law yet. Some sectors, such as banking and government work, may set hosting rules of their own, so ask your compliance team.
Yes, if it is designed for it: separate Arabic and English name fields, search that folds Arabic letter variants and diacritics, right-to-left layout with isolated mixed text, and a per-user setting for Arabic-Indic or Western digits.
When we checked on 11 October 2026, Oracle Cloud had Jeddah and Riyadh regions and Google Cloud had Dammam. Microsoft has announced a Saudi Arabia East region for November 2026 and AWS says its Saudi region is on track for December 2026, so check their status before you sign.
Yes. We work remotely from Ahmedabad with a Saudi-hours overlap, and have no office or entity in the Kingdom. The system can run on in-Kingdom hosting under your accounts. See our Riyadh page.

Next step


Want the same clarity for your product?

A short call. A written range. No obligation.