Making Your Software Saudi-Ready in 2026: Cost and Checklist

The short answer

Making an existing product "Saudi-ready" in 2026 is rarely a translation project. In our experience the work splits into four buckets — Arabic and right-to-left interface, ZATCA e-invoicing, data protection and hosting decisions under the Saudi PDPL, and local payment and identity rails — and a mid-sized B2B SaaS or internal business application typically needs 60–180 developer-days to clear all four properly. Teams that budget only for translation usually discover the invoicing and data-transfer work after they have already signed a Saudi customer.

This guide breaks down what each bucket actually requires, what drives the cost up or down, and the order we recommend doing it in. If you want the market context first, our Saudi Arabia technology hub covers how we work with companies entering or scaling in the Kingdom. Stratgik is a technology firm, not a law firm or a tax adviser — everything below describes implementation requirements as published by the regulators, and you should confirm your own legal position with qualified Saudi counsel before relying on it.

Bucket 1: Arabic and right-to-left, done properly

Arabic is not a locale file. It is a bidirectional script, which means your layout engine, not just your copy, has to change. The work that consistently gets underestimated:

• Mirrored layout. Navigation, tables, progress indicators, icons with directional meaning, and chart axes all flip. If your CSS uses left/right rather than start/end logical properties, this is a sweep through every stylesheet.
• Mixed-direction strings. An Arabic sentence containing a Latin product name, a VAT number or an IBAN is where bidirectional rendering breaks. Expect genuine bugs here, not cosmetic ones.
• Typography and fonts. Arabic glyphs need greater line height and a font with proper shaping. Many Latin-first design systems clip ascenders and descenders in Arabic at their default line spacing.
• Text expansion. Arabic strings are often shorter than English but taller; fixed-height buttons and single-line truncation break in different places than you expect.
• Numerals and dates. Decide early whether you render Eastern Arabic numerals or Western digits, and whether Hijri dates appear anywhere. Saudi government and commercial practice uses both; many enterprise buyers expect to see a Hijri date alongside the Gregorian one on documents, even though the ZATCA e-invoicing specification itself uses Gregorian YYYY-MM-DD.

On the content side, there is a hard requirement worth knowing: a Saudi tax invoice must be issued in Arabic, with any other language present only as an accompanying translation. That is a VAT invoicing rule, not a UI preference, and it means your document templates need Arabic as the primary layer even if your application stays bilingual. ClearTax's summary of KSA VAT invoicing sets out the mandatory invoice fields alongside the language rule.

A realistic range for this bucket, assuming a product with 40–80 screens and no prior internationalisation: 25–60 developer-days. If your codebase already ships a second language and uses logical CSS properties, halve it. If strings are hard-coded in components, double it.

Bucket 2: ZATCA e-invoicing is an engineering project

If your software issues invoices for a Saudi entity — or if you sell a product your customers will use to issue them — the Fatoora requirements are the most technically demanding part of Saudi readiness. The ZATCA E-Invoicing Implementation Resolution specifies, among other things:

• Invoices generated as XML, or PDF/A-3 with embedded XML, with XML mandatory for transmission to the Authority.
• A UUID on every invoice and credit/debit note, alongside a sequential invoice reference number.
• A cryptographic stamp created via cryptographic algorithms, using a stamping identifier issued through the Authority's portal, with stamping keys held non-exportable.
• A QR code carrying the seller's name, VAT number, timestamp, total with VAT and VAT total — plus, since 1 January 2023, the invoice hash, an ECDSA signature and the public key.
• Hash chaining: each invoice embeds the previous document's hash, so deletions and substitutions are detectable.
• A tamper-resistant counter that increments on every issuance and cannot be reset or reformatted.

The resolution also explicitly prohibits counter resets, changing the software clock, modifying timestamps, running multiple invoice sequences, and exporting stamping keys. That prohibition list is a design constraint: it rules out several patterns that are normal in ordinary billing systems, such as regenerating a document or back-dating a correction.

Two further points teams miss. First, clearance and reporting behave differently: standard tax invoices are cleared by the Authority, which inserts the stamp, while simplified invoices are stamped by your own solution and reported afterwards. Your architecture has to support both paths, including a defensible offline mode. Second, onboarding and certificate lifecycle management — CSR generation, compliance checks, renewal — is ongoing operational work, not a one-time integration.

Budget 20–60 developer-days to build this against the ZATCA sandbox, or 8–20 days to integrate a certified local e-invoicing provider and keep only the mapping layer in-house. For most companies whose core business is not invoicing, the second option is the better trade. Our build vs buy calculator is a reasonable way to pressure-test that decision with your own numbers.

Bucket 3: Data protection, hosting and cross-border transfer

This is where the architecture decision sits, and it is the one with the longest lead time. Under the Saudi Personal Data Protection Law, transferring personal data outside the Kingdom requires a lawful purpose, a minimum-necessary limitation, and — in the absence of an adequacy finding for the destination — an approved safeguard. SDAIA publishes Standard Contractual Clauses in four templates (controller-to-controller, controller-to-processor, processor-to-processor, processor-to-controller), and substantive changes to those templates are themselves treated as a violation. Larger groups can instead adopt Binding Common Rules, which are more flexible but costlier and subject to SDAIA review. The law firm HFW has a useful comparison of the SCC and BCR routes, and ITIF's analysis of the transfer regulation gives the policy background.

A common and expensive misconception is that cloud hosting must be inside the Kingdom. The National Cybersecurity Authority's Cloud Cybersecurity Controls originally included in-Kingdom delivery subcontrols; the 2024 revision removed them, and localisation questions were moved to the National Data Management Office at SDAIA. That does not make residency a non-issue — it means residency is now a data-classification and sector question rather than a blanket cloud rule, and it needs to be answered for your specific data before you commit to a region. Note also that the CCC applies to government tenants and to private-sector operators of critical national infrastructure, and binds cloud service providers serving them regardless of where the provider is based.

What this costs depends almost entirely on one choice: single global tenancy with an approved transfer mechanism, or a Saudi-resident deployment.

Decide this before you write localisation code, because it determines how many environments every later change has to ship to. If you are weighing it up, our Saudi PDPL compliance implementation page sets out how we scope the assessment, and the Saudi Arabia hub covers the wider entry questions.

Bucket 4: Payments, identity and the last mile

For anything consumer-facing or transactional, local rails decide conversion. In practice that means supporting mada — the domestic card network that carries the large majority of Saudi card transactions — alongside Apple Pay and the local wallets, rather than assuming international Visa and Mastercard acceptance is enough. Many foreign-issued gateways will authorise a mada card poorly or not at all, so this is usually a gateway selection decision rather than a code change.

On identity, government and many regulated services expect Nafath, the national single sign-on, for verified Saudi users. Integrating it is not difficult, but it needs an eligible local entity, so it tends to be gated by your commercial structure rather than your engineering capacity.

If any part of your product will be procured by a government entity, add the Digital Government Authority's digital platform requirements to scope, including its web accessibility guideline for government websites. Accessibility retrofits on a mature front end are among the least predictable items in a Saudi readiness plan; doing them alongside the right-to-left work is substantially cheaper than doing them afterwards.

Allow 10–30 developer-days for this bucket, excluding anything blocked on entity formation or commercial approvals.

What the whole thing costs

Rolling the four buckets together, for a product with a single web application and an existing API:

Convert developer-days at your own blended rate. Our app cost estimator will give you an indicative figure if you do not have one, and our custom software development page explains how we structure this kind of staged delivery. These are planning ranges based on the scope described above, not quotations, and a discovery pass on your actual codebase will move them in either direction.

A practical sequencing checklist

1. Classify your data first. List every category of personal data, who the controller is, and which sector rules apply. This decides the hosting question, and the hosting question decides everything else.
2. Pick the transfer mechanism. If no adequacy finding covers your destination, select the right SDAIA SCC template and get it executed. Do not redline it.
3. Decide build or buy on e-invoicing before committing to a billing architecture. Validate against the ZATCA sandbox either way.
4. Convert the front end to logical CSS properties and extract every hard-coded string, before writing any Arabic copy. This is the single highest-leverage refactor.
5. Commission Arabic copy from a native reviewer, not machine translation with a proofread. Financial and legal terminology is where machine output fails most visibly to enterprise buyers.
6. Do accessibility and right-to-left in the same pass if government procurement is plausible within two years.
7. Select the payment gateway on mada authorisation rates, not on headline pricing.
8. Write down who owns certificate renewal for ZATCA stamping identifiers and who monitors regulatory change. Both regulators revise guidance regularly; CCC-2:2024 removing the in-Kingdom subcontrols is a good example of why an un-owned assumption gets stale.
9. Budget 15–20% of the project for a second pass after your first Saudi customer uses the product in anger. Something in the bidirectional rendering or the invoice template will need fixing.

Frequently asked questions

Do we have to host our software in Saudi Arabia?

Not as a general rule. The NCA's Cloud Cybersecurity Controls removed the in-Kingdom delivery subcontrols in the 2024 revision and localisation questions moved to the National Data Management Office at SDAIA. Residency is now driven by your data classification, your sector and your customers' contracts rather than a blanket cloud requirement, so it has to be assessed for your specific data. Confirm your position with Saudi counsel before designing around it.

Can we issue invoices in English only for our Saudi entity?

No. A Saudi tax invoice must be issued in Arabic; another language can appear as a translation alongside it. Practically, that means Arabic has to be the primary layer in your invoice templates even if the rest of your application is bilingual.

Is machine translation good enough for an Arabic interface?

For navigation labels and generic microcopy it gets you a usable draft. For financial, legal and contractual language it does not, and enterprise buyers notice immediately. The cost-effective pattern is machine translation for first pass plus a native Arabic reviewer with domain knowledge for everything a customer signs, pays or disputes.

How long does the ZATCA integration take if we use a local provider?

Most teams building only the mapping and reconciliation layer against a certified provider complete it in six to ten weeks of elapsed time, with roughly 8–20 developer-days of effort. Building the cryptographic stamping, hash chain and clearance handling yourself is a multi-month project and adds permanent maintenance.

What is the most commonly underestimated line item?

Bidirectional rendering of mixed Arabic and Latin strings, and the accessibility retrofit if government procurement appears later. Both are cheap when planned into the same front-end pass and expensive when bolted on afterwards.

Do we need a Saudi legal entity to do any of this?

Not for the localisation and e-invoicing engineering itself, but entity status gates several of the local rails, including Nafath integration and some payment and government procurement routes. If those are on your roadmap, resolve the commercial structure in parallel rather than after the build.

Where to go next

If you are scoping Saudi readiness, the two documents worth producing before any code is written are a data classification map and a build-or-buy decision on e-invoicing. Everything else follows from those. Our Saudi Arabia hub, PDPL compliance implementation and custom software pages set out how we approach each stage, and how we engage explains the commercial model.

If it would help to talk it through, book a free 30-minute session with the Stratgik team. We will go through your data classification, your invoicing path and a realistic range for your own codebase — and tell you plainly which parts you should not build yourself.