Pay runs

A pay run evaluates the Pay Items for some workers in the context of personal information (such as date of birth, tax reference and bank account number) and corporate information (such as company bank details) to produce outputs such as payslips, payroll financial and statistical summaries.

In traditional payroll systems, a pay run was a batch process run once at the end of a pay period. paiyroll® greatly expands upon this limited definition:

Scheduled pay runs:

Similar to the traditional batch process.

Custom pay runs:

Allow the schedule and the set of workers to be tailored.

Single-user pay runs:

Workers can initiate their own “single-user” payruns.

On-demand pay runs:

Workers can request an early withdrawal of any earnings to date.

Scheduled pay runs

The traditional batch process is still supported using Pay Schedules, but there is now a series of interim pay runs and a final approved pay run.

• An interim pay run is typically started near the beginning of a pay period, and produces a full set of pre-approval payslips and reports which identify missing data, provide financial insight (e.g. what is the estimated tax bill?), perform validation of interactions with third parties, and so on.

  • Missing data causes notifications to be sent to the people responsible for supplying the data (the notifications are escalated as needed).

  • The payslips and reports can be examined for review purposes.

• Further interim runs are performed as updates (e.g. commission figures, timesheet submissions or new hires) are incorporated, and the reviews continue until the process is deemed complete.

• Once deemed complete, the last pay run becomes the approved pay run. The results are frozen, and the post-approval results propagated to workers as payslips and third parties such as banks and tax authorities.

This approach greatly reduces the end-of-period pressure traditional systems invariably cause, and the opening of the review process reduces errors.

The entire process is automated and orchestrated using Workflows and Bots.

Custom pay runs

These extend the traditional process to allow the schedule and the set of workers to be tailored. These are still initiated centrally, but allow for exceptional - or simply unusual - patterns of remuneration. Target pay day, Pay period dates and Next Target Pay run dates are inherited from the schedule. while the Actual date is customised.

Examples of exceptional custom pay runs used between Scheduled pay runs might be:

• An employee is due to leave and a custom pay run is initiated to pay the employee on their last day.

• A worker has requested pay for a shift and a custom pay run is used prior to payment.

In addition, certain interactions with external agencies can only be done at the end of a pay period; these interactions must therefore be suppressed till a Scheduled pay run.

The iterative, automated approach applies here too.

On-demand pay runs

Workers can request an early withdrawal of any earnings to date. The requests are validated in accordance with an Universal OnDemandScheme. All such requests are handled using an On-demand pay run:

• This is like a Custom pay run except that only workers who have requested early withdrawals can be considered for inclusion.

• The amounts requested by each worker are listed for review, and if required, the list to be paid can be tailored.

Certain interactions with external agencies require that On-demand pay runs are followed by a Scheduled pay run which performs the interactions with the accumulated outcomes for the period.

Single-user pay runs

Workers can initiate their own “single-user” payruns. This is used to generate their predicted payslip, providing an up-to-the-moment (e.g. including a just-approved timesheet or holiday-sell) estimate of their expected pay including a complete tax and benefits calculation.

Approvals

Once a pay run is approved, all pre-approval reports are finalised, and any “live” post-approval interactions with third parties initiated, for example:

• tax submissions

• banking payments

• pension payments

This typically involves manual processes or automated processes (again using Workflows and Bots) which may take some time to complete. These processes must be allowed to complete before later pay runs are approved to ensure all state is updated as expected.

Note

Later interim pay runs can continue freely. However, the pre-approval results produced must be considered to be estimates till all post-approval processing for the approved pay run process completes.

Multiple pay runs

Any Custom or On-demand pay runs must be followed by a Scheduled pay run as described above. This gives rise to multiple pay runs in a given pay period. Each approved pay run must finish its processing before another interim pay run can proceed beyond approval.

A Company may also have multiple pay schedules to pay weekly and monthly workers, and there may even be individuals who are remunerated with a mix of weekly and monthly elements. Again, the principle is that a previously approved pay run must finish its processing before another interim pay run can proceed beyond approval.

Handling errors

Processing errors caused by incorrect data (e.g. an incorrect Salary amount on a worker, or an invalid password for exchanging data with a third party) are routinely handled using the interim pay run concept: simply correct the data and Redo it as described above.

Hint

An overpayment or underpayment to a worker can often be corrected by adding a one-off Deduction and Deduction (negative) or Payment and Payment with offset to them for the next pay run. You may need to review the busses defined on the Pay Definition, and if needed, create a specialised variant with the busses adjusted as needed (e.g. to create a payment net of tax).

However, errors can also occur after a pay run is approved when:

• Incorrect data is noticed. See Rewinding a Pay Run for possible options.

• Post-approval data is being exchanged with third parties. The rest of this section describe possible options.

Normally this part of the pay run works like this:

Pay run BPMN, post-approval

Notice that all the reports are submitted in parallel and each report takes a different amount of time ranging from seconds to hours, or more. So each time round:

1. The pay run waits for a few minutes while checking if all the reports are “Done?”.

2. If all the reports are “Done?”, the pay run is finalised. This causes any state changes to be made permanent, and so allows subsequent pay rus to be approved.

3. If all the reports are not “Done?”, then the administrator must elect whether to Resume? waiting for the remaining reports to progress, or to redo the pay run with changes as needed.

The dialog for Resume? displays which reports:

• Are still running.

• Have completed successfully.

• Have completed with an error.

(For reference, the Reports tab on My dashboards or View ‣ Reports on Pay runs shows similar information statically).

Depending on the delay involved, or nature of the error shown in the results or logs, it may be necessary to retry the submission or to abandon it - possibly temporarily - in order to allow the pay run to be finalised. This part of the report submission works like this:

Report submission BPMN, exception handling

The following sections describe procedures for handling errors, along with example scenarios when they might be used.

Note

When using these procedures to handle errors in one report, avoid making changes which would invalidate other reports which have already completed successfully.

Example scenarios

A report failed…	Error handling procedure
…to send data to a third party because their service had an outage.	Retrying a report, unchanged pay run.
…to send data to a third party because an incorrect account number was configured in paiyroll®.	Retrying a report, changed pay run.
…to send data to a third party because an incorrect account number was configured at the third party. This will take time to resolve, but there is a pressing need to progress the next pay run.	Abandoning a report, temporarily.
…but it must be handled outside paiyroll®.	Abandoning a report, permanently.

Retrying a report, unchanged pay run

If a report is retried, it is regenerated from the unchanged pay run, and the submission attempted again.

Procedure:

1. Wait for the reason for the failure to be addressed.

2. Retry the failing report by accepting the Report submission’s Handle exception option to Resume?.

Retrying a report, changed pay run

If changes are required, the pay run must be redone. Then, when the report is retried, it is regenerated from scratch, and the submission attempted again.

Procedure:

1. Skip the failing report by declining the Report submission’s Handle exception option to Resume?.

2. Make the needed corrections.

3. Do the pay run again by declining the Pay Run’s Resume submission option to Resume?. The pay run will be repeated from scratch, and once approved, all reports will be re-run.

Abandoning a report, temporarily

An earlier pay run for a given Pay Schedule must be finished before a later pay run for the same Pay Schedule can start. Sometimes, it may be necessary to allow a later pay run to progress while a temporary issue with a report from an earlier pay run is resolved.

Procedure:

1. Temporarily abandon the failing report by declining the Report submission’s Handle exception option to Resume?.

2. Allow the earlier pay run to be finalised by accepting the Pay Run’s Resume submission option to Resume?. This will allow the later pay run to progress; this will be an interim pay run.

3. Once the issue is resolved, contact your CSR to restore the failing report.

4. Once the report is restored, the later pay run must perform another interim run to incorporate the results of the restored report.

   Note

   The report must be restored successfully before the later pay run can be finalised.

Abandoning a report, permanently

A report can be abandoned when it reaches the Handle exception state. However, many reports have effects on external systems which must be tracked by paiyroll® so that subsequent pay runs operate as expected.

Warning

Therefore, this procedure is generally not recommended. Contact your CSR if you think it is needed.

1. Abandon the failing report when it reaches the Handle exception state by declining the Report submission’s option to Resume?.

2. The abandoned report will not have had the intended effect on the third party involved, but a finalised pay run would still refer to it. So, the report submission must be deleted before the pay run is allowed to finalise. Contact your CSR for assistance.

   Note

   The net effect is that the previous state of the report will be taken forward.

3. Allow the earlier pay run to be finalised by accepting the Pay Run’s option to Resume?.