FAQ

Universal

How do leavers access the app and their pay documents?

Leavers have access to the app and My documents for 31 days after their last pay run.

See also leavers for details including allowing access temporarily and following payments after end, and so on.

Existing employee flag

The Existing employee flag is used in the first pay run of employment for three purposes:

1. To calculate pro-rata salary from the employee’s start date

2. To initialise employment history and generate a new starter for external systems (government, pension etc.)

3. To control when Pay Item state is automatically reset

Clear: The Existing employee flag is normally Clear (False) for a new employee or restarter – this will be the usual case. Salary will be pro-rated from their start date and a new starter generated. All Pay Items will auto reset.

Ticked: The Existing employee flag should only be Ticked (True) if the employee was previously paid/reported with an existing payroll system or when switching companies. In this case, salary will not be prorated from their start date and a new starter is not generated. The employee is an “existing employee” in their first pay-run and Pension, Holiday and Average Earnings will not auto reset - but all other Pay Items will be reset.

If you need to generate a new starter, but the employee has a start date that is more than 1 period before the pay run date, you will not be able to use the Annual Salary Pay Template on their first pay run. This is because it will attempt to pro-rate salary and this is likely to be incorrect. You should handle salary in the first pay run with a one-off payment and then add the Annual Salary Pay Template in their second pay run.

New employees can be added in four ways: HR Data Feed, Employee Add…, Upload and Import. Import is a special case where employments have already been set as if there had been a ‘prior’ payrun - therefore existing employee is not set.

In summary, the existing employee flag is set as follows:

1. When adding a new employee, the admin must set the flag appropriately.

2. If uploading from the CSV data feed, the admin must set the flag appropriately.

3. If uploading an employee CSV, the admin must set the flag appropriately.

4. If employees are imported from a GB FPS, the flag will not be set.

5. If importing from a GB Sage50 (CSV), this value is not set. In very unusual circumstances, that value may be incorrect if the employee was never paid and should be changed.

6. HR Data-feeds set the flag to False. When HR Data-feeds are used to complete an FPS/Sage50 Import (even on the first payrun) the existing employee flag will not be set. Unusually during a parallel run, there may be situations where the flag may need to be set.

After the first or next payrun, the Existing employee flag is cleared.

Changing holiday year

When using the Universal Holiday Pay Template and associated scheme, the holiday year is defined by the scheme’s reset date. When changing the holiday year reset date, care must be taken to account for the overlap:

For example, if the old holiday year starts 1st April, and the new holiday year starts 1st January, there will be an overlap of 3 months. paiyroll® has already recorded any bookings made and entitlement earned between the 1st January and 1st April, and when the reset date is changed, they will be counted again, so each affected employee’s Holiday Pay Item must be adjusted to account for this.

To change holiday year, after the last pay run for the old holiday year, you will need to work out 3 values for each employee:

1. Any carry-forward days you wish to use from the old to new holiday year, e.g. 1.

2. The total number of booked days in the overlap period, e.g. 9.

3. The total entitlement in the overlap period, e.g. 7.

Once you have these three figures you can produce a Holiday Pay Item upload file where the ‘Migrated Balance` is set to (1) + (2) – (3). With the example figures above:

Migrated Balance = 1 day carry forward + 9 days bookings - 7 days entitlement
Migrated Balance = 1 + 9 - 7
Migrated Balance = 3

Uploading the new Holiday Pay Item file will correctly set paiyroll® up for the new holiday year.

How do permissions work?

paiyroll® checks permissions using the following steps:

1. Authentication. Most access requires users to be logged in. A logged-in user will either be an Employee or an Administrator. Depending on context, Employees may have the role of:

   • An employee working on their own behalf.

   • A manager of a Department to which other employees can belong.

   Each Administrator is assigned roles with names like Payroll Approver and HR Administrator. You can view the available roles and who has them. These settings can be changed (subject to permission!).

2. Role-Based Access Control (RBAC). The first level of permission checking is based on the roles that a logged-in user has, the type of object being accessed, and the kind of action being attempted.

   Examples of types of object are Company, Employee and Pay Run. The kinds of actions are:

   Create (C):

   For example, adding a new Employee.

   Read (R):

   For example, viewing a list of Companies.

   Update (U):

   For example, updating the address of a Company.

   Delete (D):

   For example, deleting a Pay Definition.

   Upload (+):

   For example, uploading Employees from a CSV file.

   You can view a summary of the RBAC settings. These settings cannot be changed.

3. Object-level access control. After RBAC, a second level of permission checking is based on the user’s identity and the object’s identity. For example, an Employee can Create, Read and Update their own Holiday booking but must not be able to look at those of another Employee.

   In addition to the identity-based checks, permissions may be further restricted based on object state. For example:

   • Once a Timesheet has been approved and then processed in a Pay Run, it cannot be deleted.

   • Once approved, no Administrator can delete a Pay Run.

4. Task-based access control. After object-level access control on workflows, each task in a workflow requires a third level of permission checking also based on role. For example, only an Administrator with role Payroll Approver can approve a Pay Run.

   You can view which role can perform which task by looking at the annotation on the Swim Lane containing the task on the BPMN diagram for the workflow.

Re-employing workers

If you re-employ anyone, follow the administrative tasks for returning workers.

Where are the payroll reports for my accountant?

You should provide your accountant with the Journal sheet from each Pre-approval summary2 report which can be found in My documents.

Why does a Net payment appear in the Gross payslip section?

The default payslip shows any pay items that contribute to Gross pay in the Gross pay section. If you want them to appear in the Net section, simply un-tick .Gross pay in the Pay Definition.

GB-specific

HMRC DPS Data Feed Errors

We do see a fair number of retrieve errors from the HMRC DPS service. The error can occur in the prepare stage when we attempt to obtain a token or in the operate stage when data is retreived. These errors will apear as follows:

Fault error in "sequence_prepare" : Request failed. Reason unknown. Incident Reference: ABCDEFGX45B94ERZ

error in "sequence_operate" "P6:retrieve": Unknown fault occured

In all cases, you will need to re-run DPS by clicking Start in My data feeds .

Paid irregularly

If an employee is not paid for a period (e.g. 3-months or 3 pay cycles), HMRC will automatically cease their employee record, effectively making the employee a leaver. If you have employees that may be affected, then set the Paid irregularly option in Update Employee. This will send the Irregular Employment indicator to HMRC and stop the automatic cessation.

More information

Small Employers Relief

• See the Small Employer’s Relief guidance for the NIC-based rules on getting additional recovery for statutory benefits such as SMP, SPP, SSP etc.

GB Late reporting

You can use one of the late reporting reasons if you need to report late. For example if you have a reasonable excuse, the you would use G. Please follow these steps:

1. Update the GB RTI FPS Report Definition and add the late reporting reason to the report as below and click Update.

2. Then you must Redo the payrun to include this code.

3. Then Approve the pay run and the late reporting reason will be sent to HMRC.

4. After approval, ensure you remove the late reporting reason from the GB RTI FPS report definition and click Update the in preparation for the next submission.

Correcting a GB Attachment of Earnings (deduction order)

For GB Attachment of Earnings and Student Loans (Garnishes), paiyroll® uses a combination of the Debt reference string and Debt amount value to recognise if it’s continuing to process the same debt or a new one. So, errors in deduction orders can be corrected by changing the reference and/or the amount.

For example, if you change the reference number by adding a “/1” at the end it will be interpreted as a completely new debt order and start processing with all initial values. In this case you should carefully check the debt amount is the correct new one for a new order.