Guide to Rewinding Pay Runs

Rewinding an original, approved pay run consists of these steps:

  1. Start by backing up and saving any data needed. For example, to verify the rewind has done what was intended or reapply other changes.

  2. An automated rollback to restore a Company and its Employees to the point just before it was approved to allow corrections to be made, and starting a replacement pay run.

  3. Rolling forward by manually making changes, redoing and finally approving the replacement pay run.

  4. If the original, approved pay run was not the current “tip of the tree” pay run, the changes will need to be rippled forward to the current date. This is generally automated too.

  5. Finish up by reviewing the results of the rewind, reapplying any changes recorded at the start and redoing any interim pay runs, and so on.

The following sections explain these parts in more detail.

Warning

By its nature, a Rewind is a destructive operation, and of course, there are some things that simply cannot be undone such as any impact the approved run had on external systems (e.g. previous bank payments, tax and pension submissions). Therefore, paiyroll® provides simpler alternatives for most cases, see Handling errors.

Note

Once started, a rewind MUST be completed before resuming “business as usual”.

Getting started

Before the rewind itself, it is recommended that you should:

  • Perform a dry-run, then review and save the resulting log file:

    • The dry-run will check for many kinds of possible errors that would need to be addressed before the rewind can be successful. It will also produce a log file.

    • The log file contains details of all the changes that would be made to Employees and Pay Items.

    Note that the dry-run is limited in what it can check, but you should be able to correct any other issues that may arise.

  • Save the current Pay Items and any other changes you will need to reapply.

  • Download any viewable reports or other data which may be needed for comparison purposes.

What Rewind will and will not do

The rewind will not:

  • Restore any changes made to Company, Employees or Pay Items except as detailed in Rollback.

  • Restore any changes in Pay Definitions, Pay Schemes or Report Definitions. For each of these types of object:

    • Any that you have deleted will need to be recreated.

    • Any changes which you made will need to be undone.

    • Any changes made as paiyroll® develops may require assistance. Contact paiyroll® support for help.

  • Automatically Ripple forward through dates with multiple pay runs. Manual intervention will be required to process the pay run in the preferred order.

The rewind will:

  • Attempt to identify any issues before the rollback is performed.

  • Record all changes made. This is visible as a log file when performing a dry-run or by viewing the Pay Run Archive created.

Rollback

When it is needed, start the rollback from the Pay Runs screen by clicking Rewind….

The rollback generally uses current Company, Employee and Pay Item values, the exceptions being that:

  • Company and Employee state are restored from their historic values.

  • Employee details are restored from their historic values except for password, last_login and active. For example: changes to address, end date, bank account and tax details will be undone.

  • Pay Item values are restored from the pay run’s snapshot (so newer changes will be lost).

As a given Pay Run is rolled back, the corresponding Pay Schedule is restored to the state needed to roll forward.

Note

The rollback can be performed either as a dry-run, or as a “live” run.

A dry-run simulates the effect of a “live” run, but makes no actual changes. However, it does produce a detailed log of what a live run would do. The first and last parts of the log provide summary information (and the middle contains verbose details) which can be used to review the proposed change.

Roll forward

Once the rollback is complete, you will typically make the needed changes (and redo Pay Runs) until satisfied, then approve it to roll forward.

As usual, once approved, the various reports will be finalised and the state of paiyroll® will be updated accordingly. However, even when rewinding the last approved pay run, most reports cannot be simply used as is. For example:

  • Uploading banking files/APIs may double up on the original payments.

  • Pension uploads/APIs may not be able to update the original submissions.

  • Employee information such as bank account details may have become outdated.

This is made worse by the passage of time when rewinding from further back. Therefore, generally, while the roll forward simply writes out file-based reports, it will run most API-based reports in dry-run mode (see below for exceptions).

Warning

You will need to address the impact on external systems (e.g. previous bank payments, tax and pension submissions). You may need to refer back to the original pay run’s reports for this.

The roll forward will NOT re-run any interim pay runs. Typically, this means that tip of the tree pay run will need “Redo”ing manually.

Redoable report submissions

Some report APIs do allow corrections to be made while rolling forward. paiyroll® refers to these as redoable and allows for this capability to be used when rolling forward instead of running in dry-run mode.

Redoable reports

Jurisdiction

Report Template

Notes

GB

GB HMRC RTI FPS

The general advice from HMRC is NOT to redo old FPS submissions but to make any correction on a YTD basis going forward. Note that the EPS is not redoable.

GB

GB NEST Enrol and Contribute

The last contributions can be updated as long as the schedules have not been updated for payment.

GB

Book keeping/Journals

Journal submissions can generally be redone.

Ripple changes forward

If the original pay run was not the last approved pay run, after the Approval rolls forward, the changes need to be rippled forward through every subsequent approved pay run.

This process consists of applying the rollback and roll forward steps to these pay runs in order. paiyroll® automates this but you can control how it progresses in case you want to make further changes, or you need to manually recover from a failure.

Note

The ripple forward MUST be completed before resuming “business as usual”.

The ripple forward options are:

All approved pay runs:

Automatically ripple the changes forward for all approved pay runs.

This will be the normal choice.

pay run:

The description of an approved pay run, e.g. “m1 2025-03-28”. After this approval, automatically ripple the changes forward to the selected pay run. Once the selected pay run is rolled back, you will be able to make changes and proceed with approval manually as usual.

Choose this option if you know that changes are required to a specific pay run or you want to end at the tax year boundary.

——:

The blank choice. After this approval, stop. Do not ripple forward. Any later approved pay runs must be rewound separately.

You may want to choose this option if you are at the end of the tax year.

Finishing up

  • Review the changes made against what you intended.

  • Restore any Pay Items and other changes you need to reapply from before the rewind.

  • Redo the interim pay runs to pick up the changes from the rewind.

Effects on the Company

When a rewind is started, it MUST be completed. While a rewind is in progress, Administrators generally have access to make all the changes needed. However, external access operates as follows:

  • Employee and Manager access to make changes such as creating Absences or approving Timesheets is blocked just as it would be during Pay Run approval.

  • Employee and API access to live pay slips is disabled.

  • All Debbie automation for the Company is disabled, including automatic running of data feeds and pay runs.

In other respects such as API access and so on, paiyroll® operates as usual. It is recommended that care be taken to avoid:

  • Unwanted effects on the progress of the rewind. For example, Data Feeds may need to be set into dry-run mode and API uploads disabled externally.

  • Unexpected results when fetching data via an API.

Whether a rewind is in progress or not can be seen in Preferences.

Step-by-step example: Rewinding last approved pay run

This section is an example of Rewinding the last approved pay run (nearest the “tip of the tree”).

Let’s say today’s date is 2025-06-01 and you have a sequence of approved pay runs numbered Approved.<n> and in-progress pay runs numbered Interim.<n>, but worker W001 was incorrectly underpaid in Approved.1 like this:

Interim.1 quarterly, 2025-08-01 Interim.2 m1, 2025-06-27 Approved.1 m1, 2025-05-27 Approved.2 m1, 2025-04-27 today is 2025-06-01 >>>>>>> W001 underpaid here >>>>>>>

To rewind Approved.1:

  1. Before performing the rewind, it is recommended to download a copy of the pay items, the snapshot for Approved.1 to be rewound, and any viewable reports which may be needed for comparison purposes:

    1. Perform the rollback in dry-run mode, then review and save the result.

    2. Go to Tools > Create Pay Item workbook to save the current Pay Items. These can be used after the rewind of Approved.1 is complete in order to redo Interim.1 and Interim.2.

    3. Go to Pay runs , view the pay run , then click View Snapshot and save the results.

    4. Go to My documents , then either save the individual reports required or download the complete zip file.

  2. The paiyroll® system allows a Company to run multiple Pay Schedules, for example a pair of monthly and weekly schedules might be in use. Typically, there will be an in-progress, interim pay run in progress for each schedule. At the end of the rewind, these will need to be redone too.

  3. Start the Rewind from approved pay run Approved.1. The rollback will:

    1. Restore Company and Employee state from Approved.2 (or earlier if needed).

    2. Restore the Pay Item inputs from Approved.1.

    3. Unmark Sickness, Holiday and Timesheet Approvals as processed.

    4. Restore the Pay Schedule for the pay run concerned to allow it to be restarted.

    5. Archive Approved.1. Note that the archive only records summary details of the pay run and it’s reports.

    6. Start the replacement pay run CheckedOut.1 (which will delete the original Approved.1).

      If necessary, you may manually start the replacement pay run using Pay run workflows. In the case of a Custom run or On-demand pay run, the list of workers will need to be provided as needed.

    7. Produce documentation logging the changes.

  4. Review the results of the replacement interim pay run CheckedOut.1 carefully. Since this pay run has not yet been approved, further changes can be made simply using Redo as needed. Note that additional steps may be needed, for example, a Timesheet might need to be created and approved or a retrospectively-entered Timesheet may need to be removed.

    Upon error, you will be left with an interim pay run as above and will need to resolve the issue.

    Upon success, you will see the following options on the Approval page to manage the roll forward and any ripple forward needed:

    Ripple forward

    This option will not be visible as you are rewinding the last approved pay run as there are no approved pay runs to ripple forward to.

    Resend submissions

    If ticked, for this pay run, any redoable report will be re-submitted instead of being run in dry-run mode.

    Approved

    Select ‘Yes’ to mark this pay run as approved, finalise it’s reports and roll forward. Select ‘No’ to continue making changes.

Step-by-step example: Rewinding from several approved pay runs ago

This section is an example of Rewinding from several approved pay runs ago, including across a tax year start/end.

Let’s say today’s date is 2025-06-01 and you have a sequence of approved pay runs numbered Approved.<n> and in-progress pay runs numbered Interim.<n>, but worker W001 was incorrectly underpaid in Approved.5 like this:

Interim.1 quarterly, 2025-08-01 Interim.2 m1, 2025-06-27 Approved.1 m1, 2025-05-27 Approved.2 quarterly, 2025-05-01 Approved.3 m1, 2025-04-27 Approved.4 m1, 2025-03-27 Approved.5 m1, 2025-02-27 Approved.6 quarterly, 2025-02-01 Approved.7 m1, 2025-01-27 today is 2025-06-01 >>>>>>> end of tax year 2025-04-05 >>> W001 underpaid here >>>>>>>

To rewind from Approved.5:

  1. Before performing the rewind, it is recommended to download a copy of the pay items, the snapshot for Approved.1 to be rewound, and any viewable reports which may be needed for comparison purposes:

    1. Perform the rollback in dry-run mode, then review and save the result.

    2. Go to Tools > Create Pay Item workbook to save the current Pay Items. These can be used after the rewind of Approved.1 is complete in order to redo Interim.1 and Interim.2.

    3. Go to Pay runs , view the pay run , then click View Snapshot and save the results.

    4. Go to My documents , then either save the individual reports required or download the complete zip file.

  2. The paiyroll® system allows a Company to run multiple Pay Schedules, for example a pair of monthly and weekly schedules might be in use. Typically, there will be an in-progress interim pay run in progress for each schedule. At the end of the rewind, these will need to be redone too.

  3. Start the Rewind from approved pay run Approved.5. The rollback will:

    1. Restore Company state from Approved.6 and Employee state from Approved.7 (or earlier if needed).

    2. Restore the Pay Item inputs from Approved.5.

    3. Unmark Sickness, Holiday and Timesheet Approvals as processed.

    4. Restore the Pay Schedule for the pay run concerned to allow it to be restarted.

    5. Archive Approved.5. Note that the archive only records summary details of the pay run and it’s reports.

    6. Start the replacement pay run CheckedOut.5 (which will delete the original Approved.5).

      If necessary, you may manually start the replacement pay run using Pay run workflows. In the case of a Custom run or On-demand pay run, the list of workers will need to be provided as needed.

    7. Produce documentation logging the changes.

  4. Review the results of the replacement interim pay run CheckedOut.5 carefully. Since this pay run has not yet been approved, further changes can be made simply using Redo as needed. Note that additional steps may be needed, for example, a Timesheet might need to be created and approved or a retrospectively-entered Timesheet may need to be removed.

    Upon error, you will be left with an interim pay run as above and will need to resolve the issue.

    Upon success, you will see the following options on the Approval page to manage the roll forward and any ripple forward needed:

    Ripple forward

    Choose from the options provided using the guidance in Ripple changes forward.

    Resend submissions

    If ticked, for this pay run, and until the ripple forward point is reached any redoable report will be re-submitted instead of being run in dry-run mode.

    Approved

    Select ‘Yes’ to mark this pay run as approved, finalise it’s reports and roll forward. Select ‘No’ to continue making changes.

    Typically, you will choose to ripple forward to the last approved pay run, Approved.1. If you do, then the system will:

    1. For each pay run Approved.<n> from Approved.4 to Approved.1 (including both “m1” and “quarterly”) start the Rewind of approved pay run Approved.<n> as was done for Approved.5.

    2. Automatically approve Approved.<n> and then start the next loop for Approved.<n - 1>.

  5. Finally, after Approved.1 is approved:

    1. You will need to restore saved pay items for Interim.1 and Interim.2.

    2. You will need to redo in-progress pay runs Interim.1 and Interim.2.