ERPNext Accounting in Iraq

Mapping ERPNext to the account structure your accountant uses

Iraqi accountants may work from an account structure that follows a nationally prescribed classification, sometimes described as the unified accounting system, or from a structure the company has used for years. Whether a prescribed structure applies to your entity, and in what form, is for your accountant and auditor to say. I would not expect ERPNext to ship an Iraqi chart, and any Iraq-specific regional app is something to ask Frappe or the implementer about for the exact release you plan to run.

Inside ERPNext, accounts form a hierarchy in which parent groups only total and child ledgers receive entries; each carries a root type and often an account type that tells invoices and payments where to post. The task is to reproduce the accountant's structure faithfully in that tree.

The points I work through with the accountant:

• Numbers. ERPNext accounts can carry the accountant's codes, so reports can be sorted and filtered the way they expect.
• Names. Arabic account names where statements must be in Arabic, with English kept in a description or a parallel report for partners abroad.
• Dimensions. Sites, projects and branches tracked through cost centers or accounting dimensions, so the tree does not multiply.
• Mapping. Each old account traced to a new one in a sheet the accountant signs, which then drives opening balances.

For a general description of the module, see ERPNext Accounting; what is above is the Iraqi groundwork beneath it.

Dinar books, dollar trade: party accounts and month-end revaluation

An Iraqi importer or contractor may keep the company currency in dinars while buying goods, equipment or services in dollars, and sometimes selling in dollars too. Company currency is fixed when the company is created in ERPNext, so your accountant should confirm it before setup.

In ERPNext, a supplier or customer billed in a foreign currency needs a debtors or creditors ledger held in that same currency. A dollar supplier therefore sits on a dollar payables account, and a customer billed in dollars on a dollar receivables account. I list which parties belong in which currency with finance, and agree what happens when a party is invoiced in both.

Rates come from currency exchange records. The practical questions are who enters the rate, from which source, at what time of day, and whether different rates apply to buying and selling. I write these rules down with the accountant so the system follows a policy rather than each user's judgment. If the dinar value at payment differs from the dinar value at invoicing, ERPNext books the difference to the exchange gain and loss ledger named in company settings.

Before closing a month, finance runs Exchange Rate Revaluation, which recalculates unpaid dollar items in dinars and proposes the adjusting journal. I test it with part-paid invoices and advances, and confirm with the accountant how the entry is treated in the next period. Where partners abroad want figures in dollars, reports can be viewed in a presentation currency in recent versions, which helps but does not replace the statutory books. The multi-currency ERP page covers general design choices.

Site advances, petty cash and bank statement reconciliation

Iraqi contractors and service firms often spend in cash at remote sites: fuel, small parts, local labor, transport. Without structure, that spending reaches head office as a bundle of receipts weeks later. ERPNext offers employee advances, expense claims and petty cash accounts that can bring it into the ledger in an orderly way.

The pattern I set up:

• An advance is requested by the site lead, approved, and paid from a cash or bank account, creating a balance the employee owes the company.
• Spending is recorded as expense claims against that advance, with receipt photos attached and the site or project tagged.
• Unspent cash is returned or carried forward, so each advance closes to zero.
• Where a site holds a float, a petty cash account per site and currency is counted and reconciled regularly.

Bank work follows a similar discipline. Each bank account has its own ledger account and bank account record. Statement lines are loaded through a column-mapped import and then paired with recorded payments in the reconciliation screen. Some banks may only provide PDF or paper statements, so I gather an example from every bank in the first weeks, decide who turns those documents into importable rows, and trial the import on a real month. Checks issued and received are recorded with their references and clearance dates.

When the signal at a site is weak, expense claims can be entered at the next point of connection, provided a cut-off rule is agreed. The ERPNext in Iraq page covers hosting and connectivity choices.

Tax templates, withholding and the reports your accountant files

Iraqi tax obligations differ by entity, activity and location, and the rules are for your tax advisor to interpret. I would not configure any tax in ERPNext without written guidance from them. Once that guidance exists, ERPNext offers the tools to apply it.

• Tax templates. Sales and purchase templates add taxes to documents and post them to defined accounts. Item tax templates handle items treated differently.
• Withholding categories. Where the advisor says certain supplier payments carry a deduction, a tax withholding category can work out the deduction when the supplier is billed or paid and hold it in a payable ledger until it is remitted.
• Separate entities. Entities on either side of the federal and Kurdistan Region split each keep separate templates, following whatever the advisor confirms for each.

Each case on the advisor's list is entered on staging and its result checked against their workings before go-live, and rechecked whenever they report a change.

On reporting, ERPNext provides a trial balance, general ledger, balance sheet, profit and loss, cash flow and aged balances. The format your accountant or auditor files may differ, especially if statements must be in Arabic with a prescribed layout. In that case I specify a custom print format or report, built by the implementer and checked by your team. Electronic invoicing or direct submission to a tax authority is not something I would assume exists for Iraq in ERPNext; if it becomes relevant, a regional app or custom integration would need confirming with Frappe or the implementer.

Licensing, upgrades and who maintains the custom reports

ERPNext is released under the GNU GPL, so the software carries no license fee. What costs money is hosting, implementation, support from Frappe or an implementer, and the time spent keeping the system current. For Iraqi finance teams the long-term risk is less the software than the custom reports and print formats built around it.

Where the books are hosted matters for recovery. If they sit on a server at head office or with a provider, finance needs automatic backups held elsewhere, a restore rehearsed before go-live and repeated periodically, and a staging copy for testing changes. On Frappe Cloud, confirm which of those the plan covers.

Before any major version upgrade, I ask for:

• Custom reports, Arabic print formats and scripts tested on staging with a copy of live data.
• One month of invoices, payments and advances replayed on the upgraded copy, with revaluation repeated and totals matched.
• The implementer's summary of what the new version alters in posting or reports.
• The accountant's sign-off before the live site moves.

Upgrades should never land in the middle of a close. ERPNext's period closing voucher and accounting period settings help lock finished months, so a late correction does not reopen what the auditor has already seen.

Anything custom lives in its own Frappe app, stored in a code repository registered to your company, and the support agreement names the person who keeps it working. The ERP consultant for Iraq page and the Iraq hub give wider context.