Business Central Consultant in Iraq

Availability, licensing route and data location

Microsoft publishes the countries and regions where Business Central online is offered, along with the localizations it provides itself. Iraqi companies should check that list when they are ready to buy, then ask every shortlisted partner to state in writing what they propose for each entity: the country version, the licensing route, the deployment and the region where data will be held. If the route runs through a group company abroad or a partner-hosted environment, the conditions and responsibilities belong in the written answer.

Why insist on writing? Because the country version shapes everything that follows: which tax and reporting features exist, what the partner must build as an extension, and how that extension is maintained when Business Central is updated. A verbal assurance in a sales meeting does not survive a change of account manager.

I collect the answers in a comparison sheet next to scope and cost drivers, and I add follow-up questions where answers are vague: who supports users during the Iraqi working week, how users at sites connect, and what your advisors must confirm about tax configuration. The Dynamics 365 in Iraq page covers the product family and job costing; this page concentrates on setup and contract decisions.

Posting groups for federal and Kurdistan Region companies

Each Business Central company has its own setup tables, so a group with entities in federal Iraq and the Kurdistan Region designs posting groups more than once. I aim for the same structure in both companies, with differences only where registrations, banks or advisor guidance require them. That keeps reports comparable and lets one set of acceptance scripts test both.

The matrix I agree with each accountant covers:

• General business posting groups separating local clients, international clients, joint venture partners and the other group company.
• General product posting groups for materials, subcontracted work, equipment hire, labor and services.
• Tax posting groups configured only as your advisors specify for each entity, since treatment can differ between them.
• Customer and vendor posting groups that send advances, retentions and ordinary balances to separate accounts where the accountant wants them visible.

Transactions between the companies use the intercompany partner setup, so a recharge raised in one company can be sent to the other for posting, with matching accounts on both sides. I test each combination by posting sample documents and reading the resulting entries with finance before any opening balance is loaded. The multi-company ERP page discusses group structures in general.

Dimensions for contracts and a dollar reporting currency

Business Central's jobs feature tracks budgets and costs for each contract, but not every cost passes through a job. Site overheads, shared equipment and head office charges often post straight to the ledger. Dimensions fill that gap. I usually propose contract and site as the global dimensions, so every entry can be filtered by them, with cost type and business line as shortcut dimensions on entry screens.

Defaults keep the coding consistent without relying on memory: a vendor who only serves one site carries that site, a resource carries its home business line, and posting rules block entries that lack a mandatory contract code. Where jobs are used, I align job numbers with contract dimension values so both views agree.

Currency is the other reporting decision. Groups whose contract income and imported purchases are largely in US dollars, while day-to-day spending is in dinars, often want results in both. If your accountant confirms dinars as the local currency, dollars can be the additional reporting currency, giving every ledger entry a dollar amount. The design questions are practical: which rate source feeds it, who updates rates, when the exchange rate adjustment runs, and how the dollar trial balance is reviewed at month-end. I test those rules with a month of sample transactions before the partner configures production. The multi-currency page sets out the general considerations.

What to check in the partner's statement of work

The statement of work is where an Iraqi Business Central project is won or lost on paper. Partners write it from their own template, and gaps tend to sit in the places that matter most for your business. I review it line by line on your behalf, with no stake in which partner you choose.

• Scope by process. Contract costing, imports, intercompany charges and partner reporting should each appear as deliverables, or be excluded in plain words.
• Assumptions. Phrases about standard functionality, client-supplied data or a capped set of reports often move effort back to you.
• Localization and extensions. Who builds them, who owns the code and how they keep working through updates.
• Migration responsibilities. Which records the partner loads, which your team prepares and how reconciliation is signed off.
• Connectivity assumptions. What the design expects from site connections and what fallback the partner proposes.
• Support model. Coverage during the Iraqi working week, response expectations and the language of support.

I return a marked-up copy with questions, then compare revised versions until the commitments match your requirements. The vendor proposal review page explains the method, and the Iraq ERP consultant page and the Iraq hub describe my wider work.