The $440 Bug Hiding in a New Hire's First Bonus

One admin, one spreadsheet, once a month

A two-location HVAC, plumbing, and drain company had grown to the point where its incentive pay could no longer be handled the way it always had been: one office administrator, working from ServiceTitan exports, building out technician bonuses by hand once a month. That process worked, in the sense that people got paid, for a long time. But manual reconciliation across two branches and multiple job types, memberships, turnover-related spiffs, and standard service bonuses, has a ceiling, and this company had grown past it without fully realizing how far past it they were.

The proof came out sideways, the way these things usually do. While reviewing plumbing revenue reports as part of moving toward an automated system, the company found figures that were off by several thousand dollars per person compared to what the manual process had been producing. Nobody had been stealing or falsifying anything. A once-a-month, by-hand reconciliation across a growing multi-location business is simply a process with a lot of surface area for a formula to drift, a spreadsheet reference to break, or a number to get carried forward incorrectly from one month to the next, and drift like that compounds quietly until someone finally sits down and checks it against a different method.

It is worth sitting with how easily that kind of drift goes unnoticed. Nobody at this company was negligent. The admin doing the reconciliation was skilled enough to keep the whole process running by hand across two locations for a long stretch of time, which is genuinely hard work. The problem was structural, not personal: a manual process has no built-in way to flag its own errors. A spreadsheet formula that quietly references the wrong row does not throw an error message. It just produces a number that looks plausible, gets paid out, and becomes the new baseline everyone assumes is correct, until someone happens to compare it against an independent source and finds a gap of several thousand dollars per person that had been sitting there, unnoticed, for who knows how long.

That discovery is what pushed the company to move its membership and spiff logic into an automated platform rather than patching the spreadsheet again. The plan included tiered caps on turnover-related spiffs, so a single unusual job could not blow a bonus calculation wildly out of proportion, and automated detection of additional units sold based on price thresholds, which had previously required someone to eyeball an invoice and decide by hand whether a job counted as an upsell.

Rather than flip a switch and trust the new system immediately, the company took the more disciplined route: run the automated calculation in parallel against two consecutive manual payroll cycles, and only fully cut over once both runs matched closely enough to trust. That validation step is exactly what caught the next problem, on the very first cycle it ran.

This is the piece that most companies skip, and it is the single most important decision in this entire story. It would have been faster to build the automated system, spot-check a handful of totals for reasonableness, and cut the manual process loose. Faster, and considerably riskier, because a spot-check only catches an error you already suspect might be there. Running two full cycles side by side, one manual and one automated, checking every technician rather than a sample, is what turns "this looks about right" into "we know this is right," and it is the only reason the next problem got caught before it ever reached a paycheck instead of after.

A new technician's first bonus, missing entirely

During validation, one technician's numbers did not reconcile. The manual calculation said he should see $440 in bonus pay for the period. The automated system showed zero. A $440 gap on one person is a rounding error's worth of dollars in the context of a whole company's payroll, but it is exactly the kind of small, specific mismatch that either gets caught during a careful validation process or gets missed entirely and turns into an angry phone call from a technician who knows precisely what he was promised.

The cause traced back to timing. The technician was new, and the sync between ServiceTitan and the incentive platform had a gap around exactly the kind of event a new hire represents: an employee record that did not exist in one system yet when the other system went looking for it. New-hire syncs are a classic seam in any integration between two platforms that were not built together. Everything works fine for an employee who has been in both systems for months. The seam only shows up the first time someone brand new tries to pass through it, which is precisely the wrong moment for it to fail, because a new technician's first bonus is also the moment they are forming their opinion of whether this job pays what it says it will pay.

Think about what a wrong first bonus actually costs beyond the $440 itself. A technician who has been with a company for three years and hits an occasional payroll hiccup has a track record to draw on, plenty of good pay periods that make one bad one read as an anomaly worth mentioning rather than a reason to worry. A brand-new technician has no such track record. Their very first paycheck involving a bonus is also, functionally, their first real data point about whether the company's promises about pay match reality. A $0 where $440 should be, seen by someone with nothing else to compare it to, does a lot more damage to trust than the raw dollar amount suggests.

This is a narrow, specific bug, and that specificity is exactly why the two-payroll-cycle validation approach mattered so much. A broad, obvious failure, like an entire branch's numbers coming back wrong, gets noticed immediately by sheer size. A single new technician's single bonus coming back at zero, buried inside a payroll run covering a dozen or more people across two locations, is easy to miss if nobody is checking the automated output against a trusted second source line by line. The company was checking, because they had already learned from the earlier plumbing-report discrepancy that their own numbers could not be assumed correct just because they had always been produced the same way.

There is a practical takeaway here for any HVAC, plumbing, or field service business bringing on new technicians regularly, which is most of them in a tight labor market: whatever integration connects your dispatch or CRM system to your payroll or incentive calculation almost certainly has a similar seam around new hires, even if you have never had a reason to look for it. The safest time to test that seam is deliberately, on a schedule you control, not accidentally, on the first real bonus a real new employee is counting on.

What actually changed, and why the caps mattered too

Two separate fixes came out of this validation period, and they addressed two different kinds of risk. The new-hire sync gap got closed directly, so a technician's employee record reliably exists in both systems before their first bonus-eligible job comes up for calculation, rather than depending on the timing of two separate onboarding processes lining up by coincidence. The company also added a manual adjustment and deduction capability inside the platform, so a one-off correction, whether from a sync issue or anything else, can be handled directly without unwinding an entire payroll run to fix one line.

The turnover spiff caps addressed a different, less visible risk. Uncapped, a spiff tied to turnover-related work can produce an unusually large payout on an unusual job, a correct calculation in a narrow technical sense that still does not reflect what the company actually intended to pay for that kind of work. Capping the multiplier, a full-system maximum and a lower cap for single-system jobs, keeps the incentive doing its intended job, rewarding a real category of work, without letting one outlier job produce a payout nobody would have signed off on if they had seen it coming in advance.

Both fixes share the same underlying philosophy, even though one addresses a bug and the other addresses a design gap. A good incentive system is not just a formula. It is a formula plus a set of guardrails for the situations the formula's author did not think of when they first wrote it down: the employee who does not exist yet in one system, the job that is technically correct but produces an absurd number, the pay period boundary that a job happens to straddle. Nobody designs for every edge case on day one. What matters is having a process, like the two-cycle validation this company used, that surfaces those edge cases before they turn into a wrong paycheck.

Put together, the real result of this process was not a single dramatic before-and-after number. It was a company that went from a single admin's once-a-month manual reconciliation, a process already proven to drift by thousands of dollars per person without anyone noticing until they went looking, to an automated system that had been checked twice against real payroll before anyone trusted it, and that caught a genuine $440 error on exactly the kind of edge case, a brand-new hire's first bonus, that manual processes are most likely to get wrong precisely because it happens so rarely that nobody has a routine for double-checking it.

The broader lesson applies to any field service business running incentive pay across more than one location or more than one job type by hand. The failure is rarely dramatic. It is a few thousand dollars a person drifting quietly inside a spreadsheet, or a single new employee falling through a gap between two systems that were never designed to hand off to each other cleanly. Neither of those failures announces itself. Both only get caught by someone deliberately checking one method against another, which is exactly what a validation period against real payroll data is for, and exactly what caught this before a single technician ever saw the wrong number on a paycheck. Running that calculation on a platform built to pull directly from the same job and payroll data a company already trusts turns that kind of validation into a routine check instead of a once-a-year fire drill.