If the pay run has already been approved, but you need to make a correction, consider whether you can apply the correction in the next pay run in line with the HMRC advice which can be summarised as:
If you’ve reported the wrong pay or deductions
To correct a mistake made in the current tax year, update the year-to-date figures in your next regular FPS.If not, you can perform a Rewind.
To Rewind #
Navigate to the Pay Runs listing.
Click the Rewind button:
As highlighted, you can see:
- A link to the documentation on Rewind.
- This has detailed information on the effects of Rewind, and how it can be used.
- We recommend that you familiarise yourself as needed; this guide is a shorthand covering the basics.
- There are some radio buttons on the right which allows you to pick the pay run to be rewound.
- There are one or two tick boxes.
- The second tick box is shown when you pick a pay run.
The first tick box allows a Dry-run: To see if rewind will work, you can use the dry run setting. This will document what would change without actually performing a rewind.
The second tick box gives a warning: Please consider the warning given that the “replacement” pay run will redo all HMRC, bank, pension and other outputs from scratch.
Perform the rewind #
Now:
- Perform the Rewind by clearing the dry-run check box and clicking Rewind.
Here are some screenshots (the details will vary, and you may wish to refer to the documentation at time). For example starting your rewind from May even though the current pay run is September:
After a few moments, your browser will receive a downloaded log file contain details of what was done, and a pay run for May will be started. You should then see something like this:
Note the “Checked-out” state: this tells you where you are. The “Archive” button takes you to a permanent record/summary of the rewind that was done. Now, if you “Approve”, you’ll be presented with rewind-specific options including control over:
- Automatically rippling forward to skip pay run where no manual corrections/changes are needed.
- Or simply go step by step making changes as needed.
- Whether or not to resubmit a special subset of Report Definitions as you ripple forward.
For this example, if you were to ripple forward all the way to September, you would end up with:
Start the pay run #
Depending on your choices, after the rewind is complete, you may need to manually start the scheduled pay runs:
If you are unfamiliar with the steps needed to start a Scheduled pay run, follow the Starting a Pay Run guide.
Review the interim pay run #
After the interim pay run is restarted:
- Check the Pay Schedule dates are correct, or adjust them if needed. See Changing a Pay Schedule.
- Now make any other changes and corrections that required the rewind to be done.
- If you make changes, you must then do a Pay run Redo.
Set an FPS late reason if needed #
For example, you may wish to set a late reason on the FPS; you can do so by navigating to:
- Setup
- Report Definitions
- Find the FPS and click Update
Now set the late reason:
Click Update. As above, if you make this change, you must then do a Pay run Redo.
Approve #
After you have checked everything, approve the pay run as usual.
The next pay run should start automatically after the reports have been submitted..
Rewind Errors #
Missing pay definitions must be recreated: if you deleted any pay definitions that were initially included in the pay run, you will need to re-create them before rewinding the pay run.
Employees who moved between companies: if you have a worker that moves between Companies, you will have had to create a a new Employee in the new Company, and use a new username to avoid clashing usernames. During the rewind, this can cause issues best explained using an example:
- A long time ago, “Old Company” had an Employee with username “norma@example.org”.
- Recently she move to “New Company”, so needed a new Employee with a distinct username.
- So, Old Company Norma had her username changed to “norma_old@example.org”.
- And so New Company Norma could have username “natalie@example.org”.
And life moved on. But then it was discovered that Old Company need to be rewound. When performing the Dry-run, the log contained the following:
INFO: Worker details being rewound: {
…
“value”: {
“89645.username”: “norma1@example.org -> norma@example.org“
}
}
Of course, that means for the duration of the rewind, Old Company needs access to both usernames for Norma, and this is going to clash with New Company Norma. The fix is:
- The New Company norma@example.org needs to be renamed temporarily, e.g. to norma_temp@example.org
- After the rewind, you will want to fix the username for this employee in both the Old Company and New Company as needed.