Payroll compliance in 2027 starts with a map of the rules, not a marketing claim

No single certificate establishes that payroll software is compliant for every English employer. PAYE calculation and reporting, workplace pensions, personal data, access, contracts, software security and marketing each have distinct requirements and evidence.

This guide is general orientation, not legal, tax, pensions, employment or security advice. Sources were checked on 5 September 2026. A 2027 publication must reopen every time-sensitive source, especially HMRC tax-year material, product-recognition records, pension thresholds and ICO guidance.

Start with a compliance map, not a claim

Define the product version, tax year, customer, payroll pattern and service boundary. An employer application, bureau platform, managed service and embedded engine perform different tasks and may make different decisions about personal data.

Create a register with these fields:

• requirement or official process;
• activity and customer in scope;
• jurisdiction and effective date;
• primary source and version;
• product or service control;
• test or other evidence;
• responsible owner and reviewer;
• next check date;
• unresolved issue and stop condition.

The phrase "fully compliant" usually hides these distinctions. Replace it with a statement a reviewer can test, such as support for named RTI specifications in a stated tax year and customer context.

PAYE operation is a maintained scope

HMRC's running payroll guidance describes actions on or before payday and during the following tax month. These include recording pay, calculating deductions and employer National Insurance, producing payslips, sending a Full Payment Submission and, where relevant, an Employer Payment Summary.

The payroll information guide sets out employer and employee details, pay, deductions, starters, leavers, pensions and year-end information. A product team should convert applicable fields and rules into a maintained specification inventory rather than relying on a broad feature label.

The official PAYE developer collection links tax-year test data and technical specifications. Each applicable item needs an owner, effective period, implementation reference and regression evidence.

HMRC's 2026 to 2027 payroll test-data page says its examples are for developers' own testing routines and checking against guidance and specifications. Passing those examples is useful evidence, not universal assurance. Add invalid inputs, boundary values, combinations, migrations, corrections, user permissions, integration failures and restoration.

Do not assume 2026 to 2027 values apply after 5 April 2027. Obtain the relevant 2027 to 2028 material when available and record every effective date.

Describe PAYE recognition without overreach

HMRC's recognition guidance for developers provides an application route after development and testing. The tax years and stated response timing on that page are subject to change.

The live recognised payroll software directory says listed software can be used to report PAYE online. It also says HMRC cannot recommend one product or service over another and is not responsible for problems with purchased software.

Marketing and contracts should therefore identify the recognised product and capability accurately. Avoid "HMRC approved", "government endorsed" or a suggestion that recognition verifies every calculation, pension function, security control or service outcome.

Recheck status before each campaign and significant sale. Preserve the evidence date and remove claims promptly if the listing or covered product changes.

Map automatic enrolment beyond deductions

The Pensions Regulator's employer guidance says employers have automatic enrolment duties when they employ staff. Its ongoing duties page covers repeated monitoring of age and earnings, contributions, worker requests, records and re-enrolment.

The regulator's payroll-software checklist identifies possible tasks including:

• assessing workers each pay cycle;
• holding necessary current information;
• calculating employer and worker contributions;
• applying the pension scheme's tax-relief method;
• creating provider data in the required format;
• generating communications;
• handling opt-in, join and opt-out events;
• supporting postponement;
• keeping stated records.

Assign every task to the employer, software, bureau, pension provider or adviser. Document the interface. If the product produces a contribution file, test acceptance and reconciliation with the named provider. A file created successfully can still fail at the next system.

Automatic enrolment thresholds and details are time-sensitive. Link users to current regulator guidance and avoid coding an undated value into content or onboarding.

Determine personal-data roles from reality

The ICO's controller and processor guidance explains the roles and warns through its current notice that some material is under review following the Data (Use and Access) Act.

An employer may determine why payroll data is processed, while a supplier acts on documented instructions. That simple model can change when the supplier uses data for its own analytics, fraud controls, product development or marketing. Analyse each purpose separately.

Map data categories, sources, uses, recipients, storage, overseas access, retention and deletion. Payroll data can include information about pay, bank accounts, identifiers, deductions and absence. Some records may reveal health or other information requiring additional care.

The ICO's employment information hub links current guidance for organisations handling worker records. Use it with specialist review for the actual processing.

The Data (Use and Access) Act 2025 amended rather than discarded the UK GDPR, Data Protection Act 2018 and Privacy and Electronic Communications Regulations. Check the current ICO transition and updated-guidance position instead of assuming every older page is unchanged or unusable.

Make processor contracts operational

The ICO's contracts and liabilities guidance covers processing descriptions and minimum contractual terms. Topics include documented instructions, confidentiality, security, sub-processors, assistance with rights and incidents, end-of-contract action and audits.

Connect each clause to an operating control:

Contract promise	Operational evidence
Access only on instruction	Authorisation and access logs
Confidential personnel	Training, agreements and access reviews
Sub-processor control	Current register, diligence and notice route
Incident assistance	Rehearsed escalation and communication record
Return or deletion	Tested export, closure and deletion evidence
Audit support	Named evidence owner and current assurance pack

Do not promise deletion from backups on a timetable the architecture cannot meet. Explain any lawful retention and technical lifecycle accurately.

Protect identity and access to HMRC services

HMRC's May 2026 policy on accessing web services says organisations, individuals and software developers must not request, collect or use HMRC sign-in details belonging to someone else. The paper also explains HMRC's view of third-party products and automation in Government Gateway.

Review customer onboarding, adviser access and every proposed integration against the live policy. Record who authenticates, the authority granted, purpose, scope, revocation and action taken. Do not disguise credential collection as a convenience feature.

Within the product, apply least privilege and strong control over administrators, payment-related roles and bureau access. Separate customers and PAYE schemes. Log significant changes, imports, exports, approvals and support access. Remove access promptly when a user or relationship ends.

Use current software security practice

The UK government's voluntary Software Security Code of Practice provides principles and implementation guidance for developers, vendors and resellers. Its voluntary status should be stated accurately, while legal and contractual security duties still need separate analysis.

A payroll product security programme should cover secure development, vulnerability handling, dependencies, secrets, privileged access, logging, backups, restoration, customer communication and end-of-life support. Procurement evidence should match the actual product and hosting arrangement.

Test recovery, not just backup creation. Simulate unavailable dependencies, an interrupted submission, corrupted import and compromised administrator. Record who decides whether payroll can proceed, which system remains authoritative and how duplicate action is prevented.

Draft commercial contracts around the workflow

The contract should identify all parties and distinguish software, implementation, managed processing, resale and support. Define customer limits, pay frequencies, PAYE schemes, pension integrations, supported tax years and exclusions.

Allocate responsibility for source data, approval, reports, acknowledgements, payments, pension files, employee communication and corrections. Set customer input deadlines and a fair process for changes or late information.

The Small Business Commissioner's Contract Guide suggests clear written terms covering parties, service, quality or conditions, duration, payment and exit. It is helpful orientation for B2B arrangements, while complex payroll risk warrants legal advice.

Liability clauses require analysis of governing law, bargaining context, service and potential loss. The Unfair Contract Terms Act 1977 places controls on specified exclusions and restrictions, including reasonableness in some circumstances. Do not copy a competitor's cap and assume it works for a different contract.

Plan termination and transition. Specify export content, format, timing, fees, access, retention, deletion, outstanding payroll tasks and cooperation. Test whether the customer can retrieve the information needed to continue elsewhere.

Review advertising as a controlled output

The CAP Code's misleading advertising section addresses evidence, qualifications, prices, comparisons, testimonials and endorsements within its remit. The overall impression matters as well as each sentence.

Build a claim register containing:

• exact wording and channel;
• likely interpretation;
• product, plan and audience;
• supporting test or record;
• sample, baseline, period and exclusions;
• required qualification;
• owner, reviewer and expiry.

Claims such as "error free", "fully automated", "saves half a day", "secure" or "works with every pension" are objective or capable of creating objective impressions. Require evidence that matches their breadth.

Price pages should state compulsory charges, VAT treatment, billing period, usage assumptions, minimum commitment and important limits with sufficient prominence. A low base fee should not conceal required per-employee or setup costs.

Handle reviews and commercial interests openly

CAP's testimonials and endorsements guidance covers genuine evidence, permission, product relevance and disclosure of material interests. A testimonial does not independently prove the product's effectiveness.

The CMA's reviews and endorsements collection links current consumer-law guidance following the Digital Markets, Competition and Consumers Act 2024. It addresses genuine and accurate content, disclosed endorsements and fake reviews.

Determine whether the particular publication and audience fall within consumer provisions. Many payroll sales are B2B, but a site may still publish consumer review information or reach individuals acting outside business purposes. Obtain advice on the facts.

Maintain evidence that a testimonial came from a real authorised source and reflects what was said. Disclose incentives, investment, referral fees, sponsorship and ownership where material. Do not publish a staff-created review as customer experience or suppress criticism to manufacture a rating.

Adopt a disclosure and corrections policy

A payroll comparison or directory should publish who owns it, how it earns money, whether commercial relationships affect inclusion or order, and how products are researched. State the scenario, plans, criteria, evidence date and unknowns.

Label adverts and paid placement clearly. Distinguish supplier statements from independent tests. Explain how readers can report an error, who investigates and how material corrections are recorded.

Product recognition, prices, integrations and tax-year coverage can change quickly. Show the last check date beside volatile comparisons and schedule a publication-day verification. Withdraw a page when the team cannot support its decisive claims.

Run a compliance release gate

Before launch or a material update, require named reviewers to examine:

1. customer and service scope;
2. current PAYE specifications and tests;
3. recognition wording;
4. workplace pension responsibilities;
5. personal-data roles and contracts;
6. identity and access design;
7. security and recovery evidence;
8. commercial terms and exit;
9. advertising substantiation;
10. disclosures, reviews and correction routes.

An unresolved issue should state customer effect, severity, workaround, owner and target date. The reviewer must be able to stop release. Silence is not risk acceptance.

After release, monitor submission failures, incorrect calculations, pension rejections, unauthorised access, complaints, support deadlines, claim expiry and supplier changes. Treat a cluster of corrections as evidence that the control or scope needs revision, not merely a service statistic.

The 2027 compliance position

The responsible claim for 2027 is narrow and dated. A defined product version may support specified employer workflows, PAYE requirements and pension integrations under a maintained control system. That does not make it suitable for every organisation or transfer all employer duties to the supplier.

Build compliance as a living register tied to design, tests, contracts, operations and content. Recheck official material when tax years, laws, product status or service architecture change. Trust comes from transparent scope and reproducible evidence, not from one sweeping badge.