The Commission Bug That Paid One Technician Twice for the Same Job

Picture a commercial refrigeration and HVAC contractor running service calls, installations, and duct cleaning across a crew of technicians who each carry their own mix of jobs in a given week. Pay here is not a flat hourly number. Every completed job feeds a service commission, every emergency after-hours call earns a flat on-call award, and every unit or equipment sale carries its own commission rate on top of a processing fee. All of it has to reconcile before a payout goes out, four times a day, pulled straight from the company's field service software.

The trouble surfaced during a routine payout review, the kind of check that is supposed to be uneventful. The company's ops manager was comparing her own numbers against what had been calculated for the week, technician by technician, and one figure did not sit right. A job's commission was showing up twice: same job number, same customer number, counted once and then counted again. "It's weird," she said, and kept looking instead of moving on.

What she had caught was a rule that treated a repeated line in the export as a second, separate commission instead of recognizing it as the same job appearing twice in the data. It is an easy bug to miss, because most jobs never show up more than once. But when one did, the technician on that job got paid for it twice, and nobody had a reason to notice until someone compared the export against her own tracking, line by line, in the same week the money was about to go out.

That was not the only thing sitting in that week's numbers. A second technician had worked an emergency after-hours call on a holiday, the kind of call that is supposed to trigger a flat $25 on-call award on top of his regular commission. Instead, a dispatcher had logged the job as a routine "COD residential" call, and the software had no way to know the two should have meant the same thing to payroll. The job type in the system did not match the job type in real life, and the $25 quietly never showed up.

A third issue was smaller in principle but easy to get backwards in practice: how credit card processing fees should apply to different kinds of pay. On a unit or equipment sale, a 10 percent processing fee comes off the top before a technician earns a commission on what is left. On a service commission, that fee should never apply at all. Somewhere in the calculation, the two had gotten crossed, and service commissions were quietly losing a percentage they were never supposed to lose.

None of these three problems were dramatic on their own. A duplicated job here, a missed $25 there, a fee shaving a few dollars off a service call. But stacked together across one technician's week, or three technicians' weeks, the gap between what the company's own numbers said and what the payout was about to say had grown wide enough that nobody could sign off on it with confidence. One technician's number was already close, off by about $50. Another was off by roughly $150. A third needed both a missed award and a sync correction before the two sides of the math would agree at all.

A Discrepancy That Was Worth A Second Look

What made this catchable was not luck. It was that the ops manager kept her own running numbers for every technician, every week, and treated any gap between her total and the calculated payout as worth investigating rather than rounding away. That habit is what turned a repeated line item into a flagged bug instead of a quiet overpayment that went out the door with everyone's blessing.

Fixing The Duplicate, Not Just The One Job

Patching a single technician's number was never going to be enough. If a job number could repeat in the export once, it could repeat again next week, for any technician, on any job. So the first fix went after the rule itself: a deduplication check that recognizes when a job number and customer number already appeared earlier in the same export, and stops counting it a second time. Going forward, a repeated line reads as exactly what it is, the same job showing up twice in the data, not two separate jobs that both happen to deserve pay.

The missed on-call award needed a different kind of fix, because the root problem was not the payout logic, it was the label a job carried when it got logged. The team built job-type logic that recognizes when a call qualifies as emergency after-hours work regardless of what a dispatcher happened to type into the system in the moment, and automatically applies the $25 award when the conditions are met. A holiday call, a late-night call, a call flagged the way this one should have been flagged from the start, all now trigger the award on their own instead of depending on one dispatcher getting a dropdown menu right during a busy shift.

The fee issue was the most surgical of the three, because it required the calculation to actually distinguish between two kinds of pay that had been getting treated the same. Unit and equipment sales keep their 10 percent processing fee, deducted before the commission on the remainder is calculated, exactly as the company intended. Service commissions were pulled out of that logic entirely, so a technician doing a service call keeps the full commission on that call with no fee shaving anything off the top. Getting pay calculations this precise only matters because someone was willing to walk through the difference between "commission on a sale" and "commission on a service call" line by line instead of treating all commission the same.

Once the rule itself was fixed, the team reran the affected pay period against the corrected logic rather than leaving the original numbers in place and hoping the next cycle would be cleaner. That is the part that turns a bug fix into an actual correction: going back and applying the new rule to the money that was about to move, not just the money that has not been calculated yet.

The technician whose job had been duplicated came back into range once the dedup logic removed the second count. The technician who had missed his on-call award picked up the $25 he had actually earned, plus a $218 correction once his service commission synced correctly against the fixed fee logic, moving his total to $1,509, a gap the team could now describe simply as being within $100 of where it should be. A third technician's numbers, sitting at $1,244 against the company's own tracked total of $1,094, came down to $1,055 once the duplicate commission and a $75 helper-pay correction were applied, close enough that the ops manager's response was simply: "Very, very close. Perfect, perfect."

By the time that week's payout went final, every technician's number sat within about $100 of the company's own tracked total, a gap the ops manager and the team both signed off on together. That is not a coincidence born from one lucky rerun. It is the direct result of fixing three separate, unglamorous problems: a duplicate that should never have counted twice, an award that should have triggered automatically instead of depending on a dispatcher's dropdown choice, and a fee that should never have touched service pay in the first place.

The habit underneath all three fixes is the one worth keeping. The ops manager did not treat a repeated commission line as a rounding error. She compared her own numbers against the calculated payout, technician by technician, before anything went out the door, and she asked why a gap existed instead of assuming it would sort itself out. That is the same instinct that catches a mislabeled emergency call or a fee applied to the wrong kind of pay: someone looking at the number and asking whether it actually makes sense, not just whether it is close enough to wave through.

What This Means For Other HVAC And Refrigeration Shops

Most incentive pay systems built on top of field service software share the same quiet exposure: a job that appears twice in an export, a job type that gets mislabeled under pressure, or a fee rule that was written for one kind of pay and accidentally applied to another. None of these show up as an obvious red flag. They show up as a number that is a little higher or a little lower than it should be, easy to miss unless someone is comparing against a second source of truth.

The mechanical fixes here are specific to this company's setup, but the pattern is not. Duplicate detection, job-type logic tied to real conditions instead of manual tagging, and fee rules that distinguish between commission types are the kind of guardrails that turn a payroll system from something you trust by default into something you can actually verify.

What To Check Before Your Next Payout

A few habits would have caught these three issues sooner, and they are worth building into any HVAC or refrigeration company's payout process regardless of what system runs it. Keep a second, independent tally of what each technician should earn, even a rough one, and treat any gap against the calculated payout as worth investigating rather than close enough. Spot-check job types against what actually happened on the call, especially around holidays and after-hours work, since that is exactly when a dispatcher is most likely to grab the fastest label instead of the correct one. And write down, specifically, which fees apply to which kind of pay, so nobody has to guess whether a processing fee belongs on a service call or only on a sale.

None of that requires new software. It requires treating a payout the same way you would treat any other number that touches real money leaving the business: verified before it goes out, not explained away after the fact. The company in this story did not catch a duplicate commission because their system was flawless. They caught it because someone compared two numbers, noticed they did not match, and kept asking why until every technician's check was within $100 of what they had actually earned.

Why This Kind Of Precision Actually Pays Off

It is tempting to treat a $100 gap as close enough, especially against a total payout that runs into the thousands across a full team. But the dollar amount was never really the point. What technicians notice is not the exact figure on a check, it is whether the number moves in ways they can explain. A duplicate commission that shows up once and gets caught is a near miss. One that runs for a few pay periods before anyone notices becomes a pattern, and patterns are what erode trust in an incentive plan faster than almost anything else. A technician who cannot predict what a job is worth stops trusting the plan to reward the work, and once that happens, the plan stops doing the one thing it was built to do.

That is also why the fix here went further than the one number that triggered the review. It would have been easy to correct the duplicated commission, confirm the total looked reasonable, and call the week done. Instead, the team traced two other issues that were sitting quietly in the same pay period, a missed award and a misapplied fee, neither of which had triggered a complaint from anyone. Both were small enough to survive undetected for a while. Together with the duplicate, they represented three separate reasons a technician's check could come in wrong, each with its own root cause and its own fix.