The CFO of a mid-market manufacturing company reviews the August month-end financials. The accounts look broadly correct — until she spots a “Foreign Exchange Differences” line of €47,000 on the debit side. Nobody on the accounting team can explain exactly where that figure came from. It isn’t wrong. It’s just unexplained.
This scenario is common the moment a company generates 20% or more of its revenue in foreign currencies without having properly configured its ERP. The root cause is almost never the mathematical complexity of currencies — it’s the absence of the right ERP setup and processes. This guide is written for CFOs and treasurers at mid-market companies (50–500 employees) who are starting to export or who are seeing unexplained variances in their financial statements.
Why Your ERP Must Handle Currencies Natively
Transaction Currency, Functional Currency, and Reporting Currency
IAS 21 — The Effects of Changes in Foreign Exchange Rates establishes a precise three-level hierarchy that virtually every mid-market ERP reproduces:
Transaction currency is the currency in which the invoice is denominated. A purchase order placed in USD with a US supplier is a USD transaction.
Functional currency (or accounting currency) is the currency in which the legal entity keeps its books. For a UK-registered company, this is GBP. For a German GmbH, it is EUR. All transactions must be recorded in the entity’s functional currency, whatever the transaction currency.
Reporting currency is the currency used to produce consolidated group statements. In a UK–German group, the reporting currency might be EUR or GBP, independently of each entity’s functional currency.
An ERP without a multi-currency module conflates these three levels. The accountant manually enters the equivalent amount at the time of the purchase order, then re-enters a different amount at payment. Variances are never tracked or properly allocated. The “miscellaneous” line on the P&L absorbs everything.
What Happens When You Work Around It with Spreadsheets
The classic response from mid-market companies that haven’t configured their ERP is an Excel “Currency Tracker” maintained by a single accountant. This file centralises the exchange rates used for each invoice, manually calculated equivalents, and estimated month-end variances.
The risks are predictable: undetected input errors, rates carried forward from one week to the next by inertia, no audit trail for a tax inspection, total dependency on one person. Once export revenue exceeds 30% of turnover, managing FX risk through spreadsheets becomes structurally inadequate.
Configuring Currencies in Your ERP
Enabling Secondary Currencies
In Odoo 17 / 18: the multi-currency module is activated under Accounting > Configuration > Settings > Currencies. Each currency (USD, GBP, CHF) is added with its rate type (fixed, ECB, local central bank). Odoo can fetch reference rates automatically via the built-in ECB connector. Every accounting document (invoice, credit note, payment) carries the transaction currency and the functional-currency equivalent calculated at the day’s rate.
In SAP Business One: the company currency is set at initialisation and cannot be changed afterwards. Foreign currencies are declared in Administration > Setup > Currency. SAP B1 explicitly distinguishes the “system currency” (e.g., EUR for a German entity), the “local currency” of the document, and the “foreign currency” of the transaction. The banking module manages multi-currency bank statements and reconciliations.
In Sage X3: the currency is carried at legal entity (site) level and at counterpart (supplier or customer) level. The exchange rate table (Administration > Currencies > Exchange Rates) can be fed manually, via CSV, or via an ECB connector. Each accounting ledger has a mandatory holding currency.
Source of Exchange Rates: ECB, Local Central Bank, or Manual Entry
The European Central Bank publishes daily reference rates for 30+ currencies against EUR. Rates are published around 16:00 CET each business day. They are the reference for accounting and tax obligations in the eurozone. For UK-based entities, the Bank of England publishes daily spot rates that serve the same purpose.
For currencies not covered by the ECB or BoE (certain emerging-market currencies), your ERP will need to allow manual entry or a connector to a market data provider (Reuters, Bloomberg, Open Exchange Rates).
How Often Should You Update Rates?
The right frequency depends on the volume and sensitivity of your export activity:
- Daily updates: recommended for companies with significant currency flows (more than 10 transactions per week). ERPs like Odoo or SAP B1 support automated overnight jobs.
- Weekly updates: acceptable for limited export activity, provided the rate used is documented on each document.
- Real-time: rarely justified for a mid-market company, unless FX margins on currency contracts are thin and the CFO is actively managing FX risk.
The accounting rule is clear: the rate to use when recording a foreign-currency transaction is the rate on the transaction date. Using a monthly average rate is acceptable for repetitive transactions, provided it is applied consistently.
Recording a Foreign-Currency Transaction: USD/GBP Example
Here is a concrete example: a UK mid-market company (functional currency GBP) places a tooling order with a US supplier for USD 100,000.
Step 1: The Purchase Order (Day 0)
On 15 June 2026, the Bank of England GBP/USD rate is 1.2740 (1 GBP = 1.2740 USD). The GBP equivalent of the order is 100,000 / 1.2740 = £78,493. The ERP records this value in GBP at the order date. It serves as the basis for the purchase commitment and any provision for FX risk.
Step 2: Receipt and Supplier Invoice (Day +45)
On 30 July 2026, the goods are delivered and the USD 100,000 invoice is received. The BoE rate that day is 1.2520 (USD has appreciated slightly). The GBP equivalent is 100,000 / 1.2520 = £79,872. The ERP automatically generates an unrealised exchange difference of £79,872 − £78,493 = £1,379 as a charge. The supplier liability is recognised at £79,872.
Step 3: Settlement (Day +75)
Payment is made on 28 August 2026. The BoE rate is 1.2380. The GBP equivalent of the USD 100,000 payment is 100,000 / 1.2380 = £80,775. The ERP clears the supplier liability (£79,872) and records the difference of £903 as a realised exchange loss (P&L charge account). The variance is realised because the risk is extinguished: payment has been made.
The total realised exchange loss on this transaction is (£80,775 − £78,493) = £2,282, or 2.9% of the original order value.
Period-End Revaluation of Open Foreign-Currency Items
Why Run Revaluation Before Monthly Close
At the end of every month, your ERP must revalue all outstanding foreign-currency receivables and payables that have not yet been settled. This is open-item revaluation (or “unrealised FX revaluation”). The goal: reflect in the balance sheet the current value of these items at the month-end closing rate.
Without revaluation, the balance sheet shows foreign-currency liabilities and receivables at historical rates that may diverge significantly from current rates. This distorts the working capital calculation and makes financial statements non-compliant with IAS 21 (and equivalent local GAAP requirements in most jurisdictions).
Unrealised vs Realised Exchange Differences
The distinction is fundamental for the P&L:
- Unrealised exchange difference: results from revaluing an unsettled receivable or payable at period-end. Under IAS 21, it passes through the income statement. Under some local GAAPs, it is held on the balance sheet until settlement.
- Realised exchange difference: recognised at the point of actual settlement. It always impacts the P&L — either as an FX loss or an FX gain.
The CFO reading monthly financials must distinguish between the two. A large unrealised balance signals significant open exposure — a risk indicator, not a confirmed loss.
Automated Revaluation by ERP
Most mid-market ERPs include an automated revaluation job:
- Odoo: Accounting > Operations > Currency Adjustment — select the period, the offset account, and run the calculation. The entry is reversible at the start of the following month.
- SAP B1: Financials > Exchange Rate Differences > Exchange Rate Differences — the tool calculates variances and generates accounting entries with optional automatic reversal on day 1 of the next period.
- Sage X3: standard process Accounting > Period Close > Currency Revaluation — configurable by account type (trade receivables, trade payables, foreign-currency bank accounts).
Add this job to your monthly close checklist, always before calculating the period result.
Consolidated Multi-Currency Reporting for the CFO
Choosing the Group Reporting Currency
For a group whose parent company is in the UK, the natural reporting currency is GBP. But if the group generates 60% of revenue in EUR (a mid-market company with a significant German subsidiary), some CFOs prefer to report in EUR to the board. This is a strategic decision that should be made once and held: changing the reporting currency later triggers costly retrospective restatements.
Conversion Method Under IAS 21
IAS 21 mandates specific rules for translating a foreign entity’s financial statements into the group reporting currency:
- Assets and liabilities: closing rate at the balance sheet date
- Income and expenses: average rate for the period (unless rates fluctuate significantly)
- Equity: historical rate (date of incorporation or acquisition)
- Cumulative translation adjustment: the residual difference is recognised in equity (other comprehensive income, OCI)
These rules are natively supported in mid-market ERPs designed for international use (SAP S/4HANA, Oracle NetSuite, Sage X3). In Odoo, consolidation requires either the Consolidation module (Enterprise edition) or a dedicated external tool.
Reconciling ERP Dashboards with IFRS Statements
The main friction point: ERP dashboards often use “management rates” (a fixed average rate set at the start of the year) that differ from the actual accounting rates. The CFO ends up with two versions of results that appear irreconcilable.
The clean solution: define an explicit “management rate” in the ERP, document it, and produce two separate reporting packs — the management reporting pack (stable, comparable period-over-period) and the IFRS statutory pack (reflecting actual rates). Both are valid; they serve different purposes.
Going Further: Identifying and Managing FX Risk in the ERP
Calculating Your Net Exposure by Currency
Before hedging an FX risk, you need to measure it. The ERP can produce a net position by currency: total trade receivables in USD minus total trade payables in USD. The balance represents the net exposure.
For a mid-market company that buys components in USD (USD 300,000 in payables) and sells to the US market in USD (USD 180,000 in receivables), the net exposure is USD 120,000 long. If USD depreciates 5% against GBP, this company loses approximately £4,700 (120,000 / 1.28 × 5%).
Instruments the ERP Can Record
Some ERPs allow you to record basic hedging transactions:
- Forward contract: the ERP records the commitment to buy or sell a currency at an agreed rate and date with the bank. The forward’s market value is revalued at each period-end.
- FX option: the premium paid is recognised as a charge and the option is tracked through to exercise or expiry.
In SAP B1, these are managed in the “Treasury” module. In Sage X3, an optional “FX Hedging” module covers forwards and options at bid/offer rates.
What the ERP Does Not Do
Native ERP modules are sufficient for recording simple hedging instruments and producing the accounting entries. They do not replace a Treasury Management System (TMS) for advanced needs: managing a portfolio of complex derivatives, real-time mark-to-market valuation, VaR (Value-at-Risk) calculation, or IFRS 9 hedge accounting (successor to IAS 39).
Tools such as Kyriba or Finastra Fusion Treasury complement the ERP for mid-market companies whose currency exposure exceeds £5–10m per year, or whose hedging policy is formally defined.
Monthly Multi-Currency Checklist for the CFO
Before signing off on the monthly close, work through the following:
- ECB / BoE rate for the last business day of the month imported or entered in the ERP
- Open-item revaluation job run (trade receivables + trade payables + foreign-currency bank accounts)
- Unrealised FX differences balance justified line by line or by batch
- Realised FX gains and losses consistent with the month’s settlements
- Net position by currency calculated and compared to the prior month
- Hedging commitments (forwards, options) updated where applicable
- Balance sheet reconciliation: foreign-currency liabilities and receivables × closing rate = GBP balance as recorded
In a properly configured ERP, this process takes 30–60 minutes. In a spreadsheet, it takes 2–3 days — with a significantly higher error rate.
For more on multi-entity consolidation and intercompany flows in foreign currencies, read our guide on ERP multi-site, multi-entity consolidation, and intercompany multidevise. Short-term cash management and currency cash flow forecasting are covered in our ERP treasury and cash flow guide. If your operations span the SEPA zone, see our article on SEPA Instant Payment and the ERP treasury module.
