The Payroll Export That Was Quietly Heading Toward a $50,000 Weekly Number

Every field service owner has had the moment where a number on a report just does not look right. For a small pool service company, that moment came on an ordinary Monday, the day payroll has to go out no matter what the data says. The weekly labor export, the number meant to tell the owner exactly what technicians were owed for the week, was climbing in a way that did not match reality. Not gradually. Not in a way you could explain with a busy week. It was compounding.

Here is what that looked like in practice. So what we've seen in the past is it appears that when they ship their weekly stuff, it's cumulative, the owner explained. It's not this week. It's for all weeks, and the longer you do it, the more and more and more that number goes up. He put the problem in the plainest terms possible: so next week it's gonna be like $2,400, and the week after it'll be $3,600. I'm like, well, how do I pay that? Because it's not a week. It's useless to me.

That is the sound of a payroll number that has stopped meaning anything. And the trajectory was not subtle. If we are sitting here six months down the line with the reporting still broken, he said, after six months it will be the cumulative six months, and I gotta pay $50,000 for this week's business service. Fifty thousand dollars for a single week of labor at a small pool service operation is not a real number. It is what happens when a reporting bug is allowed to compound, quietly, week after week, until it produces a figure so large that everyone involved knows something upstream is broken. The dangerous part is not that a number that big would ever actually get paid. Nobody would sign a check for that. The dangerous part is everything that happens on the way there: weeks of smaller, still-wrong numbers that are just plausible enough to almost slip through.

Why the Bug Was Easy to Miss and Expensive to Ignore

The root of the problem sat in how the underlying pool service data platform exported its weekly labor report. The new version of the report was not simply duplicating rows. It was accumulating them, so that a repair job from three weeks ago and a completely different repair job from this week would both show up in the current week's total, layered on top of everything that came before. I don't think it's just duplicates, the owner clarified. So let's just say I go and do a repair for and then three weeks later I go and do a repair for a different person. They're two different repairs, two different amounts. It'll just accumulate. Each week's export was not a snapshot of that week. It was a running total dressed up as a weekly number, and running totals make terrible payroll inputs.

There was an older version of the same report, one the team already trusted, that did not have this problem. The legacy report has correct, non-cumulative labor numbers, and needs to be treated as the source of truth for payroll and export going forward. That distinction, an older report the operator already trusted next to a newer one that looked similar but behaved completely differently, is exactly the kind of trap that lets a bug like this survive as long as it did. Nobody was ignoring the problem. They were comparing two reports that looked close enough to be the same thing and had no reason to assume one of them was quietly compounding.

Fixing it meant walking away from the newer export entirely and rebuilding the sync to pull from the legacy report instead, then cleaning out the duplicate and cumulative entries that had already crept into the historical data. That is not a quick patch. It means going back through recent weeks, validating the labor numbers against what the technicians actually worked, and confirming the corrected export held steady before trusting it with a live payroll cycle.

A Second, Quieter Leak: Refunds and Discounts Nobody Was Deducting

The compounding export was not the only issue sitting in the account. Running in parallel was a smaller but very real leak involving customer refunds. So I see we've refunded $3,000 with the recorders this month, the owner noted during the same review. So we need to call that back from commission. Refunds and discounts change what a job actually netted the business, and if commission gets calculated on the original invoice amount without accounting for a later refund, the technician ends up credited for revenue the company never actually kept.

Three thousand dollars a month in refunds is not a rounding error at a small pool service company. Left unaddressed alongside a compounding payroll bug, it represents a second, quieter version of the same underlying problem: numbers that look plausible on the surface but do not actually reflect what happened in the business. The fix here was to build the payments-collected and refunds report into the regular commission workflow, so that refunded amounts get deducted before payout instead of getting caught after the fact, if they get caught at all.

There is a related wrinkle worth mentioning: diagnostic visits and retention credits. Not every discount on an invoice is a refund in the traditional sense. Some are diagnostic fees waived to keep a customer happy, and some are small retention credits issued to hold onto an account that was thinking about leaving. The only big discounts that showed up in the review were one retention credit and a handful of diagnostics, but each one still changes what a job actually netted, and each one needed the same treatment as a straightforward refund: subtracted from the reported sale amount before commission gets calculated on top of it. Getting this level of detail right is tedious. It is also exactly the kind of detail that determines whether a technician's paycheck matches what they actually believe they earned that week.

Rebuilding a Report Without Breaking What Technicians Already Trust

One of the harder parts of fixing a bug like this is that technicians do not see the export logic. They see a number on their paycheck, and they compare it to their own mental math for the week. If a correction shifts a payout even slightly, even in the technician's favor, it can read as one more reason not to trust the system, unless the correction comes with a clear explanation of what changed and why. That is part of why the rebuild here started with the trusted legacy report as the anchor rather than trying to patch the newer, buggier export in place. Anchoring to a report the team already believed in gave everyone a stable reference point to validate the fix against, instead of asking anyone to simply take the correction on faith.

It also meant the reporting interface itself needed work beyond the underlying data pipeline. The existing reporting view only offered last week or last month as options, which made it nearly impossible to pull a specific date range when something needed to be checked by hand. Technicians and office staff both need the ability to look at a defined window, Monday through Sunday, and see the itemized work orders behind a given payout, not just a single rolled-up total. Without that kind of drill-down, a corrected number is still just an assertion. With it, a technician can actually verify their own pay against the jobs they know they ran that week, which is the entire point of building performance pay on real data in the first place.

What Getting Both Fixes Right Actually Bought the Business

Once the sync was rebuilt on the accurate legacy report, the weekly labor number stopped behaving like a runaway total and started behaving like, simply, a week. That sounds like a small thing to say out loud, but it is the entire point of a payroll report: it should describe the seven days it claims to describe, nothing more and nothing less. Getting there meant validating the corrected numbers against several recent weeks before trusting the export again, since a single clean-looking week after months of compounding errors was not enough evidence on its own.

The refund fix closes a different kind of gap. Every technician's commission now reflects what the company actually collected, not what an invoice said before a customer got money back. For a company running commission on tight per-job margins, three thousand dollars a month in unadjusted refunds adds up fast, and it adds up in a direction that quietly overpays technicians for work that, financially, did not fully happen.

The Broader Lesson: A Bug Does Not Have to Be Dramatic to Be Dangerous

What makes this story different from a lot of payroll horror stories is that nobody ever actually got hit with a $50,000 paycheck demand. The bug got caught in the trajectory, not the aftermath. That distinction matters enormously for any field service company running technician pay through an integrated data pipeline. A reporting bug rarely announces itself with a single dramatic failure. It shows up first as a number that feels slightly off, then a little more off the next week, and by the time it becomes undeniable, a lot of smaller, still-wrong numbers have often already gone out the door.

The same discipline that caught this bug, comparing a new report against a trusted older one, reading the trend across multiple weeks instead of trusting any single number in isolation, and tightening commission logic against refunds and discounts, is exactly the kind of scrutiny other teams have needed to catch their own quiet payroll errors before they compounded into something much harder to unwind. A pool service company with a handful of technicians does not have room to absorb a $50,000 payroll mistake, and it should not have to. Catching the pattern early, while the numbers were still merely wrong instead of catastrophic, is what kept this from ever becoming one.

There is also a simpler, more human lesson underneath the technical one. The owner who caught this bug did not catch it because he distrusted performance pay as a concept. He caught it because he looked at a number, asked how do I pay that, and refused to accept an answer that did not make sense. That instinct, treating a strange number as a problem to solve rather than a detail to shrug off, is what separates a five-figure mistake from a story about the week a five-figure mistake almost happened. Every field service owner running technician incentives should trust that same instinct in themselves. If a payout number does not make sense, it usually is not you misunderstanding the report. It is the report.