M-Pesa Reconciliation: Closing the Collections Loop in Kenya

A rep is standing at a duka counter in Nakuru with the delivery already stacked behind him. The owner checks the note, picks up her phone and pays by M-Pesa. A confirmation appears on her screen, she reads the reference out loud, and he writes it in the margin of the delivery note.

For her, that is the end of it. The goods are hers, the money has gone, and there is a customer waiting at the door. For the brand, almost nothing has happened. A payment exists and it is attached to nothing.

Everything between that moment and the invoice being marked settled is the part nobody designs: a reference on paper, a statement pulled later, somebody in Nairobi working out which of four open invoices this outlet meant to pay. Collections in Kenya rarely drift because customers do not pay. They drift because the payment and the invoice are recorded in two places, by two people, at two different times.

A payment confirmation on a phone reconciling against an invoice line in a ledger view

The Payment and the Record Are Two Separate Events

M-Pesa is the default way money moves in Kenyan trade, not an alternative to something else. A duka, a kiosk, an agrovet and a mini-mart all reach for a phone before cash, and plenty of wholesalers do too. That part works.

What does not follow automatically is the accounting entry. The payment is an event in one place, the invoice a record in another, and the only thing joining them is a reference somebody has to capture correctly, once, at the counter. Miss it and the money is still real but unallocated, reducing nobody's balance. That is why collections teams spend mornings matching rather than chasing: the hard customers are not those who have not paid, but those who have paid and cannot be proved to have paid.

Matching is not clever work. It fails on missing fields, not on difficult logic. Before any of it can be automated, the collection record has to stand on its own:

  • The payment reference. Captured as given, not retyped from memory at the end of the beat.
  • The outlet, not the payer. The account being settled, by outlet code — the paying phone often belongs to someone else.
  • The invoice or invoices. Chosen from what is actually open on that account.
  • The amount applied. Often less than the payment, and often across more than one invoice.
  • Who collected, and where. So a disputed payment has a person and a place attached.

Till Versus Paybill Changes What You Can Reconcile

The choice between a till and a paybill looks like a treasury decision. It is really a reconciliation decision, usually made before anyone in finance is asked.

A till is built for over-the-counter payment. It is quick, the duka owner knows the routine, and the rep explains nothing. What it does not carry is a reference tying the payment to a particular invoice or outlet account. You get an amount and a payer name, and that name is often a relative, a shop assistant, or a phone with no connection to the business.

A paybill is set up to carry an account reference alongside the payment, which is exactly what reconciliation needs. The cost is that somebody has to enter the right one, and at a busy counter in an open-air market that is where it breaks. A reference entered as a shop name, a rep's first name or last month's invoice number is worse than none, because it looks like a match.

Most brands run both, and that is defensible. What is not defensible is running both without deciding which the field should use, what reference the payer should quote, and who owns the exceptions. Left undecided, the field uses whichever is quickest and the exceptions collect in a queue with no name on it.

Partial Payments, Combined Payments and the Bank Rail

Amount-matching works beautifully in a demonstration and poorly on a real route, because Kenyan trade payments are rarely one payment against one invoice. A duka pays part of what it owes, because that is what the day's takings allowed. A wholesaler settles three invoices with one transfer and leaves the brand to work out the split. An outlet pays a round figure covering one invoice and part of another.

So the collection record has to allow one payment across several invoices, and one invoice settled by several payments. Force a one-to-one relationship and the field works around it — rounding the allocation, holding payments back until they fit, or dumping the whole amount on the oldest invoice. Each quietly corrupts the ageing. Partial payment is also a signal worth reading: an outlet paying in halves is telling you about its cash position before it tells you by defaulting.

Not everything comes through a phone. Larger wholesalers, agrovet chains and supermarket groups settle by bank, using Pesalink or a plain account transfer, and some still issue cheques. These are fewer and larger, which makes the failures more expensive — one mis-posted wholesaler transfer can distort a region's ageing, and the remittance advice usually arrives separately. Keep the bank rail inside the same collections process, on the same outlet master and the same ageing. Reconciled in a spreadsheet of its own, it stops the debtor position being a number anybody trusts.

The Payment That Arrives After the Rep Has Left

Some of the hardest collections to reconcile are the ones nobody was present for. The rep delivers on Tuesday, the duka owner says she will pay when the day's takings come in, and she does — on Wednesday evening, from her own phone, with no reference, to a till.

Nobody in the field knows this has happened. The rep arrives on the next visit with an outstanding balance on screen and asks for money that has already been paid. That conversation costs the relationship far more than it costs the ledger.

The fix is not technical cleverness, it is an owned queue. Payments arriving with no field record need to land somewhere specific, be attributed to an outlet within a defined window, and reach the rep who covers that beat before the next call. It also matters that the outlet hears something back: a duka owner who pays after hours and gets no acknowledgement will pay the next one in cash, in person, and only when a rep is standing there.

Float and Cash Still Travel on the Route

M-Pesa has not removed cash from Kenyan route sales. It has removed most of it, which is a different thing and in some ways harder: the residue is handled with less discipline than when cash was the only method.

Van sales still carry an opening float, still take cash from outlets that prefer it, and still hand something over at day close. Where that cash is not declared against the same collection record as the M-Pesa payments, you get two half-pictures: a log that reconciles and a cash position reconstructed from memory.

  • Declare the opening float at the start of the day, not as a figure recalled at the end of it.
  • Record cash collections against the same invoice as M-Pesa ones, so an outlet has one payment history rather than two.
  • Close the day with a declared position — cash on hand, payments captured, deposits made — and treat the difference as an exception with a name attached.
  • Watch the conversion. Cash collected and then paid onward from a rep's own phone is a common and avoidable source of unattributable receipts.

None of this is about suspicion. It is about not asking a rep to remember, at seven in the evening after eighteen calls, what happened at the fourth.

Credit Exposure Sits on the Duka Account

Credit in the informal channel is granted at the counter, in small amounts, by people judged on volume. It is reasonable commercial practice and it accumulates into the largest risk most Kenyan distributors carry.

Exposure is only as accurate as the matching behind it. Unallocated payments make outlets look worse than they are, so good customers get blocked and the rep argues with the system. Missing collections make them look better, so credit keeps going to accounts that have quietly stopped paying. Both errors share one root, and neither is a credit policy failure.

A workable position needs three things kept current: a KES credit limit somebody owns and reviews, an ageing that reflects matched payments rather than promised ones, and a rule that operates at the point of order rather than at month end. Decide in advance what happens when an outlet is over its limit and standing in front of you — hard block, supervisor override or cash-only all work. Leaving it to the rep does not, because the rep has a target.

A Wednesday Afternoon on a Kisumu Route

A rep working the lake-side dukas and kiosks around Kisumu has eleven calls behind him. At the seventh, the owner owes for two deliveries. He shows her the balance on his handset, she disputes it, and she is right: she paid part of it on Saturday, from her sister's phone, to the till.

He cannot see that payment because it never had her outlet code against it. She can, on her own handset, and reads out the reference. He captures it against the older of the two invoices, notes the amount applied, and takes a fresh KSh 6,500 to clear the rest — this time to the paybill, with her outlet code as the reference, because that is what the brand asked for.

Two calls later, coverage drops out completely. He keeps working. The orders, the collections and both references sit on the handset and go up when signal returns. Nothing depended on the network being available at the counter, which matters where connectivity and power can both be interrupted without warning.

By the time the collections team looks at the day, the disputed payment already has an outlet, an invoice and an amount against it. Nobody had to reconstruct it.

A Payment Can Only Settle a Valid Invoice

Reconciliation assumes there is a correct invoice to reconcile against, and in Kenya that assumption carries a compliance weight it did not carry a few years ago. KRA has required electronic tax invoices through eTIMS since January 2024, across businesses broadly rather than only large VAT-registered ones. From January 2026, income and expenses declared in income-tax returns are validated against eTIMS data, expenses without a valid electronic invoice are non-deductible, and the penalties for getting it wrong are material.

The link to collections is direct. Trade customers need a valid invoice for their own deduction, so invoice errors become payment disputes rather than quiet corrections, and the collections team works a problem created upstream in order entry.

The Daily Discipline That Stops Collections Drifting

Collections drift slowly and then all at once. What holds them steady is not a monthly review but a short daily routine somebody owns by name.

  • A daily cut-off. Yesterday's collections are matched today, not at week end, while the rep still remembers the call.
  • One owner for the unmatched queue. Not a team, not finance in general. A named person whose day starts with that list.
  • A route back to the field. Unattributed payments reach the rep who covers that beat as a task on the next call, not as a line in a report.
  • An escalation age. Anything unmatched beyond an agreed number of days goes to a supervisor automatically, instead of ageing in place.
  • An honest write-off rule. Balances that will never be collected should be recognised as such, or the ageing becomes fiction and stops being used.

None of it is sophisticated, and all of it is boring. That is the point: collections stay clean through a small thing done daily, not a large thing done monthly.

Where These Programmes Go Wrong

Reconciliation programmes tend to fail in the same handful of ways, and most are design choices made early rather than problems discovered late.

  • Automating the match before fixing the capture. No rule can repair a reference that was never recorded. Get capture right at the counter first; the automation is the easy half.
  • Insisting on one payment to one invoice. Real trade payments are partial and combined. A model that cannot represent that gets worked around, and the workaround is where the errors live.
  • Leaving unattributed payments without an owner. A queue with no name against it grows until somebody declares an amnesty, and the ageing never recovers.
  • Running till and paybill without a rule. Both are legitimate. Using them interchangeably, with no agreed reference, is what makes them a problem.
  • Requiring live connectivity at the counter. An app that fails without signal or power gets replaced by a notebook on exactly the routes you understand least.
  • Measuring reps on collections without giving them the balance. A rep who cannot see an accurate ledger will negotiate from the customer's version of it.

None of those are really technology problems, which is why buying a system on its own rarely fixes them.

How 1Channel Supports Collections and Reconciliation

1Channel is not a payment provider, a mobile-money partner or a payments integrator, and it does not move money. What it does is close the gap between the payment and the settled invoice, by keeping the order, the invoice, the collection and the outlet balance in one system. Field teams work on entry-level Android handsets, capture happens at the counter, and records sync when coverage returns.

For collections specifically, the platform lets a team:

  • Capture an M-Pesa payment reference against a named outlet and a specific invoice at the point of collection, whether it went to a till or a paybill.
  • Allocate one payment across several invoices, and settle one invoice from several payments, including part payments recorded on different days.
  • Record cash collections, opening float and day-close declarations alongside mobile payments, so an outlet has a single payment history.
  • Hold a KES credit limit and a live ageing against each outlet, and apply it at the point of order rather than after the fact.
  • Route unattributed or disputed payments back to the rep who covers that beat as a task on the next call.
  • Support eTIMS-aligned invoicing, so the document being settled is the document the customer can claim against.
  • Report collections and ageing by outlet, route, distributor and region, with role-based access and audit trails aligned to Data Protection Act, 2019 obligations.

The reconciliation itself still belongs to finance. What changes is how much of it arrives already matched.

Key Takeaways

Collections in Kenya are a matching problem far more often than a payment problem. A few principles carry most of the value:

  • Capture at the counter, not in the office. A reference costs seconds to record at the duka and hours to reconstruct a week later.
  • Decide the till and paybill rule before the field decides it for you. Both are legitimate; using them interchangeably without an agreed reference is what breaks reconciliation.
  • Model partial and combined payments properly. Real trade money arrives in halves and in bundles, and a one-to-one design will simply be worked around.
  • Give the unmatched queue a name and a daily cut-off. Unattributed payments age badly, and nothing ages faster than a list nobody owns.
  • Base credit exposure on matched payments only. Promised money in the ageing blocks good dukas and extends credit to accounts that have already stopped paying.

Get those right and the monthly reconciliation stops being an investigation. The duka owner pays, the invoice closes, and the rep arrives at the next call already knowing the truth.

Insights

Want to get more insights? Click on a topic below