Payroll software operations and delivery 2027: a review framework

Payroll software operations and delivery 2027 can be assessed by whether the software supports a correct, authorised, reported and recoverable outcome for each supported pay cycle. The work begins before calculation and continues after a file is sent. Inputs, approvals, HMRC responses, pension exchange, employee outputs, payments, reconciliations and corrections all need owners.

This guide uses official sources checked on 5 September 2026. Rules and technical details can change between tax years. Reopen HMRC, The Pensions Regulator, ICO and NCSC guidance before applying it to 2027 operations.

2027 tax-year position. The 2027/28 tax year dates are confirmed: 6 April 2027 to 5 April 2028. HMRC's PAYE and National Insurance rates and thresholds for 2027/28 are to be confirmed. So are statutory payment rates, student loan thresholds and auto-enrolment earnings bands.

Confirm them through the Budget and HMRC, The Pensions Regulator and software supplier publications. Check HMRC's tax rates and thresholds page, The Pensions Regulator's automatic enrolment guidance and your supplier's 2027/28 release notes for the final figures.

What to take away

Payroll operations need named owners for inputs, approvals, FPS responses, pensions, payments, reconciliations and corrections.
A single submitted label hides uncertainty, so track FPS states from prepared through accepted, rejected and corrected.
Submission and employee payment are separate authorities, so reconcile payment output to approved payroll before release.
Close a payroll only after outputs agree, including population, gross-to-net totals, HMRC balance and pension acceptance.
Correct errors according to their facts, using current HMRC guidance rather than a universal reversal button.

Define the supported operating model

An employer-run product, bureau platform, managed service and embedded payroll component have different responsibilities. Record:

legal employers and PAYE schemes;
supported tax year and product version;
employee and payroll-frequency limits;
worker and statutory-payment situations;
pension schemes and exchange methods;
HR, time, accounting and payment integrations;
operators, approvers, submitters and support roles;
service hours, exclusions and fallback.

Put these conditions in operating instructions, qualification, contracts and support. An unsupported customer is an operational risk even if the software allows data entry.

Run the workflow from controlled inputs

HMRC's running payroll overview explains the sequence around payday and the following tax month. Employers record pay, calculate deductions and employer National Insurance, produce payslips and report through an FPS, with EPS and payment activity following where relevant.

Payroll period workflow

Confirm employer, scheme, pay date, tax year
Preserve prior approved state
Collect approved input changes
Apply cut-offs and late-data process
Record transformations and exceptions

Open each period by confirming employer, PAYE scheme, pay date, tax-year configuration and active population. Preserve the prior approved state.

Collect starters, leavers, hours, overtime, absence, bonuses, deductions and bank changes through approved channels. Every item should retain source, effective date and approval. Apply cut-offs, but provide a documented late-data process because reality will not always meet the timetable.

Integrations must not erase responsibility. A time system can send hours automatically while still requiring a manager's approval and visible rejection handling. Record transformations and exceptions so payroll can reconstruct the input.

Review calculation before action

The operator should inspect headcount, gross pay, deductions, employer liabilities, net pay and material variances. Comparison with a previous period can help, but it must account for known starters, leavers, annual changes and irregular pay.

Use risk-based checks for unusual values, missing inputs and duplicates. An anomaly flag should support judgement, not block or alter pay without accountable review.

Separate preparation from final approval where the organisation's control design requires it. Restrict overrides, capture a reason and preserve who approved. A managed service contract should state what the supplier checks and what the customer must approve.

Treat FPS state carefully

HMRC's FPS reporting guidance says employers use payroll software to report employee payments and deductions. It explains the on-or-before-payday rule, early reporting considerations, following tax-month actions and correction where an FPS contains an error.

FPS response states

Prepared but not approved
Approved but not transmitted
Transmitted with response pending
Accepted or acknowledged
Rejected with actionable errors
Corrected or superseded
Unresolved and escalated

The system should distinguish:

prepared but not approved;
approved but not transmitted;
transmitted with response pending;
accepted or otherwise acknowledged;
rejected with actionable errors;
corrected or superseded;
unresolved and escalated.

Preserve the payload reference, time, authorised user, response and correction link. Design retries to avoid duplicate action.

Submission and employee payment are separate authorities. A person allowed to prepare an FPS should not automatically be allowed to release a bank file.

Illustrative example: a payroll operator prepares an FPS for one employee with gross pay of £4,200.00. The software shows transmitted with response pending. HMRC rejects it because the National Insurance number is missing.

The operator records rejected with actionable errors, corrects the missing number, resubmits and links the accepted response to the original run. Payment release stays blocked until the accepted state is stored.

Operate workplace pensions as a connected process

The Pensions Regulator's payroll-software checklist covers employee assessment, information, contribution calculation, tax-relief method, pension-provider data, communications, worker requests, postponement and records.

Assign each task to the employer, payroll team, software, bureau or pension provider. Configure the named scheme and preserve the effective settings.

After calculation, generate provider information through the supported format or connection. Record transmission, response and rejection. Reconcile employee and employer contributions between payroll and the pension provider.

A product can support some pension work without handling all legal duties. Operating instructions should direct users to current regulator guidance and competent advice for decisions outside scope.

Deliver employee outputs securely and accessibly

Payslips, P60s and related records should reach the right person through an approved route. Verify recipient identity, protect transport and storage, and avoid placing confidential data in notification text.

Test the portal or document with relevant devices and assistive technology. Provide an alternative when an employee cannot access the standard method. Record support access and avoid asking workers to share full payroll details through an insecure channel.

When an employee leaves, the employer may still need access to records and the worker may need specified documents. Align account removal with the documented employment and retention process rather than deleting evidence prematurely or leaving broad access open.

Reconcile the complete outcome

Depending on scope, reconcile:

Payroll close reconciliation

Approved employee population
Gross-to-net control totals
Payment file or instruction
HMRC submission and expected balance
Pension contributions and provider acceptance
Accounting journal and control accounts
Open errors and corrections

approved employee population;
gross-to-net control totals;
payment file or instruction;
HMRC submission and expected balance;
pension contributions and provider acceptance;
accounting journal and control accounts;
payslips and employee documents;
open errors and corrections.

Set tolerances only where they have a defensible basis. Do not use an unexplained monetary tolerance to close calculation differences that should agree exactly.

Illustrative tolerance example: a payroll shows gross pay of £48,250.00, net pay of £37,410.22, employee pension contributions of £1,930.00 and employer contributions of £2,412.50. The payment file agrees to net pay.

The pension provider file agrees to the employee and employer contributions. If the accounting journal posts £37,410.20, the £0.02 difference is investigated rather than absorbed by a monetary tolerance.

Correct errors according to their facts

HMRC's FPS and EPS correction guidance covers different actions for wrong pay or deductions, payment dates, starter and leaver details, personal information, National Insurance categories and EPS amounts. The correct route depends on what happened and when.

Error correction record

Original input and approval
Report and response
Error discovery time and source
Impact on employee, HMRC, pension
Advice or rule relied upon
Correction approval and action
Root cause and preventive change

Create decision support that directs a competent operator to current guidance rather than a universal reversal button. Record:

original input and approval;
report and response;
error discovery time and source;
impact on employee, HMRC, pension, payment and accounts;
advice or rule relied upon;
correction approval and action;
reconciled final outcome;
root cause and preventive change.

HMRC's unexpected PAYE bill guide also identifies checks around submission timing, payment date, details, EPS and prior payment. Preserve the payroll-system totals needed to investigate.

Communicate with affected workers and customers through authorised channels. Do not expose another employee's information while explaining a correction.

Before you act

Confirm employer, PAYE scheme, pay date and tax-year configuration.
Separate preparation from final approval and restrict overrides.
Reconcile payment output to approved payroll before release.
Reconcile pension contributions between payroll and provider.
Record error discovery, impact, correction approval and root cause.
Test the responsibility matrix with a real exercise.

Assign clear team roles

The payroll owner approves process and period outcomes. A product owner controls customer scope and roadmap. Payroll tax expertise maintains HMRC rules and correction interpretation. A pensions specialist owns automatic enrolment mapping and provider compatibility.

Engineering owns implementation, dependencies and technical recovery. Quality owns test strategy and evidence. Privacy and security owners govern personal-data use, access, incidents and suppliers. Operations runs releases and service monitoring. Support manages authenticated customer contact and escalation. Commercial and finance teams qualify scope and track sustainable service cost.

Create a responsibility matrix for normal runs and exceptions. It should identify who performs, approves, advises and is informed for rule updates, releases, submissions, payment outputs, pension failures, corrections, incidents and customer communications.

Test the matrix in an exercise. A name in a document is not enough if that person lacks access, expertise, cover or authority to stop the process.

Build quality around traceable evidence

HMRC's PAYE developer support collection links current technical specifications and test resources. Convert applicable material into versioned requirements and test cases.

Quality test coverage

Ordinary supported scenarios
Boundary and invalid values
Employee circumstance combinations
Starters, leavers and corrections
Imports and migrations
Permissions and approval separation
Response-state and safe retry
Pension file rejection

Quality coverage should include:

ordinary supported scenarios;
boundary and invalid values;
combinations of employee circumstances;
starters, leavers and corrections;
imports and migrations;
permissions and approval separation;
response-state and safe retry;
pension file rejection;
connected-system failure;
backup restoration;
accessible employee and operator journeys.

Use synthetic data by default. Where production investigation is necessary, control purpose, access, copies and deletion.

Link a test result to build, configuration, environment, evidence and reviewer. A pass from a previous tax year or product edition does not automatically carry forward.

Define service standards by journey

Measure more than platform availability. For each critical function, define:

hours of expected operation;
completion and response criteria;
degraded state;
external dependencies;
support severity and acknowledgement;
target restoration;
customer-outcome recovery;
data recovery objective;
reporting and exclusions.

Support priorities should reflect payroll deadline and consequence. A routine configuration question and blocked payroll near payday should not enter the same queue with identical handling.

Publish measurement methods. Distinguish acknowledgement from resolution, technical restoration from corrected payroll outcome, and planned maintenance from incident. Do not improve a service report by changing exclusions without showing the series break.

Secure the cloud operating environment

The NCSC's guidance on using SaaS securely addresses modern authentication, logging, integration approval, incident planning and backups. Its cloud-platform guidance adds joiner-mover-leaver processes, privileged access, secrets and preparation with the provider.

Apply those prompts to the configured payroll service rather than treating provider defaults as sufficient. Maintain an asset and dependency view, strong administrator authentication, least privilege, log review, vulnerability handling and emergency contacts.

Back up critical data and configuration using an approach that does not share every failure mode with production. Restore regularly into a controlled environment and verify payroll completeness, permissions and usable outputs.

Prepare for operational incidents

Exercises should cover likely and consequential failures:

Incident exercise scenarios

Identity service unavailable
Payroll import partially processed
Calculation release unexpected variance
HMRC response delayed or rejected
Pension connection unavailable
Payment output generated twice
Administrator account compromised
Employee portal exposes wrong information

identity service unavailable;
payroll import partially processed;
calculation release produces unexpected variance;
HMRC response delayed or rejected;
pension connection unavailable;
payment output generated twice;
administrator account compromised;
employee portal exposes wrong information;
production data or configuration lost.

For each scenario, identify detection, initial containment, authoritative state, decision owner, customer communication, fallback, restoration and correction. Record exercise results and close actions.

The aim is not to claim that incidents cannot occur. It is to show that the team can limit harm, recover the service and resolve the customer outcome without improvising under deadline pressure.

Control releases and tax-year change

Maintain a release calendar around payroll schedules, HMRC effective dates, pension-provider changes and dependency updates. Avoid discretionary high-risk deployments immediately before common deadlines.

Every release should identify scope, requirements, tests, security review, migration, monitoring, rollback and communication. A tax-year update may require new calculations, fields, thresholds, documents and customer action. Test existing supported cases as well as new ones.

Provide release notes in plain English with effective date and required action. Support staff need the same information before customers contact them.

Retain the ability to identify which version calculated and reported a payroll. This is essential when investigating a later difference.

Launch readiness and cutover criteria

The launch board should examine customer scope, current PAYE evidence, pension workflow, personal data, security, migration, tests, service capacity, contracts, claims and rollback. Every item receives passed, failed, unknown or explicitly accepted risk.

Stop conditions can include an unexplained payroll difference, failed restoration, uncertain submission authority, an unsupported required employee case or support capacity below the promised service.

Name the existing authoritative system and the point at which cutover becomes effective. Prevent a pilot or deadline from converting an unresolved build into production by accident.

After launch, increase monitoring and review across several payroll cycles. Look at completed outcomes, corrections, pension rejections, support work, access events and customer understanding. Close the launch phase only when remaining issues have ordinary operational owners.

Measure operational health without vanity metrics

Useful product and service measures include:

Operational health measures

Payrolls completed within supported timing
Accepted HMRC responses
Pension exchanges accepted and reconciled
Corrections by cause and detection point
Unresolved exceptions at close
Operator interventions
Support response and outcome time
Incident recovery and payroll correction time

payrolls completed within supported timing;
accepted HMRC responses;
pension exchanges accepted and reconciled;
corrections by cause and detection point;
unresolved exceptions at close;
operator interventions;
support response and outcome time;
incident recovery and payroll correction time;
restoration test success;
customer and employee access barriers.

Segment by employer-run, bureau or managed-service context. Combining unlike workflows can hide risk and cost.

Use stable definitions and preserve series changes. A registration is not an active payroll, a sent file is not accepted, and a closed technical incident is not necessarily a corrected customer outcome.

The 2027 operating position: reliable close and recoverable correction

Good payroll operations join software with accountable human decisions. Controlled inputs, dated rules, reviewed calculations, explicit approval, secure employee outputs and evidence-led correction form one service.

For 2027, maintain that service through tax-year change, supported customer scope, recovery exercises and honest measures. The objective is not a perfect dashboard. It is a payroll process that completes reliably and can explain and repair the result when something goes wrong.

Common questions

What should be recorded when defining the supported operating model?

Record legal employers and PAYE schemes, supported tax year and product version, employee and payroll-frequency limits, worker and statutory-payment situations, pension schemes and exchange methods, integrations, operators and support roles, service hours, exclusions and fallback. Put these conditions in operating instructions, qualification, contracts and support.

How should FPS states be distinguished in the system?

The system should distinguish prepared but not approved, approved but not transmitted, transmitted with response pending, accepted or otherwise acknowledged, rejected with actionable errors, corrected or superseded, and unresolved and escalated. Avoid a single submitted label that hides uncertainty, and preserve the payload reference, time, authorised user, response and correction link.

What should be reconciled before closing a payroll?

Depending on scope, reconcile approved employee population, gross-to-net control totals, payment file or instruction, and HMRC submission and expected balance. Also reconcile pension contributions and provider acceptance, accounting journal and control accounts, payslips and employee documents, and open errors and corrections. A transmitted file is an intermediate event, so confirm the receiving system outcome where available.