Reviews
Part of A framework for comparing payroll software using statutory scenarios and service checks
Finalist trial cases for payroll software selection, and when to reject
Eight trial cases to run on finalist payroll software in England, how to record each result, and the rule for rejecting a product before you sign.
A supplier demonstration is useful, but a controlled trial with representative synthetic cases is stronger. The trial belongs to the finalists only, after the paperwork checks are done. Its job is to produce written evidence that a product handles your payroll, and a clear reason to reject one that does not.
What to take away
- Run the trial on fictitious identities and controlled values. A live employee should never become an experiment.
- Eight cases cover the ordinary run, a starter, a correction, a statutory case, pensions, access withdrawal, export restore and exit data.
- Record expected and actual results, assistance given, operator time and unresolved differences.
- Ask for a written response to every failed case. A planned feature is not current capability.
- Reject any product that fails a mandatory payroll outcome, even if its weighted score is high.
Set up the trial first
Complete the employer facts before the trial starts, so that every finalist runs the same case. List the legal employers, PAYE schemes, pay frequencies and employee counts, then add the directors, irregular workers, leavers and deductions that must be supported.
Employer and PAYE fit checks
- List legal employers and PAYE schemes
- Document directors and irregular workers
- Confirm HMRC recognised software edition
- Check FPS, EPS and year-end journeys
- Record who owns each approval
Confirm the exact edition appears on HMRC's current recognised software list, published as Find payroll software that is recognised by HMRC. HMRC cannot recommend one software product or service over another. Recognition says nothing about how the product behaves in your trial. The supplier-side checks sit with vendor due diligence.
The eight trial cases
Each case below has a single purpose. Use fictitious identities and controlled values, and write the expected result before the supplier touches the system.
| Case | Evidence to keep |
|---|---|
| Ordinary pay period | Every employee and control total reconciled |
| Starter | The submission record, using the official information available |
| Correction after approval | The updated outcome, with no duplication |
| Statutory case | Sickness, family leave or another case that fits the workforce |
| Pension cycle | Assessment, exchange and reconciliation across representative categories |
| Access withdrawal | An administrator removed, with historic actions still attributable |
| Export restore | An agreed export restored in a clean environment, or the documented recovery route shown |
| Exit data | The data needed to leave the supplier, without screenshots or proprietary reports |
Run the first four cases on a copy of the safe test pack so every finalist sees the same inputs.
Pension and payment cases
Pension work is where a generic tick hides the most. The Pensions Regulator says an employer getting payroll software should choose software that is set up for automatic enrolment, so that it can work out who needs to be put into a pension scheme.
Test the whole path. Assess workers, calculate contributions, exchange the file with a named provider, approve the payment and reconcile the response. Rejected and partial outcomes should remain visible until someone repairs them.
Pension and payment workflow
- Assess worker and apply postponement
- Send communications and capture opt-in/out
- Calculate contributions and reconcile provider
- Create and approve payment file
- Handle rejected or partial outcomes
Record what actually happened
For every case, write down the expected result, the actual result, any assistance the supplier gave, the operator time elapsed and the differences still unresolved. A result that needed supplier help is a finding, not a pass.
Here is the shape of a useful entry. The expected outcome is an accepted FPS, every employee reconciled and pension exchange matched to control totals. The actual outcome is an accepted FPS, one starter on the default tax code and a gross pay control total out by that correction.
Keep that case open until the supplier fixes it and the re-run reconciles. The record then shows the failure, the cause and the fix, which a headline score would have hidden.
Ask for the answer in writing
Ask each finalist to respond in writing to every failed case. A planned feature is not current capability, so treat roadmap items as future work. If the supplier offers a workaround, assess it for training, control and recurring effort before it counts.
Price that effort too, alongside the costs employers miss. A workaround that needs extra approvals every month has a running cost that the quote does not show. The parallel runs and rollback conditions for a chosen product are planned later, once the trial has narrowed the field.
Reject on a mandatory failure
Reject products that fail a mandatory payroll outcome even if their weighted score is high. A high total cannot cancel a failed statutory journey, which is why the scoring controls keep pass or fail gates outside the total.
For the finalists, store scenario results, unanswered questions, supplier evidence, contractual gaps, residual risks and approval names. Do not convert an untested supplier claim into a finding. The export and exit cases also feed the transition help at exit you will want in the contract.
Recheck before you sign
Before purchase, reopen the official sources, check the current tax-year version and repeat the critical cases. The selected product should fit the real workflow and give evidence when something goes wrong, not merely look polished in a prepared demonstration.
- Every case has an expected result written before the run
- Every result records assistance, operator time and open differences
- Each failed case has a written supplier response
- Any product with a mandatory failure is rejected
- Official sources and the tax-year version were rechecked
Common questions
Why use synthetic cases instead of live employees?
A live employee should not become an experiment because a trial environment lacks a feature. Fictitious identities and controlled values let you repeat a case and compare finalists on equal terms.
What should happen when a finalist fails a case?
Ask for a written response, including any roadmap item offered as a fix and the training or controls a workaround would need. Keep the case open until the re-run reconciles.
Does a high score outweigh a failed case?
No. A product that fails a mandatory payroll outcome is rejected even if its weighted score is high. Store the result, the supplier's response and the approval names in the decision record.
