Most loan management systems sold in Kenya demo beautifully and fail in the same four places: the M-PESA integration turns out to be a CSV import, the "accounting module" is a report rather than a ledger, branch permissions are an honour system, and nobody can tell you how to get your data back out. This is what to check, and how to check it in a demo rather than after you have paid.
Start from what breaks today, not from a feature list
Every vendor's feature list is the same list. It is the same list because it is the list of things a loan management system obviously does — clients, loans, schedules, repayments, reports — and being able to do all of them is the price of entry, not a differentiator. What separates two systems is how they behave in the specific situations your business is already in.
So before you look at anything, write down the five things that actually cost you time this month. For most Kenyan lenders the list looks something like this:
- Somebody spends two days a month matching paybill payments to loans.
- The loan system's outstanding balance and the accountant's trial balance disagree, and reconciling them is an annual argument rather than a monthly check.
- A branch manager can see another branch's clients because the "permissions" are a dropdown nobody enforces.
- Disbursement is a person with a phone and an M-PESA float, recorded afterwards.
- Nobody can produce a defensible arrears report on demand, because three people maintain three versions of it.
Take that list into every demo and refuse to leave it. A system that solves four of your five is worth more than one that has three hundred features and solves two.
1. Ask exactly what "M-PESA integration" means
This is the single largest difference between systems sold at similar prices, and the phrase is used for at least four different things. Ask which one you are being shown:
| What it is called | What it actually is | What it saves you |
|---|---|---|
| Statement import | You download an M-PESA statement and upload the file. | Some typing. You still do it, and you do it late. |
| C2B callback | Safaricom's Daraja API posts each paybill payment to the system as it happens. | The matching, and the delay. This is the one that matters. |
| STK push | The system prompts the borrower's phone for a payment. | Chasing. Useful, but it is collection, not reconciliation. |
| B2C disbursement | The system sends money out to the borrower's number. | A person with a float and a spreadsheet. |
Then ask the question that separates a real integration from a demo: what happens to a payment that does not match? Real paybill traffic contains people who typed their national ID instead of their loan number, people paying for a relative, duplicate callbacks, and reversals. A system that silently guesses is worse than no system, because the wrong loan gets credited and nobody notices for a month. The correct answer is that unmatched payments go to a suspense list a human resolves, reversals are posted as reversals rather than deletions, and a repeated callback with the same transaction reference is ignored rather than counted twice.
We have written the whole of that mechanism up separately in how M-PESA paybill reconciliation actually works.
2. Make them show you a journal entry
Ask to see the double-entry journal a single repayment produced. Not a report — the journal. Debit bank, credit loan principal, credit interest income, and the amounts adding to the payment.
A large number of systems sold as having "full accounting" have a set of reports computed from the loan tables, which is not the same thing at all. The difference shows up the first time you write off a loan, reverse a payment, accrue interest on a loan that has stopped performing, or post an expense that has nothing to do with lending. A reporting layer gives you a number that cannot be traced; a ledger gives you an entry with two sides that a auditor can follow.
The test is simple and vendors rarely refuse it: make one payment in the demo and ask to see the trial balance before and after. If the trial balance does not move, there is no ledger under the product. See why your loan book and your ledger disagree for what this costs you later.
3. Branch and officer scoping, tested by logging in as somebody small
Ask for a login as a relationship officer at one branch, and then try to see another branch's clients. Try it in the search box, in a report filter, and by editing the ID in the URL. This takes ninety seconds and it is the most informative ninety seconds in the whole evaluation.
Scoping that is enforced at the query layer — so a branch user's search simply cannot return another branch's rows — behaves differently from scoping that hides a menu item. The second kind is extremely common and fails the moment somebody guesses a URL or exports a report.
While you are there, check that approvals are maker-checker: the person who creates a disbursement should not be the person who releases it. If one login can originate, approve and disburse a loan, you have bought a control weakness, not a control.
4. Get the exit answer in writing before you sign
Four questions, and the answers belong in the contract rather than in an email:
- Can we export everything, in a format we can read, at any time? Clients, loans, schedules, repayment history, ledger. CSV or Excel, not a proprietary backup only the vendor can open.
- Can we export while an invoice is unpaid? Anybody who says no is telling you they intend to hold a regulated business's records hostage over a bill.
- What happens to our data when we leave? There should be a destruction schedule with a number of days on it.
- Where is it hosted, and is our data in its own database? "Multi-tenant" covers everything from a separate database per customer to a shared table with a column marking whose row it is.
If you hold personal data on Kenyan borrowers — and you do, the moment you hold an ID number — these are not just commercial questions. See the Data Protection Act 2019 for lenders.
5. Price the migration separately, and scope it against real data
The licence fee is rarely what makes a system expensive. The migration is. Any vendor who quotes a migration without seeing a copy of your data is guessing, and the guess will be low — a migration priced blind is a migration that goes wrong halfway through and stops.
What should be migrated, at minimum: clients with their KYC, active loans with outstanding balances and remaining schedules, repayment history, and opening balances for the chart of accounts. What usually should not: five years of closed loans nobody will ever look at, and free-text notes that were never structured in the first place.
Moving a loan book off Excel without losing the history goes through the order to do this in and the three checks that tell you it worked.
6. Check it fits the regulator you actually have
A deposit-taking SACCO reporting to SASRA, a microfinance bank licensed by the Central Bank, and a digital credit provider licensed under the CBK's Digital Credit Providers regulations have genuinely different reporting obligations. A system built for one of them is not automatically wrong for another, but you should know which one it was built for and what that means for your returns.
SACCO, microfinance bank or digital lender: who regulates you sets out which regime applies to whom, and why it depends on what you take in rather than what you lend out.