ERP Implementation, Saudi Arabia

What tends to go wrong on Saudi ERP projects

Saudi implementations share some failure patterns with projects everywhere, but a few are distinctly local, and I watch for them from the start:

• E-invoicing as the last task. The integration with the authority is treated as a plug-in to switch on at the end. When it finally runs, master data gaps and template errors surface just as the business needs to invoice.
• Branch and entity structure decided late. Branches, warehouses and separate commercial registrations affect invoice numbering, VAT reporting and onboarding with the authority. Changing them after configuration is expensive.
• Arabic documents left for the partner's final week. Bilingual templates are designed under pressure and checked by nobody who uses them daily.
• Owner decisions without a record. In a family-owned company, several senior people may approve changes informally. Without a log, the partner builds conflicting instructions.
• Payroll treated as separate. HR data, GOSI details and end-of-service provisions are moved on a different timeline and never reconciled with the ledger.

None of these require heroics to prevent. They require someone on your side who knows to raise them early and keeps raising them until they are closed. If your project already shows most of these signs, the ERP recovery route is the better starting point.

Testing e-invoicing integration with your partner

The technical work of connecting to ZATCA's platform belongs to the partner or the vendor's connector. What the business needs is confidence that it works for your real invoices before you depend on it. Which integration obligations apply to you, and on what timetable, is a matter for your tax advisor and ZATCA's published guidance.

I agree a test plan with the partner that covers the cases your business actually produces:

• Standard tax invoices to VAT-registered customers, including ones with discounts, retentions or advance payments where these apply.
• Simplified invoices from a counter, van sales or an online shop.
• Credit and debit notes referring back to the original invoice, including invoices issued in the old system.
• Invoices from each branch or invoicing unit that must be onboarded separately.
• Rejections and warnings: what the user sees, who is notified and how the invoice is corrected.

Where the authority offers a test or simulation environment, these cases run there first. I also check the operational side: who monitors failed submissions each day, how certificates and onboarding details are renewed, and where the evidence of submission is stored. Leaving those questions open until hypercare is a common mistake. The broader testing approach is on the ERP testing and UAT page.

Migrating from older Saudi accounting systems

Saudi companies migrate into a new ERP from a wide range of sources: Arabic accounting packages that have run for years, Sage or QuickBooks in smaller firms, an older on-premise ERP in larger groups, and spreadsheets holding stock, contracts and commissions. The extraction work belongs to the partner or your IT team, but the business must own what moves and whether it is right.

Some issues are specific to this market. Arabic text can be corrupted during export if encoding is not handled carefully, so I ask for a sample of customer and item names to be checked by your staff after the first trial. Customer records are often missing the VAT number or full address that electronic standard invoices need, so clean-up starts early with named owners. Open invoices issued in the old system must be traceable, because a later credit note has to refer to the original document.

After each trial load I check the reconciliation with finance: account-level trial balance, customer and supplier aging, stock by warehouse and value, VAT control accounts and open purchase and sales orders. Nothing is loaded for real until the data owner signs it off. My ERP data migration page explains the method, and the migration from legacy software page covers older systems in more depth.

Payroll, end-of-service and Hijri dates at cutover

When payroll moves into the new ERP, or connects to it from an HR system, the cutover has more moving parts than finance teams expect. Employee master data, contract dates, allowances, GOSI contribution details, leave balances and end-of-service provisions all need to arrive accurately, and the first live payroll has to match what employees were paid the month before.

I plan this as its own workstream with HR, finance and the partner:

• Agree a cutover point that avoids a payroll run in progress, ideally between two pay periods.
• Run a parallel payroll on the new system for at least one period and compare results line by line with the old one.
• Reconcile end-of-service and leave provisions to the ledger, with your accountant confirming the opening figures.
• Test the salary file and wage protection submission your bank and the relevant platforms expect, in the format your payroll team uses today.

Hijri dates often matter here. Contracts, residency documents and some internal policies may be tracked on the Hijri calendar while the ledger runs on Gregorian dates. I check that the system stores and displays both correctly where your business needs them. Labor and payroll rules are for your HR advisor to confirm; my role is to make sure the system reflects their guidance and is tested before go-live.

Arabic UAT, training and the first weeks live

Acceptance testing only means something if the people who will use the system run it. In many Saudi companies that means testers who work mainly in Arabic. I write UAT scripts in plain English with Arabic field names alongside where the partner provides them, and your key users or the partner translate them for the testers who need it. Results, defects and sign-off are recorded in one shared log.

Training follows the same principle. The partner or your trained key users deliver role-based sessions in Arabic; I make sure the plan covers every role, that attendance is tracked and that user readiness is one of the go-live criteria rather than an afterthought.

The go/no-go decision then rests on evidence: UAT passed, e-invoicing cases proven, migration reconciled, payroll parallel run agreed and support arrangements in place. After cutover, I run a short daily review with key users and the partner, watching especially for rejected invoices, numbering problems and VAT postings that look wrong. Hypercare closes only after a full month-end and a VAT return have both been completed in the new system.

The engagement runs in English and is delivered remotely; visits are only by arrangement. For more on this stage see ERP go-live support, or the Saudi ERP selection page if you have not yet chosen a partner.