Skip to content
allanninal.dev/build
Collaborate

Part 5 of 7 · Mileage claim checker series ~5 min read

How a mileage payment gets recorded

This system does not move money. It decides what is owed and writes it down, and then hands a file to whatever already pays people. That boundary is deliberate: payroll is a solved problem with regulatory weight attached to it, and the fastest way to make a small useful system into a large frightening one is to have it touch a bank account.

Key takeaways

  • The system decides what is owed. Payroll pays it. That boundary never moves.
  • Every payment record stores the numbers the decision was made against, not just the outcome.
  • The monthly total is a conditional increment, so two claims landing together cannot both win.
  • The payroll export is one CSV per period, regenerable, and identical every time.
  • The month-end report is three numbers and a list, and it is the reason to run any of this.

What a paid claim leaves behind

The sequence from an approved claim to a payroll lineA vertical chain of five steps entered by a box labelled Claim approved, either automatically or by a person. Step one asks whether the claim is still unpaid using a conditional status write against the DynamoDB claims table; a second tap exits to Already paid, which shows the record. Step two writes the payment, capturing the miles, the rate read from the sheet as at the claim date, and the basis. Step three adds the amount to the claimant's monthly total with a conditional increment on a DynamoDB totals table. Step four tells the claimant the amount and when they will see it. Step five includes the claim in the next export, one CSV per period. A note says the rate is stamped at the claim date so a rate change never rewrites history.AWS ACCOUNTClaim approvedauto, or by a personStill unpaid?conditional status writeDynamoDB claimsstatus = openAlready paidshow the recordsecond tapWrite the paymentmiles, rate, basisRate from the sheetat the claim dateAdd to the monthclaimant + periodDynamoDB totalsconditional incrementTell the claimantamount and whenIn the next exportone CSV, one periodThe rate is stamped at the claim date, so a rate change never rewrites history.
Fig 1. What happens after approval. The payment is written once, the monthly total moves under a condition, and the claim joins the next payroll export.
  • Database
  • App integration
  • Machine learning
  • Security & identity
  • Analytics

Why the rate is stamped, not looked up

Mileage rates change, usually in April, usually with a week’s notice. A system that computes the amount at export time by reading today’s rate will quietly restate every unpaid claim from before the change, and the first anyone knows about it is a claimant who is nine pounds short. So the rate is read once, at approval, and written into the payment record next to the miles.

The same reasoning applies to the tolerance band and the caps. The basis field stores what the rules were when the decision was made. It is three extra fields and it is the difference between an audit trail and a list of outcomes.

The payment record

FieldExampleWhy it is there
claim_idclm_2026_07_09_a3d1Links to the submission and any question asked
claimantsam@example.comWho is owed
trip_date2026-07-07Not the claim date; the driving date
miles84.0As finally agreed, after any correction
rate0.45Stamped at approval, never re-read
amount37.80miles x rate, computed once
basisexpected 41, band +50%, return tripWhy this was allowed
resolved_byclaimant / auto / managerWho closed it, if anyone had to
period2026-07Which export it belongs to
statepayablepayable, exported, or reversed

The export

One CSV per period, with one row per payable claim and a column layout your payroll software already accepts. It is generated on demand rather than on a schedule, and generating it twice produces a byte-identical file, because the period boundary is a date and not “everything since I last ran this”.

Once a period is exported, its claims move to exported and become read-only. A claim that arrives late for a closed period does not reopen it; it lands in the current period with its true trip date, which is what every payroll system expects anyway.

The report that justifies the whole thing

Everything above is plumbing. This is the output that makes it worth building.

One month of mileage claims summarised in five numbersA horizontal row of five boxes. Claimed: four thousand one hundred and eighty miles. Paid: one thousand eight hundred and eighty-one pounds. Asked about: eleven claims. Corrected: four, by the claimants themselves. Needed you: one. A note says the last number is the one to watch, and that if it grows the tolerance band should be widened.ONE MONTH, IN FIVE NUMBERSClaimed4,180 milesPaid£1,881Asked about11 claimsCorrected4, by claimantsNeeded you1The last number is the one to watch. If it grows, widen the band.
Fig 2. A month of mileage in five numbers. The interesting one is the last: how many claims actually needed a manager, out of everything that was claimed.
  • App integration
  • Machine learning
  • Analytics
  • People

Four numbers describe the money and one describes your time. A month where eleven claims were queried, four were corrected by the person who made them, and exactly one reached a manager is a system doing its job. A month where thirty were queried is a band that is too tight, and the fix is an edit in a sheet rather than a conversation with anybody.

Next: what all of this costs to run.

All posts