An ERP sold in Saudi Arabia has to do more than accounting in Arabic. At minimum it must clear and report invoices to ZATCA under Phase 2, handle 15% VAT correctly across edge cases, produce a bank-acceptable WPS payroll file, calculate GOSI and end-of-service, align with Qiwa and Mudad, run properly in Arabic and RTL with Hijri dates, and keep an auditable record trail that survives a tax inspection. This checklist covers each requirement, why it matters, and — more usefully — exactly what to make the vendor demonstrate live instead of tick on a spreadsheet.

The checklist in one screen

Print this and score every shortlisted system against it. Anything a vendor cannot show working on a screen — with your data shape, not a polished demo tenant — should be recorded as 'not proven' rather than 'yes'.

ZATCA Phase-2 e-invoicing: clearance for standard invoices, reporting for simplified, with cryptographic stamp, UUID, hash chain and compliant QR
EGS onboarding and certificate lifecycle handled inside the product, not by a consultant with a script
VAT that survives edge cases: zero-rated exports, exempt supplies, reverse charge, credit and debit notes, self-billing
WPS payroll file generation your bank or Mudad actually accepts on first upload
GOSI contribution logic that is configurable, plus statutory end-of-service (EOSB) with resignation versus termination treatment
Qiwa and Mudad alignment: contract data, wage data and Saudization headcount that reconcile with what the portals show
Arabic as a first-class UI and document language, full RTL layout, and Hijri dates alongside Gregorian
In-Kingdom hosting or a clear, documented data residency position under the PDPL
Immutable audit trail, user-level attribution, and record retention that meets ZATCA's requirements
Integrations with banks and government portals — and an honest answer where an integration does not exist

ZATCA Phase 2: the part most demos gloss over

Phase 2 (the Integration Phase) is where an ERP either works or quietly becomes a manual process. Two flows exist and they behave differently. Standard tax invoices — typically B2B and B2G — go through clearance: the invoice is submitted to ZATCA and must be cleared before you issue it to the buyer. Simplified invoices — typically B2C, including point of sale — go through reporting: they are issued to the customer immediately and reported to ZATCA afterwards, within the required window.

Underneath both sits machinery your finance team will never see but will absolutely feel when it breaks: UBL 2.1 XML, a SHA-256 invoice hash, a XAdES cryptographic stamp using a certificate issued to your e-invoicing solution unit, an incrementing counter (ICV), the previous invoice hash (PIH) that chains documents together, and a TLV-encoded QR code. Break the chain — by restoring a database, running two instances against one device, or issuing out of sequence — and rejections start arriving.

Onboarding matters as much as issuance. Each e-invoicing generation solution needs a keypair and CSR, an OTP from the Fatoora portal, a compliance CSID, compliance checks, then a production CSID that later has to be renewed. If your ERP does not own that lifecycle, someone will be doing it by hand at 11pm.

Ask them to issue a standard invoice live and show the actual clearance response from ZATCA, not a green tick in the UI
Ask them to issue a simplified invoice, then show the reported payload and the returned status
Ask them to show a rejected invoice: what the error was, where the user sees it, and how it is corrected and resubmitted
Ask them to scan the printed QR with a public verifier app in front of you
Ask them to walk through onboarding a new branch or new POS device end to end, including certificate renewal
Ask what happens to the hash chain after a restore, a device swap, or a cancelled document

VAT: the invoice is the easy half

Most systems can put 15% on a line. Fewer handle the cases that produce assessments: zero-rated exports with the evidence trail attached, exempt financial or residential supplies, reverse charge on imported services, mixed-rate documents, credit and debit notes correctly linked to the original invoice, advance payments and deposits, and the timing rules that decide which return period a supply lands in.

The output that matters is the VAT return itself. A good ERP produces a return-ready summary that ties, line by line, back to the transactions behind it — so when ZATCA asks a question, you drill down instead of rebuilding in a spreadsheet.

Demo request: produce a VAT return for a closed period, then click from a return box down to individual source documents
Demo request: raise a credit note against a cleared invoice and show how the reference and the ZATCA submission are handled
Demo request: enter a reverse-charge purchase and show both sides of the entry

Payroll: WPS, GOSI and end-of-service

Payroll is where Saudi ERP projects most often stall, because the output is validated by a third party. The Wage Protection System requires a salary file in a prescribed format, submitted through your bank or through Mudad, with employee identifiers, IBANs, and the salary broken into basic, housing and other allowances plus deductions. A file that is 'nearly right' is simply rejected, and the rejection reasons are terse.

GOSI contributions differ for Saudi and non-Saudi employees, and the schemes have been amended more than once in recent years — including changes affecting new entrants to the pension scheme. Do not accept hard-coded percentages. What you want is configurable contribution rules with effective dates, so a regulatory change is a configuration entry rather than a support ticket and a patch release.

End-of-service benefit is statutory and formula-driven: it accrues at a lower rate for the first years of service and a higher rate thereafter, and the entitlement is reduced or eliminated depending on whether the employee resigns or is terminated and how long they served. Two things separate a real implementation from a shallow one: accruing the liability monthly so your balance sheet is honest, and calculating the settlement correctly at separation including unused leave and notice.

Always confirm current rates, thresholds and formulas with your payroll advisor or the relevant authority — treat any vendor's built-in numbers as a starting configuration to verify, not as legal advice.

Demo request: generate a WPS file from their system and open it — ideally have your bank or Mudad validate a test file before you sign
Demo request: change a GOSI rate with an effective date and re-run a payroll period to show the impact
Demo request: terminate one employee and let another resign at the same length of service, and show the two different EOSB settlements
Demo request: show the monthly EOSB accrual posting into the general ledger

Qiwa, Mudad and Saudization reporting

Qiwa governs employment contracts and work permits; Mudad handles wage protection submissions; Nitaqat bands determine your Saudization standing and therefore your access to services. Very few ERPs integrate deeply with all three, and you should be suspicious of any that claims seamless two-way sync with everything.

What is genuinely achievable — and what you should insist on — is that your ERP holds the same employee master data the portals do, flags divergence, and reports Saudization ratios by entity and by job category so you can see a band change coming before it costs you a visa or a service block. If reconciliation is manual, ask how often, who does it, and what the exception report looks like.

Demo request: show a Saudization ratio dashboard and explain exactly how the numerator and denominator are derived
Demo request: show contract expiry, iqama expiry and permit renewal alerts with owners and lead times
Ask directly: which of these are API integrations, which are file exchanges, and which are manual re-keying?

Arabic, RTL and Hijri — deeper than a language toggle

A translated login page is not Arabic support. Test the hard surfaces: does the entire application mirror to right-to-left including tables, navigation, charts and date pickers? Do printed and PDF documents render Arabic correctly, with proper shaping and no reversed strings? Are numbers, SAR amounts and amounts-in-words correct in Arabic? Can a user maintain bilingual product names, customer names and chart-of-accounts descriptions so one invoice serves both an Arabic customer and an English auditor?

Hijri matters operationally, not decoratively. Leave policies, notice periods, contract terms and government deadlines are often expressed in the Umm al-Qura calendar while your financial year runs Gregorian. The system should show both, convert reliably, and let users enter dates in whichever calendar they think in.

This is also where a locally built system usually pulls ahead of a globally localized one: for a Saudi vendor, Arabic and RTL are the default path through the product rather than a layer bolted onto an English core.

Demo request: switch a live user session to Arabic and navigate three modules — look for untranslated strings and broken layouts
Demo request: print an Arabic tax invoice, a delivery note and a payslip
Demo request: enter a leave request using Hijri dates and show it reflected in a Gregorian payroll period

Hosting, audit trail, retention and integrations

Data residency deserves a direct question, not a marketing answer: where is the production database physically located, where are backups stored, and who outside the Kingdom can access them? Under the Personal Data Protection Law, cross-border transfer of personal data is regulated, and some sectors and government-linked entities have stricter cloud requirements. In-Kingdom hosting simplifies the conversation considerably; if a vendor hosts abroad, ask for the written transfer basis rather than assuming.

On audit: you want an immutable, user-attributed log of who changed what and when, covering master data as well as transactions, with posted documents that cannot be silently edited. VAT records in Saudi Arabia are commonly cited as requiring retention for at least six years, with longer periods for capital assets and real estate — confirm the exact obligation for your business with your tax advisor, then confirm the system can actually hold and export that history, including after a version upgrade.

Integrations are the last checklist item and the most oversold. Bank connectivity in the Kingdom ranges from real API integration to statement import to nothing. Ask which banks specifically, what the integration does (payment initiation, statement retrieval, reconciliation), and how many live customers use it today.

Ask for the hosting region, backup region, and support team access model in writing
Ask to see the audit log for a specific posted invoice, including a change made by a named user
Ask what an export of three years of transactional data looks like, and whether you own it
Ask for a named reference customer using each claimed bank or portal integration

Turning the checklist into a scored evaluation

Send this list to every vendor before the demo and tell them the demo will follow it in order. That single step changes the conversation: you stop watching a sales narrative and start watching a system respond. Score each item as demonstrated, claimed-but-not-shown, roadmap, or not available — and treat 'roadmap' as 'not available' when the compliance clock is real.

Which system wins depends on your size and complexity, not on the checklist alone. Large multinational groups with consolidation and complex manufacturing usually land on SAP, Oracle or Microsoft with a localization layer and an implementation partner. Odoo and ERPNext are credible and cost-effective for teams that have, or will hire, technical capability to own the compliance layer. Local accounting SaaS is often the right answer for a small trading business that mainly needs ZATCA-compliant invoicing and VAT returns. Saudi-built platforms like IntellaQ Flow sit in the middle band — SMB and mid-market operations that want ZATCA Phase 2, WPS, GOSI, Arabic-first and in-Kingdom hosting working out of the box, on one core, live in weeks rather than quarters.

For the full side-by-side comparison of those options — including where each vendor genuinely fits, what drives the cost, and how to run a structured selection — see our buyer's guide to the best ERP and CRM systems for Saudi businesses. This checklist is the compliance layer of that decision; the pillar guide covers the commercial and implementation layers around it.

Must-Have ERP Features for Saudi Businesses: ZATCA, WPS, GOSI