Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Mileage claim checker series ~6 min read

How a mileage claim gets checked

The checker has one job and one temptation. The job is to compare a claimed number with an expected one and notice when they are far apart. The temptation is to get clever — to score claimants, to build a model of normal driving, to flag people. This post is mostly about the three comparisons it does make, and partly about the ones it deliberately does not.

Key takeaways

  • The band is wide — plus fifty per cent by default — because real driving includes detours.
  • A repeat is the same claimant, same day, same two endpoints on a small grid.
  • The pattern check compares a person with their own history, never with a colleague’s.
  • Only two checks can pay a claim. None of them can refuse one; that is a person’s job.
  • Every answer carries its numbers, so the question the claimant sees writes itself.

Three comparisons, in order

The three checks a mileage claim passes throughA vertical chain of four steps entered by a box labelled Resolved claim, carrying both the claimed and expected distances. Step one asks whether the claim is inside the tolerance band read from the tolerance sheet; if outside it exits to Ask the claimant, sending both numbers and one question. Step two asks whether the same trip has been claimed before on the same day, using a fingerprint index on the DynamoDB claims table; a repeat exits to Show both, where a person decides. Step three asks whether the claim is usual for this claimant against their own previous months; an unusual result exits to Flag but do not block, which pays the claim and adds a note. Step four is Ordinary claim, paid without telling anyone. A note says the first two checks can send a claim to a human and the third can only add a note.AWS ACCOUNTResolved claimclaimed and expectedInside the band?expected +/- toleranceTolerance sheetband, caps, rateAsk the claimantboth numbers, one questionoutsideClaimed before?same day, same endsDynamoDB claimsfingerprint indexShow bothperson decidesrepeatUsual for them?vs their own monthsFlag, do not blockpay, and note itunusualOrdinary claimpay it, tell nobodyThe first two can send a claim to a human. The third can only add a note to it.
Fig 1. The three comparisons in order. The distance band and the repeat test can each route a claim to a person; the pattern check can only annotate one, and that asymmetry is deliberate.
  • Database
  • App integration
  • Machine learning
  • Security & identity
  • Analytics
  • People

The band, and why it is so wide

The default tolerance is plus fifty per cent and minus twenty. That sounds absurdly loose until you drive for a living. A return trip claimed as one leg doubles the number. A closed motorway junction adds nine miles. Picking up a part on the way adds six. Dropping a colleague home adds four. None of those is a false claim, and a band tight enough to catch the one dishonest claim would generate a question on a third of the honest ones.

A checker that asks too many questions gets ignored, and an ignored checker is worse than no checker because it also carries the implication that everybody is being watched. The band is set so that a normal month produces zero questions for a normal claimant. If it produces more than about one question per person per month, the band is wrong, and the sheet is where you widen it.

What counts as a repeat

Same claimant, same date, and both endpoints falling in the same small grid square. The grid matters: “Unit 4 Henderson” and “Henderson Plant, Ashford” are the same place typed two ways, and comparing raw strings would miss it while comparing exact coordinates would too. Rounding to roughly a hundred metres makes them equal without making genuinely different sites on one industrial estate equal.

A repeat never auto-refuses. Legitimate repeats exist — two separate call-outs to the same site in one day is an ordinary Tuesday for a plumber. So both claims go to a person, side by side, with their two reason lines, and “yes, twice” takes one tap.

The pattern check, and its limits

The third comparison is the only one with any statistics in it, and it is deliberately the weakest. It takes the claimant’s total for the month and compares it with their own previous months — not with the team’s, not with a per-role average, not with anything that would let one person’s territory make another look bad.

What the pattern check produces, in five stagesA horizontal row of five boxes. Their months: the claimant's own last six months. This month: their running total. Gap: how far outside their own range this month is. Note: the finding is attached to the claim rather than acted on. Month end: one summary read by one person. A note says it never stops a payment and only writes a line that a person reads once a month.WHAT THE PATTERN CHECK ACTUALLY DOESTheir monthslast six, same personThis monthrunning totalGaphow far outsideNoteattached, not acted onMonth endone summary, one personIt never stops a payment. It writes a line that a person reads once a month.
Fig 2. The pattern check’s whole output is a note and a monthly summary. Nothing about it is allowed to hold up a payment to somebody who drove somewhere for you.

The reason for that restraint is simple. A month that is double the usual is almost always a real cause — a big job the other side of the county, cover for somebody on leave, a fortnight of emergency call-outs. Holding up somebody’s four hundred pounds of legitimate mileage while a manager works that out is a bad trade against the rare month where the number is wrong. Pay it, note it, and let the summary do its work in a meeting rather than in a payment queue.

What the checker deliberately does not do

  • It does not score claimants. There is no trust rating, no history multiplier, and nothing that makes last month’s question affect this month’s claim.
  • It does not compare people with each other. Territories, rounds and job types are not comparable and pretending otherwise punishes whoever has the worst patch.
  • It does not read GPS. If you already track vehicles, that is a better source and a different system with a different consent conversation attached to it.
  • It does not refuse anything. The strongest thing it can do is put a claim in front of a person with the numbers already on the screen.

Next: what the question to the claimant actually looks like, and why it has to be answerable in one tap.

All posts