FPS First Submission and Resubmission to HMRC

HMRC only allows normal FPS submissions within a certain time frame.

Before you go-live or during a parallel run, as a best practice, you should always produce a Live FPS file for each payroll run, but not submit it to HMRC as a Live submission.

This will ensure that your first Live FPS won't have the issue of finding previous actions that have not had a Live FPS produced for them.

Additionally, before go-live you should set the parameter Report HMRC Payroll ID Migration Change to No (the default is Yes). This ensures that when the parameter is set to Yes for the first Live FPS to be submitted to HMRC, all previous HMRC Payroll IDs are submitted in the FPS file. Once they are produced in the file, they aren't reported again.

The default being Yes means that after go-live, any later employee additions will automatically have their Previous HMRC Payroll ID data included.

Note: Any voluntary deductions are reported in field 58B (Deductions from Net Pay). This would also apply where a refund is given. You don't need to send the FPS record if there are no values to report apart from refund of a deduction processed and reported in 58B, even though a BACS payment will be generated.

FPS and Gross Earnings for NICs in This Period

In accordance with HMRC rules, Gross Earnings for NICs will:

• Exclude earnings below the LEL, where the LEL is not reached.
• Include earnings above the AUEL.

Although they aren't in the FPS XML file, the AUEL PTD and TYTD amounts are reported in the FPS Audit report. The Gross earnings for NICs in this period are calculated as the sum of these:

Earnings below the LEL (where the LEL is reached) + PT + UEL + AUEL

Note: You need to initialize the AUEL balance by category.

FPS and Assignment Updates to a New TRU with Retro Changes to the Original TRU

By default, retro entries are created against the same HMRC Payroll ID and TRU that they were originally processed with.

However, if the original card and component are now end dated and not available as at the current period containing the retro entries, the FPS process will fail, as it cannot process against the now unavailable card.

Therefore, the best practice recommended here is not to end date the original statutory deduction card or components, so that retro payment can be processed successfully. If a TRU is disused, or if the employee’s employment has ended with no possibility of a late payment against the original TRU, it is reasonable to end date the cards and components.

However, if you have changed the HMRC Payroll ID for an assignment, and ended the old Statutory Deduction card and components, you still have the option to process all retro earnings on the new HMRC Payroll ID the assignment is currently linked to. To do this, run the payroll with a process configuration group, setting the parameter TRU Rule for Retro Entries to No.

Note: This will affect retro processing of all employees and assignments in that payroll run. The FPS will then report only the new HMRC Payroll ID that is still active. For additional information, see Changing to a Different PAYE Reference in this document.