Skip to main content

Rehiring Casual Employees: Managing Pension and Historical Data

Written by Emily Misselbrook

In industries like farming, rehiring casual employees is a common occurrence. In TELUS Farm Payroll (TFP), the system treats a rehired worker as a "new employee" to remain compliant with HMRC requirements.

While basic personal details carry over, pension information should not automatically migrate. However, you may occasionally find historical pension data—such as Auto-Enrolment (AE) dates or old scheme memberships—appearing on the new record. This guide explains why this happens and how to manage it.

Why Historical Data Appears

If an employee is rehired within the same tax year they previously left, the system may pull through historical data for two main reasons:

  • Opening Balances: TFP automatically pulls Year-to-Date (YTD) figures from the previous employment into the "Previous Employer" section of the Opening Balances page.

  • Legacy Pension Links: If an employee was not correctly "offboarded" from their pension scheme before being marked as a leaver, the system may maintain a link to their previous AE data and enrolment status.

How to Fix Current Rehire Records

Rehiring Casual Employees: Managing Pension and Historical Data

In industries like farming, rehiring casual employees is a common occurrence. In TELUS Farm Payroll (TFP), the system treats a rehired worker as a "new employee" to remain compliant with HMRC requirements.

While basic personal details carry over, pension information should not automatically migrate. However, you may occasionally find historical pension data—such as Auto-Enrolment (AE) dates or old scheme memberships—appearing on the new record. This guide explains why this happens and how to manage it.


Why Historical Data Appears

If an employee is rehired within the same tax year they previously left, the system may pull through historical data for two main reasons:

  • Opening Balances: TFP automatically pulls Year-to-Date (YTD) figures from the previous employment into the "Previous Employer" section of the Opening Balances page.

  • Legacy Pension Links: If an employee was not correctly "offboarded" from their pension scheme before being marked as a leaver, the system may maintain a link to their previous AE data and enrolment status.


How to Fix Current Rehire Records

If you have already rehired an employee and their record is displaying incorrect historical pension data, follow these steps to "clean" the record:

  1. Review the Pension Tab: Navigate to the employee's Pension settings.

  2. Clean Up the Record: Manually remove outdated postponement assessments, incorrect scheme memberships, or legacy AE dates that apply to the previous period of employment.

  3. Validate: Ensure the current pension status is "blank" or accurately reflects the start of their new period of employment.

Best Practice for Future Rehires

To prevent old pension data from "clinging" to a new record in the future, it is vital to follow this specific order of operations when an employee leaves the business:

  1. Pension First: Navigate to the employee’s Pension record.

  2. Set Status: Click "Leave Pension" and select "Leaver" from the State dropdown.

  3. Enter Date: Input the final Leaving Date.

  4. Payroll Last: Only after the pension status is updated should you proceed to process the employee as a leaver in the main payroll system.

Summary: What to Expect When Rehiring

When you re-add an employee to TFP, the system is designed to handle different types of data as follows:

Data Type

Behaviour on Rehire

Personal Details

Created as a new record, but linked to old history/payroll codes as required by HMRC.

Pension Information

Does not carry over by default. Employees must be re-enrolled manually or via the standard Auto-Enrolment assessment.

Benefits

Does not carry over. These must be re-added manually if applicable.

Tax / YTD figures

YTD figures do carry over via Opening Balances (if rehired within the same tax year).

❗Tip: Following the "Pension First" steps above is the most effective way to ensure a "clean break" between employment periods, saving you manual admin time if that employee returns for the next season.

Did this answer your question?