Choosing an ERP System for a Saudi Business

ERP selection goes wrong in a predictable way. A committee builds a requirements matrix of four hundred line items, every vendor answers "yes" to nearly all of them, the decision defaults to price or brand, and eighteen months later the finance team is maintaining a parallel spreadsheet because the system cannot produce the report the auditor wants in Arabic.

The requirements that determine success in the Kingdom are not the generic ones. Every serious ERP does general ledger and inventory. The differentiators are local, and they are the ones a global demo will never surface.

Localisation is not translation

Ask a vendor whether their product supports Arabic and they will say yes. What they usually mean is that the interface has been translated. That is the smallest part of the problem.

Test these specifically:

• Bilingual master data. Can a customer, supplier, item and chart-of-accounts entry hold both an Arabic and an English name simultaneously, and can a document be printed in either language from the same record? Systems that treat Arabic as a UI language rather than a data attribute force you to choose, and you will need both — Arabic for the government submission, English for the group consolidation.
• Hijri calendar. Not merely displaying a Hijri date, but handling it in HR: leave entitlements, end-of-service calculations, contract periods and reporting cycles that run on the Hijri year. This is where thin localisations break.
• Right-to-left in generated documents. Invoices, statements and purchase orders with mixed Arabic text and Latin product codes. Ask to see a real printed document, not a screenshot of the UI.
• Arabic in reporting and search. Sorting Arabic names correctly, searching with and without diacritics, and exporting to Excel without the encoding falling apart.

The statutory integrations that are non-negotiable

These four determine whether the system is usable in Saudi Arabia at all. Treat any gap as disqualifying rather than as a customisation opportunity.

ZATCA e-invoicing. Phase 2 integration — clearance for standard invoices, reporting for simplified ones, cryptographic stamping and compliant XML. Ask specifically whether it is native, delivered through a partner add-on, or something you would be building. The answer changes your cost and your risk materially. Ask also who is responsible for keeping it current when the specification changes.

VAT. Correct handling of standard, zero-rated and exempt supplies, reverse charge on imports, and the ability to produce a return that reconciles to the ledger without manual assembly.

WPS payroll. Wage Protection System file generation in the required format. Payroll that cannot produce a valid WPS file is not payroll you can run in the Kingdom.

GOSI and end-of-service. Correct contribution calculation for Saudi and non-Saudi employees, and end-of-service benefit calculation that follows the Labour Law rules — including the differences between resignation and termination, and the treatment of service periods. This calculation is subtle, it is frequently wrong in generic systems, and errors are expensive because they surface at the point an employee is leaving.

The realistic option space

Broadly there are three tiers, and the honest way to choose is by organisational complexity, not by revenue.

Tier one — global enterprise suites. Deep functionality, mature Saudi localisation, large partner ecosystems in the Kingdom. Appropriate for genuinely complex operations: multiple legal entities, multiple currencies, sophisticated manufacturing or project accounting. Expensive not primarily in licences but in implementation, and they require internal capability to run. Choosing one for a fifty-person trading company is a common and costly error.

Tier two — mid-market and open-source platforms. Strong functional coverage at a fraction of the implementation cost, with Saudi localisation typically delivered through regional partners or add-on modules. This is where most Saudi mid-sized businesses should be looking. The critical question is the quality and maintenance commitment of the localisation layer — because it is a partner module, and it can be abandoned.

Tier three — local and vertical products. Built for the Saudi market, often with excellent statutory compliance and Arabic support out of the box. Strong for standard operations in retail, contracting or services. The trade-offs are narrower functionality at the edges, smaller ecosystems, and concentration risk on a single vendor.

Where the money actually goes

Licence cost is the number in the proposal and the smallest part of the total. Budget realistically for:

• Implementation and configuration — commonly a multiple of first-year licence cost, higher when processes are non-standard.
• Data migration — almost always underestimated, because the work is not moving data, it is cleaning it. Duplicate customers, items with no consistent coding, opening balances that do not reconcile, historical transactions in inconsistent formats. Start this before you sign, because it is independent of which system you choose.
• Integration — with your e-commerce platform, point of sale, banking, and any system you are keeping.
• Training — in Arabic, for the people who will actually use it, delivered close enough to go-live that it is retained.
• Ongoing support and the annual localisation maintenance — the recurring cost of staying compliant as regulations change.

Why implementations fail

Automating the current process rather than fixing it. If your approval chain has seven steps because of a fraud incident in 2016, encoding all seven into the ERP makes them permanent. Implementation is the only realistic moment to simplify. Use it.

Customising instead of adapting. Every customisation is a permanent tax on upgrades. A useful rule: if the standard process is merely unfamiliar, adapt. Customise only where the difference is genuinely a competitive advantage or a regulatory necessity.

No internal owner. An ERP implementation led entirely by the vendor produces a system that reflects the vendor's assumptions. You need a named internal owner with authority to make decisions, allocated real time — not a project sponsor who attends a steering meeting monthly.

Big-bang go-live. Switching every module and every entity on a single date maximises the blast radius. Phase where you can: finance first, then supply chain, then HR — or one legal entity before the rest.

Skipping parallel running. Run the old and new systems together through at least one full month-end close. The discrepancies you find are the ones that would otherwise have been discovered by your auditor.

A selection process that works

1. Document your actual processes first — order to cash, procure to pay, hire to retire, record to report. Two weeks of internal work, and it makes every subsequent conversation sharper.
2. Separate must-have from nice-to-have honestly. Statutory compliance is must-have. A specific dashboard layout is not.
3. Shortlist three, no more. Longer lists produce paralysis and a decision made on spreadsheet scores rather than judgement.
4. Demand scenario demos on your data. Provide a sample of your real master data and require them to run your scenarios in it.
5. Reference-check with Saudi customers of similar size. Ask specifically about the statutory modules and what broke after go-live. Ask what they would do differently.
6. Evaluate the implementation partner as seriously as the software. Most failures are partner failures, not product failures. Meet the actual consultants who will be assigned, not the sales team.

The decision underneath the decision

The best ERP choice is rarely the most capable system. It is the system your organisation can actually absorb — implement in a reasonable time, staff, and keep current — that also handles Saudi statutory requirements natively rather than through work you will end up owning. Optimise for that, and the functionality question mostly takes care of itself.