Two credible revenue totals before breakfast signal that transaction volume has outrun the company’s operating model. The conflict usually appears when payments, refunds, fees and settlement timing can no longer be represented by the records and routines built for an earlier stage.
At 7:18 a.m. in Cape Town, Ama had one hand around a cooling mug of coffee and the other on her phone. She is a composite founder, drawn to illustrate a common operating problem. Her payments dashboard showed one revenue total for the previous month. The finance spreadsheet showed another, and both looked defensible.
A board update was due that morning. If Ama reported the higher number and it included unsettled payments, she could overstate performance. If she used the lower number and the spreadsheet had omitted valid transactions, she could misrepresent the company’s growth. Two people on her small team had already checked the calculations. Neither could explain the gap.
Two correct numbers can describe different events
A revenue figure feels definitive because it arrives with a currency symbol and two decimal places. Yet every total rests on a definition.
One system may count a transaction when a customer pays. Another may count it when funds settle. A third may subtract refunds immediately while a spreadsheet records them at the end of the week. Cross-border activity can add another layer through currency conversion, processing fees and settlement dates.
Each record may be accurate within its own frame. The trouble begins when nobody can state which frame governs the company’s decisions.
Ama’s team had built its process when transaction volume was low enough to inspect by hand. One person exported a file, another copied totals into a spreadsheet, and unusual payments were resolved in chat. That worked because everyone remembered the exceptions.
Growth changed the calculation. More transactions created more edge cases. More markets introduced more timing differences. The process still looked familiar, but it now depended on memory, manual corrections and definitions that lived inside individual heads.
The conflicting totals exposed that dependence.
Reconciliation failures arrive before visible breakdowns
Founders often treat a mismatch as a bookkeeping task: find the missing row, correct the formula and move on. That response can fix the immediate number while leaving the operating weakness untouched.
The more useful question is: what had to be true for two credible records to diverge?
Perhaps the payment system and ledger use different recognition dates. Perhaps refunds lack a consistent owner. Perhaps fees are recorded as expenses in one place and deducted from revenue in another. Perhaps a manual export silently excludes transactions in an unexpected state.
These are early warnings because the company can still function while they accumulate. Customers continue paying. Dashboards continue updating. The weekly meeting still starts on time. Meanwhile, the team becomes less certain about cash, margins and performance.
That uncertainty spreads. Product teams may prioritise a market that appears stronger than it is. Hiring plans may rely on cash that has not settled. Investor reporting may require late corrections. A founder who cannot explain the gap loses time at the exact moment the company needs faster decisions.
Recent reporting on African technology startups and fintech often focuses on visible growth: small teams becoming cross-border companies, as in the account of South African fintech firm TurnStay. The quieter operational question sits underneath that story. When the business crosses borders, can its records still explain what happened to each transaction?
The operating model needs a single financial language
With the board update approaching, Ama stopped asking her team to prove which total was correct. She asked them to write down what each total represented.
That changed the conversation.
The dashboard counted customer payments at one stage of the transaction. The spreadsheet counted funds after a later stage and handled certain deductions separately. The gap had a cause. More importantly, the team could see that it lacked an agreed revenue definition for internal reporting.
They chose one basis for the board update, disclosed the timing difference and documented the reconciliation still underway. It was less comfortable than presenting a clean number. It was more credible.
A durable response starts with a shared financial language. Define when revenue is counted, how refunds and fees are treated, which source owns each field and who investigates exceptions. Keep a record of adjustments so the team can trace a total without reconstructing weeks of chat messages.
Then set thresholds. A small timing difference may require monitoring. An unexplained mismatch above an agreed level should stop reporting until someone resolves it. The threshold matters less than the discipline of deciding in advance what triggers investigation.
Build the controls before volume makes the choice
After the update, Ama’s morning changed in one concrete way. The next reporting pack began with the revenue definition, the source record and a short list of unresolved exceptions. Nobody had to defend a number based on memory.
That is the practical opportunity hidden inside a reconciliation failure. It gives founders a chance to redesign the operating model while the gaps are still small enough to trace.
Start with the last reporting period. Put every credible revenue total side by side. Label the event each one measures: payment initiated, payment completed, funds settled, revenue recognised or cash received. Then follow one ordinary transaction and one exception through every system.
If the records cannot tell the same story from customer payment to company account, do not wait for the next board morning. Assign an owner, agree on the definitions and make the reconciliation repeatable before another market, payment method or surge in volume adds one more plausible total.
Comments
No comments yet.