Buying and running software in Saudi Arabia
Two requirements shape most Saudi projects, and both are structural rather than cosmetic.
The first is e-invoicing. ZATCA's Fatoora programme moved past simple PDF invoices into a phase requiring invoices to be generated in a defined format, carrying cryptographic elements and a QR code, and integrated with ZATCA systems. For any product that issues an invoice this is not a reporting feature added at the end — it constrains how invoices are numbered, stored and transmitted, so it is scoped at the start. The specific obligations depend on the business's turnover and wave assignment, which the operator confirms.
The second is Arabic. Arabic is expected as a primary language rather than a translation layer, which means right-to-left layout throughout, Arabic numerals and date handling where required, and content that reads as written rather than converted.
Payments centre on mada, the local debit scheme, which most domestic cards run on. A checkout handling only international card brands will decline a large share of real customers, so mada support through Tap, HyperPay or Moyasar is treated as a baseline rather than an addition.
Data residency comes up frequently. Where in-Kingdom hosting is required, that means infrastructure physically located in Saudi Arabia including backups and third-party services — a question reviewed explicitly, since regional proximity does not establish it.
SaaS Development in Saudi Arabia
Saudi SaaS billing has to produce compliant-format invoices per the operator's e-invoicing obligations, which makes invoice generation part of the billing engine rather than a reporting add-on. Subscription records are stored so invoices can be reissued and reconciled. Arabic invoice content and SAR handling are built in, and mada is supported for recurring collection where the gateway allows it.