The month end that does not close
At 4pm on the last working day, a finance team is still hunting for 38,000 naira. The bank statement says one number. The ledger says another. The gap is small, the books must close tonight, and three people are scrolling spreadsheets side by side.
This is reconciliation. It is not glamorous, nobody puts it in a pitch deck, and it is where a surprising number of fintechs quietly lose control of their own money.
What reconciliation is
Reconciliation is the act of proving that two records of the same events agree. Your internal ledger says a customer paid you. The bank, the card processor or the mobile money operator says the money arrived. If both agree, fine. If they do not, something is wrong, and you need to find out what before someone else does.
For a payments company there are usually more than two records. There is your own transaction table, your ledger, the processor's settlement file, the bank statement, and sometimes a partner's report. Each is produced by a different system, at a different time, in a different format.
Why it fails quietly
Reconciliation breaks in ways that never cause an outage. The product keeps working. Customers keep paying. The gap grows in the background and becomes visible only when somebody looks.
Timing differences. A transaction succeeds on Monday, settles on Wednesday and appears on the statement on Thursday. For two days the records legitimately disagree. If your system cannot tell "not yet" from "wrong", every day produces false alarms, and soon the team ignores the alerts.
Fees and rounding. Processors deduct fees before settlement. Rates differ by channel. One system rounds each fee, another rounds the total. The differences are tiny, and they are everywhere.
Duplicates and reversals. Retries, webhooks delivered twice and chargebacks all create entries that need to be matched to the originals. A reversal that arrives without a clear reference to the first transaction is a puzzle.
Missing references. The best matching key is a unique reference passed through every system. When a processor truncates it, or a bank statement drops it, matching falls back to amount and date, which breaks the moment two customers pay the same amount on the same day.
Manual repair. When a gap is found, someone fixes it with a journal entry and a note. Enough of those, and the ledger stops being a record of events and becomes a record of corrections.
What a sound approach looks like
We treat reconciliation as a product, not a month end chore.
First, design for matching from the start. Every transaction carries one internal reference that travels through every external system, and the ledger stores the external reference alongside it. It is cheap to build in and very expensive to retrofit.
Second, reconcile continuously. Run matching daily, or more often, against each source. Small breaks found the next morning are easy to explain. Breaks found a month later are archaeology.
Third, give breaks states. Matched, pending with an expected date, mismatched, and unmatched are different conditions with different owners. A pending item that passes its expected date should turn into an exception on its own.
Fourth, keep corrections visible. Adjustments are separate entries with a reason and an author, never edits to history. That is how you stay auditable.
Finally, make exceptions a queue with an owner. A report that someone may read is not a control. A queue that someone must clear is.
The honest limits
Perfect matching is not always possible. Some partners send poor data, and some differences are never explained, only written off under a policy your auditors accept. Automation reduces the pile. It does not remove the need for a person who understands the money.
The cost is also real. Building this properly takes engineering time that does not ship a visible feature. Early teams are often right to start with a simple daily match and a clear exception list, and to add sophistication as volume demands it.
An example of a break, step by step
Suppose a customer pays 50,000 naira to a merchant through your platform. Your system records the payment on Monday. The processor settles to you on Wednesday, deducting a fee of 750 naira, so 49,250 arrives in your bank account. The bank statement shows the credit on Thursday with a truncated narration.
A reconciliation process that works well does the following. On Monday it creates an expected settlement entry marked pending, with an expected date. On Wednesday the settlement file arrives and matches by internal reference, and the fee is recorded as its own line. On Thursday the bank statement credit matches the settlement total, since one credit often covers many transactions. At the end, three records agree, and each step leaves a trace.
Now take the version that fails. The processor settles 49,250, but the narration lost the reference. The statement line cannot be matched. The finance team sees an unexplained credit and a pending payment, and guesses. A guess becomes a manual entry. In a month, it is one of several hundred.
Who owns this inside a company
In many companies, reconciliation belongs to finance, while the references and data that make it possible belong to engineering. Neither side has the complete picture. Finance sees the breaks and cannot fix their cause. Engineering controls the cause and never sees the break.
The fix is organisational as much as technical. Put one named person in charge of the reconciliation outcome. Give engineering a regular report of the break categories, ranked by cost, so they can remove causes at the source. The best reconciliation teams we know spend their time deleting categories of break, not clearing the same ones every month.
Signals that your reconciliation is weaker than you think
- Month end close routinely slips because of unexplained differences.
- Write offs are growing, and nobody can say why.
- Only one person understands how the matching spreadsheet works.
- Support tickets about "missing" payments take days to resolve because staff cannot see settlement status.
If two or more are true, it is worth treating this as an engineering project, with a plan and an owner.
What we would check first
Pick last week. Can you say, for every transaction, whether it matched the bank, and if not, why? If that takes a person three days with a spreadsheet, the weakness is already there. Start with the reference that connects your systems, and build outward from it.
Fintechs rarely fail because a payment button broke. More often it is a gap in the books that nobody could explain in time.