The GPS Bug That Turned 36 Hours of Work Into 64 Hours of Overtime

Overtime is one of the few numbers on a technician's paycheck that both sides watch closely. The tech wants it to be right because it is real money for real hours. The owner wants it to be right because getting it wrong in either direction is expensive, whether that means underpaying someone who genuinely earned it or paying out for hours that were never actually worked. Both sides are trusting the same data source to get that number correct, and most shops never have a reason to question it until something looks off.

That trust is exactly what makes GPS-based time tracking so appealing to field service businesses in the first place. It promises to remove the guesswork and the friction of manual timesheets, replacing "what time do you think you started" with a location-based record nobody has to argue over. That promise only holds if the system actually understands the difference between a truck that is working and a truck that is simply turned off somewhere. When it does not, the automation that was supposed to remove disputes ends up manufacturing a new one, just with more confident-looking data behind it.

Something looked off at a residential energy and mechanical services contractor running multiple field technicians, with some of its installs involving cranes and outside subcontractors on top of its own crew. The company's ServiceTitan GPS and time tool flagged one of its best technicians for roughly 64 total hours in a single pay period, including nearly 25 hours of overtime. For a shop watching labor costs closely, a number like that on one of your strongest performers is the kind of thing that either gets paid without question or gets checked. This office manager checked it.

Idle time in a driveway, counted the same as a wrench in hand

Her manual cross-check told a very different story. Working by hand, Googling drive distances between job sites and lining them up against ServiceTitan's own arrival timestamps, she reconstructed the technician's actual worked hours at closer to 36 for that period, not 64. The gap traced back to roughly 24 hours of idle, parked truck time that the GPS system had been counting as active paid labor. A truck sitting still in a driveway or a parking lot was being logged the same way as a truck actively being driven to or worked from on a job.

That is not a small rounding error. It is close to double the true hours worked, and nearly all of the flagged overtime, sitting on the account of a technician who had done nothing wrong. He had not worked 25 hours of overtime. His truck had simply been idle for stretches the system did not know how to distinguish from active work.

What made this especially frustrating for the office manager was that it had not always been this hard to get right. The company's prior GPS vendor had given her second-by-second location data she could trust without a manual check. The built-in tool inside ServiceTitan, which had replaced it, did not offer the same visibility, and the gap in trust was exactly what had pushed her into hand-verifying hours in the first place: Googling distances, matching timestamps, rebuilding a technician's actual day from scratch because the system she was supposed to be able to rely on was not giving her a clean answer.

Multiply that manual reconstruction across a full team of field technicians and the scale of the problem becomes clear. One office manager cannot reasonably hand-verify every technician's hours, every pay period, indefinitely. It is the kind of workaround that holds up for a week or two under close scrutiny and then quietly falls apart once the office gets busy, at which point the shop is right back to trusting a number it already knows is unreliable.

Filtering idle time out of the overtime calculation, on the call

Working with ShareWillow, the fix went in during the same working session where the discrepancy came up. The team added a filter to exclude idle time from the overtime and hours calculation, so a parked, stationary truck no longer counts toward a technician's worked hours the same way active drive time or on-site time does. That is a structural change to what the number measures, not a one-time correction applied to a single pay period.

I had almost 25 hours of overtime last week. He only did 36 hours last week. I thought it was, like, 64.

That exchange, from the office team comparing the system's flagged figure against the manual hand-check, captures exactly how far the original number had drifted from reality. A gap that size is not a rounding issue anyone should have to live with, and it is not something a shop should have to catch by manually Googling drive times every pay period to keep it from reaching a paycheck.

Because the underlying tracking process still needed a longer-term fix with the company's operations lead, ShareWillow also offered a practical bridge: a shared Google Sheet tracker where the office manager could log manually verified hours and feed those into ShareWillow directly, instead of pulling raw, idle-time-inflated figures straight from ServiceTitan while the root cause got worked out. That gave the team an accurate number to run payroll against immediately, without waiting on a longer systems fix to land first.

The owner's framing of why this mattered was direct and specific: this was one of the company's best service technicians, and a 24-hour overtime discrepancy on his check was not a fight worth having, or a number worth risking a good tech's trust over, when the actual cause was a data problem rather than anything he had done.

That framing matters beyond this one technician. A shop that pays out inflated overtime without noticing is losing money quietly, in a way that never shows up as a single alarming line item, just a slightly higher payroll total every period than the actual work performed would justify. A shop that instead shorts a technician on legitimate hours because it distrusts its own GPS data risks the opposite problem: a good tech who starts wondering whether the numbers on his check can be trusted at all. Getting the underlying data right protects against both failure modes at once, rather than trading one for the other.

A number that finally matched the manual check

With idle time filtered out, the technician's flagged hours for the most recent, still-incomplete pay period dropped to roughly 31 hours, a figure much closer to the office manager's manually verified estimate of around 36 than the original system reading of roughly 64 hours with nearly 25 of those flagged as overtime. That is close to a 50 percent reduction in the false overtime figure for a single technician, on a single pay period, caught and corrected before it ever reached payroll rather than after.

The dollar value of that gap is easy to miss if you only look at the percentage. Overtime is paid at a premium rate, which means 24 hours of phantom overtime is not just 24 hours of wasted pay, it is 24 hours of wasted pay at 1.5 times a technician's normal rate, on top of the actual, correct hours he had worked. Multiply that kind of gap across a team of field technicians, each with their own idle stretches between jobs, and a shop can be quietly overpaying overtime by a significant margin every single pay period without anyone noticing, because the number on the screen always looks official even when it is wrong.

What this means for your shop

GPS and time-tracking tools are supposed to remove the guesswork from payroll, not add a new layer of it. A few lessons from this fix apply to any shop running field technicians on GPS-based hours.

• Idle time and work time are not the same thing, and your software needs to know the difference. A truck parked between jobs, or sitting at a shop, should not accumulate toward a technician's paid or overtime hours the same way active work does.
• Trust big numbers less, not more. A 64-hour week with 25 hours of overtime on one of your best technicians is exactly the kind of number that deserves a second look before it runs, not after.
• Manual verification is a signal, not a permanent solution. If your office team is Googling drive distances to double-check GPS data by hand, that is a sign the underlying system needs a structural fix, not a sign your team should keep doing it manually forever.
• Have a bridge for the gap between finding a problem and fully fixing it. A temporary, manually verified tracker kept this shop's payroll accurate while the real tracking fix got built, instead of forcing a choice between running bad data or delaying payroll.
• Do the math on what a small error rate costs at overtime rates. Because overtime pays a premium, even a modest inflation in flagged hours compounds fast, and it is worth quantifying before deciding a GPS discrepancy is not worth chasing down.
• Protect your best people first. A GPS or payroll discrepancy is most damaging on your strongest technicians, the ones you can least afford to lose trust with over a number that turned out to be wrong.

An overtime number that does not match what actually happened in the field is not a technician problem, it is a data problem wearing a technician's name. For HVAC and mechanical service companies running technicians on GPS-tracked hours, idle time is one of the most common places that data quietly drifts from reality. ShareWillow builds pay calculations directly from verified job and time data, with the flexibility to filter out exactly the kind of noise that inflated this technician's overtime, the same rigor behind how a plumbing company's office team resolved a recurring commission dispute over shared inbound calls. See what accurate, verified pay calculations would look like for your team, based on what we have learned from over 200 service businesses.