Trace each field to its source
Follow every value on the claim form back to the moment it was created, and establish where it existed, or could be produced, in complete and authoritative form.
ASKING WHAT NOT TO BUILD
Rethinking travel-expense records
Our client is a corporate finance team, part-way through digitizing how staff claim travel expenses.
The team had already done good work. Paper submission had become a digital form, employees uploaded receipts, and the system pulled exchange rates from the Bank of Thailand automatically. What remained was the part digitizing could not remove: every bill still had to be keyed in line by line, OCR misread enough of them that finance reconciled by hand anyway, and staff were still funding company travel from their own accounts while they waited to be repaid. The next increment was scoped as a claims app. The question that mattered was not how to capture receipts more accurately, but why they had to be captured at all.
SCROLL FOR THE FULL CASE
— WHAT THIS CASE CAN SHOW
A business constraint, the decision it forced, and what Bold Group contributed to that decision.
This case describes a design. It has not been shown to be implemented, and no operating result is claimed.
01 THE BUSINESS CONSTRAINT
Start with the business condition, not the presumed answer.
Paper submission had already become a digital form: employees uploaded receipts and exchange rates arrived automatically. What digitizing had not removed was the keying — every bill still entered line by line, and enough correction of scanned values that finance was re-reading claims rather than reviewing them — and staff still funding company travel from their own accounts while waiting to be repaid.
02 THE ASSUMPTION THAT HAD TO BE CHALLENGED
The record was taken to begin at the claim.
The next step was assumed to be more software.
03 THE DECISION BEHIND THE REDESIGN
How the question was worked.
Where does this information exist, or could it exist, in an authoritative form, and what are we about to build in order to reconstruct it?
The decision was to establish where the record exists, or could exist, in an authoritative form, before scoping anything to reconstruct it.
Separate the requirement from the specification
Establish what finance and audit must be able to evidence, as distinct from the application that had been proposed to evidence it.
Name what still has to be built
Define the controls, exceptions, cash spend, and policy cases a card and its statement would not cover, so the remaining scope is stated honestly rather than assumed away.
04 WHAT BOLD GROUP CONTRIBUTED
What we owned, and where this transfers.
Bold Group
Traced each field on the claim back to where it was created, and separated what finance and audit must be able to evidence from the application proposed to evidence it.
The client
Owns the policy, the banking relationship, and the route for everything a card would not cover.
This approach transfers when
- A build has been specified before anyone examined the requirement it is meant to satisfy.
- The data being captured is, or could be, produced somewhere authoritative, and is being reconstructed instead.
- Someone can state what must be evidenced, separately from how, and can define the route for cash spend, non-accepting merchants, and policy exceptions.
05 WHAT THE DESIGN MADE POSSIBLE
What is known, and its limits.
The design proposes company travel cards. Paid on one, a transaction arrives from the bank itemized, dated and converted, so for card spend the bank produces the record the team was scoping an app to capture.
What this case does not claim
01No development-cost figure or percentage is claimed for this engagement.
02This is a design. It is not claimed that the software build was cancelled, or that any saving was realised.
03A card does not cover every case. Cash spend, non-accepting merchants and policy exceptions still need a route, and the design has to state what happens to them.
04This is an illustration of requirement discipline, not a general claim that custom software is avoidable.