ERP for Zambian, Zimbabwean & Botswana Businesses
Three countries vendors sell as one bloc, and the three things that actually separate them — how the currency behaves, how far the revenue authority has gone with electronic invoicing, and how many people near you can implement what you buy. Plus the straight answer on what we do and do not build for each.
Zambia, Zimbabwe and Botswana appear together on vendor slides so often that buyers in all three end up reading a proposal written for none of them. They are neighbours, they trade heavily with each other and with South Africa, and their businesses face genuinely similar operational problems. But the three things that decide whether a system works for you are different in each — and none of the three is a module.
This guide separates them. It is written for the finance director or owner-manager comparing quotes, and it includes the parts where our answer is "not us, and here is who".
The three variables that actually differ
Everything else in a proposal — stock, procurement, approvals, assets, reporting — is broadly the same product in all three countries, because those problems are not national. These three are.
Zambia: a currency that moves against your cost base
The kwacha floats, and for an importing business that is the dominant operational fact. Goods bought in dollars and sold in kwacha carry a margin that changes between the order and the sale, and a price list built on last quarter's landed cost is quietly a discount scheme. The discipline that fixes this is not clever forecasting — it is recording the rate actually applied and loading real landed cost onto the receipt, so the margin you are looking at is the margin you got.
Zambia has also moved further on electronic invoicing than its neighbours, with the Zambia Revenue Authority operating an electronic invoicing regime that has expanded in scope over recent years. Scope, thresholds and timing change — confirm the current position for your business with ZRA or your tax adviser rather than with a vendor.
Zimbabwe: record what happened, hold no opinion
Zimbabwe is the market where the wrong software design does the most damage. A system that hardcodes an assumption about the currency — a fixed rate, a single denomination, a conversion applied at report time rather than at transaction time — becomes the problem the moment the assumption stops holding. And in Zimbabwe assumptions have stopped holding more than once inside the working lives of the people running these businesses.
What you want instead is unglamorous: the transaction recorded in the currency it happened in, at the rate that was actually applied, stored on the record. Everything else — reporting, comparison, consolidation — can be derived from that. Nothing can be derived from a record that quietly converted itself.
ZIMRA operates a fiscalisation regime, and businesses within its scope transmit invoice data to the authority through approved devices or interfaces. We do not connect to it. That is stated plainly in the ledger below rather than buried.
Botswana: stability, and a thin bench
Botswana hands you the easiest currency environment of the three and the hardest supply problem. The pula is managed against a basket and does not surprise you often; the population that can implement, configure and support a mid-market operations system is small, and much of it is in Gauteng rather than Gaborone.
This changes what you should optimise for. The clever product with a three-week implementation from a consultant who flies in is worth less than a simpler system somebody nearby can actually run. Ask harder about support geography than about feature depth — and ask it before the pilot, not after.
BURS has been progressing electronic VAT invoicing arrangements; as with the others, confirm the current requirement and timeline directly with the authority.
Side by side, on what matters
What ships for each country today
| Capability | Zambia | Zimbabwe | Botswana |
|---|---|---|---|
| National currency as a base currency preset | Yes | Yes | Yes |
| Foreign-currency transactions at the rate actually applied | Yes | Yes | Yes |
| Landed cost from freight, duty and clearing | Yes | Yes | Yes |
| VAT rate preset for the country | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you |
| Inventory, procurement, approvals, assets, projects | Yes | Yes | Yes |
| Offline capture with duplicate-safe sync | Yes | Yes | Yes |
| Transmission to the revenue authority | No | No | No |
| Maintained statutory payroll calculation | No | No | No |
| Local mobile money integration | No | No | No |
| Automatic bank statement feeds | No | No | No |
Built and maintained Configurable by you, not maintained by us Not built
A note on the Zimbabwe currency row, because the history is the point. Our preset carried the pre-redenomination code for longer than it should have; this page said so, and the code has since been corrected to ZWG. Check it on day one anyway. The VAT rows are partial for all three because presets are a starting value you own and maintain, not a rate history we keep current for you — and a preset that was quietly stale for a while is the best argument we can offer for treating them that way.
The straight answer
What AWRA OpsHub does today
- Kwacha, pula and ZWG as base currency presets, with the organization's base currency locked so money is stored, invoiced, printed and reported in one denomination. Zimbabwean businesses that price and settle in dollars set USD as the base instead, which is a configuration choice rather than a workaround.
- Every foreign-currency transaction recorded at the rate actually applied, held on the record — which is what makes a real margin visible after the fact rather than reconstructed.
- Suppliers and customers that keep their own trading currency, so a dollar supplier stays a dollar supplier without anyone having to remember.
- Landed cost from freight, duty, clearing and handling allocated onto the receipt, so the long road leg from Durban, Beira or Walvis Bay lands on the unit rather than in overheads.
- Inventory across branches with governed transfers, procurement with approvals that refuse and three-way matching, asset registers with named custody, project and funder tracking.
- Offline capture on mobile with a device register, queued operations, duplicate-safe sync and a conflict view for whoever administers it.
What it does not do
- Nothing is transmitted to ZRA, ZIMRA or BURS. Our only fiscal e-invoicing integration anywhere is Kenya's eTIMS, and it is Kenya-only.
- Statutory payroll is not turnkey in any of the three. No income tax bands, no social security contributions, no statutory return formats are maintained for these countries.
- No EcoCash, MTN MoMo, Airtel Money or Orange Money integration. M-Pesa in Kenya is our only one; elsewhere mobile money is reconciled against, not connected to.
- No automatic bank feeds. Statements are imported and matched, not pulled.
- Currency and tax presets are defaults, not maintained regulatory content. Ours carried the pre-redenomination Zimbabwe code well after the change — corrected now, but the episode is the honest argument for checking every preset yourself on day one.
- We are not a customs, clearing, freight or treasury system, and we do not hedge, forecast rates or express a view on any currency.
Two of those lines are the ones worth arguing about in a demo. If a competing vendor claims authority transmission in any of these three countries, ask for a production customer you can telephone — not a roadmap slide. If one claims compliant payroll, ask who maintains the bands when the budget changes them, and what happens in the month between the change and their update.
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 integratedHow to divide the work
The mistake in all three markets is trying to buy one thing. The arrangement that actually holds up puts a clear seam down the middle and staffs both sides.
Where the operations system stops
The operations system
What we hold, and what you should buy us for.
- Stock, transfers and counts across every branch and warehouse.
- Requisitions, approvals that block, purchase orders, receipts and three-way matching.
- Sales, customers, invoices and receipts with net, tax and gross separated line by line.
- Landed cost, so imported goods enter stock at what they genuinely cost.
- Employee records, compensation, leave, attendance and payroll cost allocation to projects.
- Assets with named custody, movements, verification and disposal.
- The source documents, attached to the transactions they belong to.
Your local specialists
What stays with people who do this work in your country.
- The statutory payroll calculation, and the filing that follows it.
- VAT returns, and the interpretation behind them.
- Fiscalisation — device, interface or accredited provider, as your authority requires.
- Customs classification, duty determination and clearing.
- Statutory financial statements and the audit relationship.
What crosses the boundary
- A monthly export of sales and purchases with net, tax and gross separated, in the shape your practitioner asks for.
- Payroll cost by employee, project and cost centre, from live records rather than a rebuilt spreadsheet.
- Source documents on request, retrieved from the transaction instead of a shared drive.
Write the seam down before go-live and name an owner on each side. Almost every implementation that disappoints in these markets does so because both parties assumed the other had the compliance half.
Buying sequence
Before you sign, in this order
- Name the three variables for your business: how your currency behaves, what your authority currently requires, and who within reach can support you.
- Get the support geography in writing — named people, their location, and the last three projects they finished in your country.
- Ask every vendor to demonstrate an approval refusing a transaction above threshold, live, on your data.
- Ask what is transmitted to your revenue authority, by whom, and for which production customer.
- Ask who maintains payroll tax bands, and what happens in the month a budget changes them.
- Set your base currency deliberately on day one. Do not accept any vendor default, ours included.
- Price the local specialists — payroll bureau, tax practitioner, clearing agent — alongside the software rather than instead of it.
- Compare three-year totals including support, not first-month prices.
Where to go next
The regional overview, including how the rand zone fits, is in operations software for Southern African SMEs. The currency question in depth — floating kwacha, managed pula, and a market where more than one currency circulates — is in multi-currency in kwacha, pula and a redenominated dollar. If you are comparing against the South African market next door, the South Africa buyer's guide is the other half of the picture.
For sector detail: mining and industrial supply and donor-funded operations across the region. Continentally, the best ERP software for African businesses sets out the same decision framework at a wider scale.
Our take
Do not buy a regional proposal. Work out which of the three variables governs your business — currency behaviour in Zambia, monetary honesty in Zimbabwe, support depth in Botswana — and make the shortlist answer that one first. The operations layer is genuinely the same in all three and it is where most of the return sits. The compliance layer is national, it stays with local specialists, and any vendor telling you otherwise in these three markets has not checked recently.
Talk to us about Zambia, Zimbabwe or Botswana
Governed operations, honest landed cost and currency recorded at the rate actually applied — with a written, specific answer on fiscalisation and payroll before you commit to anything.
Start the conversationFrequently asked questions
Do you integrate with ZRA, ZIMRA or BURS?
No. Our only fiscal e-invoicing integration anywhere is Kenya's eTIMS, and nothing is transmitted to any Zambian, Zimbabwean or Botswana revenue authority today. What we hold is the record the return is built from — sales and purchases with net, tax and gross separated line by line, and source documents attached to the transaction — which your practitioner or accredited provider works from. If authority transmission is a decision-blocker for you, tell us and we will scope it as a build with a written spec and price rather than promise it vaguely.
Which currencies are supported?
The kwacha, the pula, ZWG and the other regional currencies ship as base currency presets, alongside every other African currency in our tax and currency configuration. The organization's base currency is locked, so everything is stored, invoiced, printed and reported in one denomination; transactions in another currency are recorded at the rate actually applied and that rate is stored on the record. There is an optional organization-wide display currency for dashboards, but it is indicative only and never appears on an invoice, statement, receipt or export.
What is the issue with the Zimbabwe currency preset?
There was one, and it is worth describing rather than deleting. Our configuration carried the pre-redenomination Zimbabwean code for a long time after the change; this page said so plainly, and the preset now reads ZWG. The general principle is what matters more than the specific row: a vendor preset is a default you own, not maintained regulatory content, and ours proved the point at our own expense. Set your base currency deliberately at setup — including choosing USD if that is what your business actually prices and settles in — rather than accepting whatever the country field implies.
Is payroll handled for these three countries?
Not statutorily. Employee records, compensation, statutory identifiers, leave, attendance and payroll cost allocation to projects and cost centres are built and work anywhere. The national calculation — income tax bands, social security contributions, statutory return formats — is maintained for Kenya only, so in Zambia, Zimbabwe and Botswana we recommend a local payroll bureau or specialist, with AWRA holding the employee and cost side. That is a genuinely workable arrangement and we would rather describe it than sell a configurable tax table as compliance.
How do you handle mobile money in these markets?
As reconciliation, not integration. There is no EcoCash, MTN MoMo, Airtel Money or Orange Money connection — M-Pesa in Kenya is our only mobile money integration anywhere. In practice that means the payment is recorded against the invoice when it is received, the provider statement is imported, and the two are matched on a regular rhythm. It works and thousands of businesses run exactly this way; it is simply a different thing from a live connection, and you should know which one you are buying.
We import through Durban and Beira. Does landed cost handle that?
Yes, and it is one of the strongest reasons to use a system at all in these three markets. Freight, duty, clearing, handling and inland transport are recorded as landed cost components on the purchase and allocated onto the receipt, so goods enter stock at what they genuinely cost rather than at their invoice line. Long inland legs from the coast are exactly the case where pricing off the supplier invoice loses money invisibly, month after month, until someone finally reconciles a margin.
Can we run one system across all three countries?
Operationally yes, and many groups should. The caution is about currency and compliance rather than capability: base currency is locked per organization, so a group with entities in three countries runs an organization per entity with an indicative display currency for group reporting, and consolidation is management reporting rather than statutory consolidation. On compliance, three countries mean three regimes, three filing calendars and three sets of local specialists — the system does not collapse those, and no vendor should imply it does.
