
How a $27K Payroll Error Traced Back to One Manual Data Entry Point
Client: Mid-market manufacturing company | Role: David, HR Manager
Result: A single manual re-entry error turned a $103,000 starting salary into $130,000, overpaying the employee $27,000 before it was caught.
Most payroll errors get discussed in the abstract, a percentage, a category, a line in a compliance report. This one has a specific shape: one number, typed into one field, checked by no automated process, and left to compound for months before anyone noticed.
Context
A new hire’s starting salary of $103,000 was set correctly in the applicant tracking system after offer negotiation. The offer letter, the candidate’s acceptance, and the recruiter’s own notes all agreed on that figure. When it needed to move into the HRIS to set up payroll, it was entered manually, and it was entered wrong: $130,000 instead of $103,000, a transposition that likely happened in a moment of routine, unremarkable data entry, the kind HR staff do dozens of times a week without a second thought.
Nothing in the process flagged the discrepancy. The ATS held the correct number. The HRIS held the incorrect one. Neither system was aware the other existed, let alone that the two of them disagreed about a $27,000 difference in a new employee’s annual pay.
Why Nobody Caught It Immediately
There was no automated cross-check between the ATS’s offer figure and the HRIS’s entered figure. The two systems didn’t talk to each other, so nothing compared the two numbers and flagged a mismatch the way a well-integrated stack would have. The manual entry step was the only place the number existed as a single, load-bearing source of truth, and on this particular record, it was wrong.
This is where the absence of a defined system of record becomes more than an abstract architecture problem. If the ATS had been designated as the authoritative source for offer compensation, with the HRIS pulling that figure automatically instead of a person retyping it, this specific error becomes structurally impossible rather than merely unlikely. Instead, the HRIS was treated as its own independent source, populated by hand, and nobody was assigned to verify that hand-entered number against the system where it originated.
How the Overpayment Accumulated
Once the incorrect $130,000 figure was in the HRIS, it fed payroll directly, correctly, from payroll’s perspective. Every paycheck was calculated accurately against the number in the system. The system was working exactly as designed. The number it was working from was the problem, and nothing in the workflow was positioned to catch that kind of error before it compounded across multiple pay periods.
This is the part of the story that makes the case worth studying closely: at no point did any individual system fail. The ATS was accurate. The HRIS processed what it was given accurately. Payroll paid exactly what the HRIS told it to pay. Every component performed its function correctly, and the company still overpaid an employee by $27,000, because the failure lived in the seam between systems, in the one manual step that had no system on either side checking its work.
| Metric | Before | After |
|---|---|---|
| Salary entered in HRIS | $130,000 (incorrect) | $103,000 (corrected) |
| Total overpayment | $27,000 | Recovered via correction |
| Cross-check between ATS and HRIS | None | Manual entry point flagged for automation |
Results
The error was eventually caught and corrected, but the correction itself created a second problem: the employee had been living on the higher figure for months, budgeting around it, and when it was adjusted down to the correct $103,000, they resigned. A single manual re-entry point cost the company $27,000 in overpayment and, ultimately, the employee it had just hired and onboarded.
The financial cost is the easier number to point to. The harder one to quantify is the trust cost: the employee’s experience of the correction wasn’t “we fixed an error,” it was “the company changed my pay without warning,” a framing that’s difficult to walk back regardless of how clearly the mistake gets explained after the fact. That reaction is a predictable outcome of a compensation correction landing without context, not a sign the employee overreacted.
Why This Kind of Error Is More Common Than It Looks
A transposed digit is an easy mistake to imagine happening once, to one company, in an unusual set of circumstances. It isn’t unusual. Any workflow that depends on a person retyping a compensation figure from one system into another carries this exact risk, on every single transaction, for as long as the manual step remains in place. The specific numbers in this case, $103,000 and $130,000, are memorable because they’re documented, not because the underlying failure mode is rare.
What makes compensation data specifically risky is that the error doesn’t announce itself. A typo in an address field gets caught the first time mail bounces. A typo in a compensation field flows silently into payroll, gets paid out correctly against the wrong number, and stays invisible until someone happens to compare the HRIS figure against the original offer, which, absent an automated check, can take months or never happen at all.
Lessons Learned
- A manual entry point with no automated cross-check is a single point of failure for compensation accuracy, no matter how careful or experienced the person doing the entry is.
- The error wasn’t caused by carelessness. It was caused by a workflow with no system designed to catch a mismatch between two numbers that should have matched from the start.
- The fix isn’t “be more careful.” It’s removing the manual entry point entirely, so the ATS’s offer figure flows directly into the HRIS without a person retyping it at all.
- This is the exact pattern covered in the seven HR workflows most likely to hide manual data re-entry, and it’s one of the clearest arguments for choosing a single source of truth for compensation data specifically.
What Would Have Caught This Before It Compounded
A basic automated cross-check between the ATS’s offer figure and the HRIS’s entered figure would have flagged this specific error within the first pay cycle, before it had a chance to compound across multiple paychecks. That kind of check doesn’t require a sophisticated system, just a rule that compares the two numbers and raises a flag on any mismatch above a defined threshold, the exact kind of validation that a properly designed single source of truth builds in by default.
The deeper fix, removing the manual entry step entirely so the ATS’s figure flows directly into the HRIS, addresses the root cause rather than just adding a check on top of the existing manual process. A cross-check catches the error after it happens. Removing the manual step prevents the error from being possible in the first place, which is the more durable of the two fixes and the one worth prioritizing.
Expert Take
What strikes me most about this case isn’t the dollar figure, it’s how invisible the error was for so long. Payroll was doing its job correctly, calculating checks accurately against the number it had. The failure happened one step earlier, at a manual handoff nobody was watching, which is exactly why these errors are so hard to catch after the fact and so much cheaper to prevent before they happen in the first place.

