top of page

Changing Payroll Software Should Not Break the Pension Record

  • James Williams
  • Jul 16
  • 11 min read

Updated: 1 day ago

Changing payroll software can create an important opportunity for a payroll bureau to improve efficiency, strengthen reporting, introduce greater automation and provide a more consistent service across its client portfolio.


The migration process usually focuses on whether employees will be paid accurately and on time, whether tax and National Insurance information has transferred correctly, and whether the new system can produce the reports required by the employer and HMRC. Workplace pension data deserves the same level of attention.


A pension record extends beyond the contribution calculated during the current pay period, because it also contains information about an employee’s scheme membership, enrolment history, contribution basis, opt-out decisions, previous submissions and future re-enrolment requirements. When any part of this information is incomplete, incorrectly mapped or left behind during a payroll migration, the consequences may only become visible several weeks or months later, when a contribution file fails, an employee is assessed incorrectly or the employer reaches its next re-enrolment date.


For payroll bureaus managing workplace pensions across multiple clients and providers, pension data continuity should therefore form a central part of every software migration, client transfer and payroll implementation.


The pension record is wider than the current payroll calculation

The information required to calculate an employee’s pension contribution may appear relatively straightforward, particularly when the scheme uses a defined percentage of qualifying earnings or pensionable pay.


The wider administration process depends on considerably more information.

The Pensions Regulator identifies dates of birth, salaries, National Insurance numbers, contact details and the amounts paid into the pension scheme during each pay period as essential staff records that should remain correct and up to date. It also advises that payroll software and processes should work effectively with the employer’s pension scheme so that information can move between the two systems.


A complete pension record may also include:

  • The employee’s pension scheme and contribution group

  • The basis used to calculate pensionable earnings

  • Employer and employee contribution rates

  • The date the employee was assessed

  • The date they were enrolled or joined the scheme

  • Any postponement period that has been applied

  • Opt-in, joining or opt-out information

  • The employee’s pension provider identifier

  • Historic contribution and submission records

  • Leaving dates and scheme status

  • Re-enrolment information

  • Records of correspondence issued to the employee


Some of this information may sit inside the payroll system, while other elements may be held within a pension provider portal, an employer’s HR system, a document archive or a separate administration spreadsheet.


A software migration can therefore transfer the visible payroll record while leaving parts of the wider pension history distributed across several locations. The new system may calculate the next contribution correctly, yet the payroll team may no longer have a complete view of how the employee reached their current pension status.


Employee identifiers protect the connection between payroll and the provider

Pension providers need to match every contribution submitted through payroll with the correct member record.


This matching process may use a combination of the employee’s name, date of birth, National Insurance number, payroll reference and a provider-specific identifier. When these fields remain consistent, the provider can usually allocate contributions to the correct pension account.


A payroll migration may create new employee or payroll reference numbers, change the format of an existing identifier or remove a provider reference that was stored within a custom field in the previous system.


These changes can create duplicate pension records, unmatched contributions or rejected submissions, particularly when the provider receives information that appears to relate to a new employee rather than an existing scheme member.


The problem may affect only a small number of employees during the first submission, although the time required to investigate each case can be significant. Payroll teams may need to compare records across both systems, contact the employer, review previous provider submissions and request support from the pension provider before the contribution can be allocated correctly.


Preserving the relationship between payroll identifiers and provider membership records should therefore be treated as a specific migration requirement. Every field used to identify an employee should be documented, mapped and tested before the first live pension submission is produced from the new software.


Where a new payroll reference must be introduced, the bureau should understand how the pension provider will recognise the change and whether any additional information needs to be included within the submission.


Contribution history supports more than reconciliation

Historic pension contribution data provides payroll teams with an important record of what has previously been calculated, deducted and submitted.


During a migration, attention often centres on opening balances and year-to-date payroll figures, while detailed pension history may receive less scrutiny because the immediate priority is calculating the next pay period.


This history can become important when an employee questions a deduction, a provider reports a missing payment or a payroll administrator needs to reconcile the value submitted for a previous period.


Contribution records can also help identify when an employee’s pension rate changed, whether an employer made an additional payment and how a correction was handled after a previous payroll adjustment.


The Pensions Regulator states that employers should retain records showing when money was paid into the pension scheme, alongside employee and scheme information that demonstrates how their automatic enrolment duties have been met. Most of these records must be kept for six years, while records of requests to leave the scheme must generally be retained for four years.


A payroll migration plan should establish which historic contribution information will move into the new system, which records will remain within an accessible archive and how administrators will retrieve them when a query arises.


The old system may eventually become unavailable, particularly when a software licence expires or a client moves between payroll providers, making a reliable archive essential for future investigations.


Scheme configuration needs to be transferred accurately

The same percentage can produce a different pension contribution depending on how the scheme has been configured.


One scheme may calculate contributions using qualifying earnings, while another may use basic pay, total pensionable pay or a certified earnings basis. Different employee groups may have separate employer contribution rates, and some workers may make fixed or additional voluntary contributions.


Tax relief arrangements also need to be configured correctly because relief at source and net pay arrangements affect how employee contributions are processed through payroll.


The Pensions Regulator advises payroll professionals and business advisers to understand which tax relief method a pension scheme uses and ensure that the correct method is entered into the payroll software.


During a migration, scheme names and percentage rates can be transferred while the underlying calculation settings remain incomplete or are interpreted differently by the new platform.


A contribution may still be generated, although the amount may vary from the previous system because the software has included different pay elements, applied thresholds differently or treated salary sacrifice arrangements in another way.


Scheme configuration should be documented at client, scheme and employee-group level before data is moved. This should include the earnings basis, contribution structure, tax relief method, certification basis where applicable, salary sacrifice arrangements and any client-specific rules that affect the calculation.


Testing should then confirm that the same employee and pay information produces the expected pension result in both systems.


Opt-out and joining records must remain visible

An employee’s current pension status is often the result of a previous decision or statutory process.


They may have been automatically enrolled, chosen to opt in, requested to join the scheme, opted out within the permitted period or stopped contributing at a later date. Each event can influence how payroll should treat the employee in future.


The Pensions Regulator requires employers to retain records of opt-outs and explains that payroll must stop further deductions once a valid opt-out has been received, with the employee’s contributions normally refunded through payroll. When a migration transfers only the employee’s current status, the evidence supporting that status may remain in the old system or disappear from the payroll team’s normal workflow.


An employee may appear as a non-member in the new software without a visible record of whether they opted out, ceased membership or have never met the eligibility criteria. This can create uncertainty when the employer approaches re-enrolment or when the employee challenges how their pension has been handled.


Joining dates, opt-out dates and the reason for the current scheme status should therefore be included within the migration design, alongside access to the original notices or supporting records where required.


Clear status codes and consistent terminology are particularly important when the old and new systems describe pension membership differently. A status labelled “inactive” in one system may contain several distinct employee circumstances, each of which may need a different action under automatic enrolment.


Re-enrolment depends on reliable historic information

Employers must generally assess eligible employees for re-enrolment approximately every three years, including workers who previously opted out or ceased active membership more than 12 months before the employer’s chosen re-enrolment date.


Payroll software can support this process by identifying employees who need to be assessed and placed back into the workplace pension scheme. The accuracy of that assessment depends on the history retained within the system.


Where an employee’s opt-out date, cessation date or previous enrolment status has not transferred correctly, the new payroll software may exclude somebody who should be assessed or include an employee whose circumstances require a different treatment.


The issue may remain undetected during normal monthly processing because the employee’s current contribution is zero. It becomes visible when the re-enrolment process begins, potentially several years after the original software migration. This delay makes re-enrolment information particularly vulnerable during data transfers, because it may appear less urgent than the information required for the next payroll run.


A migration should preserve the employer’s previous re-enrolment date, the next expected cycle, employee opt-out and cessation dates, and any information needed to understand why an employee is currently outside the scheme.


Payroll bureaus should also establish where responsibility sits for maintaining this information when a client joins partway through its three-year re-enrolment cycle.


Provider compatibility needs to be tested before the first live run

Payroll software may support automatic enrolment calculations while producing pension files in a format that differs from the previous platform.


Providers can require different field names, employee identifiers, contribution categories and submission processes. Some payroll platforms connect directly with selected providers, while others produce files that must be uploaded manually through a portal.


The Pensions Regulator advises employers and their advisers to confirm that payroll software supports automatic enrolment and works with the chosen pension scheme, allowing information to transfer effectively between the two.


This compatibility should be tested using the employer’s actual scheme configuration rather than relying solely on a general statement that the software supports workplace pensions.


A successful test should confirm that:

  • Every employee appears in the expected contribution category

  • Provider and payroll identifiers are retained

  • Pensionable earnings are calculated correctly

  • Employer and employee contributions match the expected values

  • New joiners and leavers are represented correctly

  • File headers, dates and pay-period information are accepted

  • Corrections and negative adjustments can be processed

  • The provider can match the submission with its existing member records


Payroll bureaus managing several providers may need a separate test for each file format and integration, because a process that works successfully for one pension provider may require different data or controls for another.


Completing this work before the first live submission gives the bureau time to resolve configuration issues without placing contribution deadlines under unnecessary pressure.


Parallel testing can reveal differences before they affect employees

A parallel payroll run compares the output from the existing system with the results produced by the new platform using the same employee and pay information.

For pensions, the comparison should extend beyond the total contribution value. Two systems may produce the same overall contribution while allocating different amounts to individual employees, using a different pensionable pay figure or assigning workers to the wrong scheme group.


Testing should therefore compare employee-level assessment outcomes, pensionable earnings, contribution values, scheme membership, employer rates, employee rates and provider identifiers. Any difference should be investigated and explained before the new system becomes the live payroll record.


Some variances may result from a deliberate improvement in configuration, particularly where the migration has identified an existing error or inconsistent process. Those changes should be documented clearly so that the bureau and employer understand why the new calculation differs and what action has been taken.


A well-controlled parallel run provides evidence that the new payroll process can continue the pension record accurately, while also giving administrators an opportunity to become familiar with the new exception messages, reports and provider submission workflow.


Client transfers create an additional pension handover risk

Payroll migrations also occur when an employer moves from one payroll bureau to another.

In this situation, the incoming bureau may receive employee and year-to-date payroll information without the complete pension administration history held by the previous provider.


The new team may know which employees currently contribute and the percentages being deducted, while having limited visibility of previous opt-outs, re-enrolment dates, provider errors, contribution corrections or scheme-specific arrangements.


The employer remains responsible for meeting its automatic enrolment duties even when payroll or pension administration is delegated to an external adviser. The Pensions Regulator makes clear that advisers can perform tasks on behalf of a client, while responsibility for ensuring those duties are completed correctly and on time remains with the employer.


A structured pension handover can help both the employer and incoming bureau establish a reliable starting point.


The handover should request scheme details, provider references, current membership information, contribution structures, opt-out and joining records, postponement information, re-enrolment dates, previous submission reports, unresolved exceptions and confirmation of the last contribution period completed. Any missing information should be recorded and addressed before the bureau assumes that the pension record is complete.


This approach also helps the incoming provider distinguish between data created by the migration and issues inherited from the previous payroll process.


Clear ownership supports a controlled migration

Payroll software changes usually involve several parties, including the employer, payroll bureau, software provider, pension provider and sometimes an implementation consultant or adviser.


Each party may assume that another team is responsible for validating the pension data.

The software provider may focus on the technical transfer, the pension provider may confirm only whether a submitted file has passed its validation rules, and the employer may expect the payroll bureau to retain information that has historically been held within its own HR records.


A migration plan should define who is responsible for supplying, checking, approving and retaining each part of the pension record.

It should also establish who will resolve any differences identified during testing and who will confirm that the first live pension submission has been accepted and reconciled successfully.


For payroll bureaus, this creates a clear boundary between implementation activity and ongoing service delivery, while giving the client a better understanding of the information they need to provide.


The plan should continue beyond the first successful payroll run because some pension issues become visible only when the contribution file reaches the provider, payment is reconciled or a later employee event triggers the historic record.


A pension migration checklist creates consistency

Payroll bureaus often manage several implementations at the same time, each involving different employers, pension schemes and software configurations.

A standard pension migration checklist can create a more consistent process while allowing for client-specific requirements.


The checklist should cover:

  • Employee and provider identifiers

  • Pension scheme names and references

  • Earnings definitions

  • Contribution rates and employee groups

  • Tax relief arrangements

  • Salary sacrifice configurations

  • Joining and enrolment dates

  • Opt-in, joining and opt-out records

  • Postponement information

  • Leaver and cessation dates

  • Re-enrolment history and future dates

  • Year-to-date and historic contribution data

  • Outstanding corrections or failed submissions

  • Provider file formats and integrations

  • Access to archived records

  • Parallel testing results

  • Approval of the first live submission

  • Reconciliation of the first provider payment


Using the same framework across every implementation reduces reliance on individual knowledge and makes it easier for payroll leaders to review migration readiness across the bureau.


It can also support better client communication because the employer receives a clear list of the information required, the decisions that need to be made and the consequences of incomplete data.


Stronger pension data continuity supports scalable payroll services

Payroll technology will continue to change as bureaus seek greater automation, stronger reporting and more efficient ways to manage increasing client volumes.

The value of that technology depends on the quality and continuity of the information within it.


A successful migration should leave the payroll bureau with a pension record that remains complete, understandable and usable across future pay periods, employee queries, contribution reconciliations and re-enrolment cycles.

This requires more than transferring the contribution percentage currently applied to each employee. It requires preserving the decisions, dates, identifiers and historic records that explain how each employee should be treated.


Payroll bureaus that make pension data continuity a core part of their migration process can reduce failed submissions, avoid repeated investigations and give their teams greater confidence in the information held within the new system.

They can also create a stronger foundation for future automation because reliable pension processes depend on consistent data moving accurately between payroll, employers and providers.


Changing payroll software should improve the way workplace pensions are administered while maintaining the integrity of the record employees and employers depend on.

When pension data is documented, transferred, tested and reconciled with the same care as the wider payroll, the bureau can introduce new technology without disrupting the contribution journey or losing the history behind it.

Comments


bottom of page