Two Currencies in One Till
Costs in one currency, receipts in the other, both of them cash, and no treasury function anywhere. The exposure is real and it is nobody's job.
Multi-currency in most software means an import: you buy in a foreign currency occasionally, the system records the rate, and your books are unambiguously in one denomination. The foreign currency is an event.
Where two currencies circulate as ordinary cash, that model does not describe the business. Both are money here. A supplier may quote in one, a customer may pay in the other, a wage may be set in one and settled in the other, and the same day's takings may contain both. There is no treasury function, no hedging policy and usually nobody whose job this is.
There is not a single exchange rate in this post
Deliberately. No figure, no direction, no expectation about which way anything moves. The structural problem below is the same whatever the relationship does, and a post carrying a rate would be wrong within the month and would invite a reader to plan against it. Your bank and your adviser are the source for numbers; this is about where the numbers have to live.
Three places it goes wrong, none of them dramatic
-
The margin is measured across a boundary
Goods costed in one currency, sold in the other, and a margin percentage calculated by converting one of them at whatever rate the system happened to hold. The percentage is arithmetically clean and describes nothing, because the two halves were never converted at the same moment.
-
A single figure spans both
A total on a report, or in a spreadsheet built from one, that has silently added two denominations. This is the failure that survives longest, because a plausible number is never questioned. It is also the easiest to prevent: a total either names its currency or it should not be produced.
-
The difference is discovered as a lump
A purchase agreed in one currency and settled in the other weeks later leaves a difference. Where the rate actually applied was never held on the transaction, that difference cannot be attributed to the order that caused it — so it arrives at year end as one figure nobody can decompose.
The problem is almost never that somebody used the wrong rate. It is that the rate they used was not written down, so nobody can tell afterwards whether it was wrong.
What a system has to do, which is less than it sounds
Three properties. None of them is clever and all three are load-bearing.
The transaction keeps the currency it happened in
Not translated at the point of storage. A record converted on the way in has destroyed the two facts that mattered — the original amount and the rate applied — and no report can recover them.
The rate actually applied travels with it
Held on the transaction rather than looked up later from a table that has since moved. This is what makes a margin explainable a year on instead of recalculable from an assumption.
No report silently blends two denominations
A single figure names the currency it is in. Where a total would span currencies it either scopes to one or discloses what it is made of. This is a design rule rather than a setting, and it is the one that prevents the most durable error.
Counterparties hold their own currency
A customer who settles in one and a supplier who quotes in the other are held as such, rather than normalised into one price list whose margin nobody can explain.
A treasury or hedging function
Not ours and not planned. We record what happened at the rate it happened at. Managing the exposure is a finance decision and, in a market where both currencies are cash, frequently a commercial one too.
Any view on how a difference should be presented
Your accountant's judgement with your accountant's liability. We show the working; the treatment is theirs.
The test, and it takes one report
Pull any total out of your current system that could conceivably include both denominations — a sales figure, a supplier balance, a stock valuation.
- Does the report say which currency the total is in?
- If it converted, at what rate, and where is that rate recorded?
- Take one transaction from inside it: is the original amount still there, or only the converted one?
- Ask whoever produced it what happens to a payment made in the other currency. If the answer involves a spreadsheet, you have found the boundary of the system.
- For one purchase settled late: can anybody tell you the difference between the agreed and the settled amount, and which order it belonged to?
If those five have answers, this is not your problem and the rest of the operation is where to look. If two or three do not, the fix is not a currency module — it is that amounts stopped being stored as they happened, and that is a recording decision rather than a reporting one.
Why this is not the same as a pegged pair
Worth separating, because the instinct is to treat all two-currency situations alike and the two cases fail in opposite directions.
Where two currencies float against each other, the danger is visible: everybody knows a conversion happened and the argument is about which rate. Where two currencies are pegged at par — as in southern Africa's common monetary area — the danger is that they look interchangeable, so a system holds them as one code, is arithmetically correct for years, and produces a record that cannot say which currency anything was actually in. One trap is a moving number. The other is a missing distinction. They need the same mechanism and they are noticed at completely different speeds.
What is built here, what is not, and what we would decline is on the Liberia market page. The instrument change happening alongside all of this is when the instrument changes, your history does not.
