How to Choose an ERP System: A 5-Step Framework for Saudi Enterprises

Most ERP selection projects start too late: teams compare demos before agreeing what decision the new system must support. That is why how to choose an erp system is a requirements and governance problem, not a software popularity contest. A defensible process defines business outcomes, gathers testable requirements, builds an independent shortlist, runs fit-gap scenarios, checks Saudi-specific obligations, and scores total cost and delivery risk before any recommendation is approved.

The difficult part is rarely finding ERP vendors. The difficult part is creating a selection process that prevents a polished demo, an incumbent relationship or a low headline price from becoming the decision before the evidence has been collected.

CFOs, COOs and IT directors should therefore agree the decision framework before suppliers enter the room. Once vendors begin shaping the agenda, it becomes harder to distinguish a genuine requirement from a capability that simply happens to demo well.

How to Choose an ERP System: Define the Decision Before You Compare Products

An ERP replacement is not one decision. It is a sequence of decisions about process standardisation, operating-model change, integration, data, controls, localisation, implementation risk and long-term cost.

Before comparing products, write a short decision statement that answers three questions: what business problem is being solved, what must materially improve after implementation, and which constraints the selection cannot violate.

For example, “replace the legacy ERP” is too broad. A better decision statement may be: select a platform that supports multi-entity finance, procurement and inventory across Saudi operations while reducing manual reconciliations, maintaining required tax and invoicing controls, and integrating with the current customer and warehouse systems.

The decision statement should then define what is genuinely open to choice. Some organisations are willing to redesign processes around standard ERP functionality. Others have operational requirements that cannot be changed without creating commercial or regulatory problems.

A useful five-step ERP selection process is:

1. Define the decision. The executive sponsor, CFO, COO and IT lead should agree business outcomes, scope boundaries and non-negotiable constraints. Allow roughly three to five working days once the right stakeholders are available.

2. Gather testable requirements. Process owners, finance, IT, security and data leads should convert current needs into scenario-based requirements. Allow roughly two to four weeks depending on organisational complexity.

3. Build the shortlist independently. The evaluation team should screen the market against agreed requirements before vendor influence shapes the criteria. Allow roughly one to two weeks for a focused market scan and evidence review.

4. Test fit through real scenarios. Process owners and technical specialists should run structured demonstrations, fit-gap workshops and integration reviews. Allow roughly two to three weeks for a serious shortlist.

5. Score cost, risk and fit. Finance, procurement, IT and business sponsors should normalise commercial proposals, score evidence and prepare the final recommendation. Allow roughly one week after the final evidence is complete.

The sequence matters. If product demonstrations start before requirements and scoring rules exist, the organisation is no longer evaluating the market against its needs; it is often rewriting its needs around what suppliers chose to show.

Step 1: Build Requirements That Survive Contact With a Demo

ERP requirements gathering often fails because teams produce long spreadsheets full of statements such as “supports purchasing”, “has reporting” or “handles inventory”. Almost every serious ERP supplier can answer yes to requirements at that level.

A useful requirement describes the business condition, the expected system behaviour and the evidence needed to prove the capability.

Separate Outcomes, Capabilities and Constraints

Start with business outcomes. Examples include shortening financial close activity, reducing manual purchase approvals, improving stock visibility or supporting a new multi-entity operating model.

Then translate those outcomes into capabilities. A need for better inventory visibility may require lot tracking, warehouse transfers, inventory valuation, replenishment rules, mobile transactions and integration with external logistics systems.

Finally, document constraints that are not simply functional preferences:

• Regulatory constraints: Tax, invoicing, data, audit or sector-specific requirements that the selected design must support.

• Architecture constraints: Existing identity, integration, data or infrastructure standards the ERP must work with.

• Operating constraints: Language, locations, business hours, subsidiaries, currencies and organisational structures.

• Delivery constraints: Required implementation timing, internal capacity, migration windows and dependencies on other programmes.

Write Requirements as Testable Scenarios

Instead of asking whether the ERP “supports procure-to-pay”, ask the vendor to demonstrate a representative transaction from purchase request through approval, order, receipt, invoice matching and posting, including the exception that currently causes manual intervention.

The same principle applies to finance. Do not ask whether the software supports consolidation; provide the actual entity structure, currencies, intercompany pattern and reporting outcome that matter to your organisation.

Requirements should also distinguish what the system must provide natively from what can reasonably be delivered through configuration, extension or integration. If every gap is automatically solved with custom development, the evaluation stops measuring product fit.

Once the requirements are clear, the team can examine the relevant product category without assuming that every platform serves the same operating model. A practical starting point is to review the ERP systems we work with and then test each relevant category against your own requirements rather than against generic feature lists.

Step 2: Move From Longlist to Shortlist Without Vendor Input

The longlist should be broad enough to avoid prematurely protecting the incumbent or the best-known brand, but not so broad that every supplier in the market receives an RFP.

Start with objective exclusion criteria. These may include organisational scale, geographic coverage, relevant functional depth, deployment model, integration capability, sector suitability, local support and the ability to meet mandatory Saudi requirements.

Then classify requirements into three groups:

• Mandatory: Failure means the product does not progress, unless the requirement itself is reconsidered.

• Weighted: Better capability improves the score but is not an automatic pass or fail.

• Differentiating: Capabilities that meaningfully separate otherwise credible finalists.

This prevents teams from treating a cosmetic feature and a fundamental operating requirement as if they deserve the same weight.

A shortlist built mainly from vendor marketing is already biased. Suppliers naturally emphasise the use cases where their platforms are strongest, so the buyer should establish the comparison set independently before demonstrations begin. A neutral view of the best ERP for Saudi companies can help frame the realistic market before suppliers are invited to influence the evaluation criteria.

Product-to-product comparisons become useful only after the organisation has identified which architecture and operating assumptions matter. For buyers deciding between different enterprise and cloud ERP approaches, a focused netsuite vs sap s4hana comparison can expose questions that deserve deeper testing rather than deciding the winner on brand reputation.

Keep the Shortlist Short Enough to Evaluate Properly

Adding more finalists can make a process look rigorous while reducing the quality of evaluation. Every additional vendor requires scenario preparation, technical review, commercial normalisation, reference work and stakeholder time.

The purpose of the shortlist is not to prove that procurement considered every available ERP. It is to identify the small number of products that have enough evidence of fit to justify expensive evaluation effort.

Step 3: Run Fit-Gap Against Your Actual Processes

A scripted vendor demonstration is not a fit-gap assessment. It shows what the supplier wants to demonstrate, usually in a clean environment with prepared data and a sequence designed to avoid awkward exceptions.

Fit-gap analysis reverses control. The buyer provides scenarios, data assumptions and exception cases, then records whether the product fits natively, requires configuration, needs integration, depends on an extension or creates a genuine process gap.

A practical fit-gap classification can use:

• Native fit: The requirement is handled by standard product capability with acceptable configuration.

• Configuration fit: The requirement can be met through supported setup without custom code.

• Extension fit: The capability requires an approved extension, low-code component or add-on.

• Integration dependency: The outcome depends on another platform or interface.

• Process change: The organisation must change how it works to use the standard design.

• Material gap: No acceptable solution exists without disproportionate customisation, risk or cost.

Test the Difficult Transaction, Not the Happy Path

Every business has processes that look simple in a flowchart but become complex at exceptions. ERP selection should concentrate on those points.

For finance, test corrections, intercompany activity, partial processing, multi-entity controls and period-end exceptions. For procurement, test rejected approvals, mismatched invoices, returns and delegation. For inventory, test adjustments, transfers, traceability and unusual fulfilment conditions.

The demo should also expose the evidence needed by IT. Ask where configuration lives, how APIs are managed, how permissions are separated, which capabilities depend on partner products and what happens during upgrades.

When the shortlist contains products with different ecosystem assumptions, comparison should focus on the consequences rather than only the feature labels. For example, a netsuite vs dynamics 365 review is most useful when it helps the buyer identify differences in operating model, integration, surrounding tools and implementation dependencies that should be tested during fit-gap.

Document every material gap while the demonstration is happening. Do not let unresolved items become “to be confirmed later”, because those are often the issues that become change requests after the contract is signed.

Step 4: Test Saudi-Specific ERP Requirements

Saudi requirements should be part of the selection criteria from the beginning, not added as a localisation workstream after the preferred product has been chosen.

The correct question is not whether a vendor has customers in Saudi Arabia. It is whether the proposed product, configuration, implementation partner and operating model can satisfy the requirements that apply to your entity.

ZATCA E-Invoicing Integration

ERP buyers should verify how the proposed solution supports the Zakat, Tax and Customs Authority's electronic invoicing requirements applicable to their organisation.

The assessment should test the complete operating flow rather than a screenshot of an invoice. That includes how invoice data is generated, validated, transmitted or integrated where required, how rejected transactions are handled, and how evidence is retained for finance and audit teams.

Ask the vendor to demonstrate:

• How the ERP produces the required invoice information from the underlying transaction.

• How integration with the applicable ZATCA e-invoicing process is handled.

• What happens when an invoice fails validation or communication.

• Which component is provided by the ERP vendor, implementation partner or third-party provider.

• How updates to regulatory requirements are maintained after go-live.

A product may be technically capable of supporting the requirement while the proposed implementation design is not yet ready. Score the actual solution architecture being offered, not a general statement that the ERP is “Saudi compliant”.

Arabic and Bilingual Operation

Arabic capability should be tested in the real user experience. Translating selected menus or printing an Arabic report is not the same as supporting bilingual operations across finance, procurement, inventory and management reporting.

Ask representative Arabic-speaking users to test:

• User-interface behaviour and right-to-left presentation where relevant.

• Arabic customer, supplier and item master data.

• Bilingual forms, invoices and business documents.

• Search, filtering and reporting when Arabic and English data coexist.

• Training material and local support in the language users will actually work in.

The evaluation should distinguish between technical Arabic support and operational Arabic parity. A platform can display Arabic correctly but still depend on English-only administration, configuration documentation or support processes that create operational friction.

Zakat and VAT Handling

ERP software should support the accounting data and transaction controls required by the organisation's tax processes, but the system itself does not replace tax policy or specialist tax interpretation.

Test tax codes, adjustments, exemptions where relevant, transaction classifications, reporting extracts and the controls finance needs to prepare filings and respond to audit questions.

Zakat should be approached with the same discipline. The ERP needs to produce reliable financial and master data that supports the organisation's calculation and reporting process, while specialist interpretation remains a finance and tax responsibility.

Do not accept “Saudi localisation included” as sufficient evidence. Ask the supplier to map the proposed design to the organisation's actual legal entities, transaction types and finance processes.

Data Residency and Regulatory Scope

Data residency should not be reduced to a generic requirement that every Saudi organisation must host everything inside the Kingdom. The applicable requirement depends on the entity, sector, data type, system architecture and regulatory scope.

During ERP selection, document:

• The primary hosting location.

• Backup and disaster-recovery locations.

• Where administrators and support personnel can access data from.

• Which subprocessors or cloud services participate in delivery.

• How personal data and sensitive organisational data are classified.

• Which NCA, NDMO, PDPL or sector-specific obligations apply to the proposed arrangement.

The purpose is to identify the actual obligation before architecture is locked in. Data residency, cross-border access and personal-data transfer are related questions but should not be treated as identical requirements.

For regulated entities, the ERP team should involve security, privacy and compliance functions early enough that a hosting or support model can still be changed without restarting the commercial process.

Step 5: Score Fit, TCO and the Final Recommendation

The final ERP recommendation should be built from evidence collected before commercial pressure peaks. A weighted score alone is not enough, but it is useful when every finalist has been evaluated using the same criteria and evidence rules.

A practical scoring model may include:

Normalise Cost Before Comparing It

Commercial proposals rarely have the same boundary. One may include implementation, another may exclude migration, and another may make internal customer effort look like a zero-cost assumption.

Build the five-year cost model using the same users, entities, modules, implementation scope, integration assumptions, support model and growth assumptions for every finalist.

Then test whether changing a major assumption changes the ranking. If one small change in licence growth or implementation effort reverses the preferred option, the recommendation should show that sensitivity rather than hiding it behind one total score.

Separate Scoring From Judgement

A weighted score should inform the recommendation, not automate it. A product with the highest arithmetic total may still have an unresolved mandatory gap, a delivery dependency the organisation cannot manage or a level of customisation that changes the business case.

The scoring method should therefore sit inside a wider technology evaluation framework that records evidence, mandatory gates, risks and decision rationale rather than treating the spreadsheet total as the decision itself.

Once the evidence is complete, the recommendation should explain why the selected platform is preferable, which trade-offs are being accepted and what must be validated before contract signature.

If your team has reached the scoring stage but supplier proposals, fit-gap evidence or commercial assumptions are still difficult to compare, a focused ERP consulting and selection review can be used to normalise the decision evidence before the organisation commits to the implementation.

ERP Selection Mistakes That Cost the Most

The most expensive ERP selection mistakes usually happen before implementation. By the time they become visible, contracts are signed, project teams are mobilised and changing direction is politically and financially harder.

• Starting with demos: The supplier defines the agenda before the organisation has defined its requirements.

• Choosing by brand recognition: Market size or reputation is treated as evidence of fit for the organisation's processes.

• Allowing one department to dominate: Finance, operations or IT optimises for its own concerns while enterprise trade-offs remain unresolved.

• Using hundreds of equal-weight requirements: Minor conveniences dilute the influence of requirements that genuinely determine business fit.

• Accepting generic localisation claims: Saudi tax, invoicing, Arabic and regulatory requirements are assumed rather than demonstrated.

• Ignoring implementation dependence: The product is evaluated separately from the partner, migration approach and integration architecture needed to make it work.

• Comparing licence prices instead of TCO: Integration, internal labour, change, support and exit are left outside the commercial decision.

• Scoring before evidence is complete: Unresolved items receive optimistic assumptions so the preferred vendor can progress.

• Letting the likely implementer control the shortlist: Commercial incentives can influence which products are investigated deeply and which are dismissed early.

The final mistake deserves particular attention. When the organisation needs a neutral buying process, the adviser designing the comparison should make its commercial incentives visible. An independent technology and vendor selection process can separate the decision criteria from supplier sales priorities before an implementation partner is appointed.

ERP Selection Checklist Before Final Approval

Use the checklist as a decision gate, not as an administrative document completed after the preferred vendor is already known.

• Decision defined: Is there a written statement describing the business outcome, scope and non-negotiable constraints?

• Governance assigned: Are the executive sponsor, decision owner and evaluation roles explicit?

• Requirements tested: Are critical requirements written as scenarios rather than generic feature statements?

• Shortlist independent: Was the market screened before suppliers influenced the scoring criteria?

• Fit-gap documented: Does every material gap have a classification, owner and treatment?

• Saudi requirements demonstrated: Have applicable invoicing, tax, language, data and sector obligations been tested in the proposed design?

• Architecture reviewed: Are integrations, identity, data, security and surrounding platform dependencies understood?

• Implementation assessed: Has the actual delivery team, methodology, migration plan and client effort been reviewed?

• TCO normalised: Are finalists compared over the same commercial horizon and scope?

• Risks separated from scores: Are mandatory gaps and high-impact dependencies visible outside the weighted total?

• References validated: Have comparable customers been asked about implementation reality, not simply product satisfaction?

• Exit considered: Does the organisation understand data portability, contractual commitments and replacement difficulty?

• Recommendation documented: Can an executive reader understand why the winner was selected and what trade-offs were accepted?

A checklist is more useful when it belongs to a repeatable decision process rather than one ERP project. Teams that want to connect discovery, comparison, selection and implementation readiness can review our five-stage methodology as one example of structuring those decisions in sequence.

Cost should also be tested before the advisory scope grows. Comparing published consulting cost ranges with the internal capability gap can help determine whether the organisation needs full selection support, targeted independent review or no external advisory work at all.

Make the ERP Decision Defensible Before You Make It Final

The practical lesson in how to choose an erp system is to delay the product decision until the evidence is strong enough to support it. Define the business outcome first, turn requirements into testable scenarios, shortlist independently, test difficult processes and make Saudi requirements part of the evaluation rather than an implementation assumption.

Then score business fit, technical fit, delivery risk and five-year cost using the same rules for every finalist. Keep unresolved gaps visible and document the trade-offs that management is consciously accepting.

A successful ERP selection does not prove that one platform is universally better than another. It proves that one option is the most defensible fit for this organisation, this operating model, these constraints and the evidence available at the point of decision.

How to Choose an ERP System FAQs for Saudi Enterprises

What are the most important ERP selection criteria?

The strongest ERP selection criteria cover business-process fit, technical architecture, integration, data, usability, Saudi operational requirements, implementation risk, supplier capability and total cost of ownership. Separate mandatory requirements from weighted preferences. A criterion should influence the decision only when the team can define what acceptable evidence looks like and score every shortlisted product using the same rule.

How long should an ERP selection process take?

There is no single correct duration because organisational scope and stakeholder complexity vary. A focused selection normally needs enough time to define the decision, gather requirements, build an independent shortlist, run structured fit-gap demonstrations, review implementation assumptions and normalise commercial proposals. Compressing the process by skipping requirements or fit-gap usually transfers the unresolved work into implementation rather than removing it.

How many ERP systems should be included in the shortlist?

The shortlist should contain only products with credible evidence that they can meet the mandatory requirements and operating model. Too many finalists reduce the depth of demonstrations, technical assessment and commercial normalisation. The objective is not to invite every recognised ERP vendor; it is to evaluate a small number of defensible alternatives thoroughly enough to make the final recommendation evidence-based.

What Saudi-specific requirements should be checked when choosing ERP software?

Saudi enterprises should assess the requirements that actually apply to their entity, including ZATCA electronic invoicing, tax processes, Arabic and bilingual operation, data architecture, privacy, cybersecurity and sector-specific obligations where relevant. These should be demonstrated in the proposed implementation design. A generic statement that an ERP is “Saudi compliant” should not replace evidence against the organisation's real processes.

Should ERP cost or functionality have more weight in the final decision?

Neither should automatically dominate. Mandatory functionality must first be proven; after that, compare business fit, technical fit, delivery risk and five-year cost using agreed weights. The cheapest platform can become expensive through implementation or integration, while the richest feature set may create unnecessary complexity. The weighting should reflect the organisation's actual business outcomes and risk tolerance.