SACCO Management Software in Kenya: What It Does and How to Choose

An ordinary business keeps a record of what it sold and what it owes. A SACCO keeps a record of what it owes its own members, which is a materially harder problem. Every member has a share capital position, a deposit balance, possibly several loan balances, a guarantor exposure to other members' loans, a dividend entitlement and a transaction history, and all of those have to reconcile to the shilling against each other and against the SACCO's own books. The members are the owners, so the record is not an internal management tool. It is the basis of their claim on the institution.

That produces three requirements general software does not have. The first is that any balance has to be reconstructable as at a past date, with the transactions that moved it, because that is what an audit is. The second is that changes have to be attributable: who altered a member record, when, and what it was before. The third is that the system has to produce member statements on demand that are correct without anyone assembling them by hand from several places, because a member who cannot get a clean statement stops trusting the SACCO, and member trust is the entire basis of the model.

Layered on top of that, a SACCO licensed to take deposits carries regulatory reporting obligations to the Sacco Societies Regulatory Authority. The specific returns, their frequency and their format are set by the regulator and revised, so confirm the current requirements with SASRA rather than relying on a vendor's description of what its reporting module covers. A system that cannot produce what the regulator currently asks for is not fit for purpose regardless of how good the rest of it is.

Most SACCO software demos show the member dashboard first. The things that determine whether a system survives an audit are further down the list, so ask about them first.

1. 1

   Can it reconstruct a balance as at a past date?

   Ask the vendor to show you a member's deposit balance as at a date twelve months ago, and the transactions that have moved it since. If that takes an export and a spreadsheet, the system is a current-state database rather than a ledger, and every audit will be an event rather than a routine.

2. 2

   Is every change attributable?

   Ask to see the audit trail on a member record: who changed what, when, and the previous value. A member record that can be edited without leaving a trace is the single largest internal fraud exposure a SACCO has, and it is the first thing a competent auditor will test.

3. 3

   Does it produce a member statement on demand, correctly?

   Ask for a full member statement covering share capital, deposits, loans and guarantees, generated in front of you, without preparation. This is the document members actually judge the SACCO by, and systems that assemble it from several sources produce statements that disagree with each other.

4. 4

   Does it handle guarantor exposure as a real position?

   A member guaranteeing three other members has a committed portion of their own deposits and a reduced borrowing capacity. Ask to see that modelled, not as a note on a file but as a balance the system enforces when the guarantor next applies to borrow. Many systems track guarantees as text.

5. 5

   Does it reconcile M-Pesa to the member, automatically?

   Most Kenyan SACCOs collect deposits and repayments by mobile money, and matching those to the right member account is where the manual work actually is. Ask specifically what happens to an unmatched payment, because the exceptions are the workload, not the matches.

6. 6

   Does it produce the returns the regulator currently requires?

   For a deposit-taking SACCO, confirm the current return requirements with SASRA directly and then ask the vendor to demonstrate producing them, rather than accepting a feature-list claim. Requirements change; a module built against an older format is worse than no module.

7. 7

   What happens to your data if you leave?

   Ask for the export format, whether it includes full transaction history rather than closing balances, and what it costs. A SACCO that cannot get its own member history out of a system is not choosing a supplier, it is choosing a permanent dependency.

8. 8

   Who is accountable when it is down?

   Ask about business continuity, backup frequency, where data is held, and what the recovery process actually is. Member deposits are involved, so this is a governance question for the board rather than an IT preference.

Veira is a point-of-sale and business operating system for Kenyan businesses. It does not hold member accounts, share capital, member deposits, loan ledgers, guarantor positions or dividends, it does not produce SASRA returns, and it is not a replacement for a SACCO management system. If you are shopping for the category described above, Veira is not in it, and a page on the Veira site should say so plainly rather than blur the line.

There are two places where Veira is genuinely relevant to a SACCO, and both are outside the member ledger. The first is the trading side. A SACCO that runs a member shop, a canteen, or a fuel and spares counter at a transport SACCO is running a retail operation, and that operation needs a till that works when the connection drops, stock that is counted rather than estimated, staff selling under their own logins, and a KRA-compliant eTIMS invoice on every sale. That is what Veira does, and it sits alongside the SACCO system rather than replacing any part of it.

The second is the member's own business. Sacco lending is sized against deposits, but a loan application for a business purpose still asks what the business earns, and most small Kenyan businesses answer with an estimate. A business running on Veira has a recorded trading history instead, with business money kept separate from personal money, which is a document rather than an assertion. That is ordinary business software being useful to a SACCO member, not a SACCO feature.