One Payment at a Time

The last step in buying something is paying for it, and it is the step where the money actually leaves. Everything upstream — the requisition, the approval, the order, the receipt, the match — exists to make that final action safe.

Ours is safe, one payment at a time, and only one payment at a time.

What is genuinely well built here

It is worth starting with the control, because it is one of the better things in this product and it would be easy to miss underneath the complaint.

There is a single definition of whether something may be paid, and every route that can move money calls it — the web screen, the interface, the manual vendor payment, and the mobile money and card routes. That matters more than it sounds: those routes were built at different times and write to two different ledgers, and before the gate existed they shared no check at all.

A discrepancy between what was ordered and what was received blocks payment by default. Paying before anything has arrived only warns, because deposits and prepayments are legitimate, and you can turn that into a block if you want it. Overriding a block needs a permission that is deliberately not the same as approving purchase orders, plus a written reason — and the override is pinned to the specific discrepancy it authorised, so it withdraws itself if the documents change into a different problem or the order later reconciles. A stale authorisation cannot keep releasing money.

The authorisation is strong. It is the ceremony around it that does not exist.

What a payment run is, and why its absence is felt weekly

A payment run is the practice of paying suppliers in batches on a rhythm rather than continuously as invoices arrive. It is not primarily an efficiency measure, though it is that too. It is a control, and a scheduling instrument, and a negotiating position, all at once.

1. Select what is due

   Everything approved and payable as at a date, assembled in one place, with the total visible before anything is committed.

2. Review the batch as a whole

   This is the step that catches things no individual payment ever could — the same supplier appearing twice, an amount out of line with their history, a payment about to go to a supplier somebody meant to put on hold.

3. Approve once, at the total

   Somebody senior authorises a figure they can see in full, rather than forty separate figures they never see together.

4. Release, and reconcile as one

   The batch is paid and reconciles against the bank as a batch, which is dramatically easier to check than forty separate movements.

Without it, each of those four steps either does not happen or happens in somebody's head. The selection is whatever the clerk got to today. The review is per payment, so the comparisons that matter are unavailable. The approval is repeated forty times at a scale small enough that nobody senior looks. And reconciliation is forty lines to match rather than one.

Why this bites harder on a group operating across several countries

Because the number of payment decisions multiplies with entities and currencies while the number of finance people does not. A group with operations in five countries has five sets of suppliers, often five banking relationships, and one small finance team trying to hold a picture of what is going out.

The individual-payment model quietly pushes the aggregation problem onto that team, and they solve it the only way available: a spreadsheet assembled by hand each week, which is the thing the system was supposed to remove. Worse, the spreadsheet becomes the real control — the place where the review actually happens — while the system holds the authorisation. Splitting a control across two artefacts is how it stops being reliable, because neither is complete and each assumes the other.