Short answer
A serious multi-currency system records the original currency amount, the rate used, the functional-currency value, the rate source, and later settlement or revaluation differences. If it stores only the converted amount, it hides whether profit came from operations or from exchange movement.
Many regional businesses live in three currencies within one week. They buy stock in USD, pay staff and rent in local currency, quote a regional customer in KES or EUR, then present management accounts in a functional currency chosen for reporting.
That is normal business. The danger is that many accounting tools treat it as an afterthought. The user enters the foreign amount, the software converts it, and everyone assumes the problem is solved. It is not solved. It has only been hidden.
Foreign exchange affects margin, cash flow, tax packs, audit trails, and management decisions. If the system does not handle it properly, finance will spend the month-end close explaining differences that should have been captured automatically.
Start with three currency fields, not one
A good accounting system does not ask only "what is the amount?" It asks: what currency was the transaction in, what is the entity's functional currency, and what reporting currency will the group or owner use?
Under IAS 21, the functional currency is the currency of the primary economic environment in which the entity operates. A Ugandan company may use UGX as functional currency, while receiving USD customer payments and holding a KES supplier balance. Another business may price mainly in USD even though many expenses are local.
The system should therefore store at least five values: transaction amount, transaction currency, exchange rate, functional-currency amount, and rate source. Reporting currency can then be layered on top instead of being confused with the operational record.
Record the transaction at the right rate
For a foreign-currency transaction, the accounting system needs the rate at the transaction date. In practice, businesses may use a reliable daily source or an approved average rate where the framework and policy permit it. The key is not that a clerk remembers the perfect rate. The key is that the system records which rate was used and makes the policy visible.
For example, a supplier invoice for USD 10,000 should not become only "UGX equivalent" in the ledger. It should remain a USD supplier bill with a UGX functional-currency value and a rate reference. When that bill is paid later, the difference between the original recorded value and the settlement value becomes part of the FX story.
Separate realised and unrealised differences
This is where many small systems mislead management. Realised FX gains or losses arise when the foreign-currency item is settled. Unrealised differences arise when open monetary items are remeasured at the reporting date.
If a USD receivable was recorded at one rate and collected at another, the difference is realised. If the invoice remains unpaid at month-end and finance revalues it to the closing rate, the difference is not yet cash. It is a revaluation movement that helps the accounts reflect the current position.
Mixing those two categories makes performance harder to understand. A sales manager may think margin improved because pricing was strong, when the uplift came from exchange movement. A CFO may think cash erosion is operational, when the issue is an open payable exposed to a weakening currency.
Revalue open monetary balances at close
The balances that usually matter are monetary items: foreign-currency bank balances, receivables, payables, loans, and similar items expected to be received or paid in money. At period close, those balances need revaluation using the appropriate closing rate.
That does not mean rewriting history. The original invoice remains as posted. The revaluation entry shows the reporting-date effect. In the next period, the system can reverse or update that revaluation according to policy. The audit trail remains clean.
What to demand from the system
Store the transaction currency, functional currency, rate source, rate date, and reporting currency amount separately.
Keep exchange differences out of revenue unless the accounting policy and framework clearly support that treatment.
Revalue open monetary balances at close, not every old transaction in the history.
Separate realised gains and losses from unrealised revaluation differences.
Keep a rate audit trail so a reviewer can see which rate was used, when, and why.
Reconcile each bank, mobile-money, receivable, and payable control account by currency.
Build controls around the rate
The exchange rate is a controlled input, not a casual field. The system should allow a normal user to select an approved rate, but restrict manual override. When an override is necessary, it should record the reason, source document, approver, and timestamp.
For cross-border businesses, I also recommend a rate-source register. It names the source used for accounting, the source used for commercial quoting, the source used for tax or statutory reporting where required, and the person responsible for updating each one. That prevents the common problem where sales, finance, and operations quietly use different rates.
Reports should answer the CFO's real questions
A useful multi-currency report should show exposure by currency, ageing of receivables and payables by currency, realised and unrealised FX movements, bank and mobile-money balances by currency, and rate exceptions. It should also let finance drill from the FX line to the source invoice, payment, revaluation entry, and rate record.
Without that drilldown, the CFO is left with a number that looks precise but cannot be explained. With the drilldown, foreign exchange becomes a managed discipline instead of a month-end surprise.
The management lesson
Multi-currency accounting is not about making the ledger look sophisticated. It is about protecting the truth of profit. When the system records currencies properly, management can see whether margin is changing because the business is performing better, because supplier timing changed, or because the exchange rate moved against open balances.
If your business already operates across currencies, do not wait for a full ERP replacement to fix the discipline. Start with rate policy, transaction currency capture, clean settlement posting, and month-end revaluation. The quiet errors are usually already in the books. The earlier you expose them, the easier they are to control.
For related reading, see building a data trail you can trust and software that scales across borders. To review whether your accounting system is ready for multi-currency operations, get in touch.
Frequently asked questions
What is the biggest mistake in multi-currency accounting systems?
The biggest mistake is storing only the converted amount. A proper system keeps the original currency amount, the rate used, the functional-currency amount, the rate source, and the later settlement or revaluation history. Without that, finance cannot explain whether a margin changed because of pricing, timing, or exchange movement.
When is an FX gain or loss realised?
It is realised when the foreign-currency item is settled: for example, a USD invoice is collected, a EUR supplier bill is paid, or funds are moved and converted. A revaluation of an open receivable, payable, bank balance, or loan at month-end is usually an unrealised difference until settlement.
Can one system support several currencies without full ERP complexity?
Yes, but it needs the right accounting data model. Even a lean system must distinguish transaction currency, functional currency, rate, rate source, settlement, revaluation, and reporting. A simple tool can work if it protects those fields and produces a clear audit trail.
Which rate should a business use?
For accounting, the answer depends on the reporting framework, policy, source document, and local requirements. Under IAS 21, foreign-currency transactions are initially recorded using the spot exchange rate at the transaction date, with practical average-rate use only where appropriate. Operational systems should make the rate source explicit instead of hiding it.
Sources and usage note
This article is systems guidance for finance leaders. It draws on IAS 21 and IFRS for SMEs materials but is not a substitute for advice from your accountant, auditor, tax adviser, or the applicable standard text for your reporting framework.
About the author
Peter Bamuhigire
Software architect and ICT consultant — business management systems across Africa
Peter Bamuhigire has led ERP, SaaS, and custom software programmes for organisations in Uganda, Kenya, Rwanda, DRC, Senegal, Sierra Leone, and Guinea over the last fifteen years, and runs the practice as principal architect.