Two Ledgers, One Truth: How an NGO Closed the Gap Between M-Pesa and Business Central

Composite scenario drawn from typical East African deployments. Institution details are anonymised and figures are representative rather than attributable to a single client.

Month-end took eleven days

An international NGO running programmes across four Kenyan counties had a finance function that worked hard and closed late.

Payment requests came in by email — supplier invoices from programme offices, petty cash requests from field teams, cashbook payments from the Nairobi office. Approvals happened in reply-all threads. Once approved, a finance officer initiated an M-Pesa payment through the gateway portal, saved the confirmation to a folder, and later keyed the entry into Dynamics 365 Business Central.

The gap between the payment leaving and the entry landing was typically two to three weeks. At month-end, someone reconciled an M-Pesa statement against a general ledger that had been populated from memory and folder names.

Eleven days to close. Two prior donor audits had raised findings about supporting documentation that could not be linked to specific transactions. Nothing had been misappropriated; the trail simply did not hold together.

The three real problems

Approval had no state. An email thread is not a workflow. Nobody could say how many requests were awaiting approval, who held them, or how long they had been sitting. Requests were routinely re-sent because the submitter assumed they had been lost — sometimes creating duplicates that were paid twice and recovered later.

Payment and posting were separate acts by separate people. The person who disbursed was not the person who posted, and neither owned the link between them. A payment reference existed in the gateway. A journal entry existed in Business Central. Nothing connected them except a filename convention that had drifted.

Documents lived apart from transactions. Invoices sat in SharePoint, in a folder structure organised by the programme officer who uploaded them. Finding the invoice behind a specific ledger entry meant knowing who had submitted it and roughly when.

What was implemented

The NGO deployed Creodata's expense and payment platform on Azure, with Entra ID single sign-on so that staff used existing accounts and role assignments followed the organisation chart.

Approval became a stage, not a thread. Requests route through a defined chain — head of department, then finance reviewer, then CFO where thresholds require it — with role-based dashboards for each. Every participant sees what is waiting on them. Overdue approvals escalate automatically, which ended the practice of programme officers physically walking to the CFO's office.

Payment moved inside the workflow. M-Pesa disbursement — both B2C for field payments and B2B for suppliers — is initiated from the approved request itself, through the gateway integration. The payment reference returns to the request record. There is no window in which a payment exists and the system does not know about it.

Posting became automatic. Approved and paid requests post to Business Central over OData, with the supporting document attached, so the ledger entry and its evidence arrive together. The re-keying step, and the two-to-three-week lag it created, no longer exists.

Documents attached to transactions, not folders. SharePoint remains the document store, but filing is driven by the request rather than by the uploader's habits. The invoice behind a ledger entry is one click from the entry.

Three request types — supplier invoices, petty cash and cashbook payments — were configured with different approval thresholds and different documentation requirements, because treating a KES 4,000 field petty cash top-up like a KES 2 million supplier invoice had been a genuine source of delay.

The result

Month-end close moved from eleven days to three. That number gets quoted internally, but the finance director cares more about a different one: the reconciliation between the M-Pesa statement and the ledger is now a verification rather than an investigation, because both sides were written from the same event.

The next donor audit produced no documentation findings. When the auditor selected a sample of 40 transactions, each one resolved to an approval chain, a payment reference and an attached invoice without anyone leaving their desk.

Duplicate payments stopped, for the unglamorous reason that a submitter can now see their request is pending rather than assuming it vanished.

What transfers to other organisations

If approval lives in email, you do not have an approval control. You have a convention. It cannot be reported on, escalated, or evidenced to an auditor, and it silently generates duplicates.

Mobile money widened the gap it was supposed to close. Instant disbursement paired with manual posting produces a larger reconciliation problem than cheques did, because volume goes up and the lag stays. The disbursement and the ledger entry need to originate from the same record.

Attach documents to transactions at the moment of approval. Retrofitting evidence to a ledger entry six weeks later is the single most common cause of audit findings we see in donor-funded organisations — and it is entirely avoidable.

Further reading: The Complete Expense Management Guide · Improving Audit Readiness with Workflow-Based Expense Approvals

---

Closing late, or carrying audit findings on documentation? Book a consultation or explore Expense Management to see how approval, payment and posting work as one chain.