ERP Business Analyst, Saudi Arabia

Turning FATOORAH into testable requirements

ZATCA's e-invoicing program has been rolled out in phases: first electronic generation and storage of invoices, then integration with ZATCA's platform for taxpayers in successive groups. For a business analyst, the important point is that "compliance" is not one requirement. It is many, and each one needs an owner and a test.

When I write the e-invoicing section of a BRD, I typically separate:

• Invoice types: standard tax invoices for business customers and simplified invoices for consumers, plus credit and debit notes, each with its own data and flow.
• Document content: mandatory fields for seller and buyer, VAT breakdown, and QR codes where required.
• Structured data: generation of the invoice in the required XML format and its storage.
• Integration: clearance before sharing for some invoice types and reporting after issue for others, once integration applies to your business.
• Exceptions: what happens when a submission fails, how errors are shown to users and who corrects them.

I leave dates, thresholds and wave assignments to your tax advisor and the vendor, because these are updated over time. My job is to make sure every obligation they confirm becomes a requirement with acceptance criteria. This sits within my wider ERP requirements gathering work.

Process mapping for how Saudi businesses really run

Generic ERP templates rarely match Saudi operations exactly. Before writing requirements, I map the processes that matter most to you, using swimlane diagrams that show each department, handoff and approval.

Common areas I map for Saudi clients include:

• Contracting: project budgets, progress billing, retention, subcontractor certificates and variation orders.
• Trading and distribution: import costing, multi-warehouse stock, van sales, price lists by customer group and credit control.
• Services and facility management: contracts, scheduled maintenance, service tickets and recurring billing.
• Group structures: multiple commercial registrations, intercompany transactions and consolidated reporting for owners.

Approval chains deserve special attention. Many Saudi companies have layered sign-offs for purchases and payments that reflect how authority is delegated in the business. If the ERP cannot reflect these, staff will approve outside the system. The process maps make these rules explicit so they become workflow requirements rather than assumptions. For the method behind this, see my ERP process mapping service.

Bilingual BRDs and Arabic document requirements

A BRD is only useful if everyone who must approve it can understand it. In Saudi projects, that often means a document in English, with Arabic terminology for fields, statuses and document names that users see every day. I agree a short glossary at the start, so terms like customer classifications, cost centers and invoice types mean the same thing in both languages.

Arabic output is also a requirement area of its own. I specify, for each document, which language is needed, whether layouts must be bilingual, how right-to-left text is handled and which fields come from Arabic master data, such as customer names in Arabic. Typical documents include tax invoices, quotations, purchase orders, delivery notes, statements of account and payment vouchers.

Calendar needs are captured too. Accounting and VAT periods follow the Gregorian calendar, but some HR records and contracts may need Hijri dates displayed. Writing these needs down early prevents the common situation where Arabic templates are left to the last week and rushed. My BRD consulting page shows the full BRD structure I use.

Fit-gap analysis and integration requirements

Once requirements are agreed, I score them against the platforms you are considering. The fit-gap matrix lists each requirement with its priority and shows whether it is met by standard features, configuration, an add-on or connector, a workaround or custom development. For Saudi projects, the e-invoicing approach is always its own line: native support, a regional edition or a third-party connector, each with different cost and support implications.

Integration requirements are documented in the same detail. Typical interfaces include banks for payments and statement import, payroll and HR systems, point-of-sale and e-commerce channels, and CRM. For each one, I specify the direction of data, frequency, ownership of master data and what happens when a sync fails.

This gives you a fair basis for comparing vendors and partners, and it becomes the reference during implementation when someone asks whether a feature was ever in scope. If you are still at the platform stage, my ERP gap analysis and the ERP consultant page for Saudi Arabia explain how analysis feeds into selection.

UAT scripts for VAT, e-invoicing and go-live

The last part of business analysis is proving the system meets the requirements. I prepare user acceptance testing scripts that walk through real scenarios with realistic data, each linked back to a BRD requirement.

For Saudi clients, the e-invoicing and VAT scripts usually cover standard and simplified invoices, credit notes against prior invoices, zero-rated and exempt lines as advised by your tax consultant, invoices with discounts and advances, QR code content, and the handling of rejected or failed submissions in the vendor's test environment. Arabic templates are checked visually for layout and content.

Core process scripts test procure-to-pay, order-to-cash, inventory movements, project billing and month-end steps. I support each test cycle remotely, log defects, retest fixes and keep a clear record of what passed. This record is useful for management sign-off and later for auditors. You can read more about this stage on my ERP testing and UAT page, or start with a conversation through the contact page. For the bigger picture of my work in the Kingdom, see the Saudi Arabia hub.