Automating the back payment process

The process of back-paying an employee can sometimes be quite tedious, complex and manual. Firstly, you need to identify all the components of an employee’s historic pay that require back payment, then you need to start calculating the rate difference for the back pay period (which gets more complicated when the employee is also paid penalties), then you need to calculate the tax owed on the back pay, and so on. The back pay feature automates these processes and significantly removes the need for any manual calculations.

To access the back pay feature, go to Payroll Settings > Pay Conditions > Back Pay. If you cannot see Back Pay listed underneath the Pay Conditions menu, this probably means you are not on the correct subscription plan and will need to upgrade to get access.

This article will break down the specifics of the back pay and the steps users need to follow to back pay an employee. The back pay functionality consists of completing three steps. These steps are:

Step 1: Search for employees requiring back pay

This first step is needed to identify which employees had a pay rate increase over a defined period. When entering the defined period, the platform will check for any employee whose Pay Rate field (within the employee’s Pay Run Defaults screen), was updated with a higher rate than what was previously contained in that field.

1. To search for affected employees, go to Payroll Settings.
2. Under Pay Conditions, click on Back Pay.
3. Click on Add.
4. Click on Add Employees.
5. In the context panel, select the applicable pay schedule the employees would be associated with.
6. Select the date range of when the changes to the employee pay rates would have occurred.
7. If you want to include terminated employees in the search, tick the Include terminated employee(s) checkbox.
8. Click Search.
9. A list will then appear with any employees fitting the criteria searched and show the old (previous) rate with the new (current) rate. If you have included terminated employees in your search, they will be identified with a star next to their name:

Upon reviewing the list, select those employees that do require a back pay by ticking the checkbox on the left of the employee’s name. If all employees need a back pay then you can tick the checkbox in the header and this will select all the employees. Then click on Add. The back pay table will populate. You are now ready for step 2.

Step 2: Finalise employees requiring back pay

Once employees have been selected, the back pay table will populate with their details as per the following example:

The following is an explanation of the columns and activities that can be performed in this table:

Effective date: The effective date is populated based on the employee’s anniversary date. This is the date entered in the Anniversary Date field from the employee details screen. If the anniversary date field is blank, the platform will apply the date in the employee’s Start Date field. In terms of the year that is populated, the platform will apply by default the most recent year that has passed prior to the pay increase being added to the employee’s Pay Run Defaults screen.

For example:

• An employee’s anniversary date is 12/6/2012
• The employer updated the employee’s pay rate on 10/4/2023
• The day and month used to determine the effective date will be 12 June, based on the employee’s anniversary day and month
• The year used to determine the effective date will be 2022, as that is the most recent year prior to the pay increase taking effect. 

There may be instances where the employee’s anniversary date is not the date the back pay starts from. If this is the case, you can override the employee’s effective date and then click the refresh icon so that the platform can update the total lump sum based on the new effective date. Another example where you may need to change the effective date is where there are 2 back pay records for an employee, for example:

The reason for there potentially being 2 records is that the employee would have received multiple pay increases during their anniversary period. In this instance, you may want to change the second record to a later date (if there is back pay to be processed). Otherwise, you can simply delete one of the records if they do not require any back pay.

In instances where the same effective date is to be applied for all employees in the table, you can override the first employee’s effective date and then click on the downward arrow. This will copy the same date across to all employees.

Old pay rate: The figure populated in this column is the pay rate that applied to the employee prior to being updated. If, for any reason, you want to change the figure entered in this field you can do so by clicking on the Override checkbox. This will open up the Old pay rate and Total lump sum fields thereby allowing the user to enter ‌a different old pay rate. Beware that the platform will not recalculate the total lump sum amount if the old pay rate amount is overridden. Instead, the total lump sum amount will also need to be manually entered. If you want to revert back to ‌platform-generated amounts, simply untick the Override checkbox.

Total lump sum: The amount populated in this field is the total back pay owing from the employee’s effective date up to the last pay run that the employee was paid at their old rate. Hovering your mouse over the tooltip info icon will display a breakdown of how the lump sum amount was calculated.


Take note of the following regarding the calculation of the total lump sum:

• The platform can only calculate back pay-off pay runs processed in the platform
• Opening balances are not factored in when calculating back pay
• Any earnings associated to fixed unit pay categories, such as bonuses, allowances, leave loading, etc, are not factored in when calculating back pay
• Earnings associated with the employee’s primary pay category and linked pay categories of that primary pay category are factored in when calculating back pay
• Any paid leave that applies to the employee’s base rate of pay is factored in when calculating back pay
• If an employee has been included in an adhoc pay run during the anniversary period, this pay run will be included when the platform checks for back pay. Similarly, if an employee has changed from one pay schedule to another during the anniversary period, earnings from both pay schedule pay runs will be included when the platform checks for back pay
• When the employee’s effective date is mid-pay period, the platform will pro-rata the hours used for back payment. This is explained in detail further below.
• For employees who have a rate loading associated with their base rate of pay, such as casuals, the old and new pay rates will display their base rate, i.e., excluding the loading. However, the breakdown will be inclusive of ‌rate loading. Referring to the below screenshot as an example, the difference in old and new rates is $0.58 per hour. The rate used to calculate the breakdown, however, is inclusive of the loading, being $0.58 * 25% loading = $0.73.
  
  
  
  

  Override: This functionality has been explained in the Old pay rate section. A further thing to note here is that when an employee’s back pay has been overridden, the tooltip showing the breakdown of the lump sum amount will be removed as it effectively no longer applies. As stated above, the override can be reverted to the original platform calculated values by unticking the Override checkbox. Refer to the pay categories section for further information on how overridden lump sum amounts are applied in the pay run.

  Delete: You can remove a back pay record from the table by clicking on the bin icon to the right of the employee record. Before deleting, take note of the following:

  • Although the employee will be removed from the back pay table, if you do a subsequent search for eligible back pays using the same date range, the employee will reappear;
  
  
  
  If you want to delete an employee because they have a $0 lump sum amount - this could be because the employee had no pay runs in the platform during the anniversary period or they had pay runs but the new rate was being applied from the anniversary date - rest assured that the employee will not appear in the pay run (this relates to step 3). For example, say the back pay table displayed the following records:
  
  
  
  Employees paid based on their basic work pattern: For these employees, we follow the same pro-rata principles as in other methods used in the platform, which is explained in further detail in this article

Step 3: Apply back payments in payrun

Save for later: At any stage, prior to completing the records, you can choose to save the record and access it again at a later stage. Keeping the record as saved, as opposed to complete, will not send the data through to the pay run. You can access the record again from the main Back Pay screen by clicking on the edit (pencil) icon.

Export: At any stage, whether the record is saved or marked as complete, you can export the details of the back pay record by clicking on the Export button. This will allow you to download an excel or csv export of the back pay details.

Add employees: Once you have completed an initial search of employees eligible for a back pay, you can choose to add more employees to the same back pay record. You may choose to do this to (a) obtain employees associated with a different pay schedule that could be eligible for a back pay and/or (b) obtain employees associated with the same pay schedule but choose a different data range.

Complete: Once you have reviewed the back pay records for eligible employees and are 150% confident that the records can now be processed in the pay run, click on Complete. Marking the record as complete signifies it is ready to be processed in the pay run and, as such, will lock the records whereby they cannot subsequently be edited. You cannot edit or delete a back payment after marking it complete. This means you need to make all required edits before clicking the Complete button. Once you click on Complete, the following modal will display: This warning displays to clarify that the platform will not automatically process these back pays in the background. Instead, the back payment records will display when (a) the pay run associated with the employee’s pay schedule is subsequently created or (b) an adhoc pay run is created and the employees associated with the back payments are manually added to that adhoc pay run. In order to proceed, you must tick the I understand checkbox and then click Complete.

How does the platform pro-rata the hours owed for back pay?

As per above, we have discussed how the effective date is determined and how that effective date can be overridden. Because payroll is not always simple, there will be situations where an employee’s effective date does not fall on the start date of a historic pay run and instead is mid-way through such a pay run. In this scenario, the platform looks to pro-rata the hours that are owed back pay. This section will explain how the pro-rata of hours has been determined based on the different employee scenarios.

• Employees paid based on timesheets submitted: As timesheets are date-based and these dates are recorded in the pay run, when the platform looks to pro-rata back pay hours, it will assess timesheet earnings based on the date of such earnings. For eg, if the employee’s effective date was 4/1/23 and the pay run associated with that date had a pay period start of 2/1/23 to 8/1/23, the platform will pick up all timesheet earnings processed in that pay run from 4/1/23 onwards.
• Employees paid based on their advanced work pattern: Similarly to timesheet employees, employees paid based on advanced work hours are date-based in the pay run. As such, the same principle is applied as per timesheet employees. 

Employees paid based on their basic work pattern: For these employees, we follow the same pro-rata principles as in other methods used in the platform, which is explained in further detail in this article.

How does the platform pro-rata the hours owed for back pay?

As per above, we have discussed how the effective date is determined and how that effective date can be overridden. Because payroll is not always simple, there will be situations where an employee’s effective date does not fall on the start date of a historic pay run and instead is mid-way through such a pay run. In this scenario, the platform looks to pro-rata the hours that are owed back pay. This section will explain how the pro-rata of hours has been determined based on the different employee scenarios.

• Employees paid based on timesheets submitted: As timesheets are date-based and these dates are recorded in the pay run, when the platform looks to pro-rata back pay hours, it will assess timesheet earnings based on the date of such earnings. For eg, if the employee’s effective date was 4/1/23 and the pay run associated with that date had a pay period start of 2/1/23 to 8/1/23, the platform will pick up all timesheet earnings processed in that pay run from 4/1/23 onwards.
• Employees paid based on their advanced work pattern: Similarly to timesheet employees, employees paid based on advanced work hours are date-based in the pay run. As such, the same principle is applied as per timesheet employees. 

Employees paid based on their basic work pattern: For these employees, we follow the same pro-rata principles as in other methods used in the platform, which is explained in further detail in this article.

Step 3: Apply back payments in pay run

Once the back pay records from step 2 have been marked as completed, they will now be eligible to be processed in pay runs. As advised in step 2, users can either:

• Choose to wait to process the back payments in the normal pay run, whereby eligible back pay employees associated with that pay schedule will appear in the Back payment tab of that pay run; or
• Create an adhoc pay run and manually add the eligible back pay employees to that pay run whereby they will then appear in the Back payment tab of that pay run. 

When referencing the Back payment tab in the pay run, this relates to a new tab added alongside the existing pay run tabs, for example: 
Clicking on that tab will display a table of back pay records that have been marked as Complete in Step 2. An example of this table display is as follows:

The following is an explanation of the columns and activities that can be performed in this table:

Effective from and Amount: These values are populated from the records in step 2 and cannot be edited as the back pay amounts were marked as Complete.

Calculation method: Back payments are to be taxed as per the ATO requirements of taxing a lump sum payment. The taxation calculation method to be used can be either Method A or Method B. In this instance we cater for the Method B(ii) option. 

At this stage, users should determine what method they want to use and select that for each employee. If the same method is to be applied for each employee in the back payment table, then you can choose the method for the first employee and then click on downward facing arrow to copy the same method to all employees.

Special mention for Lump Sum E back payments: Refer to the Lump Sum E section of this article for further details on how pay periods are calculated.

Special mention for working holiday makers and seasonal workers: For any employee classified as either of these (which is configured in the Tax calculation options within the employee’s Tax File Declaration screen), take note that methods A and B do not apply to these employees. This is because they have their own special tax arrangements which include back payments. In this instance, you will notice that the calculation method is not configurable for these employees. Instead, a tooltip will appear in the calculation method column, as follows: 
When hovering over the tooltip, you will see either of the following messages:

Pay periods: When method B2 is selected the pay period column is ignored. When method A is selected, the platform will auto-calculate the number of pay periods based on the number of pay periods the back payment relates to. This starts from the pay period that includes the effective date up to the last pay period the employee was being paid the old rate. There is one exception to the rule though! This exception will be triggered when the back payment owing to the employee is classified as a Lump Sum E. This is further explained below.

Notes: You can choose to add a note that will apply to each back pay earnings line. This could simply be a record for the business or, if you have ticked Show line notes in the Pay Slips settings, this will also be displayed in the employee’s pay slip. Make sure to refer to the pay slip notes section of this article to see what employees will see on their pay slip. If you want to apply the same note to all employees, then add the note to the first employee and then click on the downward-facing arrow to copy the same note to all employees.

Bulk apply: Clicking on this button will bulk apply the back payments to the pay of the employee(s) whose checkbox (positioned to the left of the employee name) is selected. By default, all employees’ checkboxes will be selected.

Filter these employees: Clicking on this button will filter out all other employees, not subject to a back pay, that are in the pay run.

Actions: There are three options here in the dropdown, which will display based on where you are at with the back pay process). You can either:

• Apply the back payment in the pay run on an individual employee basis, i.e. Apply; or
• Choose to Mark as applied manually. Choosing this option will not apply the back payment into the employee’s pay, so you would select this option if some other back pay arrangement has already been processed or if the employee does not need to be paid the back payment. It also means that the employee will not appear in back pay search results (as per step 1) for the same pay increase.
• Choose to undo a back payment. This option will appear after you have applied the back payment. This action will be needed if you no longer want the employee to receive the back payment earnings and, as such, want to delete them from their pay.

Once you apply the back payments to the pay run, the employee(s) back pays will display in the Other Earnings section of their pay. The reason for this is that the platform applies 1 unit of back pay as opposed to x hours of back pay owed. As the employee has already been paid for the hours they have worked, we do not apply the number of back pay hours at the rate difference because this will over inflate leave accrued where leave is accrued on hours worked.

Back Payment earnings are linked to platform-generated pay categories specific to back payments. This is explained further in the pay categories section of this article. Once a back payment has been applied, the back payment earnings line cannot be deleted from the employee’s pay. Instead, you will need to navigate back to the Back payments tab in the pay run and click on Actions > Undo.

Refer to the pay slip notes section of this article for further details of what information is provided to the employee on their pay slip.

Additional information

Lump Sum E back payments