ERP Requirements Consultant, UAE

How a UAE specification is organized

A UAE requirements specification earns its value from structure rather than length. It needs a fixed numbering scheme, so a vendor can reply line by line and your project manager can still find requirement FIN-REC-xx when a dispute comes up later. For a UAE company I organize it into a small set of chapters:

• Context: legal entities, free zone and mainland licenses, sites, users by role and the systems in place today.
• Functional requirements by process area, from quotation to cash receipt and from purchase request to supplier payment, including stock, projects, fixed assets and month-end.
• UAE statutory requirements: tax, invoicing, payroll and record keeping, kept in their own chapter because they change on a different rhythm from the rest.
• Non-functional requirements: hosting, security, audit, performance and availability.
• Interfaces and data migration.
• Reporting: the management, entity and regulatory reports each role needs.

Each requirement has an identifier, an owner, a priority, a source and an acceptance condition. That last field is what turns a wish into something testable. "The system supports VAT" cannot be tested; "a credit note must reference the original tax invoice and reverse its VAT on the same treatment" can. How the requirements get gathered in the first place sits on my ERP requirements gathering page; this one is about what the finished UAE document has to hold.

Writing UAE tax, e-invoicing and WPS needs as testable statements

The statutory chapter is where vague wording causes the most trouble later. I write it with finance and your tax advisor, and every statement is marked as confirmed by the advisor before the chapter is signed. I do not decide how a rule applies to you; I make sure the rule your advisor gives becomes a line a vendor must answer.

Typical statements for a UAE business look like this:

• Each sales line must carry a VAT treatment drawn from an agreed list, defaulted from customer and item, and changeable only by a named role.
• Tax invoices and credit notes must print in English and Arabic using a layout approved by your team, with the Arabic text approved by an Arabic-speaking reviewer you nominate.
• The system must hold the data fields your future e-invoicing provider will need, including buyer tax registration numbers, and must record the status returned for each invoice once the national program applies to you. Scope and timing come from official guidance, not from the vendor.
• Books must be kept separately for each legal entity, with related-party transactions flagged, so your accountant can prepare corporate tax workings. The tax treatment itself stays with your advisor.
• Payroll, inside the ERP or through a provider, must produce a salary file in the format your bank or exchange house accepts under the Wage Protection System.
• Accounting records and source documents must be retained and retrievable for the period your advisor confirms.

Written this way, each statement can be shown in a demo and passed or failed in testing. The analyst work that leads to these statements is covered on my UAE ERP business analyst page.

Non-functional requirements UAE specifications tend to skip

Many specifications stop at functions. The non-functional chapter is shorter but carries as much contractual weight, because it describes how the system must behave rather than what it does. For a UAE company I cover at least these areas:

• Hosting and data location: which regions the production and backup data may sit in, whether a customer contract or sector regulator has a view on that, and what your legal team needs to review. I phrase these as questions the vendor must answer in writing, since the right answer depends on your situation.
• Access control: roles mapped to your delegation of authority, separate access per entity, and approval limits that cannot be bypassed by changing a user's role on the fly.
• Audit trail: who created, changed and approved a record, with old and new values kept for financial and tax fields.
• Performance: expected users at peak, invoice and stock movement volumes at month-end, and acceptable response for posting and reporting, described in words your team can recognize during testing.
• Availability for remote locations: how warehouses, project sites or a unit in another emirate keep working when the connection is weak, and what offline or mobile behavior is acceptable.
• Language and currency: AED as the functional currency, foreign currency purchasing and revaluation, and Arabic on printed documents rather than on every screen unless users need it.

Left out of the specification, these points tend to vanish from the statement of work as well, and then nobody is obliged to deliver them.

Integration, migration, priorities and traceability

Interfaces and data migration get their own requirements, not a single line saying "integrations as required". For each interface I record the systems at each end, the direction of data, how often it runs, which side owns the master record and what happens when a transfer fails. In the UAE that list commonly includes bank payment and statement files, a payroll or HR provider, ecommerce or marketplace channels, POS in retail branches and, later, the accredited e-invoicing provider.

Migration requirements state which master data moves, which open items move (unpaid invoices, open orders, stock by location and batch), how much history is kept and where older history will be archived, and how balances will be reconciled entity by entity. Groups with both free zone and mainland companies need this per company, because opening balances and intercompany positions must agree before go-live.

Priorities use a simple scale: must have, should have, could have and not in this phase. I agree them with the process owner and sponsor, not with the vendor. A requirement marked must have has to appear in the demo script and in the acceptance tests; that link is held in a traceability matrix that runs from requirement to demo scenario to UAT case. When a vendor later says something was never in scope, the matrix answers the question. The ERP gap analysis then records how each shortlisted platform meets each line.

Using the specification in RFPs, contracts and sign-off

Once signed, the specification does three jobs. It becomes the requirement annex of the RFP, so bidders reply line by line with fit, configuration, add-on or custom development. It drives the scripted demos on my UAE ERP selection work. And a frozen baseline version is attached to the statement of work, so the partner is bound to the same text you approved.

Version control is simple but strict. Each issue has a version label and a change log; after the baseline, changes go through a short request that records the reason, the owner who approved it and any effect on cost. Sign-off happens chapter by chapter, with the finance lead signing the statutory chapter only after the tax advisor's confirmation is attached.

Gaps that put UAE specifications at risk include:

• E-invoicing written as one line rather than as data, status and exception handling.
• Free zone and mainland entities treated as one company, which hides intercompany and VAT questions.
• Arabic printouts left to the partner with no approval step.
• WPS assumed to be handled somewhere, with no owner.
• No retention or archive requirement at all.

For the formal tender process around the document, see ERP RFP consulting, or start from the UAE overview.