INSIGHTS

Multi-currency accounting: how it works and how to implement it in an ERP

Conceptual illustration of group entities sending transactions in different currencies through rate and approval checks into the Arfinex core and a consolidated ledger
Conceptual Arfinex workflow illustration: each entity's currency flows into one consolidated ledger

Multi-currency accounting means recording each transaction in the currency it happened in, measuring it in the currency your company actually operates in, and presenting it in the currency owners, boards and lenders read. Done well, every balance can be explained from source documents and from rates with a known origin and date. Done badly, month-end turns into a hunt for unexplained differences between bank statements, receivables and the general ledger

This guide explains the three currency layers, where exchange rates should come from, the difference between realized and unrealized FX results, period-end revaluation and group consolidation. It then sets out a practical implementation path inside a financial operating system, the way Arfinex delivers it: rate policy and chart of accounts first, approved opening balances, a sandbox build, a parallel run and a go-live the customer signs off

Transaction, functional and reporting currency

Every multi-currency ledger rests on three distinct currencies, and most errors come from blurring them

  • Transaction currency: the currency printed on the invoice, receipt or bank movement. The original amount in this currency is stored and never overwritten
  • Functional currency: the currency of the main economic environment in which a company operates. Each legal entity has exactly one, and its books are measured in it
  • Reporting currency: the currency in which statements are presented to a group, a board or a lender. A group may present in one currency while its companies keep books in others

A practical rule follows. Every ledger line carries the transaction amount, the transaction currency, the rate applied, the rate's source and date, and the resulting amount in the functional currency. With all five stored, any figure can be rebuilt and audited later. Which currency is functional for a given entity is a judgement under the applicable standard, such as IFRS or a local GAAP, and it is confirmed by the customer's accountant rather than assumed by software

Exchange rates: sources, dates and approval

A rate is data like any other figure, so it needs a source and a time. Your exchange rate policy should state in writing which feed or bank is the reference, which rate type applies (spot, buying, selling or average), at what cut-off time it is captured, and what happens on weekends and holidays

Which date drives the rate

  • Invoices and bills: the transaction date, normally the document date
  • Payments and receipts: the settlement date on the bank or gateway record
  • Period-end revaluation: the closing rate on the last day of the period
  • Translation of income and expenses for group reporting: a documented period average, where the policy allows it

When a rate changes after posting

Rates sometimes arrive late or get corrected. Silently changing the rate behind a posted entry would rewrite history, so the correction is recorded as a reversing entry plus a new posting. In Arfinex a post-hoc rate change is a sensitive action: one person records it, a second person approves it, and both the old and the new rate stay visible in the audit trail. If a rate is missing, the converted amount stays marked unknown instead of being filled with zero or a guess

Realized and unrealized FX differences: a worked example

Exchange differences arise because the rate on the day a monetary item is recorded is rarely the rate on the day it is settled. The difference is unrealized while the receivable or payable is still open, and realized once cash actually moves

Worked example with illustrative figures

Take a company whose functional currency is the dollar. It issues a sales invoice for 10,000 euros when the reference rate is 1.10 dollars per euro, so the receivable is booked at 11,000 dollars. At month-end the closing rate is 1.08, and the customer pays the following month when the rate is 1.05. These numbers are invented purely to show the mechanics

  1. Invoice date: debit receivables 11,000 dollars (10,000 euros) and credit revenue 11,000 dollars
  2. Month-end revaluation: the open receivable is remeasured to 10,800 dollars, so debit unrealized FX loss 200 and credit receivables 200
  3. First day of the next period: if the policy says so, a new entry reverses the revaluation and the receivable returns to 11,000 dollars
  4. Settlement: the bank receives 10,000 euros worth 10,500 dollars, so debit bank 10,500, debit realized FX loss 500 and credit receivables 11,000

Across both months the total loss is 500 dollars: 200 shown as unrealized in the first month, then reversed and recognized as realized on settlement. Reversing revaluations or carrying them forward is a policy choice, and both reach the same total. What matters is that each step is a balanced double entry traceable to the invoice, the two rates and the bank record

Foreign exchange revaluation at period end

Foreign exchange revaluation applies to monetary items: bank and cash accounts, receivables, payables and loans held in a foreign currency. Non-monetary items such as prepayments or inventory carried at historical cost are generally not revalued, and the exact treatment is confirmed by the accountant against the applicable standard

  • Lock the closing rate set for the period and record its source and capture time
  • Run revaluation per entity, per account and per currency, never on netted totals
  • Post results to separate unrealized gain and loss accounts so they stay visible in the income statement
  • Reconcile foreign-currency bank balances in their original currency before revaluing them
  • Close the period, knowing that reopening it later needs a second approver

Revaluation, totals and postings run on deterministic, testable code instead of spreadsheets, so the same inputs always produce the same entries. An AI assistant can explain why a revaluation moved or flag an unusual rate, but its output is labelled as a proposal and posts nothing on its own

Multi-company groups and consolidation

Groups add a second layer of currency work. Each company keeps its own ledger in its own functional currency, and the group translates those results into the reporting currency for consolidation. Intra-group balances must agree in both companies before they are eliminated, otherwise the elimination leaves a gap that looks like a real asset or liability

  • Tag every intra-group invoice, loan and recharge with the counterparty company
  • Agree intra-group balances in the transaction currency first, then in each functional currency
  • Translate with the rates the policy defines and track the translation difference separately
  • Never add two currencies together; every total states its currency

Arfinex consolidated reporting for multi-company groups builds each company's statements and the group total from each company's ledger entries, with intra-group items eliminated and the status of every figure shown beside it: confirmed, computed, unreconciled or unknown

How to implement an ERP for multi-currency operations

A successful ERP implementation for a multi-currency business is mostly design and evidence work, not configuration. In Arfinex delivery, ERP implementation and multi-currency accounting sits on a reference ledger, so invoices, receipts, payments, inventory and payroll post to the same books that treasury and reporting read

Design decisions before any build

  • Entities and the functional currency of each company, confirmed by the accountant
  • A chart of accounts with separate accounts per foreign-currency bank, receivable and payable control accounts per currency, and realized and unrealized FX result accounts
  • The rate policy: sources, rate types, cut-off times, fallback rules and who approves corrections
  • Currency precision and rounding rules, including where rounding differences are posted
  • Roles and an approval matrix per company: who records and who approves

The delivery path

  1. Introduction and scope review: the companies, currencies, sources and reports in scope
  2. Corporate identity verification and screening, completed before the contract
  3. Design and build in a sandbox with synthetic or anonymized data, including test cases for revaluation, settlement and rate correction
  4. Opening balances: legacy books are mapped account by account, loaded per currency with their original amounts, and approved by a second person before they become final
  5. Parallel run alongside the current method, comparing balances, FX results and reports until every difference is explained
  6. Go-live with customer approval, after which the old method is retired

Each step leaves evidence: mappings, control totals and approvals. The multi-asset financial engine and ledger keeps balances as the sum of entries, so any balance can be rebuilt on demand instead of being trusted blindly

Common pitfalls and how to avoid them

  • Storing only the converted amount and losing the original currency and rate
  • Editing a posted rate in place instead of reversing and re-posting with approval
  • Revaluing non-monetary items or netted balances
  • Treating a missing rate or a missing statement as zero
  • Mixing currencies in dashboard totals
  • Loading opening balances without control totals or a second approver

Each of these breaks the audit trail. An immutable double-entry ledger with a full audit trail avoids them by design, because corrections are new entries and never edits or deletions

Multi-currency accounting that stays explainable

Multi-currency accounting stays manageable when every amount keeps its original currency, every rate has a source and a date, and every correction is a new approved entry. Implemented inside a financial operating system, the ERP becomes one part of a connected whole in which ledger, treasury, reconciliation and reporting work from the same entries

Arfinex is not a bank, broker or tax adviser. Currency conversion runs only through licensed providers in supported jurisdictions, and local accounting and tax rules are confirmed by your accountant

Arfinex

Request pricing for multi-currency accounting and an ERP implementation scoped to your companies and currencies