A trading company in Dubai invoices local customers in AED, pays a Chinese supplier in USD, and has just quoted a Saudi customer in SAR. A software agency in Kochi bills a US client in dollars and pays salaries in rupees. Neither thinks of itself as doing "multi-currency accounting" — until the books stop adding up and nobody can say exactly why.
The mechanics aren't hard, but they're precise. This guide covers the four ideas that make multi-currency books behave: base currency, transaction currency, realised FX differences, and the reporting rule that everything hangs on.
Base currency vs transaction currency
Your base currency is the currency your books are kept in — the currency of your P&L, your balance sheet, and (not coincidentally) your tax filings. A UAE business keeps AED books; an Indian business keeps INR books. You pick it once, and it doesn't change.
A transaction currency is whatever a particular document happens to be in. The USD supplier invoice, the SAR quotation — each document lives in its own currency, and carries a conversion to base at the rate on the transaction date.
Both amounts are real, and both are kept. The customer owes 10,000 USD — that's the legal fact on the invoice, and it doesn't drift. Your ledger recorded it as, say, 36,730 AED at that day's rate — that's the accounting fact. Multi-currency bookkeeping is the discipline of never confusing the two.
Where the money appears and disappears: FX differences
Here's the part that surprises people. That 10,000 USD invoice was booked at 3.6730. The customer pays two months later, and by then the amount you actually receive converts to 36,690 AED. The customer paid exactly what they owed — 10,000 USD — but your books received 40 AED less than they recorded.
That 40 AED is a realised exchange difference — a real gain or loss, recognised when the settlement happens, posted to an FX gain/loss account. It isn't an error and it isn't rounding; it's the price of time passing between invoice and payment in someone else's currency. Trying to make it "go away" — by editing the original invoice, or nudging the payment amount — is how multi-currency books rot. Booked correctly, FX difference becomes a line you can read: how much did currency movement actually cost us this quarter?
Meanwhile, unpaid foreign-currency balances raise the same question in unrealised form: what are the open USD invoices worth in AED today? Revaluing open balances at a period-end rate keeps the balance sheet honest about it.
The one reporting rule: never sum across currencies
If you take one sentence from this post, take this one: a total that adds amounts in different currencies is not a number.
"Receivables: 78,000" means nothing if it's 40,000 AED plus 10,000 USD plus 5,000 SAR arithmetic-ed together. It's the accounting equivalent of adding kilograms to kilometres. Honest multi-currency reporting only ever does two things:
- Group by currency — show the AED receivables, the USD receivables, the SAR receivables, each as its own subtotal, or
- Convert to base first — translate everything at stated rates, then total, and say that's what you did.
This sounds obvious. It is also the single most common multi-currency error in spreadsheet-run businesses, because a spreadsheet will cheerfully sum a column without asking what's in it — one of the many ways spreadsheets fail quietly at scale. A proper system refuses the meaningless total by construction.
The everyday disciplines
Beyond the concepts, multi-currency hygiene comes down to habits the system should enforce for you:
- Rates are captured per transaction, on the transaction date — not typed from memory, not "whatever rate we used last time."
- Documents keep their currency for their audience. The customer's SAR invoice and statement stay in SAR; the conversion is your books' business, not theirs.
- Cash and bank accounts have currencies. A USD bank account is a USD ledger; paying an AED expense from it is itself a conversion event.
- Price lists can differ by currency — the USD price for export customers needn't be a mechanical conversion of the AED price.
- Tax follows local rules. VAT and GST amounts are reported in the local currency at prescribed rates on the invoice — one more reason conversion happens at document time, not return time.
How BIZA helps
BIZA handles multi-currency in the core: documents in the customer's or supplier's currency with rates captured at transaction time, base-currency books underneath, realised FX differences posted where they belong, and reporting that groups by currency or converts explicitly — never a mixed sum. It's how the same system serves businesses working across SAR, AED, INR, and whatever your suppliers invoice in.
See our finance and accounting features, or talk to the team.