System Integration Consultant, Iraq

Getting site data to head office

For Iraqi contractors and oil and gas service companies, the hardest integration is often the one between sites and head office. Storekeepers record receipts and issues, supervisors approve timesheets and site accountants pay small expenses, frequently in places where internet access comes and goes. If those records reach the ERP late or twice, project costs and stock balances stop meaning anything.

I design site data flows around three options, often combined:

• Mobile capture with offline support, where the ERP's app or a form tool stores entries on the device and syncs when coverage returns.
• A site server or local instance that works independently and exchanges batches with head office on a schedule.
• Structured file uploads from site spreadsheets, validated before import, as a fallback or for smaller sites.

Whichever is used, each record carries a unique reference and a site code, so retries never create duplicates and head office can see which sites are behind. A daily control lists sites that have not synced and the age of their oldest pending entry.

Testing happens from the sites themselves, over their real connections, not from a fast office line. I ask a storekeeper and a supervisor at each pilot site to run the scripts while the partner watches. How site connectivity affects platform choice is discussed on my Iraq ERP selection page; this page covers the data flows themselves.

Banks, wallets and statement files

Banking integration in Iraq usually starts modestly. Many banks provide statements through online portals as downloadable files rather than live feeds, and a corporate portal may or may not accept payment files. Wallet and card payment services are part of the picture for some customers, while cash remains common for both receipts and site payments.

I design what is realistic for your banks rather than an ideal that will not be supported:

• Statement imports by file for each account and currency, with validation that totals and opening balances match before posting.
• Payment files generated from approved payment runs where the bank accepts them, and a controlled manual route where it does not.
• Wallet and card settlements mapped to customer receipts, with fees separated.
• Currency fields carried on every line, since dinar and dollar accounts often sit side by side.

What each bank and provider offers is confirmed directly with them and your finance team; I do not assume an API exists. Where the honest answer is a weekly file import, I make that import reliable, logged and checked, which beats a fragile custom link that fails without anyone noticing.

Cash payments at sites are recorded in the ERP through advances and expense claims with approvals, and the integration simply ensures site records reach the ledger completely and on time.

Client portals and reporting packs for international partners

Iraqi suppliers to international energy companies, contractors and development organizations often have to send data in the client's format: invoices uploaded to a supplier portal, timesheets in a prescribed template, cost reports by work order or monthly packs for a joint venture partner. When these are prepared by hand from ERP exports, numbers drift and submissions get rejected.

I treat each recurring output as an interface with its own specification:

• The source data in the ERP, such as approved timesheets, work orders or invoice lines, with the client's reference numbers stored against them.
• The format required, whether a portal upload, a structured file or a report template.
• Validation rules that catch missing references or mismatched totals before submission.
• A record in the ERP of what was submitted, when, and whether it was accepted.

Where a client portal offers an upload format or an API, submission can be automated; where it requires manual entry, the ERP produces a checked file the team uploads. Either way, the figures sent match the figures booked.

Portal rules and contract terms are set by each client, so I work from their documentation and your contract team's guidance. Getting this right protects cash flow, because a rejected invoice package is a frequent reason payment slips into the next cycle.

Federal Iraq, the Kurdistan Region and the group view

A group trading both in federal Iraq and in the Kurdistan Region often keeps a separate legal entity on each side, sometimes on separate systems. Integration then has to keep them apart where law and accounts require it, and together where management needs a single view.

The flows I usually specify:

• Shared master data such as items, suppliers and employees, with one owning company or a central master and clear rules for local additions.
• Intercompany transactions for goods moved, staff seconded or services recharged between the companies, with matching documents on both sides.
• Group reporting in a common currency, built in Power BI or the ERP's consolidation features, with definitions of revenue, cost and margin agreed by finance.
• Payroll journals per company and site from the payroll provider or module, posted to the correct entity.

A monthly reconciliation of intercompany balances is part of the design, not an afterthought. So is access control: users in one company should not edit the other's records unless finance has agreed it.

Which registrations, taxes and reporting each company needs is for your accountant and legal advisors in each region. My role is making sure the integrations respect those boundaries and carry the right entity, currency and rate on every record. The sales side of the same structure is covered on my Iraq CRM consultant page.

Who builds, supports and watches the integrations

Support capacity shapes integration choices in Iraq more than in many markets. A clever custom interface that only one developer understands is a risk if that person leaves or the partner relationship ends. I therefore prefer approaches your team or a replaceable provider can maintain: standard connectors when they handle your real cases, tools like Make, Zoho Flow or n8n when many applications exchange the same records, and custom APIs only where volume or complexity requires them.

I stay on the design, mapping, testing and supervision side. Interfaces are coded by your in-house developers, an outside integration firm or the implementation partner, although I occasionally configure a simple low-code flow myself. Either way, the company holds the credentials, the configuration exports or source code, and the documentation.

Every interface goes live with alerts to an accountable person, a queue for failed records, a runbook for common problems and a daily or weekly control check. Hosting matters here too: where middleware runs, how it is backed up and what happens if a site cannot reach it.

Once the system is live, I can look through error logs from wherever I am and help decide which issues to fix first; travel happens only when agreed beforehand. To keep a partner on plan, see my implementation oversight work in Iraq; my general method is on the ERP integration page, and the Iraq hub lists everything else.