Agentic Payroll Auditing: Catching Pay-Rate Errors and Unauthorized Overtime Before a Pay Run Posts
written by Cooter:Labs
published on August 28, 2026
Introduction
A payroll run is one of the few ERP processes where the cost of a mistake is realized almost immediately and is genuinely hard to claw back — once a pay run posts and funds move, correcting an overpayment means asking an employee to return money they've already spent, and correcting an underpayment means a compliance exposure on top of an angry employee. That asymmetry is why most payroll teams build in a manual review step before every run, and it's also why that review step is the first thing that gets compressed when headcount grows, pay frequency increases, or a company runs payroll across multiple entities and jurisdictions from the same shared-services team. The review doesn't get worse gradually — it fails the same way manual controls usually fail, by working fine until the one run where a reviewer misses the one line that mattered.
A human reviewer scanning a payroll register before it posts is good at catching what looks wrong at a glance — a number with too many zeros, a negative net pay, an employee who appears twice with different ID formats. What that review structurally misses is anything that requires cross-referencing the register against a system the reviewer isn't looking at: whether a pay rate actually matches the last approved comp change in the HRIS, whether an overtime total matches the hours a manager actually approved in the time-and-attendance system, or whether an employee flagged as terminated three weeks ago is still receiving a check because the termination never propagated to payroll. Each of those checks is mechanical and well-defined, but doing all of them for every line on every run, every pay cycle, is not something a person scanning a register can do at the pace payroll actually runs.

The pay rate on a given payroll line should trace back to a specific, approved event — an offer letter, a comp-change form, a collective bargaining agreement's wage schedule, or a promotion effective on a specific date. In practice, payroll systems and HRIS systems are often separately maintained, and a rate change approved in the HRIS doesn't always make it into payroll cleanly, or makes it in with the wrong effective date. An agent that pulls the current approved rate for every active employee from the system of record and compares it against what's actually configured in payroll catches both directions of drift: a rate that's stale because an approved raise never propagated, and a rate that's wrong because someone made a manual override in payroll that was never approved anywhere. The check is a straightforward comparison, but doing it for every employee on every run, rather than sampling a handful for a spot check, is what actually closes the gap.
A duplicate employee record — the same person entered twice under slightly different name spellings, or a rehire who got a new employee ID instead of having their old record reactivated — can result in two active pay lines for one person if nobody notices the overlap. A ghost record is the more deliberate version: an employee record that stays active and continues drawing pay after the person has actually left, either because termination processing lagged or because the record was never properly closed out. An agent that cross-references active payroll records against current HRIS employment status, and separately checks for near-duplicate identity signals — matching Social Security number, bank account, or address across records with different names — surfaces both cases before the run posts rather than after an audit finds them months later.
Overtime hours in a payroll run typically come from a time-and-attendance system, but the hours that get recorded there aren't automatically the hours that were authorized — an employee can clock extra hours that a manager never approved, or a system can miscalculate overtime eligibility for an employee who crossed a threshold partway through a pay period. An agent that compares the overtime hours flowing into payroll against the manager-approved schedule and any explicit overtime authorization on file, and separately checks the overtime calculation itself against the applicable rule (weekly threshold, daily threshold, or a state-specific double-time rule), flags a mismatch as a specific discrepancy — this employee has 12 recorded overtime hours but only 6 were approved — rather than leaving it to whoever reconciles the schedule against the time clock after the fact, which in most companies is nobody, on most weeks.
Retroactive pay corrections and off-cycle payments exist because normal payroll processing genuinely can't handle every situation — a late-processed rate change needs a retroactive adjustment, a terminated employee needs a final paycheck outside the regular cycle. But retroactive and off-cycle transactions are also where controls tend to be weakest, because they're handled as one-off exceptions by whoever has payroll system access at the time, often without the same review that a scheduled run gets. An agent that treats every retroactive adjustment and off-cycle payment as its own reviewable event — checking it against a specific approved reason, confirming the adjustment amount matches what that reason justifies, and flagging any adjustment that lacks a documented trigger — closes the gap where the exception process becomes the actual path of least resistance for an error or a deliberate manipulation to get through.
A payroll administrator who gets a message saying "3 anomalies detected, review required" has to redo the underlying comparison from scratch to find out what's actually wrong, which is slower than catching nothing at all if it happens on every run. What's actionable is a specific claim: this employee's configured rate is $34.50/hour but the last approved comp change in the HRIS set it to $31.75, effective three pay periods ago; this employee has 14 overtime hours in the time system but the manager-approved schedule shows 8. An agent that surfaces the discrepancy with both numbers, the source of each, and the specific line it affects lets the payroll administrator resolve it in the time it takes to read it, and lets the rest of the run proceed without every flagged line holding up every unflagged one.
Looking Ahead: Challenges and Innovations
The two failure modes have different costs, and the tuning has to reflect that honestly
A false positive on a payroll anomaly check costs a reviewer a few minutes confirming a line is actually fine. A false negative that lets an overpayment through means asking an employee to return money, which is legally constrained in many jurisdictions and damages trust regardless of how it's handled; a false negative that lets an underpayment through is a wage-and-hour compliance exposure the moment it happens, not just an inconvenience. Tuning the matching and threshold logic to minimize total alert volume, without weighting these outcomes differently, optimizes for the wrong thing — a payroll control that's quiet is not the same as a payroll control that's correct.
Exempt/non-exempt classification and CBA interpretation are judgment calls an agent should flag, not resolve
Whether a specific employee's role and duties support exempt status under the applicable wage-and-hour rules, or how a specific overtime scenario should be interpreted under a collective bargaining agreement's wage schedule, are determinations that require someone with actual HR or labor-law expertise, not a pattern match. An agent can flag that an employee's recorded hours and pay pattern look inconsistent with their current exemption classification, or that a CBA-covered employee's pay doesn't match what the current agreement's schedule specifies — but assigning the classification itself, or resolving an ambiguous CBA interpretation, isn't something the agent should be doing unsupervised. Treating every classification-adjacent flag as a referral rather than a resolved finding keeps the actual judgment call with a person qualified to make it.
The check is only as good as the HRIS and time system it's cross-referencing, and those go stale independently
Comparing payroll against an approved rate or an approved schedule only catches drift if the thing being compared against is itself current — an HRIS record that's a week behind on processing an approved raise will make an agent flag a correctly-updated payroll rate as a discrepancy, and a manager who approves overtime verbally instead of in the system will produce a false flag on hours that were actually authorized. None of this is a reason not to run the check, but it does mean the integration feeding the comparison, and the process discipline around actually recording approvals where the agent can see them, matters as much as the matching logic itself.
The metaverse
Payroll auditing fits the same continuous-monitoring pattern showing up across other ERP subledgers under agentic oversight: a value that should stay synchronized with an approved source of truth — a pay rate with a comp change, an overtime total with a manager's approval, an employee's active status with their actual employment — drifting quietly because the systems that hold the source of truth and the systems that execute against it update on different schedules and nothing forces them back into agreement automatically. The same mechanism that catches a stale pay rate here is the one catching a stale lease remeasurement, a stale export classification, or a stale vendor banking detail elsewhere in the ERP: watch for a change in the underlying fact, and re-check the dependent value against it, rather than trusting a point-in-time entry indefinitely. As that pattern gets applied more broadly across the payroll and HR stack specifically, the differentiator moves from having a payroll review step at all — most companies already do — to whether that review step can actually see every discrepancy instead of the subset a person scanning a register has time to catch.
Conclusion
Payroll errors that survive to a posted run rarely happen because nobody was reviewing the register — they happen because the review that exists can't cross-reference every line against the HRIS, the time-and-attendance system, and the approval trail behind every rate and every overtime hour, at the pace and volume a real payroll run requires. The individual checks are mechanical and well-specified: match every pay rate to its approved source, catch duplicate and ghost employee records, verify overtime against what a manager actually authorized, and treat every retroactive or off-cycle adjustment as its own reviewable event rather than a bypass around normal controls. What has to stay with a person is the genuine judgment — an exemption classification, a CBA interpretation, a borderline case the rule set didn't anticipate. Running the mechanical checks continuously, against source data that's actually kept current, and putting a specific, evidenced finding in front of a payroll administrator instead of a generic warning, is what keeps a pay-rate error from being something the company only discovers after the money has already moved.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.