Produce payslips, pay employees and send FPS

Produce payslips from the approved version

Bind every payslip to the run ID, version and approval snapshot from Lesson 8. Gross pay, total employee deductions and net pay must agree with the approved employment result. Do not regenerate a payslip from an unapproved draft or silently change its values after payroll approval.

Employers must provide payslips on or before payday. They must show earnings before and after deductions and deductions that can change each pay period. Where pay varies according to time worked, include the hours for which variable pay is being made. Read the current GOV.UK payslip guidance.

Store time exactly

Keep variable time in integer minutes rather than floating-point hours. A 390-minute line can display as 6.5 hours while retaining an exact calculation source. Include the relevant rate or pay line where it helps the employee understand the result. Do not imply that every salaried employee must receive a universal fixed-hours line when pay did not vary according to time worked.

Explain fixed deductions correctly

A fixed deduction can be explained on the payslip or through a separate written statement given before the first relevant payslip and updated at least annually. Retain the statement reference, issue date and next review date. A generic unexplained “adjustment” is not a dependable audit trail.

Printed and electronic delivery

Printed payslips are valid and need appropriate production and handover evidence. Electronic payslips can use a secure portal or suitably protected electronic method. A verified ordinary email address does not automatically make an unprotected attachment secure. Record the selected delivery method and evidence appropriate to it.

Reconcile the payment instructions

The payment population and total must agree with the approved Lesson 8 net-pay results. Each instruction carries the employment ID, payroll-result reference, amount, verified payment-destination reference, normal payday, bank release date and expected funds date.

Separate preparation and authorisation where staffing permits. This is a recommended fraud and error control. A one-person employer can record an explicit self-review against the approved payroll total.

Release is not payment confirmation

Uploading a payment file or receiving a bank acknowledgement means the instruction was released or accepted for processing. It does not prove that funds reached the employee. Track prepared, authorised, released, confirmed, failed, cancelled and reissued states separately.

A changed destination requires fresh independent verification. Do not rely on the message that requested the change as its own verification.

Control reissues

Do not reissue merely because a bank status is delayed. The original must be confirmed failed, cancelled or recalled, with evidence. The replacement references the original and preserves the same approved payroll-result reference and amount. A changed amount requires another approved payroll version or a separately controlled correction.

If the original and replacement both succeed, raise a blocking duplicate-payment exception. A failed payment may also affect the actual-payment and FPS analysis, so review the dates before reissuing rather than assuming payroll reporting remains unchanged.

How to submit an FPS to HMRC

Begin with Lesson 8’s controlled population, then make a reportability decision for every employment. One person can hold two employments within the same PAYE scheme; keep the employments distinct and use unique payroll IDs.

Lesson 8 population
→ inclusion or exclusion decision for each employment
→ FPS-reportable employment population

An expected zero-pay, held or excluded record is not automatically included in FPS. Equally, it must not disappear without a recorded decision. An included employment needs an inclusion reason and approved output reference. An excluded employment needs an exclusion reason. Duplicate employment IDs or included payroll IDs block preparation.

Reconcile current and year-to-date fields

Check more than payday totals. For every included employment, reconcile current taxable pay and tax; current National Insurance earnings and contributions; year-to-date taxable pay and tax; year-to-date NI earnings and contributions; student and postgraduate loans; pension fields; statutory-payment year-to-date values; starter and leaver indicators; payroll-ID changes; irregular-payment indicator; payment frequency and earnings periods covered.

Use maintained employee outputs and prior accepted reporting history. Do not manually recreate statutory calculations. HMRC lists the payroll information reported through FPS.

Check employer identifiers

Verify both the employer PAYE reference and Accounts Office reference in the FPS employer data. Lesson 10 owns turning the Accounts Office reference into the correct HMRC payment reference and allocation; Lesson 9 verifies that the maintained employer identifier is present in the report.

Coordinate the payday dates

Keep four dates distinct: normal contractual payday, bank release date, expected funds date and FPS payment date. Payroll calculation date is not automatically the FPS payment date.

Where normal payday falls on a non-banking day and employees are paid on the last working day before it, report the normal contractual payday in the FPS payment-date field. Other supported non-banking-day and exceptional situations must follow current HMRC guidance and retain the relevant evidence.

Submit on or before payday

FPS is normally due on or before payday. Specific reporting exceptions have their own timing rules. A late-reporting reason describes what actually happened; it is not a general permission to file late or a way to hide an operational delay. Use HMRC’s late-FPS guidance beside any exception decision.

Before sending, bind the payload to the approved run version, employment-population hash and employee-output hash. Reconcile the employment count, payment date, current and year-to-date values, employer PAYE reference and Accounts Office reference.

Read the response in four stages

1. The software connection succeeded.
2. HMRC received the submission.
3. HMRC accepted or rejected it, possibly with warnings.
4. The employer remains responsible for factual and legal correctness.

Keep response status separate from warnings. An accepted FPS with a warning remains accepted, but the warning must remain visible and receive an owner. Technical acceptance is not statutory verification.

Rejected attempts remain immutable. Correct the underlying reporting issue and link the next attempt to the rejected one. Do not repeatedly submit an unchanged payload unless the response and retry reason support that action.

Review Riverside’s payday board

The board deliberately shows one released payment that is not yet confirmed and one accepted FPS warning. Neither is hidden by another green status. The fictional scenario is complete only after required controls pass; Academy lesson completion remains learner-confirmed, and neither state proves that a real payroll completed.

Retain the approved Lesson 8 reference, payslip artifacts and delivery evidence, payment instructions and outcomes, FPS inclusion decisions, current and year-to-date reconciliation, payload hashes, submission attempts, HMRC responses and payday exception decisions.

An accepted FPS and confirmed employee payments do not mean HMRC has been reconciled or paid. Lesson 10 will decide whether EPS is needed, reconcile the employer liability and HMRC account, construct the applicable payment reference and record HMRC settlement.

Three key takeaways

1. Payslips, employee payments and FPS are separate outputs bound to one approved payroll version.
2. Derive FPS population by employment and reconcile both current and year-to-date values.
3. Bank release is not payment confirmation, and HMRC acceptance is not proof that every value was correct.

What comes next

Continue to Lesson 10, Send EPS, reconcile and pay HMRC, for employer-level reporting, liability comparison, payment references and settlement.