Strategy
Part of Payroll software strategy and planning 2027: a framework
Ninety days from choosing the payroll problem to a decision on launch
Follow a 90-day England payroll software plan covering audience evidence, rule mapping, pension workflows, safe prototypes, parallel runs and launch gates.
Ninety days can validate a narrow payroll proposition and produce a controlled pilot. It is not a credible timetable for supporting every employer situation. This plan assumes a team has authority, relevant expertise and access to genuine users while protecting all payroll and research data.
What to take away
- Write one measurable pilot outcome before building anything.
- Fix the rule boundary from HMRC and Pensions Regulator material before testing calculations.
- Expect specialist payroll and reconciliation time to dominate the budget, not test licences.
Days 1 to 15: choose the problem
- Define the user, buyer, payroll pattern and exclusions.
- Observe recent payroll cycles with safe or redacted evidence.
- Quantify the current workaround, errors and staff time.
- Map approvers, blockers and buying trigger.
- Write one measurable pilot outcome.
Use HMRC's running payroll overview as an official process reference, then document how the selected English organisations actually perform each step.
Days 1 to 15: Choose the Problem
- Days 1-15Define user, buyer, payroll pattern, exclusions
- Days 1-15Observe recent payroll cycles with redacted evidence
- Days 1-15Quantify workaround, errors, staff time
- Days 1-15Map approvers, blockers, buying trigger
- Days 1-15Write one measurable pilot outcome
For illustration, a narrow outcome for a bureau could be this. An operator runs and reconciles a weekly PAYE cycle for 40 standard clients in 20 minutes or less. No unexplained differences appear across three consecutive cycles. Any manual correction outside the documented fallback counts as a fail.
Days 16 to 30: establish the rule boundary
- Inventory supported tax-year calculations and reports.
- Identify the applicable HMRC specifications and test data.
- Decide whether PAYE recognition is required for the route.
- Map pension assessment, contribution and data exchange.
- Record controller, processor and sub-processor roles.
The HMRC developer collection is the index of PAYE Online technical specifications and submission services, including the full payment submission and employer payment summary. The Pensions Regulator's software task guide prevents a narrow calculation test from being mistaken for a full pension workflow.
Days 31 to 50: build and test the thin workflow
- Create only the path needed for the pilot outcome.
- Use synthetic records covering ordinary and boundary cases.
- Test permissions, validation, calculation and audit history.
- Exercise submission outcomes, errors and correction paths.
- Test export, backup restoration and service fallback.
HMRC's payroll test data for 2026 to 2027 is one input to testing, not a complete assurance pack. Add customer-specific frequencies, configurations and integrations.
Days 51 to 70: run controlled parallels
- Recruit a small set matching the exact segment.
- Agree data handling, responsibilities and stop conditions.
- Run the existing process and prototype in parallel.
- Reconcile every difference before progressing.
- Record operator time, interventions and support demand.
Do not submit, pay or replace the live system merely to accelerate learning. The pilot agreement should say which process remains authoritative.
Days 71 to 90: decide and prepare
- Resolve or explicitly accept every material issue.
- Review security, privacy, pensions, tax and operations evidence.
- Test support around the selected payroll deadline.
- Calculate pricing from observed delivery cost.
- Decide to launch narrowly, extend the pilot, change direction or stop.
If interaction with HMRC services is planned, check the current access policy before approving the architecture.
The day-90 output is an evidence pack: supported scope, test results, reconciliations, unresolved risks, operating instructions, support model and commercial case. A decision to stop can be successful when evidence disproves the proposition before broader customer exposure.
Effort varies with the number of parallel payroll cycles, test data volume and whether external payroll or pension advice is needed. Specialist payroll and reconciliation time usually dominates; test licences are a minor line. Typical effort ranges from a few person-days a week to a full-time pair.
Weekly governance throughout the plan
Maintain one decision log containing assumption, evidence, confidence, owner and expiry. Review unresolved issues with the people responsible for payroll, tax, pensions, privacy, security, operations and finance. The reviewer able to accept a risk must also be able to pause the work.
Keep customer communication precise. Pilot participants should know what is experimental, which system remains authoritative, what data is used and how to report a problem. Do not offer a public compliance claim in exchange for participation.
At each weekly review, compare progress with the narrow outcome rather than task volume. Remove backlog items that do not strengthen it. If evidence reveals two substantially different customer workflows, select one for the current period and document the other for later research instead of combining them in a rushed build.
Before you act
- Confirm the written outcome, decision log and stop conditions from the phase checklists, then start the parallel run.
Common questions
What should the pilot agreement say about the live system?
The pilot agreement should say which process remains authoritative. Run the existing process and prototype in parallel, then reconcile every difference before progressing.
What is the day-90 output?
The day-90 output is an evidence pack. It covers supported scope, test results, reconciliations, unresolved risks, operating instructions, support model and commercial case. The team then decides to launch narrowly, extend the pilot, change direction or stop.
How should two substantially different customer workflows be handled?
If evidence reveals two substantially different customer workflows, select one for the current period. Document the other for later research instead of combining them in a rushed build. This keeps the ninety-day plan focused on a narrow, measurable pilot outcome.
