Currency Exposure Is the Wait, Not the Rate
Currency exposure is usually explained as a rate that moves. In a market where payments queue, the rate is not the variable — the interval is, and no hedge addresses an interval.
Every explanation of currency exposure starts the same way: you owe a foreign amount, the rate moves, the local cost changes. It is correct, it is what treasury products are built around, and it quietly assumes something that is not true in a large number of markets — that the time between committing to a payment and making it is short and roughly predictable.
Where that assumption fails, the exposure changes shape. It stops being a function of volatility and becomes a function of delay. Two businesses with identical purchasing, identical suppliers and identical currency pairs can have wildly different exposure purely because one of them settles in a fortnight and the other settles in four months.
The same purchase, two intervals
Illustrative, deliberately unremarkable, and the point is the comparison rather than the figures. Assume a currency drifting at roughly the same rate throughout — no crisis, no devaluation event, just ordinary movement.
Two businesses, one purchase, one currency pair
Run this with your own rates and your own longest wait. The multiple is what matters, and it is usually larger than people expect, because the drift accumulates across a period nobody is tracking.
A hedge protects you against the rate moving. Nothing protects you against carrying the obligation for four months, because that is not a price risk — it is a duration you did not choose.
Why this is invisible in a normal set of accounts
Four structural reasons, and each of them is a reasonable design decision made for a different context.
| Why it hides | What would reveal it |
|---|---|
| Exchange differences post in aggregate, in one line, at period end | Attributing the difference to the transaction that produced it, so it is traceable to a specific wait |
| Ageing measures elapsed time from the invoice, not time spent in a particular state | Recording when the payment entered the queue, so the wait itself is a measurable interval |
| The exposure is created after every approval | Nothing in a procurement control can catch it, so it has to be reported rather than prevented |
| Nobody owns it, because no budget holder authorised it | Assigning the reporting of it to somebody, even if the cause is outside anybody's control |
The third of those is the one worth sitting with. In a normal cost structure you control exposure by controlling the decision — a threshold, an approval, a negotiation. Here the cost is generated entirely after the last decision anybody made, which means no control anywhere in your procurement process can touch it. It is not a governance failure. It is outside the scope of governance.
What actually changes the number
Three things, and it is worth being clear about which of them are yours and which are not.
Shortening the wait
Almost entirely outside your control where the constraint is currency availability. It is a banking and macroeconomic matter, and any software vendor implying otherwise is selling something they cannot deliver.
Changing the currency of the obligation
Genuinely available in some cases — negotiating in local currency, or agreeing terms that fix the local amount. It transfers the exposure to your supplier, who will price it, so it is a commercial trade rather than a saving. Worth modelling before assuming it helps.
Measuring the interval
Fully available and almost never done. Recording when a payment entered the queue and how long it stayed there turns an unexplained exchange line into an attributable cost with a duration behind it.
Recording the rate actually applied
The transaction holds its original currency and the genuine rate rather than a standing monthly one, so the difference between commitment and settlement has an explanation instead of a plug.
The uncomfortable conclusion
Two of those four are not things you can fix, and the two you can are both measurement rather than mitigation. That is a genuinely unsatisfying answer, and it is the honest one. What measurement buys you is not a smaller number — it is a number at all, which changes how you price, what terms you negotiate, and what you tell a board about why margin moved. Businesses absorbing a cost of this size without knowing its size are making pricing decisions on an incomplete cost base.
Where this applies beyond one market
This was written from a Malawian starting point, because that is the market where the pattern is most visible right now. It is not a Malawian phenomenon.
The same shape appears anywhere a payment can be approved and then wait — currency rationing, allocation queues, exchange approval processes, banking capacity constraints, and in a different form wherever letters of credit and long confirmation cycles are the norm. It has appeared and receded in a good number of economies over the last two decades and will again.
The practical test for whether it applies to you is not "is our currency volatile". It is a simpler question: how long, on your worst month, between approving a foreign payment and the supplier having the money? If the answer is measured in months, the standard explanation of currency exposure is describing a smaller problem than the one you have.
- Do you know the average and worst interval between approving a foreign payment and settling it?
- Is your exchange difference attributable to individual transactions, or does it arrive as one line?
- Can you distinguish a supplier balance waiting on currency from one waiting on a decision by you?
- Has anybody calculated what the intervals cost you last year, in total?
- Do your pricing decisions include that cost, or is it discovered afterwards in the accounts?
The last question is the one that turns this from an accounting curiosity into an operating problem. A cost you cannot see is a cost you are not passing on.
What is not built for Southern Africa today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Southern Africa. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a revenue authority pipeline, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax pipelines and return output
Return output in the shape your revenue authority expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Banks, EFT and card acquirers
Bank statement feeds, EFT and debit-order files and card acquirer settlements pulled into the Payments Register so receipts match invoices without re-keying.
Payroll and statutory returns
Payroll tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integrated