AI in Payroll: The Risks, the Benefits, and Where the Line Sits

Here is the division of labour I would defend to any payroll manager: AI belongs in detection and explanation, and it does not belong in calculation or approval. It should find the wrong number before it goes out and explain the right number after it does. The figure itself stays deterministic, produced by rules a person can re-run.

The reason is not that AI is dangerous. It is that payroll’s core requirement is reproducibility, and a system that produces an answer it cannot fully explain is worthless in payroll even when the answer happens to be correct. If you cannot derive the number from the rules a second time, you do not have a payroll system. You have a guess with good manners.

That is the whole argument about the risks and benefits of AI in payroll, and everything below is the working out. Worth saying the obvious thing first, though, because the vendor pages skip past it: every payslip is a trust event. One bad run costs more goodwill than a year of correct ones earns, which is why payroll is the one HR process where people are right to be conservative.

Payroll has four requirements that most software categories do not share. The number must be deterministic — same inputs, same rules, same answer, every time. It must be reproducible on demand, including eleven months later when someone queries it. It must carry an audit trail. And it must be explainable to the person it affects, in language they can act on.

Notice that none of those is accuracy in isolation. A correct number you cannot reproduce or explain fails three of the four.

This matters because the existing process already leaks, and that is the honest argument for bringing help in. In a 2022 EY survey of 508 payroll professionals at U.S.-headquartered organisations of 250 to 10,000 employees, one in five payrolls contained errors, at an average cost of $291 each. Organisations of roughly 1,000 employees were making around 15 corrections per pay period and spending something like 29 workweeks a year fixing the most common ones.

Date that properly: it is a 2022 survey and it is now nearly four years old, so treat it as evidence that the problem is structural rather than as a reading of current conditions. I use it because it is the best-sampled benchmark on payroll errors that is not a vendor’s own marketing, and because its size range maps almost exactly onto the companies I talk to.

The point is not that payroll teams are careless. It is that manual checking is the wrong tool for finding fifteen anomalies in ten thousand lines at six in the evening on a cutoff day. That is a pattern-matching problem, and pattern matching is the one thing software is unambiguously better at than a tired human.

I want to argue the upside mechanically rather than with a borrowed statistic. Every “cut payroll errors by 80%” figure I checked traces back to a vendor page with no methodology behind it, and you should discount those as hard as I do.

This is the highest-value use of AI in payroll and the least discussed. Before you commit a run, compare it against the last one and against the rules. A salary that moved with no change record behind it. A first-time zero-hours line for someone who has been full-time for three years. A tax code that changed for exactly one person in a group of forty. A leaver still sitting on the run.

None of that requires the software to calculate anything. It requires it to notice that this run does not look like the last one and to say so. And the design rule that makes it safe is one word: flag, do not fix. The software raises the exception and a human resolves it, which keeps the correction inside the audit trail rather than beside it.

This is the pattern our own platform implements on the payroll side, and I would recommend the pattern regardless of what you run it on. It is also the cheapest form of help to adopt, because nothing downstream changes — you are adding a check, not replacing a process.

The second-highest value, and it is aimed at your ticket queue rather than your calculation. “Why is my net pay lower this month” is a question your payroll team answers dozens of times a year with the same handful of causes: a mid-period change, a benefit starting, a tax code update, a one-off deduction.

Software can answer that well, with two hard requirements. It must cite the rule and the figures the answer came from, so the employee can check it. And it must be able to say “I do not know, here is who to ask” rather than producing something plausible. An explanation tool that guesses is worse than no tool, because it launders a wrong answer into an official-looking one.

Variance narratives between runs. Mapping a new benefit into the payroll setup. Drafting the note to finance about why the accrual moved. Low blast radius, high volume, reversible, and genuinely tedious. This is where the hours actually come back.

Some things stay with a person, and it is worth being specific about why in each case rather than waving at “sensitivity.”

Approval of the run. Somebody signs. That signature is the control, and automating it removes the only point in the process where a human looks at the whole picture.

Anything that changes a rate, a classification or an employment status. These are decisions about a person’s terms, not calculations. They belong to someone accountable.

Retros, backdated adjustments and off-cycle runs. Name these specifically, because this is where payroll actually gets hard and where automation most often earns or loses trust. A backdated change ripples across periods that are already closed, already reported and already paid. The arithmetic is not the difficulty. Deciding what should have been true, and when, is the difficulty.

Termination-adjacent pay. Final pay is calculated under time pressure, often with unusual components, and it is the payment most likely to be disputed later.

If you build a payroll logic engine, this is the lesson that arrives early and never leaves: the hard part was never the arithmetic. It was retros, mid-period changes, and proving the same number twice. Every hour I have watched go into payroll correctness went into those three things, and none of them are made easier by a system that cannot show its working.

Short, because it should land. Calculating the net figure. Deciding who gets paid what. Any determination you would have to defend to a regulator, an auditor or a court.

A model may propose a number. The number that reaches the payslip must be derived by rules a person can re-run and get the same answer from. If your vendor is blurring that distinction, the blur is the product risk.

And on blame: the technology does not move it. The employer is responsible for the pay being right, exactly as before. What changes is your evidence. Your control is the audit record, and a tool that cannot produce one has a disqualifying feature, not a missing feature.

1. The run is reproducible from inputs and rules. You can re-derive any figure from the source data and the rule set, without the model in the loop. If a number only exists because a model produced it, it should not be on a payslip.

2. Every AI-touched change carries a record of what it did and why. Not just what changed. What the software was working from when it flagged or proposed. This is the payroll audit trail question, and it is the one to ask first in a vendor conversation.

3. Approval thresholds are explicit. Decide in advance what size of change or anomaly forces a human signature, and write it down. A threshold nobody agreed to is a threshold that moves quietly under deadline pressure.

4. The rollback path is rehearsed before you need it. Know how you reverse an incorrect run, how you communicate it, and how long it takes. The teams that handle a bad run well are the ones that had already walked through it on a calm Tuesday.

A brief note on what an agent is, since the word is now attached to payroll products too: an agent chooses its own next step and acts without a person approving each action. That capability question is a bigger subject [pending: T-06]. In payroll, the answer stays the same either way — proposing is fine, committing is not.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and moved the application date for stand-alone Annex III high-risk systems, including AI used in employment, from 2 August 2026 to 2 December 2027. The AI Act’s transparency obligations were not deferred and have applied since 2 August 2026.

Be careful with the read-across: payroll calculation is not obviously an Annex III employment use case, since that category concerns decisions about the work relationship. For most payroll AI today the operative constraint is data-protection law on decisions taken about a person with no human involvement, not the AI Act. The Act’s employment provisions in depth are their own subject [pending: T-03].

Can AI run payroll without a human? No, and it should not. Approval of a payroll run is the control point where one person sees the whole picture before money moves, and removing it removes your last check. AI can prepare the run, flag anomalies in it and explain it afterwards. The commit stays with a named person who is accountable for it.

What are the biggest risks of using AI in payroll? Non-reproducibility first: a figure you cannot re-derive from the rules cannot be defended to an employee, an auditor or a court. Then confidently wrong explanations, which turn one error into a trust problem at scale. Then missing audit records, so you cannot reconstruct why something happened. Note that none of these are the model being inaccurate.

Where does AI actually reduce payroll errors? In detection before the run, not in calculation. Comparing this run against the last one and against your rules surfaces the anomalies humans miss under deadline pressure: unexplained salary movements, leavers still on the run, a tax code that changed for one person in a group. The software flags, a person resolves. That keeps the fix inside your audit trail.

Do we have to tell employees when AI is involved in their pay? Tell them. Where employees interact directly with an AI system, EU transparency duties have applied since 2 August 2026, and disclosure is the safe default everywhere regardless of what is strictly required. The practical reason outweighs the legal one: discovering after the fact that a payslip explanation came from software, unannounced, costs you more trust than announcing it ever would.

What should we ask a payroll vendor about its AI features? Ask whether the payslip figure is derived by rules or produced by a model, and get a clear answer. Then ask to see the audit record for an AI-touched change, including what the system was working from. Then ask what it does when it is uncertain. A vendor whose tool cannot say “I do not know” has built a confident guesser.