ERP Requirements Consultant, Iraq

Structuring the document by entity and region

Many Iraqi groups include a company registered in federal Iraq, another in the Kurdistan Region, and perhaps a branch or affiliate abroad. They may share people and suppliers but answer to different tax administrations and banking practices. A specification that treats them as one company invites bidders to underprice.

The structure I use separates what is shared from what is entity-specific:

• Group scope: each entity with its region, activities, sites and the phase in which it goes live.
• Shared functional lines: purchasing, inventory, contracts and projects, sales and finance processes that work the same way across entities.
• Entity statutory sections: one per entity, each reviewed by the advisor responsible for it.
• Intercompany lines: recharges, transfers of stock or staff costs, and how balances between entities are reconciled.
• Non-functional, integration and migration sections, with site classes where conditions differ.

The separation also helps when a group decides to start with one entity. The specification can then be issued with some sections marked out of scope for now, without rewriting the rest. How each entity actually operates is mapped first in the ERP business analysis for Iraq. More on multi-entity setups is on the multi-company ERP page.

Statutory and currency lines written as tests

Iraqi tax and payroll obligations depend on the entity, its region and its activities, so I do not generalize them. Each statutory line is drafted from your advisor's guidance and tagged with who confirmed it. The aim is wording a tester can check. Examples:

• A payment to a contractor applies the deduction your advisor specifies for that entity and records it against the contract, with a report that supports the related filing.
• A contract record flags whether duties apply to it, as your advisor has defined, and stores the evidence of payment.
• Payroll results from your provider or payroll module post by entity, and any social security file required in that region is produced as agreed.
• Transaction records and attachments remain retrievable for the period each advisor confirms.

Currency lines follow the same discipline:

• Each document records whether it is in dinars or dollars and the rate used, from the source your finance policy names for that document type.
• A contract priced in dollars and paid in dinars records both amounts and posts the difference to the account your accountant specifies.
• Every management report states its presentation currency and the rate basis behind converted figures.

Lines like these turn a vague promise of multi-currency support into something a bidder must demonstrate.

Non-functional requirements for sites with weak connections

A system that works well at head office can fail at a remote store or project site. I classify sites by their connection and power conditions, then write non-functional lines per class rather than one statement for everyone.

Offline capture. Which transactions must be possible without a connection, such as goods receipts, stock issues, timesheets and cash vouchers, and how they sync and resolve conflicts when the link returns.

Bandwidth. Whether key screens remain usable over a slow mobile connection, and whether attachments such as delivery photos can be compressed or deferred.

Hosting and data. Questions each bidder answers in writing: where production data and backups are held, who can access them, how restores are tested and how all records can be exported. Whether to host in-country, regionally or with a cloud provider remains your decision, informed by the answers.

Access and audit. Roles that separate requesting, approving and paying; an audit trail on bank details, rates and posted documents; visibility rules so each entity sees its own data unless group roles allow more.

Availability. Described by business moment, such as payroll week or a month-end at head office, instead of figures that are easy to promise and hard to verify.

Integrations, migration and priorities

Integration lines name each interface with its source, destination, frequency, owner and failure handling. For Iraqi companies the list often covers bank statements and payment files, payroll results, reporting feeds for international partners or a foreign parent, and any field or fleet application already in use.

Migration lines say what moves and in what condition: open contracts with billed and unbilled amounts, guarantees and their expiry dates, open advances to staff and subcontractors, supplier and customer balances in their original currency, and stock by location. Where the source is paper or a local accounting package, the line states who prepares and certifies the load file. Leaving advances or guarantees out of migration scope is a gap that often stays hidden until cutover.

Every line then receives a priority from its owner: Must at first go-live, Should, Could, or Won't yet. In a phased rollout, priority can differ by entity, so the register allows that. The Won't list is written out, so bidders do not later claim an omitted area was implied.

How these lines are delivered is covered on the ERP data migration and ERP integration pages.

Traceability, contract use and gaps to watch

Each requirement has an identifier that the demo script, the fit-gap matrix and the UAT case all cite. One register shows which lines a bidder proved, which they promised to build and which were deferred by decision. The ERP testing and UAT page shows how those identifiers carry into acceptance.

In a tender, bidders reply per line with a fixed code: out of the box, by configuration, by custom code, through another product, or not at all. That puts an Erbil firm, a Baghdad firm and a regional bidder on the same footing, and the answers feed the Iraq ERP selection. After sign-off by each entity's owners and the sponsor, the baseline version is named in the contract, and later changes are logged with a reason and an approver.

Gaps that put Iraqi specifications at risk:

• One scope for the whole group, with no Kurdistan Region section.
• Currency stated as "dinar and dollar" without rate sources.
• Site conditions assumed to match head office.
• Arabic or Kurdish document needs left undefined.
• No export requirement if the group later changes provider.

The engagement runs in English; Arabic and Kurdish samples are checked by your staff. Delivery is remote and no vendor pays me. The Iraq ERP consultant page and the Iraq overview give wider context.