Multi-Currency Accounting for Cross-Border East African Trade
When you buy in dollars, sell in shillings and move stock across three currencies, the rate you actually paid is rarely the rate in your books. The disciplines that let an East African trader state a true cost, protect a margin and reconcile across currencies — and an honest line on what accounting software does versus what your accountant decides.
Cross-border trade in East Africa is a currency problem wearing a logistics costume. A Nairobi importer pays a supplier in US dollars, clears goods with fees in shillings, sells to a distributor in Kampala who pays in Ugandan shillings, and settles an inter-office balance in a third rate a month later. Somewhere in that chain a margin either survives or quietly disappears — and the difference is almost never the trade itself. It is whether the business recorded each step in the currency it actually happened, at the rate it actually happened, or reconstructed it later at a rate someone half-remembered. This guide is about closing that gap.
The core rule: record money in the currency it moved
Almost every multi-currency mess traces back to one shortcut — converting to a single "home" currency at the point of entry and throwing away the original. Do that and you can never answer "what did this actually cost in dollars?" again. The discipline is the opposite:
- Book each transaction in its own currency, with the exchange rate applied explicitly and stored, not baked in and forgotten.
- Keep each entity's books in its home currency — KES in Nairobi, UGX in Kampala, TZS in Dar — so local statutory reporting is native, not a back-conversion.
- Let the group view convert by a declared policy, applied the same way every period, so the consolidated number does not depend on who built the report — the one-system-across-the-EAC principle applied to money.
- Treat the rate as data, not decoration: the rate on the purchase, the rate on payment and the rate at period-end are three different facts, and the difference between them has a name — foreign-exchange gain or loss.
Landed cost: your true cost is not the invoice
The most common cross-border margin error is pricing off the supplier invoice instead of the landed cost. By the time an imported unit reaches your shelf it has absorbed freight, insurance, duty, clearing, and the exchange rate you actually paid — and a "40% margin" calculated off the invoice can be a loss once landed cost is honest. The mechanics are the same across the region and are worked through in what is landed cost and, for a currency-scarce economy, birr and multi-currency operations.
| Cost component | Currency it usually lands in | Why it gets lost |
|---|---|---|
| Supplier invoice | USD / EUR / CNY | Recorded at a stale or assumed rate, not the rate paid |
| Freight & insurance | USD or local | Booked as an expense, never loaded onto the stock |
| Duty & taxes at import | Local (KES/UGX/TZS) | Treated as overhead rather than unit cost |
| Clearing & handling | Local | Paid to an agent and never tied back to the shipment |
| FX difference on payment | The gap itself | Ignored until year-end, when it is a surprise |
The test that exposes a fake multi-currency system
Ask the vendor to enter a dollar purchase, apply the rate you paid, add local freight and duty, and show you the landed cost per unit in your home currency — then show the same stock item's margin on a shilling sale. If any step forces a manual spreadsheet or loses the original currency, the system does single-currency accounting with a currency field bolted on.
Reconciling across currencies without the year-end shock
- Revalue open foreign balances on a rhythm, not once a year — a debtor or creditor in dollars is worth a different amount each month, and finding that out in December is a self-inflicted wound.
- Keep FX gain and loss explicit and per-source, so you can see whether the exposure is on purchases, sales or inter-office balances — and hedge the behaviour, not just report the number.
- Reconcile inter-office balances monthly, in the currency they were created, before converting — the intercompany and multi-entity discipline that keeps a group's books trustworthy.
- Match mobile-money and bank settlements to the original transaction, not to a converted total, so a cross-border payment reconciles cleanly even when it lands days later at a moved rate.
The honest boundary: software records, your accountant decides
A capable system records foreign-currency transactions with explicit rates, loads landed cost onto imported stock, revalues open balances and reports FX differences. What it does not do is make the calls that belong to a professional: which exchange-rate policy your group adopts, how unrealised FX differences are treated for tax, and what your statutory accounts require in each country. AWRA is the system of record for the money movements; the treatment is confirmed with your accountant and the relevant revenue authority, and specifics change — so this is not tax advice. A vendor who states cross-border tax treatment as settled fact is overreaching.
One more boundary worth stating plainly: this is operational and accounting record-keeping, not a treasury or FX-trading platform. It tells you your exposure honestly; it does not hedge currency for you.
State your true cost across every currency
Foreign-currency purchases at the rate you paid, landed cost loaded onto imported stock, open balances revalued and FX differences explicit — one honest set of books across the region.
See multi-currency operations in AWRAFrequently asked questions
Does the system store the exchange rate I actually paid, or a system rate?
The rate you actually paid, applied explicitly to the transaction and stored with it — that is the whole point. A system that silently converts at a central rate and discards the original cannot tell you your true cost later. You should be able to see the original currency, the rate applied and the home-currency value on any foreign transaction.
How does landed cost work for imports across a border?
Freight, insurance, duty and clearing are loaded onto the shipment and spread across its units, so each item carries its real cost by the time it is on the shelf — in your home currency, at the rate you paid. That is what lets you price a cross-border import for a genuine margin instead of pricing off a supplier invoice that ignores everything the goods absorbed in transit.
Will it calculate our foreign-exchange gains and losses for tax?
It records and reports FX differences explicitly, by source, which gives your accountant a clean basis to work from. How unrealised differences are treated for tax, and what your statutory accounts require, are professional decisions that vary by country and change over time — confirm them with your accountant and the revenue authority. The software is the record; the treatment is theirs.
Is this a treasury or currency-hedging tool?
No — it is operational and accounting record-keeping that shows your currency exposure honestly across purchases, sales and inter-office balances. It does not trade currency or place hedges. Knowing your exposure clearly is the prerequisite for managing it; the managing happens with your bank or treasury partner.
Can it consolidate several currencies into one group report?
Yes — each entity keeps its home-currency books and the group view converts by a policy you declare, applied consistently every period. You choose the reporting currency and the method; the system applies it the same way every time so the consolidated number is trustworthy rather than dependent on who ran the report.
