M-PESA reconciliation & financial record integrity
A successful payment is not a reconciled one. We take a month of your M-PESA records and a month of what your own system recorded, match them line by line, and account for every difference we can — naming what is unmatched, what looks duplicated, and what the evidence cannot settle. The assessment is free and the findings are yours whatever you do next.
These are the things that can go wrong between money arriving and your records being right about it. Not an accusation about your business — a list of what we would be looking for.
The money is in the M-PESA records. No order, invoice or ledger entry corresponds to it. Usually the reference was mistyped, or the payment was for something recorded elsewhere — but until somebody looks, it is simply unexplained.
The business system shows the transaction. The payment evidence does not. That can be a timing difference across a cut-off, a confirmation that never arrived, or a record entered in advance of the money.
A statement re-uploaded because nobody was sure the first one worked. A confirmation retried by the sender. Without a guard against it, one payment becomes two — and every figure built on top reads high, which is the expensive direction.
Somebody exports a statement, opens the sales report beside it, and compares references and amounts down the page. It mostly works. It does not scale, it is not repeatable, and nobody can say afterwards how a particular figure was arrived at.
What a comparison can consider
Not every source carries every field. Which rules are possible depends on your records, the payment route and the data quality, which is why the rules are agreed with you rather than assumed.
And what it can conclude
Matched
Reference, amount and timing agree within the rules you have agreed. Nothing further is owed on it.
Probable match
Enough agrees to be likely, not enough to be certain. Put in front of a person rather than resolved by a rule.
Unmatched payment
Present in the payment evidence, with no business record that accounts for it.
Missing business record
Present in your system, with no payment evidence against it.
Possible duplicate
Two records that appear to describe one payment, flagged rather than merged.
Not resolvable
The available evidence cannot settle it either way. Named as such instead of being counted as either.
An ambiguous record stays ambiguous. Matching it on a reasonable rule would make the report look cleaner and the books less true.
Which routes money arrives by, what your own system records against each payment, and how reconciliation is done today. Scope is agreed in writing before anything starts.
One call, thirty minutes
How references, amounts and dates should be compared, what tolerance is reasonable, and at which point a record should stop and wait for a person instead of being matched by a rule.
Before any comparison
Every payment read against what your system recorded, with the results separated into matched, probable, unmatched, missing, possibly duplicated, and not resolvable from the evidence.
Within five working days
Each exception written up with the records behind it, so anyone in your business can check the reasoning. Where repeatable matching is worth building, it is scoped and quoted separately.
With the findings
What arrived
Matched against
Under rules you agreed
What comes out
An illustration, not anybody’s records
Payment evidence
SJ4••••001
Amount
KES 12,000
Your record
INV-1041 · KES 12,000
Outcome
Matched
Payment evidence
SJ4••••002
Amount
KES 8,500
Your record
no record with this reference
Outcome
Unmatched payment
Payment evidence
—
Amount
no payment evidence
Your record
INV-1043 · KES 20,000
Outcome
Missing business record
Worth doing if
Probably not if
What it is not
Because we are building toward a reconciliation product, and real records are the only way to learn what one has to handle. You get the findings whether or not you ever become a customer, and we will say plainly if the answer is that your records agree and your process is sound — which is a good result, and the one we expect from a business that has this under control. What we will not do is find something to sell you.
An M-PESA statement for the period, and an export of what your own system recorded over the same period. Almost every accounting package, ERP, marketplace and in-house system can produce one, so there is nothing to build before the first piece of work.
Accounting or ERP exports, order and invoice records, a spreadsheet somebody maintains, a marketplace report, or existing payment confirmation logs if you keep them. We work with what exists rather than asking you to produce something new.
Whether payment records can be pulled directly, rather than exported, depends on your shortcode, how it is set up, what Safaricom will authorise for it and how far back the records reach. It is a question answered during scoping, with evidence — not a capability claimed in advance.
The assessment runs on files you send. We do not ask for an M-PESA PIN, a portal login, API keys or access to any live system, and you should refuse anyone who does.
If payer names or phone numbers are not needed to answer the question, say so and remove them before sending. A reference, an amount and a date are usually enough.
Your records are kept separate from every other engagement, used for your assessment and nothing else, and deleted on request once the findings are delivered. Retention is agreed in writing with the scope.
Every match and every exception carries the records that produced it. Where a person made the call rather than a rule, that is recorded too. A finding you cannot trace back is a finding you should not act on.
Reconciling records does not move money. This work cannot initiate, reverse or recover a payment, and nobody reconciling your books should ever ask you for an M-PESA PIN or a portal password.
Comparing the record of money that arrived against the record of what it was for, and accounting for every difference between the two. A payment confirmation proves a payment happened. Reconciliation establishes which order, invoice or account it belongs to, and whether your own books now say the right thing.
No. It is a scoped piece of work on your records, delivered as written findings. There is nothing to install, no dashboard, and no subscription. If the findings justify building something, that is quoted separately afterwards.
That is the whole of it. Payment evidence on one side, your own order, invoice or ledger records on the other, matched on the fields both actually carry — and every difference listed rather than averaged away.
No, and it is the most common case. A spreadsheet is an export already. What matters is whether it carries a reference, an amount and a date for each transaction; if it does not, that is itself the finding, and we will tell you which field is missing.
Usually not. In order of likelihood it is a mistyped or absent reference, a timing difference across a cut-off, a confirmation that never arrived, a duplicate import, or a record entered by hand. Theft is possible and it is the last explanation the evidence supports, not the first. Anyone who tells you otherwise before looking at your data is selling you something.
Not in the general case, and this is worth understanding before anyone promises otherwise. Safaricom's transaction status query needs either the M-PESA receipt number or the originator conversation ID, and a payment you never heard about gives you neither. There is a separate interface that returns transactions for a shortcode over a requested period, including ones whose confirmation failed to arrive, but it covers only a short recent window and has to be enabled for the shortcode first. After that window, the statement export is the record — which is one of the reasons this work starts there.
Not for the assessment. Exports are enough. Whether a direct connection is worth building afterwards depends on your volume and how often you need the answer, and we would have to justify it rather than assume it.
Yes, as far back as you can export records for both sides. Historical reconciliation is often more useful than live, because the differences have stopped moving and can be settled once.
Files, sent by you. No credentials, no live system access, no PINs. Strip any field the question does not need before sending. If later implementation work needs access to something, it is agreed in writing and scoped to that work.
You have the findings and nothing further is owed. If something in them is worth building — repeatable matching, a duplicate guard, exceptions raised when they happen rather than at month end — we scope and quote it. You are free to take the findings to somebody else and have them do it.
Because we are building toward a reconciliation product and real records are the only way to learn what it has to handle. You get the findings whether or not you ever become a customer, and if the honest answer is that your records agree and your process is sound, that is what the report will say.
A fee platform reconciling payments to named pupils across schools that must never see each other's books, where money arrives live, by file and by hand and all three reach one answer through one piece of code, the same payment arriving twice is recorded once, and an ambiguous match is routed to a person rather than guessed. The case study is on this site.
Start with one month
Start with a review of your transaction records, your business records and the way you reconcile them now. We will establish what can be matched, what remains unresolved, and what should happen next. The findings are yours whatever you decide.
Request the assessment