Strategy
Part of Payroll software strategy and planning 2027: a framework
Payroll software strategy mistakes in England, sorted by stage
Twelve payroll software strategy mistakes in England sorted by stage: before the build, before launch and after launch, each with a warning sign and a fix.
Payroll software strategy mistakes in England surface at different moments. Some are made before a line of code is written, some just before launch and some only after customers are live. Sorting the twelve by stage tells you which review to run now.
What to take away
- Before the build, check scope, HMRC recognition, tax-year maintenance and pensions.
- Before launch, check test coverage, sign-in practice, recovery evidence and the line between pilot and live.
- After launch, check pricing against support, what counts as success, retention and sales qualification.
- HMRC recognition is not approval of usability, security, pensions or the wider service.
- Reject designs that rely on borrowed Government Gateway credentials.
- Turn each mistake into a release gate with an owner and an evidence requirement.
Before the build: four mistakes
The earliest mistakes are cheap to fix and expensive to ignore. Each one sets the shape of everything built afterwards, so settle them while the product is still a plan.
| Mistake | Warning sign | Fix |
|---|---|---|
| Targeting every employer | The target customer is described only by employee count | Select one operating context and state exclusions |
| Treating recognition as endorsement | Recognition appears in marketing as approval | Describe it only as recognition for online PAYE reporting |
| Building once and forgetting the tax year | Rule changes have no named owner | Named owners, dated rule inventories, regression testing and customer release plans |
| Reducing pensions to one deduction field | Pensions are a single column in the design | List the pension tasks the product performs |
Employee count alone does not describe payroll. Pay frequency, worker situations, PAYE schemes, pensions, source systems and approvals change the job. A product for hospitality employers with weekly paid staff might exclude umbrella companies, off-payroll contractors and salary sacrifice.
HMRC publishes recognised payroll software for online PAYE reporting, and it says it cannot recommend one software product or service over another. Recognition should not be described as HMRC approval of usability, security, pensions or the wider service.
A launch team without a maintenance team does not have a viable payroll product. Fund the maintenance team before launch, because the tax year does not wait for the roadmap.
The Pensions Regulator's software guidance lists assessment, contribution, provider-data, communication, request and record tasks. State which of them the product performs, and verify the chosen scheme's format and tax-relief method.
Before launch: four mistakes
Launch is where optimism meets payday. These four mistakes are about evidence: what the tests really cover, what access the product relies on, and whether anyone has seen it recover.
| Mistake | Warning sign | Fix |
|---|---|---|
| Equating supplied test cases with complete assurance | Test data is the whole test plan | Add boundary, negative, migration, security, restoration and real workflow tests |
| Designing around borrowed sign-in details | A workflow needs a customer's own Government Gateway login | Redesign so no one uses details that are not theirs |
| Promising availability without recovery evidence | The service level quotes average uptime | Define critical functions, support ownership, backup scope and fallback |
| Letting the pilot become live by accident | A customer deadline is driving the prototype | Authoritative system, governed data, named submission authority, stop conditions |
The 2026 to 2027 payroll test data supports developers' own routines. It does not cover every configuration, integration, user action or failure, so treat it as a starting point and add your own scenarios.
HMRC's web-services access policy says third parties must not request, collect or use sign-in details that do not belong to them. Its current position is that automation tools must not be used to enter data into or navigate Government Gateway. A commercial shortcut that conflicts with that policy is an architectural risk, not a growth hack.
Average uptime says little about a customer blocked before payday. Measure successful recovery from realistic incidents, including restoration tests, fallback and correction routes.
Parallel testing needs an authoritative system, synthetic or governed data, a named submission authority and stop conditions. A customer deadline must not convert an unresolved prototype into production. The go-live checklist shows what has to be true before that switch.
After launch: four mistakes
Once customers are live, the mistakes move from engineering into the business model. They are quieter, because nothing breaks on payday, and they decide whether the product is worth running.
| Mistake | Warning sign | Fix |
|---|---|---|
| Pricing before measuring support | One flat fee for easy and difficult customers alike | Calculate gross margin after onboarding and deadline support |
| Confusing a submission with a resolved outcome | Success is logged at the API call | Define success at the end of the supported workflow |
| Measuring registrations instead of retained use | Free accounts and imported records inflate the dashboard | Track completed payroll cycles, paying cohorts and renewal |
| Hiding exclusions from sales | Unsupported cases appear only in a technical document | Put them in qualification scripts, order forms and onboarding |
A simple per-employee fee can hide migrations, extra runs, late data and complex exceptions. Calculate gross margin after onboarding, payroll-deadline support, assurance and regulatory maintenance, and segment cohorts rather than averaging easy and difficult customers.
A transmitted report can be rejected, duplicated or inconsistent with the customer's expectation. Preserve acknowledgements, error states and correction history, and define success at the end of the workflow rather than at the call.
Track completed payroll cycles, active paying cohorts, support effort and renewal using written definitions. Unsupported cases belong in sales qualification, so review lost deals to find where positioning widened beyond delivery.
A smaller honest market is preferable to recurring failures among customers the product was never designed to serve.
Turning stages into release gates
Give each mistake a gate with an owner and an evidence requirement. Strategy improves when the team can stop work that widens scope without strengthening the chosen customer outcome.
Review the gates before each tax year, major integration and entry into a new payroll segment. The strategy and planning framework shows how the gates fit a full plan.
- Before the buildone operating context, named rule owners, listed pension tasks.
- Before launchrestoration tests passed, no borrowed sign-in details, pilot stop conditions written.
- After launchmargin calculated after support, success defined at the end of the workflow, exclusions in sales scripts.
Common questions
What does HMRC recognition actually mean for payroll software?
HMRC publishes recognised payroll software for online PAYE reporting, while saying it cannot recommend a product. It is a status for reporting, not an endorsement of the whole product.
Why keep a pilot away from live payroll deadlines?
A customer deadline must not turn an unresolved prototype into production. Parallel testing needs an authoritative system, governed data, a named submission authority and stop conditions agreed in advance.
Why is targeting every employer a mistake?
Pay frequency, worker situations, PAYE schemes, pensions, source systems and approvals change the job. A broader target widens scope without strengthening the chosen customer outcome.
