Loan Management Software in Kenya for Microfinance and Lenders

Good loan management software in Kenya takes a loan from application to the final shilling without anyone typing a repayment from an M-Pesa statement. It appraises, disburses, receives payments on your Paybill, applies them to the schedule, charges penalties on time, reminds borrowers before they slip, and tells you each morning exactly which part of the book is at risk.

This guide is for microfinance companies, credit-only lenders, asset financiers and chama-style lending groups that currently run their book in Excel, or in an old system that no longer matches how they lend. It walks through each stage of the loan lifecycle and what the software should do at each one.

Where manual loan tracking breaks

A lender with fifty borrowers can manage a book in a spreadsheet. The problems arrive gradually, then all at once. You will recognise some of these:

• A repayment comes in on the Paybill with the account number typed wrongly, and it sits unallocated until the borrower complains that they are being chased for money they already paid.
• Penalties are calculated whenever someone has time, so two borrowers in the same situation are charged differently.
• The loans officer who knows which borrowers are "a bit late but fine" leaves, and that knowledge goes with them.
• Interest income in the loan sheet does not match interest income in the accounts, and nobody can say which is right.
• Head office asks for portfolio at risk by branch, and it takes three days to produce a number that is already out of date.

Each of these is a symptom of the same cause: the loan book, the money and the ledger live in different places, joined by people. Software fixes that by making one transaction update all three at once. If you are not yet sure you need a system at all, our guide to choosing business software helps with that first decision.

Applications and appraisal

The lifecycle starts before any money moves. The system should hold your rules so that every officer applies them the same way.

What to configure

• Loan products with their own interest method (flat or reducing balance), term, repayment frequency (daily, weekly, monthly), fees and limits.
• Eligibility rules such as minimum business age, maximum loan as a multiple of savings, or a cap for first-time borrowers.
• Required documents and checks: ID, KRA PIN where you need it, guarantors or collateral, and a credit reference bureau check if your policy requires one.
• Approval levels, so a loan over a certain size goes to a branch manager or credit committee automatically.

Maker-checker

The person who captures a loan should never be the person who approves it. This single control prevents a large share of internal fraud in small lenders, and a system should enforce it rather than rely on trust. Ask any vendor to show you that an officer literally cannot approve their own application.

Disbursement and repayment via M-Pesa

For most Kenyan lenders, M-Pesa is both how money goes out and how it comes back. This is the part of the system worth testing hardest.

Disbursement

Disbursing to a borrower's phone uses Safaricom's B2C service on the Daraja platform, which needs a B2C-enabled shortcode and approval from Safaricom. The system should record the disbursement against the loan, fix the repayment schedule at that moment, deduct any upfront fees correctly and post the whole thing to the ledger.

Repayment

Repayments arrive through Daraja's C2B service on your Paybill. The flow you want looks like this:

1. The borrower pays, entering their loan or ID number as the account number.
2. Safaricom sends the payment details to your system within seconds.
3. The system matches the account number to the loan and applies the money in your chosen order, typically penalties, then interest, then principal.
4. The ledger is updated, and the borrower receives an SMS showing the amount received and the new balance.
5. If the account number matches nothing, the payment goes to a suspense list for a person to resolve, rather than being guessed at.

That suspense list is a good test of a vendor's maturity. Systems that "auto-match everything" are either guessing or hiding problems. Our separate guide to M-Pesa payment reconciliation explains matching rules and how to clear unmatched payments quickly.

Penalties, arrears and reminders

This is where automation pays for itself. Late payments are cheaper to prevent than to collect.

A worked example

Say a lender in Eldoret issues a KES 30,000 business loan over 12 weeks with a weekly instalment of KES 2,900, and charges a flat penalty of KES 200 for each week an instalment is more than three days late (an illustrative policy, not a recommendation). Here is what software does without anyone remembering to:

• Two days before the due date, an SMS reminds the borrower of the amount and the Paybill details.
• On the due date, if nothing has arrived, a second SMS goes out.
• Four days after, with the instalment still unpaid, the KES 200 penalty is charged and the loan moves into the 1–30 day arrears bucket on the officer's list.
• At 30 days, the loan's entire outstanding balance, not just the missed instalments, counts towards portfolio at risk, and it appears on the branch manager's report.
• When the borrower pays KES 3,100, the system clears the penalty first, then the instalment, and sends a receipt with the remaining balance.

Done by hand, each of those steps depends on someone noticing. Done by software, they happen every day for every loan, consistently. Make sure your penalty policy is disclosed to borrowers in writing and is consistent with any rules that apply to your type of lender; the Central Bank of Kenya publishes the framework for digital credit providers.

Collections workflow

• A daily list for each officer of loans due and loans late, sorted by days in arrears.
• Notes and promises-to-pay logged against the loan, with a reminder on the promised date.
• Escalation rules: guarantor notification, field visit, then formal recovery.
• Restructuring recorded as a new arrangement, with the old schedule kept for the record.

Portfolio reports

A lender is only as healthy as its book. The reports below should be available at any time, not produced at month-end:

The key question is whether these figures come from the same data as the loan screens. If the PAR report and the balance sheet disagree, one of them is wrong, and the software should make that impossible.

Moving your book off spreadsheets

Switching systems mid-book frightens most lenders, and with reason: get the opening balances wrong and every borrower's statement is wrong from day one. A careful sequence keeps the risk small.

1. Freeze a cut-over date, ideally a quiet week just after month-end.
2. Clean the client list. Merge duplicates, fill in missing ID and phone numbers, and mark closed loans as closed.
3. Load each active loan with its outstanding principal, accrued interest, unpaid penalties, remaining schedule and days in arrears.
4. Prove the totals. The sum of outstanding balances in the new system must equal the loan book figure in your accounts on the cut-over date.
5. Tell borrowers by SMS if the Paybill account number format changes, well before the switch.
6. Watch the suspense list daily for the first month. Old habits produce odd account numbers, and clearing them quickly keeps borrowers' trust.

Expect the first fortnight to be slower, not faster. By the second month, most officers will not want to go back.

Choosing a system

Lenders tend to choose between three routes:

• International core lending platforms. Mature and feature-rich, but often priced for banks, and M-Pesa integration may need a local partner.
• Kenyan loan management products. Built around M-Pesa and local practice, usually cheaper to start, but check accounting depth and data separation carefully.
• Custom systems. Worth considering for unusual products such as asset finance with tracking devices, or lending embedded in another business. More expensive and slower, but fully yours.

Whichever you look at, ask these questions:

1. Does a Paybill payment post to the loan and to the ledger without anyone touching it?
2. Is the accounting a real double-entry general ledger?
3. What happens to a payment that cannot be matched?
4. Are reversals posted as reversals, with the original kept?
5. Is our data separated from other lenders' data, and can we export all of it at any time?
6. Can branch and officer access be restricted so each person sees only their own portfolio?
7. How is SMS billed: through our own provider account, or resold with a margin?

If you lend through a SACCO, you will also need share, deposit and dividend handling; our SACCO software checklist covers those extras. For microfinance companies, SACCOs and digital lenders, our own Microfin was built around exactly the questions above: Daraja C2B collections matched to loans automatically, B2C disbursement, unmatched payments held in suspense, and a general ledger that posts as each transaction happens. The product page lists current plans, and a demo on your own numbers is the quickest way to see whether it fits your book.