Outlook
Part of What is already confirmed for payroll software in 2027, and what still depends on choices
Payroll software risk scenarios: five failures employers should rehearse
Five payroll software risk scenarios for employers in England, with controls for rule changes, faulty integrations, AI errors, outages and supplier exit.
Payroll risk is easier to manage when a team rehearses a concrete failure instead of maintaining a vague risk register. The following scenarios are prompts for employers in England. They do not predict that an event will occur, and each organisation should adapt the controls to its workforce, timetable and systems.
What to take away
- Rehearse concrete payroll failures instead of keeping a vague risk register.
- A green supplier status does not replace the employer's own check of affected cases.
- Restrict AI assistants to approved purposes and require human review for changes.
- Test continuity and exit plans before a crisis, not during one.
- Assign an owner, warning signal, control, response and recovery evidence to each scenario.
A rule changes but configuration does not
A payroll is processed using old statutory logic after an effective date. The control set should include an official change register, named owner, supplier-release review and synthetic acceptance cases. Keep the source and expected result beside every decisive test.
Rule change control steps
- Official change register
- Named owner
- Supplier-release review
- Synthetic acceptance cases
- Source and expected result
This matters for live changes such as statutory sick pay. HMRC's February 2026 Employer Bulletin explains the removal of the waiting period and lower earnings limit from 6 April 2026. A green supplier status should not replace an employer's own check of affected cases.
An integration silently drops changes
HR records show a starter, leaver or pay adjustment, but the payroll import omits it without a visible rejection. Control totals should compare record counts, gross values and exception lists before calculation. A named person must investigate differences rather than correcting the final net figure without finding the cause.
Test blank fields, duplicate identifiers, retrospective dates and interrupted transfers. Retain the source file and import report so the investigation has evidence.
An AI assistant invents an answer
An operator asks a built-in assistant about an unusual deduction and receives a plausible but unsupported instruction. HMRC's generative AI guidance for tax software explicitly identifies inaccurate or made-up outputs as a limitation users should understand.
Restrict the assistant to approved purposes, display its sources and require human review for changes. Complex cases should be referred to reliable guidance or a qualified adviser. Logs must show the prompt, response, correction and final decision without retaining unnecessary personal data.
The service is unavailable near payday
An outage blocks calculations, reports or payment files. Establish recovery priorities and deadlines before buying the service. Ask for documented backup, restoration and incident-communication arrangements, then test the employer's own continuity steps.
The NCSC's Software Security Code of Practice provides a voluntary baseline for customer conversations about resilient software and supplier responsibilities. The contract should also state escalation channels, dependencies and access to essential records.
The fallback might be a delayed change, an authorised prior-period method or a separately controlled payment process. It should never be invented during a crisis. Legal, financial and employee consequences need review in advance.
The employer cannot leave the supplier cleanly
At contract end, data arrives late, lacks history or uses an unusable format. The buyer should specify exports, attachments, audit logs, field definitions, timing, assistance, retention and deletion before signing. Run a sample export while the relationship is healthy.
The ICO's worker information guidance is relevant because changing processor does not remove the employer's data protection duties. Access and deletion need confirmation on both sides of the migration.
Turn scenarios into rehearsals
Assign an owner, warning signal, preventive control, response and recovery evidence to each scenario. Test one or two cases every quarter with synthetic data, and record what the exercise changes. Update the set after a new rule, integration, supplier incident or workforce shift.
The purpose is not to produce a risk score that looks precise. It is to make sure the payroll team knows what to notice, who can decide and how employees will be paid accurately when an ordinary process fails.
Before you act
- Keep a change register with a named owner.
- Compare record counts and gross values before calculation.
- Display AI sources and log prompts and corrections.
- Establish recovery priorities and deadlines before buying.
- Specify data exports and deletion terms before signing.
- Test one or two scenarios each quarter with synthetic data.
Common questions
How should an employer check a payroll rule change?
Use an official change register, a named owner, supplier-release review and synthetic acceptance cases. Keep the source and expected result beside every decisive test. A green supplier status should not replace the employer's own check of affected cases.
What controls prevent an integration from silently dropping changes?
Control totals should compare record counts, gross values and exception lists before calculation. A named person must investigate differences rather than correcting the final net figure without finding the cause. Test blank fields, duplicate identifiers, retrospective dates and interrupted transfers.
What should an employer do if the payroll service is unavailable near payday?
Establish recovery priorities and deadlines before buying the service. Ask for documented backup, restoration and incident-communication arrangements, then test the employer's own continuity steps. The fallback might be a delayed change, an authorised prior-period method or a separately controlled payment process.
