Replacing a Spreadsheet-Based Expense Process
Why expense claims break down at around thirty people, what an automated system actually has to do to fix it, and the failure modes that make replacements stall.
Almost every company starts with the same expense process: an employee spends money, keeps the receipt, fills in a spreadsheet at month end, and hands the printout to finance with the receipts stapled behind it.
It works. It keeps working for longer than people expect. Then somewhere around thirty employees it stops working, and it stops for reasons worth naming precisely, because the reasons determine what a replacement actually has to do.
Where the spreadsheet process breaks
Not "it is inefficient". Specifically:
The receipt and the claim are separated in time. Someone spends money on the 3rd and writes it down on the 30th. By then the receipt is in a jacket pocket, the amount is remembered as "about K400", and the business purpose is a guess. Everything downstream inherits that imprecision.
Finance becomes a transcription service. Twenty spreadsheets in twenty slightly different shapes arrive at once, and someone re-keys them into the accounting system. This is the single largest cost, it lands entirely in the last three days of the month, and it is the least valuable possible use of a qualified finance person's time.
Policy is enforced after the fact, or not at all. The limit lives in a document nobody has open while they are spending. Breaches are discovered at approval, when the money is already gone and the remaining options are all awkward.
Nobody knows the position until the month closes. Spend commitments exist for weeks before anyone can see them. Budget conversations are therefore always about last month, the one month you can no longer do anything about.
The audit trail is physical. A question about a claim from eight months ago means finding a box.
What a replacement has to do
Every one of those problems is about when information is captured, not how it is stored. That is the useful frame, because a system that digitises the same month-end ritual has automated the typing and fixed nothing else.
Capture at the point of spend
The claim should be created when the money leaves, on the phone already in the person's hand, with a photograph of the receipt attached. This one change fixes the accuracy problem at source rather than compensating for it downstream.
The practical bar: submitting a claim has to be faster than putting the receipt in a pocket. If it takes more than about thirty seconds, people revert to the pocket and you have bought a system nobody uses.
Extract what you can, verify the rest
Optical character recognition will read a printed total and date reliably enough to be worth having. It is markedly less reliable on faded thermal paper, handwritten receipts, and photographs taken at an angle in bad light, all of which are common.
Treat OCR as a draft the user confirms, not an authority. A system that silently trusts a misread total produces errors harder to catch than manual entry, because nobody is expecting them.
Enforce policy at submission
Check the rule when the claim is created, while the person can still do something about it. "This exceeds the K500 meal limit, add a note explaining why" at the moment of spending is a different conversation from the same message three weeks later.
Post to the ledger without re-keying
If an approved claim still has to be typed into the accounting system by hand, the largest cost has not been removed. The integration is the point, not a nice-to-have, and it should be scoped from the start rather than deferred to a phase two that may not arrive.
The failure modes
Expense system replacements stall for fairly predictable reasons.
Adoption, not technology. The system is only as complete as its least diligent user. One person still emailing a spreadsheet means finance runs both processes, which is worse than either alone. Roll out to everyone at once with a hard cutover date rather than leaving the old path open indefinitely.
Modelling the policy you wish you had. Configuration tends to encode the written policy, which is often not the operated one. If field staff have always been reimbursed for something the document does not mention, the system will reject those claims on day one and the pilot will be judged a failure. Find the real rules first, and where they differ from the document, decide deliberately which one changes.
Approval chains longer than the organisation. It is tempting to encode three levels of sign-off because that is theoretically correct. Every level adds latency, and latency on reimbursement is what employees actually feel. Match the chain to how decisions really get made.
Offline as an afterthought. Receipts get photographed where there is no signal: a filling station on a road trip, a basement car park. If capture requires connectivity, capture fails exactly when it matters. Queue locally and sync later.
Sequencing that works
The lowest-risk order runs roughly like this:
- Write down the current process honestly, including the exceptions everyone makes and nobody documents.
- Pilot with one team for one full cycle. A month-end is the only real test; anything shorter misses the crunch the system exists to fix.
- Fix what the pilot surfaces. It will mostly be policy edge cases rather than software defects.
- Cut over completely. Set the date, communicate it, close the old path on it.
- Connect the ledger. Once claims are trustworthy, remove the last re-keying step.
The realistic gain is not that expenses take zero effort. It is that the effort moves from a painful concentration at month end to a few seconds spread across the month, and that finance spends the last week of the month on analysis instead of typing.
Whether it is worth it
A rough test: multiply the hours your finance team spends transcribing claims each month by their loaded cost, then add what reimbursement delays cost you in goodwill. Under about thirty employees, a disciplined spreadsheet is often still the right answer. Past that, transcription cost grows with headcount while a system's cost does not.
We build and integrate systems like this, including our own expense management product. If you are weighing up whether to replace a process that still technically works, talk to us. The answer is genuinely sometimes "not yet".