Six Doors, Two Ledgers, One Register
There are six ways to pay a supplier in this product and they write to two different ledgers. For a long time they shared no guard at all. The fix was not a check — it was a service that all six had to call, and the reason that matters is the lesson rather than the feature.
When somebody asks whether a system controls supplier payments, the honest first question back is: how many ways are there to pay one? Because a control on the payment screen is worth nothing if there are five other screens.
In ours there were six, and they wrote to two separate ledgers, and none of them shared a guard.
The six doors
Paying an order through the web interface. Paying it through the API. Recording a manual vendor payment. Two mobile-money paths — one for paying a person, one for paying a business. And a card processor.
Each of those was written at a different time, for a different reason, by somebody solving the problem in front of them. None of them was wrong. Together they were a control surface with five holes in it, and nobody had ever counted.
Count the doors before you design the lock. The number is almost never one, and it is almost never the number anybody guesses.
Why two ledgers
The same accretion, at the data layer. One payment path grew up alongside the original order module; another grew up alongside the vendor payment rails, with their own webhook logs and their own payee records. Both are real, both hold real money movements, and they are not the same table.
That is not a defensible design and we would not present it as one. What it is, is the ordinary shape of a system that grew — and the useful part is what was done about it rather than the apology.
Two things were done. A cross-module payments register pulls both together so there is one place to see money going out regardless of which rail carried it. And a single gate now decides whether an order may be paid, and every one of the six doors calls it.
What the gate does
A discrepancy between what was ordered and what was received blocks payment by default. Paying before receipt only warns, because prepayments and deposits are legitimate, and that warning can be turned into a block per organisation.
Overriding needs a dedicated permission — deliberately not the one that approves purchase orders — plus a written reason recorded with who and when. And the override is pinned to the discrepancy count it authorised, so if the documents change into a different problem it withdraws itself. A stale authorisation cannot keep releasing money.
That last detail was found by a test rather than by design. The first version would have kept authorising payment after a discrepancy agreed as "short delivery accepted" turned into something else entirely.
What is still one payment at a time
There is no payment run and no batch payment approval. Payments are recorded and released individually, one order at a time, by a person.
For a business paying a handful of suppliers a week that is unremarkable. For one paying dozens on a fixed day it is a real cost, and the cost is not only time — a person doing the same action forty times in an afternoon is a person who stops reading the screen.
| What you might expect | What is here |
|---|---|
| A weekly payment run | Individual payments |
| Approve a batch of payments together | No batch approval |
| A bank file to upload | No payment file export |
| One register showing all money out | Yes — the payments register spans both ledgers |
| One rule deciding what may be paid | Yes — one gate, called by all six paths |
| Mobile money beyond one provider | One integration only |
The last row is worth flagging for anybody outside East Africa in particular. There is exactly one mobile-money integration in the product. Where your suppliers are paid through a different provider, that payment is a manual vendor payment recorded after the fact rather than a rail the system operates.
Four questions about payment controls in any system
How many ways can a supplier be paid in this system?
A good answer sounds like
A number, and a list.
What it actually means
A vendor who has never counted has never audited the control surface. Ours is six and we had to find them.
Do all of them call the same guard?
A good answer sounds like
Yes, and they can name it.
What it actually means
This is the question. A control implemented as a check in one controller is a control on one door.
Is the override a permission or a separate permission?
A good answer sounds like
Separate from the approval it overrides.
What it actually means
An override sharing a permission with the approval is not a separation of duties, whatever the audit log says.
Does an override expire when the facts change?
A good answer sounds like
Yes, pinned to what it authorised.
What it actually means
A standing override is a permanent hole with a justification attached to it.
What AWRA OpsHub does today
- A single gate deciding whether an order may be paid, called by all six payment entry points across both ledgers.
- A discrepancy blocking payment by default; payment before receipt warning, switchable to a block per organisation.
- Overrides requiring a dedicated permission plus a written reason with actor and time, pinned to the discrepancy count they authorised.
- A cross-module payments register showing money out regardless of which rail carried it.
- Supplier payment rails held per vendor — bank details and mobile-money identifiers — and a card processor path.
- Webhook logging on the vendor payment rails.
What it does not do
- A payment run or batch payment approval. Payments are recorded individually.
- A bank payment file export.
- A single unified payment table — two ledgers exist and the register reconciles across them rather than replacing them.
- Mobile money beyond one provider. There is one integration and no other.
- Any supplier-facing remittance advice generated automatically.
Not ours, by choice
- The two ledgers are an accretion rather than a design, and we would rather describe them accurately than present the register as though the underlying tables were unified.
- The gate is the strongest control in the procurement module. It exists because somebody counted the doors, which is the transferable part of this page.
- Nothing here is Angolan. It is the arithmetic of plural payment rails; this is a market where plural rails are the norm rather than the exception.
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, a rule your own operation needs that the standard one does not have, 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.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
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 integratedOur position
The gate is real and it covers every path, which is more than most systems in this bracket can say. Plan for individual payments rather than a run, grant the override permission to at least two people so it is not an availability problem, and if you pay suppliers through a mobile-money provider we do not integrate with, treat those as recorded rather than operated and reconcile them deliberately.
Count your own doors
Whatever system you are evaluating, ask for the list of ways money can leave. It is the single most revealing question in a procurement demonstration and almost nobody asks it.
Talk about controlsFrequently asked questions
Why not merge the two payment ledgers?
Because both hold live history, and a merge is a data migration with a reconciliation risk rather than a refactor. The register that spans them gives you the single view without moving anything, which is the safer order to do it in — and it is honest to say the underlying tables are still two.
Can I stop payment before receipt entirely?
Yes, per organisation. The default is a warning because prepayments and deposits are legitimate for many suppliers, and a business that never prepays should switch it to a block on day one.
What happens if a supplier is paid outside the system?
Record it as a manual vendor payment, which is a first-class path and calls the same gate. The risk with any out-of-system payment is not the record, it is the delay — an order that reads unpaid for three weeks will be paid twice by somebody eventually.
