Say one of your community carers does eight or nine visits a day and drives between every one. Each journey is a mileage claim, and a line someone has to capture, calculate, check and pay. Across a team of forty that’s roughly seven thousand claims a month, and each one passes through at least three pairs of hands before it’s paid.
Mileage in community and domiciliary care isn’t an occasional expense that you can tidy up at quarter-end. It’s a continuous, high-volume process that sits next to payroll, and treating it as a minor line item is how it comes to drain finance-team time while the figures drift.
Why the error grows with the workforce
Manual mileage error scales with the number of journeys, so the larger and more distributed the workforce, the more a spreadsheet gets wrong. Some claims end up over-paid and others under-paid, and the sheet itself gives you no way to tell which.
A spreadsheet feels adequate because each claim is small and simple, at least if you’re dealing with ten rows. In reality it’s far more than ten rows, and more like several thousand if you’re managing reimbursements across a decent sized organisation. Every hand-off between the carer who drove, the coordinator who approves and the payroll run that pays adds another chance of a rekeyed figure or a rounding habit.
Where does a spreadsheet stop coping?
At high reimbursement volumes you’ll see spreadsheets failing in predictable ways:
- Journeys logged from memory at the end of a shift rather than captured when they happened
- Figures rekeyed by hand between the carer's note, the coordinator's sheet and payroll
- Rounding and estimation creeping in
- No audit trail behind individual claims if they’re ever questioned
None of this is a case against spreadsheets, which have their place in any finance team. They just aren’t built to carry a continuous, distributed process with this many hand-offs.
Fix it in order: capture, calculate, approve, pay, record
Mileage is best treated as the process it is and fixed stage by stage:
- Capture the journey at the point of travel, while it's fresh
- Calculate it automatically against the rate you've set
- Route it for approval
- Pay it
- Keep a record of each claim
Most of the error enters at the first stage. If a carer writes up the day’s journeys from memory at the end of a shift, the figures are already approximate before anyone calculates, approves or pays them, and every later stage inherits that. So the place to fix accuracy is capture: record the journey when it happens, and the rest of the process is working with clean data instead of correcting it.
What Moss enforces, and what stays your call
Moss handles the process from capture onwards. Carers submit each journey from their phone at the point of travel, the claim is calculated automatically against the rate you’ve set, it routes to the right approver, and every claim carries its own audit trail into the payment run.
Moving capture onto the carer’s phone is where most of the accuracy comes from, because it removes the memory and the rekeying.
Moss applies the rate you set the same way on every claim, but it doesn’t set the rate. The HMRC approved rate is your benchmark, and whether to pay at it, above it or below it is a policy decision that stays with the provider.
What changes across a full team
With a fully digitised, centralised reimbursement process, you shift to something like this: A carer logs each journey from their phone between visits. The claim is calculated at the set rate the moment it’s submitted. Approval is a glance rather than a reconstruction, and every one of the month’s seven thousand claims carries its own record.
Payroll then runs on data that was right at capture rather than corrected afterwards. For a distributed team doing thousands of journeys a month, that removes a large block of admin and most of the points where an error could have crept in.






