Microfinance Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does replacing the whole core in one release go wrong?

The board approves a core banking replacement, so the scope becomes a core banking replacement: loans, savings, shares, general ledger, branch teller operations, mobile money, member app, prudential reporting and migration, delivered together because a core is a single thing. Eighteen months later the project is still integrating the second mobile money operator and the field officers are still carrying paper collection sheets, which is where the actual losses are.

Microfinance makes this worse because your risk is not concentrated in the ledger. It sits in the window between a group meeting and the branch, in an unmatched paybill payment, and in an arrears classification that does not match what your platform computes. Each of those pays back on its own, and bundling them behind one go live means none of them pays back until all are finished.

The fix is to sequence by where the money leaks. In Digital Heroes delivery experience a focused first release covering group and individual loan origination, disbursement, the offline field collection application, officer cash accounts and branch reconciliation runs $90,000 to $180,000 and ships in 16 to 22 weeks. The full core adding savings and share products, one or two mobile money rails, prudential and investor reporting, a member self service application and migration off the legacy system runs $250,000 to $600,000 phased across 9 to 18 months. Take the field layer first, leave the legacy core as the ledger for a while, and let the recovered cash fund the rest.

What goes wrong when loan balances and savings ledgers are migrated?

The migration plan says move members, loans, balances and savings. What that omits is arrears history, and arrears history is where the undocumented decisions live: a loan rescheduled by a branch manager in 2023 with no record of the authority, a group cover that was posted as a payment rather than as a loan from the group fund, a compulsory savings balance partly applied to a written off account. None of that reconciles cleanly, and all of it affects a member's balance today.

In retail banking a wrong balance produces a call centre complaint. In microfinance it produces a group meeting where thirty people watch an officer fail to explain a figure, and the group's confidence is the collateral behind an unsecured loan. That is a credit issue, not a service one.

The fix is parallel running measured in weeks, not a cutover weekend. Move balances, run both systems, compare daily to the unit, and only retire the legacy core when the difference has been zero for a full repayment cycle. Treat arrears history as its own reconciliation exercise with a credit person involved, not a data load, because most of the awkward cases need a decision about what happened rather than a mapping rule. Print member statements from the new system and check them against passbooks in one branch before rolling further. Anyone who tells you migration is a weekend has not done it.

Why do mobile money integrations break after launch?

The paybill works in the sandbox and works in the first week. Then the failure modes arrive. A callback is delivered twice and the member is credited twice. A callback is delayed by hours and arrives after the officer has already recorded a cash payment for the same instalment. A member pays the right amount to the right paybill with a reference belonging to her sister, or to a member who left last year. The operator's end of day settlement file does not match what your system posted, and nobody notices for a fortnight because there is no automated comparison.

What makes this specific to microfinance is that the payer and the borrower are frequently different people, and the reference is typed by hand by someone standing in a shop. Matching cannot rely on a clean identifier because a clean identifier is not what arrives.

Three fixes. Store every inbound notification raw before anything is interpreted, so a matching rule can be rerun later without losing the source. Apply idempotency on the operator transaction identifier so a repeated callback cannot post twice, which is the single most common live incident in this category. And match in tiers, exact reference first, then phone number against member records, then name and amount against expected instalments, with anything unmatched going to a suspense account that ages visibly. Unmatched money is a liability, and pretending otherwise is how institutions end up with a balance nobody can explain to an examiner. Pull the operator's own settlement file daily and compare it to your postings automatically. Never trust the callback alone.

What happens when officer cash custody and offline sync are not covered?

The application records a repayment when an officer accepts it at a meeting. That is a payment in the software and it is not a payment in reality, because no money has moved anywhere. The officer is holding cash, sometimes overnight if the meeting is remote and the branch closed, and that cash is an institutional asset sitting in a bag on a motorbike. Loan servicing platforms have no concept of an officer float, a cash in transit balance, a banking slip that closes the float, or a shortfall recovered under a documented process, so the slow leak in that window stays invisible while the software reports a clean collection rate.

Offline fails alongside it, and for the same reason: the design assumed a completed request. Meetings happen under trees, in church halls and in market yards, on entry level Android phones that must last a full route. A design that requires connectivity produces receipts written on paper and entered that evening from memory, which is the data quality problem you were paying to remove.

The fix on both is structural. Give every officer a cash account that opens at zero each morning, credits every receipt she issues, and only clears when a branch cashier accepts and counts. Issue receipt numbers to her device in blocks so a voided or missing number is visible immediately, and put a ceiling on the float that forces banking before the next route. Build the collection application offline first: the device holds the group roster, schedules and balances before she leaves, records receipts locally with a device issued identifier, gives the member a receipt she can hold, and replays the queue when signal returns. Resolve conflicts by rule, rejecting a duplicate on its identifier and letting a head office schedule change override a cached copy, with anything unresolved going to a supervisor queue showing both versions.

Should you build custom or configure what you already own?

Configure and do not build if you are under roughly 8,000 active borrowers, lend individually, and take repayment by bank transfer or a single mobile money paybill. Apache Fineract is genuinely capable, the licence costs nothing, and a good implementation partner will get you live for far less than a build. Mambu is the right answer if you want a hosted core, your products are close to standard, and you would rather pay a subscription than own a system. Musoni was designed with field operations in mind and fits an institution whose model matches the way it was built.

Build when two or more of these are true. Your credit policy on group cover, savings liens and cycle eligibility is genuinely yours and you change it more than once a year, so every change in a packaged system becomes a fork you then maintain. Your officers work offline for a meaningful part of the week and your losses live in the cash window between a meeting and the branch. Your regulator's classification and provisioning rules do not match what your platform computes and you are already rebuilding returns in a spreadsheet.

A hybrid is legitimate and underused: keep Fineract as the ledger and build the field layer, officer cash accounts and reporting around it. That gets the leak closed without funding a full core, and it leaves the option to replace the ledger later once you know what you actually need from it.

How do hidden costs get into the quote?

Four places that reliably move the number.

• Mobile money rails. Each operator is weeks rather than days, because sandbox access, live approval, callback handling and the end of day settlement file are separate work. A quote saying mobile money integration without naming the operators and the countries has priced one of them.
• Migration. The single most underestimated line. Live balances, arrears history and savings ledgers have to move and then reconcile to the unit, with weeks of parallel running. Ask for it priced by number of accounts and a stated parallel period.
• Multi country operation. Each jurisdiction multiplies the reporting layer, and prudential templates and deadlines are not transferable. Price per regulator, not per institution.
• Deposit licence scope. Savings and share products carry obligations that lending alone does not, including lien behaviour and member equity across years. If you take deposits, say so in the first meeting, because it changes the ledger design rather than adding a module.

What separates a microfinance core that works from one that fails?

Four things, testable before you sign.

Ask them to draw the ledger before they draw a screen. A team that has done this puts member, group, loan account, savings account, officer cash account and suspense on the board as accounts with double entry between them, and they will tell you unprompted why the officer cash account is the one that saves you money. A team that draws users, loans and payments has built a lending application and is about to learn field banking on your budget.

The group is modelled as a balance, not a label. When a group covers a member from the meeting collection or the group fund, that is a posting with a counter entry against the member, the arrears clock keeps running on the original instalment because the regulator does not care who paid, and the decision about whether a savings lien is called is your credit policy expressed as a rule your committee can change without a vendor ticket.

Classifications are computed, not stored. The system holds raw instalment, posting and reschedule events, then computes the central bank's prudential bands, the portfolio at risk measure your social investor expects, and your board view as separate named policies over the same data. When a circular changes you revise one policy, rerun history, and show the examiner the old and new figures side by side.

You own it, in writing before kickoff: the repository, the cloud accounts and the unrestricted right to hire another firm. At Digital Heroes the code is yours from the first commit. In a regulated institution this is not only commercial hygiene, because a core banking system whose source you cannot access is a concentration risk an examiner will eventually raise with your board.