Mileage is a billing problem dressed up as a finance problem.
Every kilometre coded to the wrong project is either margin you ate, or margin you over-billed and won't catch until the client does. Most Irish engineering firms know this in the abstract and don't track it in the specific. The leak is real, it compounds, and it's almost always invisible until someone goes looking.
This post is about the specific. Where the leaks hide, what they cost, and what right looks like.
The two ways mileage misallocation costs you money
The first is the obvious one: a trip that should have been billed to a client gets coded to overhead. The kilometres get reimbursed to the engineer at civil service rates, the cost goes into the firm's general expense bucket, and the client never sees it on an invoice. The firm pays for travel that should have been recovered. That's eaten margin.
The second is the less obvious one: a trip that should have been overhead gets coded to a client. The client gets billed for travel that wasn't theirs. If the client's procurement team is awake, they catch it on a milestone review and you get the awkward conversation. If they're asleep, you build a credit liability you'll have to write off when someone notices.
Both directions of error cost money. The eaten margin is the bigger number for most firms, because the bias of busy engineers is to leave the project code blank rather than to invent one - and a blank project code falls to overhead by default.
A worked example: Eileen's multi-site Tuesday
Eileen is a senior structural engineer. Tuesday is her site-visit day. The day looks like this:
- 08:30 - leaves home
- 09:45 - arrives at Site A in Athlone (Project Alpha)
- 11:00 - leaves Site A, drives to the office in Galway
- 12:00 - arrives at the office, takes a call, eats lunch
- 13:30 - leaves the office, drives to Site B in Mayo (Project Bravo)
- 15:00 - arrives at Site B
- 16:30 - leaves Site B, drives home to Sligo
- 17:45 - arrives home
Total distance for the day: 320 km.
The home-to-Site-A leg is 90 km. The Site-A-to-office leg is 50 km. The office-to-Site-B leg is 95 km. The Site-B-to-home leg is 85 km.
Here's the question: which kilometres get billed to Project Alpha, which get billed to Project Bravo, and which fall to overhead?
The Revenue rule, the billing reality
Revenue's rule for civil service mileage is the "lesser distance" rule: business mileage is the lesser of (home to temporary workplace) and (normal place of work to temporary workplace). For Eileen, that means:
- Home (Sligo) to Site A (Athlone): 90 km
- Office (Galway) to Site A (Athlone): 60 km
- Lesser distance: 60 km. The first 30 km from her house each day is her own commute.
That's the reimbursement calculation. Eileen gets paid mileage for 60 km on the Site A leg, not 90 km.
The billing question is different. The firm bills clients for the engineer's time and travel against the project. Project Alpha gets billed for the actual travel time and the firm's policy on mileage recovery. If the firm's policy is "we recover civil service mileage 1:1 from the client," then Project Alpha is invoiced for 60 km of mileage. If the policy is "we recover at full cost plus a fee," it might be 60 km plus a multiplier.
Same logic applies to the return trip and to Project Bravo. Each leg gets the lesser-distance rule applied for reimbursement, and each leg gets allocated to a specific project for billing.
Where the leak happens
The leak is in the middle bit. The office leg.
From Site A to the office is 50 km. That's a return to the normal place of work, which Revenue doesn't count as business mileage and which the client shouldn't be billed for. Project Alpha doesn't get billed. Project Bravo doesn't get billed. The kilometres are absorbed by the firm.
From the office to Site B is 95 km. Lesser-distance rule again: home to Site B is 110 km, office to Site B is 95 km. Lesser is 95 km. All 95 km is reimbursed and billable to Project Bravo.
If Eileen's process for logging the day is to write "Athlone -> Galway -> Mayo -> home, 320 km, project Bravo" because Bravo was the bigger job, the firm has just over-billed Project Bravo by 60 km of Site A travel and 50 km of office travel. The client's invoice has 110 km on it that shouldn't be there.
If the process instead is "Athlone -> Mayo, 145 km, project Alpha" because Eileen was thinking about Athlone first, Project Alpha gets over-billed and Project Bravo gets nothing.
If the process is "320 km, no project code, sort it out next week," everything goes to overhead and the firm eats both Project Alpha's 60 km and Project Bravo's 95 km.
That's the leak. The Tuesday is one engineer's one day. Multiply it by 200 working days a year and 30 engineers, and the cumulative leak gets serious.
The €4,200 per engineer per year
Conservatively, assume each engineer has one mis-allocated trip per fortnight - one Tuesday like Eileen's where the project codes don't tie cleanly to the legs. Average mis-allocation is 80 km per fortnight, at the average of Band 1 and Band 2 rates (around 70c/km blended). That's €56 per fortnight per engineer of mis-allocated mileage.
Across 26 fortnights a year, that's €1,456 per engineer per year of mileage that's pointing at the wrong cost centre.
That's the easy half of the calculation. The harder half is the recovery markup. If the firm bills mileage to clients with a multiplier, every mis-allocated kilometre is also a mis-allocated billing line. The blended impact, including unbilled overhead and over-billed clients that have to be credited back, runs around €4,200 per engineer per year for a typical Irish engineering practice.
For 30 engineers, that's €126,000 a year.
It doesn't show up as a single line item on a P&L. It shows up as project margins drifting 2-3% below plan, consistently, for reasons nobody can pinpoint.
Why retroactive coding doesn't work
The instinct in most firms is to fix this at month-end. Niamh sits down with the engineer's logs and tries to allocate the kilometres correctly after the fact. This works in theory and fails in practice for two reasons.
The first is memory. Three weeks after the Tuesday, neither Niamh nor Eileen can reliably reconstruct which kilometres belonged to which leg. The day was 320 km in total, and the legs blur. Reasonable allocation is the best you can do, and reasonable allocation isn't accuracy.
The second is cost. The retroactive review takes Niamh roughly an hour per engineer per month. For 30 engineers, that's 30 hours of finance-lead time monthly, and the result is still approximate. At a fully loaded €60/hour, you're spending €1,800 a month - €21,600 a year - to produce an approximate allocation. The leak you're trying to plug is bigger than the cost of trying to plug it, but only just, and the work is miserable.
What right looks like
Per-trip project allocation at the moment of submission. Not at the end of the day. Not at the end of the month. At the moment Eileen logs the leg.
The driver UX matters here. If logging a trip means tapping the project code from a short list of active projects on the engineer's phone, with the route Maps-verified, before the engineer leaves the site - the allocation is accurate by default. The retroactive reconciliation goes away, because there's nothing to reconcile.
If the project list is also smart - showing the projects the engineer is currently assigned to, with the recent ones at the top - the friction is low enough that engineers actually use it. If it's a free-text field they have to type from memory, they don't.
This is the design difference between mileage software that's a specialist tool for engineering firms and a generic mileage tracker that handles distance only. The generic tool gives you the kilometres. The specialist tool gives you the kilometres tied to the right project at the right rate at the right margin.
A note on the YTD interaction
The other reason per-trip allocation matters: the band-split rule applies to the engineer's year-to-date kilometres, regardless of which project the kilometres got billed to. A trip that crosses a band threshold has to split at the right point on the YTD axis, and the resulting amounts have to be allocated to the projects in proportion to where the band split fell.
That's harder than it sounds. A spreadsheet that handles project allocation OR band splitting can usually be made to work. A spreadsheet that handles both, correctly, retroactively, is unusual.
The bottom line
Mileage misallocation is a billing problem with a finance presentation. The cost is real, it's recurring, and it's invisible to most firms because nobody pulls the report that would show it.
If you'd like to see what per-trip allocation looks like in practice - on the driver side and the finance side - book a 20-minute demo. Bring a recent week of one engineer's diary if you have it. We'll walk through what the same week looks like with project allocation done at the leg level.
Last updated: 28 April 2026.
