Process Consultant, Saudi Arabia

E-invoicing exposes the steps before the invoice

Saudi Arabia's e-invoicing program, run by ZATCA, expects invoices to carry structured and correct data. The exact obligations depend on your business and on the phase that applies to you, and those details are for your tax advisor and software vendor to confirm. From a process point of view, though, one thing is clear: every weakness upstream now shows up at the invoice.

When I trace a sample of invoices back to their origin, I sort the causes of each correction into a few groups:

• Customer records created by sales without the buyer's VAT number, address details or legal name in the required form.
• Deliveries invoiced before the customer accepted the goods, leading to credit notes and reissued invoices.
• Prices and discounts agreed outside the system and corrected by accounts after the invoice was raised.
• Credit notes issued without a clear link to the original invoice or a recorded reason.

None of these is an e-invoicing problem in itself. They are process problems that the new rules make expensive. The redesign gives each piece of data an owner and a point in the flow where it must be complete, for example a customer cannot be used on an order until the account owner has filled the required fields. The invoice then becomes the natural end of a tidy process rather than the place where errors are discovered. The Saudi ERP consultant page covers the system side of e-invoicing.

One process across Riyadh, Jeddah and the Eastern Province

Companies with branches in several Saudi cities often discover that each branch runs its own version of the same process. One branch takes customer deposits; another never does. One warehouse confirms receipts the same day; another batches them weekly. Head office sees the totals but not the differences, until a reconciliation fails or a customer complains that two branches told them different things.

I map the process in head office and in a sample of branches separately, using the same structure, and then put the maps side by side. The comparison is often the most useful document of the whole engagement, because it turns vague complaints into specific differences that managers can discuss.

For each difference, leadership decides one of three things:

• adopt the better branch practice everywhere;
• keep a local variation because there is a real reason, such as a different customer base or regulatory setting, and document it;
• remove the variation because it exists only by habit.

The result is a single process with a short list of approved local exceptions. That matters later: an ERP configured for one consistent process is far simpler to support than one configured to tolerate every branch habit. Training also becomes easier, because a cashier or storekeeper moving between cities finds the same steps. Process owners at head office then hold the branches to the agreed version, with a light review routine rather than constant firefighting.

Contracts, progress claims and retention in project businesses

Contracting is a large part of the Saudi economy, and project firms carry processes that a trading company never sees. A contract award triggers mobilization, advance payment arrangements, guarantees, procurement against a budget, subcontractor appointments, monthly progress claims, variations and, finally, retention release and the final account. Each step involves different people: commercial managers, site engineers, procurement, document control and finance.

The as-is maps answer a few pointed questions. Are variations agreed on site and priced weeks later? Are progress claims built from spreadsheets that disagree with the cost records? Is retention, both what you hold from subcontractors and what your client holds from you, tracked by one person outside any system, so a release date can pass unnoticed?

The future process I design with your commercial and finance leads covers:

• how a contract is set up internally, with its budget, payment terms and retention terms recorded once;
• who may instruct and approve a variation, and when it must be priced;
• the monthly cycle from site measurement to claim submission to invoice;
• who tracks retention and guarantees and what triggers each release request.

Interpretation of contract clauses stays with your legal and commercial advisors. My job is to make sure the process captures what the contract says and that nothing depends on memory. The Saudi construction ERP page shows how the agreed design is carried into a system.

Hire to pay, residency documents and end of service

For a Saudi employer, paying staff is the last step of a long chain. Recruitment, contracts, residency and work permit steps, registrations on government HR and social insurance platforms, bank account setup, attendance, salary changes and finally end-of-service settlement all feed the payroll. In many companies, HR, government relations staff and finance each hold a part of that chain in separate spreadsheets.

I map hire to pay as one flow, from the approved vacancy to the final settlement, and mark where data passes between teams. Typical findings include employee details entered in several places, document expiry tracked by one person, salary changes approved by email and applied late, and end-of-service calculations rebuilt from scratch each time someone leaves.

The redesign agrees one owner for each type of employee data, a single trigger for renewals, a written approval path for salary changes, and a checklist for exits that finance and HR share. The rules for residency, wage protection and end-of-service entitlements come from the authorities and your HR advisors, and I do not interpret them. Where HR records use Hijri dates alongside Gregorian ones, the maps note which documents need both.

Many of these documents are bilingual. The engagement runs in English, and Arabic content in procedures and forms is written or checked by your own team or a local partner. With the process settled, choosing or improving an HR or payroll system becomes a clear exercise.

Approvals, ownership and the order of decisions

Many Saudi businesses are family-owned or founder-led, and decisions often flow to the top by default. That brings speed when the owner is available and long queues when they are not. A process engagement gives leadership a structured way to decide which approvals they want to keep and which they are ready to delegate, written as levels by decision type and company rather than as a general instruction.

Ownership is the second half. Every process I map ends with a named owner: someone senior enough to change it and close enough to see it working. The owner charter lists what they watch, described in words such as invoice corrections, overdue approvals or late claims, and how often they review it with leadership.

The order of decisions matters as much as the decisions. I recommend this sequence:

1. agree the process and approvals;
2. fix what can be fixed with existing systems and simple discipline;
3. remove manual steps where automation clearly helps, as described on my Saudi business automation page;
4. select and implement new software only for what remains.

Everything is delivered remotely through video workshops and shared documents, with visits only by arrangement. I take no vendor commissions or referral fees, so a recommendation to keep your current system is a real option. For the method in more depth, see ERP process mapping or the Saudi Arabia overview.