The Payable That Cannot Be Paid
An import payable in Malawi passes through six states. Every accounting system models the first and the last. The four in between are where the money and the risk actually sit.
Malawi has been short of foreign exchange for years and the Reserve Bank has said so publicly, describing the difficulty of allocating what exists between competing essentials. For an importer, that macroeconomic sentence has a very specific operational consequence: a payable that is approved, funded in kwacha, correctly documented, and unpayable.
Every accounting system in the world has a state for unpaid and a state for paid. Almost none has a state for waiting — and in this market waiting is not an exception, it is the middle of the process.
The six states
This is the ordinary life of an import payable here. Nothing in it represents a failure by anybody in the business.
-
Approved
The purchase is authorised, the goods are ordered or already received, the invoice is matched. Every system models this state. Most of them stop here and resume at state six.
-
Funded in kwacha
The local currency is available and committed. Internally the obligation now feels settled: the money is set aside, the budget line is consumed, the decision has been made. Externally nothing whatsoever has happened.
-
Lodged with the bank
The application for foreign currency is in, with a date and often a reference. This is the last point at which anybody in the business does anything — and in most businesses it is also the last point that gets recorded anywhere.
-
Waiting
Where the time goes. Days, weeks, in bad periods considerably longer. The supplier chases and the honest answer is that nobody knows. Meanwhile the payable is denominated in a currency that continues to move against the one already committed.
-
Allocated, wholly or partly
Some or all of the currency comes through. Partial allocation is common and it is the state that breaks the most reports, because the payable is now two payables with two histories and one invoice number.
-
Paid
The supplier has the money, at a rate set months after the commercial decision that created the obligation. The books record a payment and a difference. What they usually do not record is that the difference was produced entirely by the gap between states three and five.
An ageing report in this environment is not a measure of your payment behaviour. It is a measure of a bank queue, and it presents both identically.
The damage is bigger than the exchange loss
The revaluation is the number that gets noticed, because it lands in the accounts and somebody has to explain it. It is not the expensive part.
Consider what a supplier balance at 120 days can mean here. It might be a genuine dispute. It might be an oversight. It might be a cash shortage. Or it might be four months in a bank queue with a perfect file and nothing outstanding on your side. A standard ageing report shows all four identically.
| What follows | Why it matters |
|---|---|
| The report stops being read | Once a report is known to be dominated by one cause you cannot control, people stop opening it — reasonably |
| The genuine problems inside it stop being found | The actual dispute, the actual oversight and the actual duplicate invoice are now hiding in the same column as an administrative wait |
| Supplier conversations become negotiations about trust | Because nobody can state a stage, every call is an apology rather than an exchange of information, and suppliers who tire of it quote higher or stop quoting |
| Exposure accrues with no owner | The revaluation was created after every approval in the process had already been given, so no budget holder recognises it as theirs |
Two things that sound similar and are not
It is worth being precise about what this problem is, because there are two neighbouring problems that get conflated with it and neither responds to the same fix.
Not a rate problem
- The rate at settlement is not in dispute; it is simply months away from the rate at commitment.
- A business with a stable currency and a four-month queue still has this problem, in cash-flow form.
- Recording transactions at the rate actually applied is necessary and does not fix it.
- This is a time problem wearing a currency problem's clothes.
Not a documentation problem
- Unlike the CEMAC exchange-control file, there is no set of documents you can produce to make this move.
- The file can be perfect and the currency still not exist.
- So the fix is not a better checklist or a stricter matching rule.
- It is representation — the payable needs a state your chart of accounts does not have.
What can actually be done
Nothing on this list obtains foreign currency. It would be worth stopping to read any vendor claim that does.
- Give the payable a stage, not only an age — approved, funded, lodged, waiting, part-allocated, paid.
- Record the date lodged and the bank reference against the payable, so elapsed time in the queue is a number rather than a recollection.
- Make ageing reportable by stage, so a dispute is visually distinguishable from a wait.
- Handle partial allocation as one obligation with two settlements rather than two records with one invoice number.
- Calculate what the wait cost last year, once, deliberately. Almost nobody has this number and it belongs in a board pack.
Who owns which part
Graded honestly, because the first row is the one people hope for and the honest answer to it is no.
Obtaining or accelerating foreign currency
Not built, not buildable, and not a software category. No product obtains currency, influences an allocation or moves you up a queue. A vendor implying otherwise is selling something they cannot deliver, and that is the end of the evaluation.
The stages, as configuration
A status you define, the date lodged, the bank reference, an alert past a threshold of days, and reporting grouped by stage rather than only by age. Ordinary tools applied to your process — there is no forex-queue module and it would be dishonest to describe one.
The rate actually applied, retained
The transaction holds its original currency and the genuine rate rather than a standing monthly one, and a partial allocation is one obligation with two settlements rather than two records sharing an invoice number.
What to do about the exposure
Negotiating in local currency, agreeing terms that fix the local amount, forward cover where it exists. Commercial and banking decisions that belong with you and your advisers. We record what happened; we do not advise on it.
On where currency comes from
Arrangements outside the formal banking system are widely reported in this market. This piece takes no position on them and offers no advice about them: where you source foreign currency and on what terms is a commercial and legal question for you and your advisers. What a system should do is record transactions at the rate actually applied, so the accounts describe what happened rather than what a rate table thought should have happened. That is a design decision, not a recommendation about anything else.
The number worth producing this month
Two steps, both of which you can do without software and neither of which most businesses here have done.
First, list every payable currently waiting on an allocation: value, supplier, date lodged. If assembling that list requires asking people rather than running something, you have found the gap. It is also usually longer than the finance team expects, which is itself informative.
Second, take one import settled in the last year, find the rate at commitment and the rate at payment, calculate the difference, and multiply roughly by how many of those you do annually. That figure is the honest size of the problem. It is not a software problem — it is a business condition — but it is a figure a board should have, and having it changes what you buy and why.
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 integrated