Ownware
Guide · Aug 22, 2026

Due by Date, or Due by Distance — Why a Fleet Register Should Never Turn Miles Into Days

A service can be due by calendar or by odometer, and software has to decide which one bites first. The tempting shortcut is to convert distance into time. That conversion requires a number nobody has, and inventing it produces a maintenance schedule that is confidently wrong.

Every fleet maintenance schedule has the same shape written on the sticker in the windscreen: every 12 months or every 10,000 miles, whichever comes first.

That single word — whichever — is where fleet software either earns its keep or quietly starts lying to you.

Two clocks, running at different speeds

A service interval is really two independent countdowns:

due date      = last done on   + interval days
due odometer  = last done at   + interval distance

A van doing school runs will hit the twelve months long before the ten thousand miles. A van doing motorway deliveries hits the mileage in four months and the date never matters. Same interval, same vehicle model, completely different answer — and the fleet has both vans parked in the same yard.

So the software has to decide which clock is closer to expiring. And there is a shortcut that looks reasonable and is not.

The shortcut, and why it is wrong

The tempting move is to make the two comparable by converting one into the other. Take the vehicle's average daily mileage, work out how many days are left before it reaches the service odometer, and now both legs are in days — sort by days, done. One number, one ranked list, no awkward cases.

The problem is the average. To convert miles into days you need a usage rate, and a usage rate is a prediction. It is derived from what the vehicle did last month, which is exactly the thing that changes when a contract ends, when a driver goes on holiday, when a van is reassigned from local delivery to trunking, or when it sits in a yard for three weeks waiting for a part.

The output of that conversion does not look like a prediction, though. It looks like a date. It renders in the same column as the insurance expiry, which is a fact, and the inspection due date, which is also a fact. A person reading the screen has no way to tell that one of those numbers came from a certificate and another came from an assumption about driving habits.

That is the specific failure worth designing against: not being wrong, but being wrong in the typeface of being right.

What honest looks like instead

The rule is to compare each leg against its own window, in its own units, and never to convert:

  • The date leg is compared against a warning window measured in days.
  • The distance leg is compared against a warning window measured in distance.
  • Whichever leg has entered its own warning band first is the one that decides the status.

No shared unit, no conversion, no invented rate. The result is that a service which is 300 miles from due and 200 days from due reads as due by distance, because the miles crossed their threshold and the days did not — which is what the sticker in the windscreen meant all along.

And when both legs are inside their windows at once, the honest answer is both. Nine thousand miles and two hundred days are not comparable quantities. Software that ranks one above the other is asserting a relationship it has no basis for. Saying "both" costs a word and tells the truth.

The unknown state, and why it must exist

Here is the case that separates a register you can trust from one you cannot.

A service is tracked by distance. No odometer reading has ever been logged for that vehicle. What is its status?

There are three possible answers and only one of them is defensible.

"OK" is the worst. It is a green tick over a total absence of information, and it will hold that green tick right up until the engine tells you otherwise.

A guessed due date is worse in a subtler way, because it is actionable. It puts a row on a screen and a date on a calendar, and someone plans around it.

"Unknown" is the honest one. It says: this service is tracked by mileage, nobody has told me the mileage, and I will not pretend. In a well-built register that status sorts after everything actionable but before everything healthy — it is not urgent, but it is not fine either. It is a gap in the record, sitting in the ranked list where a gap belongs, until someone closes it by logging a reading.

The same honesty carries into the calendar feed. An unknown-status service is left out of the subscribed calendar entirely, rather than being handed a plausible date so the feed looks complete. A calendar with a wrong date in it is worse than a calendar with a missing entry, because the wrong date gets trusted.

Three consequences that follow from the rule

Completing a service restarts both clocks, through one writer. If completion is recorded in more than one place — a screen, an API, an assistant — and any one of those paths restarts only the date leg, a distance-tracked service silently becomes never-due-again. It will not error. It will not warn. It will simply stop appearing, which is the failure mode nobody notices until it matters. One code path, called by every door.

An odometer never runs backwards. A reading lower than the last one on file is a typo, a different vehicle, or a misread — never a fact. Accepting it corrupts every distance calculation that follows. The guard has to sit at every entrance, not just on the form, or the API becomes the way around it.

The interval belongs to the operator, not to the vendor. Fleet types, compliance regimes and manufacturer schedules differ by country, by industry and by contract. Software that ships one country's inspection regime as though it were the shape of the world is wrong everywhere else, quietly.

Why this is worth a whole article

Because it is the part that gets skipped. A fleet register is not hard to build in the sense of being technically demanding. It is hard in the sense that there are perhaps a dozen small decisions like this one, each of which has an easy answer that produces a screen that looks right and a schedule that is not.

Fleetora implements the rule above, including the unknown state, the calendar exclusion, the monotonic odometer and the single completion writer — and its test suite exercises every branch of the whichever-comes-first decision against hand-worked fixtures, because that logic is precisely the kind that passes a casual look and fails a specific Tuesday.

If you would rather rent this problem than own it, the teardown of what the subscriptions cost has four vendors' published prices, each quoted from the vendor's own page and dated.

Own your tools

Stop renting your own business.

Every tool in this store is a one-time purchase: install it on your own server, keep your own data, and never see a renewal invoice.

Affiliate program
Recommend tools people own — earn 35% on every sale. 90-day tracking, instant delivery, payouts by Lemon Squeezy.
Become an affiliate →