ERP Requirements Consultant, Qatar

What goes into a Qatar ERP specification

The document is organized so the head of each function can open their own part, read it in one sitting and sign it. For a Qatar company I use these parts:

• Company profile: legal entities, whether any sit in the Qatar Financial Centre or a free zone, project sites, stores, users by role and current systems.
• Process requirements: one chapter per area, such as estimating and contracts, billing and collections, procurement, stores and plant, projects, HR and payroll, and the monthly close.
• Statutory lines: tax data, payroll output, document language and record keeping.
• Behavior requirements: hosting, access, audit, load and connectivity.
• Connections and data to move.
• Reports for owners, project managers and the auditor.

Every requirement is a single sentence with a reference code, an owner, a priority and a test condition. The test condition matters most. "Track project costs" is a topic; "every purchase order must carry a project and cost code, and the project cost report must show committed and actual cost separately" is a requirement a vendor can demonstrate and your team can accept or reject.

The interviews and process maps that feed this document are described on my Qatar ERP business analyst page. This page is about the specification itself and what it is used for once written.

Statutory and tax-readiness lines without a VAT return

Qatar has not introduced VAT so far, so the statutory chapter looks different from that of its neighbors. It is still essential, and I draft it with finance and your tax advisor, who confirms each line before it is signed. I do not advise on tax; I turn the advisor's guidance into requirements.

Lines that commonly apply today include:

• Books must be kept per legal entity, with ownership details available so your advisor can prepare corporate income tax workings where foreign ownership makes them relevant.
• Payments to non-resident suppliers must be identifiable, so withholding obligations confirmed by your advisor can be applied and reported.
• Payroll, in the ERP or a provider, must produce the salary file your bank accepts under the Wage Protection System, with a record of what was paid and when.
• Customer-facing documents must print in Arabic, English or both as your team specifies, with the Arabic wording supplied and signed off by a bilingual colleague you name.
• Ledgers and source documents must remain accessible throughout the retention period your auditor and advisor confirm.

Then come tax-readiness lines, marked as should-have rather than must-have: tax codes held on items, customers and suppliers even if unused; invoice layouts with space for a tax registration number and tax breakdown; reports able to separate taxable categories. If VAT or e-invoicing is introduced, these lines let the system adapt through configuration rather than a rebuild. The Qatar ERP consultant page covers the wider tax picture.

Behavior requirements for sites, entities and data

Behavior requirements, often called non-functional requirements, describe how the ERP must perform rather than what it does. They are short to write and easy to forget, and in Qatar a few of them carry real weight.

• Hosting and data location: where production and backup data may be stored, how that sits with Qatar's personal data protection law, and whether any client contract, especially public sector work, sets conditions. I write these as questions vendors answer in writing, for your legal team to review.
• Entity separation: QFC or free zone entities may follow different rules from mainland companies. The specification states that each entity has its own ledger, number series and access, with intercompany trading recorded on both sides.
• Access and approvals: roles matched to who can commit spend, approve variations or release payments, with limits that users cannot widen themselves.
• Audit history: who changed bank details, prices or approval limits, with before and after values.
• Site connectivity: how storekeepers and site engineers record receipts, issues and timesheets from locations with poor coverage, whether through mobile apps, offline capture or delayed sync, and what delay is acceptable.
• Load: peak users and transaction volumes at month-end and payroll, described so they can be checked during testing.

A behavior that is missing from the specification is just as easily missing from the contract.

Interfaces, migration and the priority trail

Each interface is written as its own requirement group: which systems, which data, which direction, how often, which side holds the master record and how failures are raised. For Qatar companies the list often includes bank payment and statement files, the WPS route through the bank, HR or timesheet tools used on sites, plant or fleet systems, and sometimes a client or main contractor portal for payment applications.

Data migration requirements are just as specific. They state which master records move, how open contracts are brought across with their billed-to-date values, retentions held and advances outstanding, which open invoices and orders transfer, how stock and plant registers are loaded, and how opening balances are reconciled for each entity. Anything not migrated has an archive requirement so it remains retrievable. My ERP data migration page explains how this is executed later.

Priorities are set by the business in plain bands, running from essential at go-live down to deferred to a later phase. The tax-readiness lines described above fit naturally in the should-have band. Each must-have line is traced forward to a scripted demo scenario and then to a UAT case, and the trace lives in a matrix next to the fit result from the ERP gap analysis. If a vendor later claims a line was never agreed, the matrix shows where it was demonstrated and tested.

How the document works in tenders and contracts

Once signed, the specification is issued as the requirement annex in your request for proposal. Bidders answer each line as standard, configuration, add-on, custom or not offered, with comments. Because every bidder answers the same lines, their offers become comparable, which is the core of the work on my Qatar ERP selection page. The signed baseline is then attached to the implementation contract so scope means the same thing to both sides.

Control is kept simple. Each issue carries a version label, chapter owners sign their own parts, finance signs the statutory chapter once the advisor's confirmation is on file, and any later change goes through a recorded request with its reason and effect on cost.

Gaps that put Qatar specifications at risk:

• No tax-readiness lines, so a future tax change means rework.
• QFC or free zone entities assumed to work like mainland ones.
• WPS mentioned but not specified, so payroll output is untested.
• Live contracts missing from migration scope.
• Site connectivity ignored until the first week live.

If you want help running the tender that uses this document, ERP RFP consulting covers it; otherwise begin at the Qatar overview.