Understanding England's payroll software market through PAYE, pensions and official data

England has a large and recurring need to calculate pay, make deductions, report to HMRC and support workplace pension administration. That does not mean there is a single reliable figure for England's payroll software revenue, or that every employer is an available customer.

This guide sets out what official evidence can establish, what it cannot, and how a supplier or publisher can evaluate the market for 2027. Sources were checked on 5 September 2026. Tax-year rules, product recognition and technical specifications can change, so every dated point needs another check before publication or operational use.

Define payroll software before measuring it

The term covers several different products and purchasing arrangements:

• software used directly by an employer;
• a bureau platform processing payrolls for many clients;
• an enterprise payroll module within a wider human-capital system;
• tools used by a managed payroll provider;
• an embedded engine or API inside another business product;
• free software, including HMRC's Basic PAYE Tools for eligible use cases;
• internally developed systems.

A market estimate should say whether it includes subscriptions, implementation, support, outsourced processing and adjacent HR or pension functions. Mixing these revenues produces an impressive but unusable total.

Geography also needs a rule. A supplier can be based outside England while serving English employers. An English employer can run payroll for workers elsewhere in the UK. A bureau can process customers remotely from one office. Decide whether the unit is customer headquarters, worker location, provider establishment or contract billing address, and disclose the choice.

What the official business data shows

The ONS UK business: activity, size and location 2025 release counted 2.73 million VAT and/or PAYE businesses in the UK in March 2025. The associated dataset provides breakdowns by region, industry and employment size.

This is valuable for understanding the employer landscape, but it is not the number of payroll-software customers. The population includes VAT-only businesses that may have no payroll. An enterprise may operate several local units. Some employers use bureaux, free software or a wider platform, and one product can serve many PAYE schemes.

For an England sizing exercise, extract the relevant enterprise and employment-size tables from a single edition. Keep enterprises separate from local units and preserve the downloaded workbook, table names, filters and rounding notes. Do not multiply all registered businesses by an average software price.

Official statistics also do not isolate current software contract values. Build a bottom-up estimate from observed buying behaviour in defined segments. Useful inputs include paid employer accounts, active employees, pay frequencies, bureau client volumes, renewal values, implementation fees and the share using different operating models.

Publish a range. A low case can use validated adoption and retained-customer values; a central case can reflect the best supported assumptions; a high case can test plausible expansion. Each assumption should be editable without rewriting the whole model.

PAYE makes payroll a repeated operational process

HMRC's PAYE and payroll guide says employers normally operate PAYE as part of payroll. A business running payroll itself generally reports employees' payments and deductions on or before each payday. Those amounts can include salary, bonuses and statutory pay, while deductions may cover tax, National Insurance, student loan repayments and pension contributions.

This cadence matters commercially. A defect near payday is not an abstract software inconvenience. It can interrupt a time-sensitive process affecting workers, employer records and amounts reported to HMRC.

The HMRC payroll information guide describes the Full Payment Submission and Employer Payment Summary information employers may need to send. It also covers starters, leavers, National Insurance, pensions and year-end reporting. A product team needs a maintained field and rules inventory, with effective dates and test evidence.

HMRC's find payroll software page explains that software used to run payroll must report PAYE online unless the employer is exempt. It also points out that products differ. Some may not handle payslips, pension deductions, different pay periods or particular reports.

That guidance gives researchers a better segmentation principle than "small versus large" alone. Two employers of the same size may need very different products because one pays weekly and monthly groups, has variable work, sends pension data or manages several PAYE schemes.

Understand what HMRC recognition means

HMRC publishes a list of recognised payroll software that can report PAYE information online. The page includes free and paid products. It is a useful view of recognised supply at the time checked, not a league table, quality review or measure of active users.

HMRC states that it cannot recommend one product over another and is not responsible for problems with purchased software. Publishers should therefore avoid labels such as "HMRC approved" when the official description is recognition for online PAYE reporting.

For developers, the PAYE recognition guidance sets an application route after development and testing. At the time checked, it referred to the relevant RTI and expenses and benefits specifications and stated an aim to respond within six weeks. Both the tax years and review period are dated details that must be reopened before anyone plans a launch around them.

Recognition is one product gate. It does not settle usability, pension compatibility, data protection, payment controls, accessibility, customer support or every employer's fitness requirements.

Automatic enrolment expands the workflow

Under the Pensions Act framework described by The Pensions Regulator, employers have workplace pension duties when they employ staff. The regulator's current guidance says automatic enrolment is a continuing responsibility rather than a one-off setup exercise.

Its ongoing duties page tells employers to monitor staff age and earnings, maintain contributions, manage requests and keep records. Assessment and contribution work connects directly to each payroll cycle.

The regulator's payroll process guidance recommends choosing software set up for automatic enrolment and checking that an outsourced provider's software supports it. More detailed guidance for advisers highlights staff data, contribution calculation, pension-provider formats and the scheme's tax-relief method.

These requirements create real product questions:

• Does the system assess the right population each pay cycle?
• Which inputs and effective dates drive the result?
• How are contributions calculated and rounded?
• Can the product create the file required by the named pension provider?
• What happens when a file is rejected?
• How are opt-in, opt-out and join events recorded?
• Which communications are produced, and which remain the employer's task?

A broad claim that software "does pensions" answers none of them. Compatibility should be stated for the particular workflow and tested version.

Data protection is part of the product, not a footer

Payroll records can include identity, contact, pay, deduction, absence and bank information. Product design therefore needs a documented view of why data is processed, who decides the purpose and means, who acts on instructions, how long records are kept and who can access them.

The ICO's data protection definitions for small organisations uses payroll providers as an example of processors. It also explains that a controller retains responsibility for keeping personal data safe when processing is delegated.

The detailed ICO controller and processor guidance notes that the current material is under review following the Data (Use and Access) Act. Recheck that status before publication and do not assume that a contract label determines the role if actual decisions point elsewhere.

Procurement evidence may need to cover access controls, authentication, encryption, logging, sub-processors, overseas access, retention, deletion, backup, restoration and incidents. A generic security badge cannot replace answers about the actual payroll service.

Compare five commercial models

Employer subscription

An employer buys software to run its own payroll. Pricing may combine a base fee and active employee count. The model can scale efficiently, but small customers may need substantial setup and deadline support. Analyse margin after onboarding and support, not before.

Bureau platform

An accountant or payroll bureau uses one system for many employers. The product promise shifts towards permissions, batch work, client separation, exception queues and audit trails. Pricing may use employer count, employee count, runs or a combination. Test it against real client variation.

Enterprise module

A larger organisation contracts for payroll within a wider system. Implementation, configuration, integrations and assurance can be significant revenue lines. They also lengthen sales and deployment, while local configuration creates more change testing.

Managed payroll

The supplier performs operational tasks as well as providing a system. The contract should identify who supplies and approves data, sends submissions, releases payments, responds to workers and corrects errors. Employee count alone may not predict service effort when exceptions dominate.

Embedded payroll

A finance, HR or sector platform incorporates another provider's payroll components. Distribution may be attractive, but responsibility becomes shared across interfaces. The partners need one end-to-end map of data, calculations, filing, failures and customer support.

Locate opportunities in the difficult hand-offs

The practical opportunity is often between systems or people rather than inside a headline calculation. Candidate problems include:

• structured collection and approval of variable pay;
• validation of starter and leaver information;
• migration with year-to-date reconciliation;
• preservation of payroll IDs and submission continuity;
• pension-file creation, rejection handling and reconciliation;
• secure employee document delivery;
• accounting journals with traceable mappings;
• bureau deadline and exception management;
• restoration and emergency payroll procedures.

HMRC warns that changing software without handling payroll IDs correctly can result in duplicate records or an incorrectly calculated PAYE bill. That makes migration a plausible paid problem, but only customer evidence can reveal the frequency and willingness to pay.

Integrations also need restraint. Passing approved hours into payroll can remove rekeying; it can just as easily transmit an incorrect value faster. Preserve the source, approver, timestamp, transformation and exception state so reviewers can reconstruct the result.

Use a disciplined market-entry sequence

Start with one segment, such as English accountancy practices processing 50 to 200 monthly employer payrolls, or hospitality employers combining weekly and monthly pay. Then:

1. Observe at least one full payroll cycle, including corrections.
2. Identify the task, consequence, current workaround and decision-maker.
3. Specify supported and excluded worker situations.
4. Map current HMRC reporting and pension requirements.
5. Design controller, processor and sub-processor responsibilities.
6. Build dated tests around the relevant technical rules.
7. Run parallel calculations and reconcile every difference.
8. Test imports, acknowledgements, failures and restoration.
9. Price using measured workload and support, not optimism.
10. Pilot with paying customers before widening the scope.

Claims should match evidence. "Supports submission of the tested FPS fields for tax year 2026 to 2027" is narrower and more useful than "fully compliant payroll". Savings claims need a baseline, observation period and explanation of what human work remains.

Build a 2027 evidence dashboard

A market dashboard should keep demand, product performance and commercial health apart.

For demand, record qualified enquiries by employer size, pay frequency, current operating model and trigger event. For performance, track completed payroll runs, submission acknowledgements, exceptions, corrections, pension-file failures and time to recover. For the business, measure acquisition cost, implementation effort, support minutes, gross margin, renewal and expansion using stable cohort definitions.

Do not count free trials as customers or registered employees as paid active employees. Do not treat a submitted file as an accepted one. Do not infer England revenue from a UK supplier's global customer total.

Review the evidence at each tax-year change and whenever HMRC or pension technical requirements alter. Preserve old definitions so a chart does not silently compare incompatible periods.

The responsible conclusion

Payroll software in England serves a recurring, consequential process with clear official reporting and pension connections. The market is nevertheless fragmented by employer size, payroll frequency, operating model, integrations and service expectations.

The sound 2027 strategy is to define one buyer and workflow, use ONS data only for the employer structure it actually measures, validate willingness to pay through live use, and maintain strong reporting, pension, data and continuity controls. There is no need to invent a national revenue total. A narrow proposition with reproducible evidence is a better foundation for product and publishing decisions.