Payroll competitor research that compares like with like, from HMRC status to leaving

Competitor research should describe verifiable offers at a stated date, not decide which logo looks most established. Use this checklist to compare products serving the same customer and payroll job. Preserve evidence so another researcher can repeat the work.

Set the comparison frame

• Define the English buyer, employer size and operating model.
• Specify pay frequencies, PAYE schemes and employee situations in scope.
• Separate employer software, bureau platforms and managed services.
• State whether adjacent HR, time, pension and payment functions count.
• Record the research date and tax year.

A product for ten salaried monthly employees is not directly comparable with a multi-client bureau system. Create separate tables when the primary buyer or service boundary changes.

Build the candidate list

• Search the current HMRC-recognised software list.
• Record supplier and product as separate fields.
• Note whether the listing describes free, paid or bureau use.
• Add credible products outside the list only with an explanation.
• Never describe recognition as HMRC recommendation.

The official page confirms ability to report PAYE online for listed products at the time checked. It does not establish adoption, quality, service reliability or fitness for every employer.

Compare like with like

• Capture a dated first-party feature page for every product.
• Test payslips, pay frequencies, statutory pay and promised submissions.
• Record automatic enrolment tasks and named pension compatibility.
• Examine permissions, approval records and multi-entity separation.
• Verify imports, exports, integrations and correction workflows.
• Distinguish included functions from paid add-ons or partner services.

HMRC's payroll software overview gives a useful minimum feature prompt but explicitly notes that products differ. Check the actual plan and customer type rather than attributing a supplier-wide claim to every edition.

Normalise price and contract evidence

• Record currency, VAT treatment, billing period and minimum commitment.
• Note base fees, employee bands, extra runs, setup and migration.
• Capture renewal, cancellation, overage and data-export conditions.
• Mark quote-only prices as unavailable, not zero.
• Calculate sample scenarios using identical employer assumptions.

Screenshots and archived copies help show what was displayed, but the live contract governs a purchase. Recheck all amounts on the decision date.

Review trust and operations

• Read current privacy, processor and sub-processor material.
• Ask for security and resilience evidence appropriate to the risk.
• Test accessibility with relevant users and assistive technology.
• Check support hours against the payroll schedule.
• Verify service status, incident and restoration routes.

The ICO's controller and processor guidance helps frame responsibility questions, but product documents still need factual review.

Conclude with gaps, not a universal winner. A defensible shortlist states which scenario each product was tested against, which claims remain unverified and what evidence must be obtained before purchase.

Test the buying and leaving experience

• Request a demonstration using the same prepared scenario.
• Ask the supplier to show an error, correction and audit record.
• Import dummy year-to-date data and reconcile the result.
• Export every record needed to leave the service.
• Measure staff interventions and unresolved questions.

Do not enter genuine employee information in a trial unless the organisation has approved the processing and supplier. Synthetic records are sufficient for initial workflow comparison.

Repeat important checks with two researchers where interpretation could alter the result. Keep claim, source URL, plan, access date and evidence excerpt in separate fields. A red, amber or green score should link back to those records.

Refresh volatile fields such as pricing, tax-year coverage, product recognition and integrations immediately before a decision. Preserve the previous snapshot so the team can see whether a product changed or the research method did.