A Sale in a Currency the Books Do Not Keep
You can invoice a customer in another currency, record the rate that applied, and take a payment in that currency. What you cannot do is keep a second set of books. The documents are right; the ledger is single-currency; and the difference between those two facts lands on whoever reconciles.
There are two quite different questions hiding behind the phrase multi-currency, and every evaluation conflates them. Can I transact in another currency? And can I account in one?
Our answers
Yes to the first, and comprehensively — customers, invoices and payments all carry a currency, and every document freezes the rate and the conditions that applied when it was raised. No to the second: one organisation keeps one set of books in one base currency, fixed at setup, with no revaluation and no exchange-difference accounting. Plan for the reconciliation, because it is yours.
What the transaction side does
A customer carries a currency. An invoice carries its own, together with a snapshot of the conditions it was raised under — the country, the tax treatment, the rate that applied and the moment it was captured. A payment carries a currency too.
So a document raised in another currency reads correctly forever, at the rate that applied on the day, regardless of what has happened since. That mechanism is one of the better things in the product and it is described in full in Eight Fields That Freeze a Moment.
The customer statement inherits it: each row carries the currency of the document it came from, so a customer invoiced in two currencies gets a statement that says so rather than one that silently adds them together.
Every document knows its own currency and its own rate. The books know one currency and no rates at all.
What the accounting side does not
The organisation has one base currency, chosen at setup, and it does not change. Everything in the ledger is in it.
Nothing revalues. An invoice raised at one rate and settled at another produces a difference, and that difference is not computed, not posted, and not reported. There is no realised exchange gain or loss, no unrealised revaluation of open items at a period end, and no exchange-difference account.
Other currencies can be displayed, and a display figure is indicative — a convenience for reading, not a second set of records.
That is a defensible design and we would defend it. A display conversion presented as a second set of books would be worse than not having one, because it would look like accounting and would not be.
Where the two halves meet
On the desk of whoever reconciles, once a month.
One invoice, two moments
Nothing here is wrong. Both the invoice and the payment are recorded accurately. The difference between them is a real amount that the product does not name, and naming it is a chart-of-accounts decision as much as an engineering one.
Why a Burundian seller should decide this deliberately
Because for many businesses here the transaction currency and the reporting currency are genuinely different things, and the gap between them is not stable.
A seller who prices regionally, collects in more than one unit and reports locally has to choose a base currency at setup, and that choice is permanent for the organisation. Choose the one your statutory reporting is in, not the one most of your revenue arrives in. The documents will carry the transaction currency regardless; the books can only be one thing, and the one thing they need to be is the one your accountant files.
The second decision is who owns the difference. It is a real number, it recurs monthly, and it belongs to a named person with a spreadsheet. If nobody owns it, it accumulates as an unexplained gap between what the books say you collected and what the bank says.
The rate is already recorded. That is most of it.
The reason exchange-difference reporting is a tractable build here rather than an open-ended one is that the input already exists and is already correct: every document carries the rate that applied when it was raised.
Realised exchange differences
The rate at invoice against the rate at settlement, per document. A report before it is a posting, and useful as a report on its own.
Revaluation of open items
Outstanding foreign-currency invoices restated at a period-end rate. Needs a posting decision, which is why it is second rather than first.
A second reporting currency
The largest by a wide margin, and the one we would push back on hardest. Multi-book accounting is a different product and pretending otherwise would not serve anybody.
No dates on a public page. If exchange differences are material to your reporting rather than a rounding line, describe the volume and we will scope it in writing.
Scope currency reportingWhat AWRA OpsHub does today
- A currency on customers, invoices and payments, and a currency per row on the customer statement.
- A financial snapshot on every sales document holding the country, currency, tax context, exchange rate and capture time.
- Documents that read at the rate that applied when they were raised, permanently, regardless of later changes.
- Indicative display currencies for reading figures in a familiar unit.
- Tax context frozen per document, so a rate change does not restate history.
What it does not do
- A second base currency. One organisation keeps one set of books, fixed at setup.
- Any revaluation of open items at a period end.
- Realised or unrealised exchange difference accounting, or an exchange-difference account.
- Any report of the gap between the rate at invoice and the rate at settlement.
- Consolidation across organisations, which is the shape you would use to report in two currencies.
Not ours, by choice
- Refusing to present a display conversion as a second set of books is a position rather than an omission, and we would argue for it.
- The base currency is a permanent decision at setup. Choose the currency your statutory reporting is in.
- Nothing here is Burundian. It is the difference between transacting and accounting in more than one currency; this is a market where those two are routinely different.
Four questions that separate transacting from accounting
Can I produce a trial balance in two currencies?
A good answer sounds like
Yes, or an honest no.
What it actually means
This is the question. Ours is no. Everything else about multi-currency is downstream of it.
What happens to an open foreign-currency invoice at period end?
A good answer sounds like
A revaluation, or nothing.
What it actually means
Ours is nothing. Either is workable; not knowing means the difference appears as an unexplained gap.
Where is the rate on this document, and when was it captured?
A good answer sounds like
A stored value with a timestamp.
What it actually means
A document that resolves its rate at read time changes value daily. Ours does not.
Is the second currency a set of books or a display?
A good answer sounds like
A straight answer.
What it actually means
A display conversion described as multi-currency accounting is the most common overstatement in this category.
Choose your base currency once, correctly
It is permanent for the organisation and it should be the currency you file in, not the one you invoice in most. Ten minutes before setup, and never again.
Talk it throughFrequently asked questions
Can I change the base currency later?
Treat it as permanent. It is set per organisation and everything in the books is kept in it, so changing it once there is history is a data problem rather than a setting. Decide it at setup with your accountant in the room.
How do I handle the exchange difference at month end?
Outside the system, with a named owner. The inputs are available — every document carries the rate that applied when it was raised, and payments carry their currency — so the calculation is a spreadsheet rather than an investigation. What it needs is somebody whose job it is.
Does the statement add up two currencies?
Each row carries the currency of the document it came from, so a mixed-currency customer gets a statement that shows both rather than one that silently sums them. Read the running balance with that in mind — it is a sequence of rows rather than a single converted total.
