ERP Requirements, Saudi Arabia

The shape of a Saudi ERP specification

A specification for a Saudi company is easier to review when it follows the way the business is organized rather than the menus of any one ERP. I build it in chapters that department heads can own:

• Business context: commercial registrations, branches, warehouses, users by role and the systems being replaced.
• Functional requirements for each process area: sales and collections, procurement and payables, inventory, projects or service contracts, fixed assets, HR and the financial close.
• Statutory requirements: a separate register for tax, invoicing, payroll and record keeping.
• System behavior: where data is hosted, who may see and approve what, the change history kept, expected load and uptime at branches.
• Connections and cutover data.
• Reports: operational, management and statutory reports by role.

Each line follows the same pattern: an identifier, a single requirement, the process step it belongs to, an owner, a priority and an acceptance condition. Writing one requirement per line feels slow, but it is the only way a vendor can say "standard", "configuration" or "custom" against it honestly, and the only way your testers can later mark it passed or failed.

Where the business has several commercial registrations, I note which requirements apply to every entity and which apply only to one, because that affects licensing, setup and testing effort. The analysis that produces these lines is described on my Saudi ERP business analyst page; here the focus is the finished document and how it is used.

A statutory register that can change without chaos

Saudi statutory requirements are not static. ZATCA has introduced e-invoicing in stages, and the detail of what applies to a given taxpayer, and when, is set by the authority and confirmed by your advisor. So I keep the statutory chapter as a register with extra columns: the source of each obligation, the date it was confirmed by your advisor, and a review trigger if guidance is updated.

Statements in that register are concrete enough to test. For example:

• The system must generate each invoice type your advisor identifies, standard and simplified, with the structured data and QR content ZATCA requires, and store the result.
• Where integration with ZATCA applies to you, the system must submit invoices through the route the vendor documents, record the response, and show rejected documents to a named role for correction.
• Credit and debit notes must reference the original invoice.
• Ledgers and dimensions must give your accountant the entity-level data needed for VAT returns and the Zakat computation; the treatment itself stays with your advisor.
• Payroll, in the ERP or a connected system, must hold the employee data your HR team needs for social insurance and salary transfer processes.
• Invoices and books must stay retrievable, in a readable form, for as long as your advisor says the law requires.

When guidance changes, the register shows exactly which lines, demo scenarios and test cases are affected. That is far easier than reopening a whole document. The Saudi ERP consultant page covers the wider tax landscape.

Arabic, Hijri dates and other non-functional requirements

Non-functional requirements describe how the system must behave, and in Saudi projects several of them are cultural and practical rather than technical. I write them as explicitly as any functional line.

• Language: which documents print in Arabic or in both languages, whether users need Arabic screens or only Arabic data, and how right-to-left layout is checked. The engagement runs in English; Arabic wording is supplied and approved by Arabic-speaking staff you nominate or by a local partner.
• Calendar: the Gregorian calendar for accounting and VAT periods, with Hijri display only where HR records, contracts or customers need it.
• Hosting and data location: where production, backup and disaster recovery data may sit, and what your legal and IT teams need to verify against Saudi data protection and cloud rules. I phrase these as written questions for vendors, because the answer depends on your sector and contracts.
• Access and audit: roles aligned to delegated authority, segregation between those who raise, approve and pay, and a change history on tax, bank and pricing fields.
• Performance and availability: peak volumes such as month-end invoicing, and how branches or project sites in other regions keep working on weaker connections.

These lines rarely appear in a vendor's standard proposal, which is exactly why they belong in the specification you issue rather than the one they write.

Integration, migration and traceable priorities

Interfaces carry a large share of go-live risk, so each one gets a requirement block of its own: the two systems, what data moves, in which direction, how often, who owns the master record and how failures are reported. Common entries include bank payment and statement files, payroll and HR systems, government-facing HR platforms used by your team, point-of-sale in retail branches, ecommerce, and the e-invoicing route itself if a connector is involved.

Migration requirements define what moves from the old system: customers and suppliers with complete VAT registration data, items and units, open invoices and orders, stock by warehouse, fixed asset registers, employee records and opening balances by entity. They also state what is archived rather than migrated, and how reconciliation will be signed off. Incomplete customer tax data is worth flagging as a must-fix item, because it affects invoicing from day one.

Priorities are set by the business on a plain scale: must have, should have, could have, not in this phase. Must-have lines are traced forward into scripted demo scenarios and then into UAT cases, so nothing marked essential can quietly disappear. The same matrix records each platform's fit result from the gap analysis, giving you one view from requirement to proof.

From RFP annex to contract baseline

A finished specification is issued in two forms. The bidder edition goes into the RFP as the requirement annex, with a response column for each line: standard, configuration, add-on, custom or not supported, plus a comment. The contract baseline is the signed version, frozen and appended to the SOW, which binds the partner to the same text your process owners approved. My Saudi ERP selection work then uses the must-have lines to script vendor demos.

Sign-off runs chapter by chapter. Finance signs the statutory register only once the advisor's confirmation is attached; HR signs the payroll and workforce lines; IT signs hosting and security. After the baseline, every change needs a short request that records the reason and its effect on scope or cost.

Risks that weaken Saudi specifications include:

• E-invoicing written as a single compliance line, with no exception handling or owner.
• Arabic printouts treated as a late cosmetic task.
• Branch and entity differences ignored, so setup effort is underestimated.
• Payroll interfaces assumed rather than specified.
• No rule for what happens when tax guidance changes after contract.

For the tender process itself, see ERP RFP consulting, or visit the Saudi Arabia overview.