Buying Operations Software in Malawi: A Straight Guide
A small market with a real constraint no software can lift. This guide is mostly about lowering your expectations to the right level and then buying well within them.
The most useful thing a software guide for Malawi can do is tell you what software cannot do here, clearly enough that you stop looking for it. So: no operations system, ours or anybody's, obtains foreign currency, influences an allocation, or moves you up a bank queue. If a vendor implies otherwise, that is the end of the evaluation.
What remains after that is smaller, real, and worth buying. This guide is about how to buy it without paying for the version that was promised.
The one question that matters most
Ask any vendor to show you a payable that is waiting on a foreign currency allocation, and to show you how long it has been waiting.
A good answer is a demonstration using ordinary tools — a status you define, a date lodged, a bank reference, an alert at a threshold of days, and reporting grouped by stage rather than only by age. It should be honest that this is configuration rather than a built-in module. A bad answer is a generic ageing report, offered as though the question had been about ageing.
Why that question works
It cannot be answered with a feature name, it requires the vendor to have thought about your actual process rather than a generic accounts payable one, and the shape of the answer tells you whether they will configure to how you work or expect you to work how the software does. It also flushes out the vendors who will claim a "forex module" — ask what it does, precisely, and listen for whether anything in the answer is about a bank.
You are not buying access to currency. You are buying the ability to see and account for a delay you are already paying for — and that is a much smaller purchase than most vendors will let you believe.
Four things worth checking, in order
What to ask, and what the answers mean
Show me a payable waiting on an allocation, and how long it has waited.
What a good answer sounds like
A configured status with a lodged date, a bank reference, a threshold alert, and reporting by stage. Stated honestly as configuration.
What a weak answer tells you
A standard ageing report. Or worse, a "forex module" with nothing in its description that touches a bank.
How does a partial allocation work?
What a good answer sounds like
One obligation with two settlements, both traceable to the same invoice, with the remaining balance still in its queue state.
What a weak answer tells you
Two separate records, or an instruction to raise a credit note. This is the single most common source of broken reports here.
Where does the exchange difference land, and can I trace it to a transaction?
What a good answer sounds like
Attributable to the individual payable, with the rate actually applied retained on the transaction.
What a weak answer tells you
A single period-end line. Defensible accounting, and it makes the cost of the wait permanently invisible.
Who answers on a Tuesday afternoon, and where are they?
What a good answer sounds like
A named channel, a location, stated hours, and an honest answer about what happens when your implementer leaves.
What a weak answer tells you
Vagueness, or a regional reseller with no Malawian customers. In a market this size that is the risk that actually materialises.
If you are a donor-funded organisation, read this instead
A meaningful share of the organisations evaluating software in Malawi are NGOs and donor-funded programmes rather than importers, and most of this guide is not written for them. Being direct about that is more useful than stretching the argument.
If your funding arrives in dollars and is converted as needed, you have the mirror image of the importer's problem rather than the problem itself — your exposure runs the other way and your constraint is usually grant compliance rather than currency availability. Where an operations system earns its place for you is different and it is worth naming:
- Cost attributed to the right grant and budget line, so a donor report is produced rather than reconstructed.
- Procurement that will not exceed an authorised amount, per grant, with the refusal recorded.
- Assets under named custody across sites, which is where most programme audits actually find problems.
- An audit trail a donor can be walked through, showing who changed what and when.
- Reporting on grant periods rather than only fiscal years, because the two rarely align.
That is a different and in some ways better-defined purchase than the one this guide is mostly about, and there is a body of material behind it worth reading before you shortlist anybody.
Where we fit and where we do not
What we do here today
- Supplier balances and ageing with the underlying documents attached, answerable from the record rather than a folder.
- Multi-currency held at the rate actually applied, with the original currency retained on the transaction.
- Landed cost on the consignment, so transport, clearing and duty reach unit cost.
- One register for money out, covering transfers, cash and mobile wallets, including partial settlements against one obligation.
- Approvals that block above a threshold, with a complete audit trail.
- Multi-site stock, confirmed transfers and counts with variance attributed to a place and a period.
What we do not do — the first is the only one that matters if you hoped otherwise
- We cannot get you foreign currency and nothing here shortens a queue. No software does. What changes is that the wait becomes visible, attributable and countable.
- No built-in allocation-queue module and no bank integration. The stages are modelled with ordinary statuses, dates, documents and alerts, configured to your process.
- No MRA integration. No filing, no return preparation, no fiscal device or e-invoicing connection, no advice on your obligations.
- No Malawian payroll. No PAYE bands, no pension contributions under the Pension Act, no statutory schedules.
- No treasury, hedging or forward cover. We record what happened; deciding what to do about exposure is a conversation with your bank.
- No local office and no Malawian implementation partner. Support is remote from Nairobi, in English, one hour ahead.
What is not built for Malawi 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 Malawi. 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 an MRA pipeline, a Malawian payroll engine, 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.
MRA output and fiscalization
Return output in the shape the Malawi Revenue Authority expects, and electronic invoicing or fiscal device integration against whatever interface is prescribed for your category, with retries, a failure queue and a daily report of sales carrying no fiscal reference.
Banks, mobile money and the foreign currency queue
Bank statement feeds and mobile money settlement into the Payments Register, plus the thing no vendor offers and every importer here needs: a payable that knows it is waiting for an allocation, how long it has waited, and what the wait has cost in revaluation. We cannot obtain foreign currency for you and will never suggest otherwise. We can stop the wait being invisible.
Payroll and statutory returns
PAYE on the Malawian bands, pension contributions under the Pension Act and the associated schedules, produced in the layout each body expects from live payroll records.
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 integratedA scorecard weighted for this market
Five criteria, weighted for Malawi
Score each vendor out of the weight shown, on demonstrated evidence rather than claims.
The waiting payable
Make them prove it: Show me one, and how long it has waited.
Support reality
Make them prove it: Who, where, what hours, and what happens when your implementer leaves.
Partial settlement
Make them prove it: Settle half an invoice and show me both halves against one obligation.
Traceable exchange difference
Make them prove it: Trace an exchange difference back to the transaction that produced it.
Named gaps
Make them prove it: What are you not good at here?
One exercise before any demonstration
List every payable currently waiting on an allocation — value, supplier, days lodged. Then take one import settled last year, find the rate at commitment and the rate at payment, and calculate the difference. Multiply roughly by your annual volume. Those two outputs are the honest size of your problem and they cost you an afternoon. If the list takes ten minutes to produce, your record-keeping is better than most and you should weight your evaluation towards something else entirely.
That is a real possible outcome, and finding it out for free is a better use of an afternoon than three vendor demonstrations.
