Sector note · HR and payroll

Payroll is the one HR process an agent can actually be graded on

Attention in HR technology goes to recruitment screening and the holiday-balance chatbot. The money sits upstream of the payslip, in the reconciliation nobody wants to own — and that is the only part of HR where you can prove whether the software was right.

Alphaweb sector note

The money is upstream of the payslip

Recruitment AI is visible and forgiving; the payslip is neither, and its inputs are owned elsewhere.

Ask an HR technology team where AI will pay for itself and most will point at recruitment: CV screening, interview scheduling, a conversational front end that tells people how much leave they have left. That is where the demonstrations are, because those processes are visible, they touch a lot of people, and nothing catastrophic happens if the answer is slightly wrong. None of that is true of the payslip. It is the only artefact the HR function produces that moves money, carries a statutory deadline, and creates a legal record that the employee, the tax authority and eventually an employment tribunal can all act on.

Everything upstream of it — the joiner record, the mid-month contract change, the timesheet, the commission plan, the pension election — is a supply chain feeding a number that must be right on a fixed date. And that supply chain is not owned by the people who are blamed when it fails. Deloitte's 2025 Payroll Benchmarking Survey — a small-sample benchmark of 15 large multinational employers, ranging from 25,000 to around 240,000 employees — asked how involved payroll teams are in validating the data arriving from upstream systems: the largest group, 6 of 13 respondents (46%), described themselves as only "moderately involved". The same survey found 6 of 12 (50%) have "No defined SLA" for resolving employee payroll enquiries at all. These are indicators of large-employer practice, not population statistics. So the team accountable for the number does not control its inputs, and does not measure its own response when the number turns out to be wrong.

This is worth holding against the wider adoption picture. McKinsey's "The state of AI in 2026: On the road to ROI" reports that 40% of respondents at organisations with revenues above $1 billion report scaling AI agents, up from 27% a year earlier, while 37% attribute at least some EBIT impact to AI — about the same share as last year. Scaling and value have come apart. The organisations closing that gap are not the ones with better models. They are the ones that picked processes where the output can be checked against something other than an opinion.

A payroll team samples forty records and calls it a control; the software has no reason to sample at all.

Why this work fits, and it is not the reason vendors give

Every payroll case has a document behind it, the answer is checkable later, and errors fail silently.

Payroll work has a shape that suits software carrying a whole process rather than answering questions about one. It is high volume, it repeats on a fixed cycle, and every case has a documentary answer sitting somewhere: an employment contract, a collective agreement, an absence record, a signed commission plan, or the statute itself. There is no case where the correct answer is a matter of taste.

More importantly, the ground truth is recoverable after the fact. You can take a payroll period that closed a year ago, replay it, and compare what the software concludes against what was actually paid and against every correction raised in the three months afterwards. Almost nothing else in enterprise AI can be graded that way. Most of it is assessed by asking users whether they found it helpful. Payroll gives you a marked exam paper, which is exactly why it is the honest place to start — and why a studio that is wrong about it will find out quickly.

The second structural fact is about coverage, not cleverness. Human payroll control is sampling. A team reviews a variance report, checks a handful of new starters, looks at the largest movements, and stops when the submission deadline arrives. Coverage is a function of headcount and the hours between cut-off and payment. Software has no reason to sample. The argument for it is not that it reasons better than an experienced payroll manager; it is that it can do to forty thousand records what the manager currently does to forty.

The third is that the failure mode is silent. A wrong net pay figure looks exactly like a right one. It surfaces months later as a tribunal claim, an underpayment of holiday pay, or a correction run that consumes a week. That is why the check has to be independent — recomputing from source documents — rather than a second pass through the same logic that produced the error.

The three processes that go first

Read before write: findings first, and the one process that writes has a human approving each record.

The order below is deliberate and it runs read-before-write. The first two processes produce findings and evidence; they do not touch pay. Only the third writes anything into a system of record, and it does so with a named human approving each record. Any sequence that starts by letting software post to the payroll master is a sequence that will be stopped by the first controller who reads the design, and rightly so.

The common thread is that in each case the software is not asked to decide what is fair. It is asked to find the document that explains a number, and to say plainly when no such document exists. That second output — the unexplained variance, escalated with everything already gathered — is the one that changes how a payroll team spends its week.

What actually stops these projects

Blockers: unowned findings, undocumented rules, no calendar slack, and write-back that often has no API.

The first obstacle is ownership, and it is the one that kills most attempts. An agent that reviews a full population will not find twelve discrepancies; it will find four hundred. Those four hundred become work for line managers, HR business partners and a time-and-attendance administrator, none of whom report to the person who commissioned the software. Deploying detection without first agreeing who resolves what, and by when, produces a queue that grows until someone switches the thing off. Agree the resolution path before the first run, not after.

The second is that the rules are not written down. The shift premium is how a particular payroll officer has always calculated it. The collective agreement has a side letter from 1998 that everyone honours and nobody can find. In the same 15-company Deloitte benchmark, 6 of 13 respondents (46%) maintained between zero and twenty documented payroll processes — individual desktop procedure documents — in total. You cannot automate a rule that exists only as institutional memory, so the first several weeks are archaeology: sitting with the payroll team, reconstructing the logic case by case, and writing it down. This is the real cost of the project. It is not the software, and any proposal that prices it as though it were is misleading you.

The third is the calendar. Payroll has no slack. You cannot run an experiment in the week before a pay date, and there is no safe way to introduce a new control other than parallel running — the software and the existing process both operating over the same live cycle, results compared afterwards. That doubles the work for a period or two. If the team cannot absorb that, the honest answer is to wait until it can.

The fourth is genuinely technical, and it is narrower than people expect. Reading is usually fine. Writing back is not. Payroll bureaux, outsourced providers and payroll engines designed decades ago frequently have no usable API; the integration is a fixed-width file dropped overnight, and the contract with the provider does not contemplate a third party writing into it. Establish what the write path actually is before designing anything that depends on one, because the answer is sometimes that there isn't one.

A ninety-day sequence

One entity, read-only, replay then parallel run. The artefact that matters at day ninety is the override log.

The sequence below assumes one legal entity, one payroll population and read-only access to start. It is designed so that the decision at day ninety is made on evidence generated inside the organisation rather than on a reference customer. The most important artefact it produces is not the agent; it is the override log — the record of every case where a human reviewer disagreed with the software and why.

What it is worth, and why nobody should give you a number

Nobody can quote you a percentage. Build it from correction volume, the coverage gap and pay-gap work coming.

Any vendor who quotes a universal percentage for payroll automation is quoting a number they cannot have. The value depends on things specific to you: how many legal entities and collective agreements you carry, what share of pay is variable, whether your HRIS and payroll engine share a data model or exchange files, and how much of your current control is sampling rather than coverage. A single-entity, single-agreement payroll with a clean HRIS and a stable workforce may not be worth doing yet, and that is a legitimate finding.

The calculation you can do yourself has three parts. Take your actual correction volume over the last four quarters and the fully loaded cost of resolving one, including the employee's time and the query it generates. Add the coverage gap: what proportion of records currently receive a real check, and what the population looks like that receives none. Then add the deferred work you already know is coming — for most European employers that is the pay-gap analysis by category of worker, split between basic and variable pay, which is difficult precisely because the underlying data has never been reconciled.

The honest expectation is that the first return is not headcount. It is cycle time, the ability to close a period without three people staying late, and an evidence trail that survives contact with an auditor. Headcount effects, where they arrive, arrive later and are usually reallocation rather than reduction — payroll people stop reconciling and start handling the exceptions that were previously invisible. That is a less exciting claim than the ones being made elsewhere, and it is the one worth putting in a business case.

A ninety-day sequence that survives contact

1. Days 1-15 — One population, read-only, twelve months of historyPick a single legal entity and payroll population. Secure read-only access to the HRIS, the time and attendance system, and twelve months of closed payroll output including every correction subsequently raised. Do not scope a second country. The history is the point: it is what makes the work gradeable rather than a matter of opinion at the end.
2. Days 16-35 — Write the rules downSit with the payroll team and reconstruct the calculation logic case by case — the shift premia, the collective agreement provisions, the local overrides, the side letters. Expect this to be slower and less tidy than anyone forecast, and expect it to surface rules that contradict each other. This document is the deliverable of the phase. It has value even if the project stops here.
3. Days 36-55 — Replay closed periodsRun the variance agent retrospectively against periods that closed months ago, where the right answer is already known from the corrections that followed. Measure two things separately: what it found that the team did not, and what it flagged that was in fact correct. The second number decides whether anyone will trust it, and a high false-positive rate at this stage is a design problem, not a tuning problem.
4. Days 56-75 — Parallel run against a live cycleRun the agent alongside the existing process over at least two live pay cycles. It reports; humans decide; nothing it produces reaches the payroll engine. Agree beforehand who resolves an escalation and within how long, because this is the phase where an unowned queue quietly forms and discredits the whole exercise.
5. Days 76-90 — Decide on the override logReview every case where a reviewer overrode the software and why. If there are almost none, your human oversight is a rubber stamp and will not withstand scrutiny. If the overrides cluster around one rule, fix that rule. Then decide on a second population or a second process, with the cost of the archaeology phase now known rather than estimated.

What we read

The documents behind this note. Each entry says what it is, what it found, and why it should change what you do — then the link to the original.