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.
Software Modernization in Saudi Arabia
Modernisation enquiries from Saudi Arabia are often driven by a specific deadline: an existing system that cannot produce invoices in the required e-invoicing format, or cannot be hosted where the business now needs it. Scope starts by separating what must change to meet the requirement from what merely looks dated, so the deadline work ships first and the rest follows.
