Multi-Currency Operations in Kwacha, Pula and a Redenominated Dollar
Three currencies in one region behaving in three completely different ways — a floating kwacha, a managed pula, and a Zimbabwean environment where more than one currency circulates. Why the right software design is the one with no opinion, and the four habits that make margin visible instead of estimated.
Regional vendors treat "multi-currency support" as one tick box. It is not one thing, and Southern Africa is the clearest place to see why. A Botswana wholesaler, a Zambian importer and a Zimbabwean manufacturer all need currency handling, and each of them needs it to solve a different problem. Sold the same feature, two of the three will conclude the software does not work.
This is about what the three problems actually are, and about the design principle that covers all of them — which turns out to be a refusal rather than a feature.
Three problems, one tick box
A floating currency
Zambia: the margin moves after you quote
You buy in dollars and sell in kwacha. Between the purchase order and the sale, the relationship changes. Your problem is timing — knowing what a unit actually cost you, at the rate that actually applied, before you set a price you cannot revisit.
A managed currency
Botswana: stability, and complacency
The pula is managed against a basket and behaves. Your problem is not volatility, it is the habit stability creates: pricing off the supplier invoice, ignoring freight and duty, and discovering the real cost only when a competitor prices below what you thought was your floor.
More than one currency in use
Zimbabwe: two truths in one ledger
Transactions genuinely happen in different currencies within the same business, and the environment has been redenominated inside living memory. Your problem is fidelity — a system that quietly converts, or that hardcoded an assumption about the currency, becomes the source of the confusion rather than the cure.
Read those and notice that only one of the three is about volatility. The other two are about discipline and about record fidelity — which is why "we support multi-currency" answers none of them.
The design principle: record, do not opine
The single most useful property a system can have in this region is the absence of a view. Not sophistication — abstinence.
What a currency-honest system does and refuses to do
One locked base currency per organization
Everything is stored, invoiced, printed and accounted in one denomination. There is no ambiguity about what a number means, ever.
Foreign transactions at the rate actually applied
The rate is stored on the record, not recalculated at report time. This is the single feature that makes a real margin visible after the fact.
Suppliers and customers keep their own trading currency
A dollar supplier stays a dollar supplier without anyone remembering to set it each time.
Landed cost folded into the unit
Freight, duty, clearing and inland transport allocated onto the receipt, so the imported unit enters stock at what it genuinely cost.
An indicative display currency for dashboards
An optional organization-wide preference so a head office can read in dollars. Indicative only — it never appears on an invoice, statement, receipt or export, deliberately.
Multiple base currencies inside one organization
The base currency is locked. A group with entities in three countries runs an organization per entity, and consolidates as management reporting.
Hedging, forward cover, exposure limits, rate forecasting
Not a treasury system. We record what happened and express no view on what will happen.
Special logic for pegged or managed currencies
Deliberately absent. The day a fixed rate stops being fixed, a system that hardcoded it becomes the problem.
That last row is the design principle for this whole area, and Southern Africa is where it earns its keep. Every assumption a system makes about a currency is a liability waiting for a monetary announcement. Record what actually happened, at the rate actually applied, and let policy be somebody else's department.
What the wrong record costs, arithmetically
The abstract argument convinces nobody. Here is the concrete one, using an importer buying in dollars and selling in a floating local currency.
One consignment, priced two ways
The proportions here are illustrative, not a benchmark — your freight, duty and route determine the real number, and that is precisely the point. A business using Method A cannot calculate its own figure, which is why it keeps happening. The mechanics are set out in what landed cost actually means.
Four habits
-
Stop pricing off the supplier invoice
Price off landed cost, always, including on the goods where freight feels negligible. The habit matters more than any individual calculation, because the exceptions are where the losses hide.
-
Record the rate at the moment of the transaction
Not a monthly average, not a rate applied at reporting time. The rate that was actually used, stored on the record. Everything downstream — margin analysis, budget variance, grant burn — depends on this and nothing recovers it later.
-
Set your base currency deliberately on day one
Do not accept a vendor default, ours included. It is locked once operations begin and changing it later is a migration, not a setting.
-
Review margin by consignment, not by month
Monthly gross margin averages away the consignment that lost money. Per-consignment review is where a currency problem announces itself early enough to act on.
Groups operating across all three
A holding company with entities in Zambia, Zimbabwe and Botswana asks a reasonable question — can we see the whole thing in one currency? — and deserves a precise answer rather than a comfortable one.
Each entity runs as its own organization with its own locked base currency, which is what keeps its invoices, statements and statutory records honest in the country they belong to. Group-level viewing uses an indicative display currency on dashboards and on-screen reports. That is genuinely useful for management, and it is genuinely not statutory consolidation — no eliminations, no group accounting standard, no automatic revaluation postings. Those remain your auditors' work, from records we provide.
The multi-entity pattern is worked through in intercompany and multi-entity operations for regional groups, and the continental version in multi-currency ERP for pan-African operations.
The straight answer
What AWRA OpsHub does today
- A locked base currency per organization, resolved from the country, in which everything is stored, invoiced, printed and reported.
- Foreign-currency transactions with the rate actually applied stored on the record — the feature the worked example above depends on entirely.
- Suppliers and customers holding their own trading currency, so it does not depend on anyone remembering.
- Landed cost built from freight, duty, clearing and handling, allocated onto the receipt.
- An optional organization-wide display currency for dashboards and on-screen reports, giving a head office an indicative view.
- Every currency in the region as a preset — kwacha, pula, rand, metical, kwanza and the rest — alongside the other African currencies in our configuration.
What it does not do
- No treasury function. No hedging, no forward contracts, no exposure limits, no position management.
- No rate forecasting and no advice on which currency to hold. We record what happened; we express no view on what will happen.
- No multiple base currencies inside one organization. The base is locked, and the display currency is indicative only — it never appears on an invoice, statement, receipt or export.
- No automatic revaluation postings into a statutory ledger. Revaluation for statutory purposes is your auditors' work.
- No special handling for pegs or managed floats, deliberately.
- No maintained currency or tax rate history. Presets are defaults you own. Ours carried the pre-redenomination Zimbabwe code long after the change — corrected now, but set your base currency explicitly rather than accepting whatever the country field implies.
The Zimbabwe preset line is a small fact with a large lesson attached. Treat every vendor currency and tax default as a starting value you own, not as maintained regulatory content — that applies to our configuration exactly as much as anyone else's, as our own stale code demonstrated. A vendor unwilling to say so is worth less than one who volunteers it.
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 integratedWhere to go next
Regionally: operations software for Southern African SMEs for the buying context, and ERP for Zambian, Zimbabwean and Botswana businesses for the country-by-country detail. Sector detail in mining and industrial supply and donor-funded operations across the region.
For the same discipline in other currency environments: the CFA franc and the euro peg, multi-currency across East Africa, and the continental view in multi-currency ERP for pan-African operations.
Our take
Buy the system with the fewest opinions. In a region containing a float, a managed basket and an environment that has been redenominated, every clever assumption a vendor has coded about currency is a liability with a date on it. What you want is unglamorous: one locked base currency, every foreign transaction stored at the rate actually applied, landed cost folded into the unit, and a display currency that is honest about being indicative. Get those four right and the volatility becomes something you can see rather than something you discover.
See currency handled without opinions
One locked base currency, the rate actually applied stored on every transaction, landed cost folded into the unit, and an indicative group view that never pretends to be an invoice.
Talk to us about your currency setupFrequently asked questions
Can one organization hold two base currencies?
No, and the restriction is deliberate. The base currency is locked per organization and everything is stored, invoiced, printed and accounted in it, which is what makes any given number unambiguous. There is an optional organization-wide display currency for dashboards and on-screen reports, but it is indicative only and never appears on an invoice, statement, receipt or export. A business genuinely operating in two currencies at statutory level is two entities, and should be run as two organizations.
How does a Zimbabwean business with dollar and local transactions use this?
By setting one base currency deliberately and recording every other transaction in the currency it actually happened in, at the rate actually applied, stored on the record. The system holds no view about which currency is preferable and applies no automatic conversion at report time — that is the whole design. It means your records stay faithful to what occurred, which is the only foundation any later reporting, comparison or reconstruction can rest on. Set the base currency deliberately at setup — USD if that is what the business actually prices and settles in, ZWG if not — rather than accepting whatever the country field implies.
Do you handle hedging or forward contracts?
No. There is no treasury function: no hedging, no forward cover, no exposure limits, no position management and no rate forecasting. If your business genuinely needs those, you need a treasury capability and probably a bank product, and an operations system is the wrong place to look. What we do is record every transaction at its real rate so that whoever manages your exposure is working from facts rather than from a reconstruction.
Where do exchange rates come from?
For your operational transactions, from you — the rate actually applied to that transaction is what gets recorded, because that is the only rate that reflects what happened. The system does not impose a market rate on your purchases or sales. Separately, our own subscription pricing is denominated in Kenyan shillings with a US dollar equivalent derived from a live rate refreshed on a schedule, which is a billing mechanism rather than anything that touches your books.
Is a managed or pegged currency handled differently?
No, and that is intentional. We hold no special logic for fixed, pegged or managed currencies because a system that hardcodes a monetary assumption becomes the problem on the day the assumption changes — and in this region, assumptions have changed. A pegged pair simply produces the same rate transaction after transaction, which the general mechanism handles perfectly well without needing to know it is a peg.
Can we consolidate a group across three countries?
For management reporting, yes: each entity runs as its own organization with its own locked base currency, and an indicative display currency lets a head office read the whole footprint in one denomination. For statutory purposes, no — there are no eliminations, no group accounting standard applied and no automatic revaluation postings. Statutory consolidation stays with your auditors, working from the records we hold. The distinction is worth insisting on with every vendor you shortlist.
What does this change about how we price?
It moves the floor. Pricing off a supplier invoice ignores freight, duty, clearing and the inland leg, which in this region routinely runs into double-digit percentages of the invoice value — so the margin you believe you are making is not the margin you are making. Landed cost allocated onto the receipt gives you the real floor per unit, and per-consignment margin review surfaces the shipment that lost money while you can still respond, rather than averaging it away in a monthly total.
