These figures are estimates. Shyftr works them out from the shift and pay rate information in the system. Shyftr isn't a certified payroll processor and doesn't work out PAYE, National Insurance or pensions. A qualified payroll professional or accountant must check every pay run before anyone is paid.
The model in one paragraph
Pay runs pay scheduled hours for the whole period, including shifts not yet worked. Changes after export are recovered in the next run. A pay run takes every shift in its period that has an employee and hasn't been paid before, and pays it at its scheduled hours and locked rate, whether or not it has happened yet and whether or not you've approved it. Holiday days inside the period are added at the holiday's rate. When you finalise the run, those shifts are marked as paid. If a paid shift later changes, the difference is taken back (or added) in the next pay run as an adjustment, so nothing has to be reopened.
What a run includes
For each employee whose pay frequency matches the run:
- Field and fixed hourly staff: every shift starting in the period, at scheduled hours × the shift's rate. Paid sick and paid holiday absences are paid as normal shifts. Unpaid absences are counted but not paid.
- Salaried staff: the fixed amount for the period (annual salary ÷ 12, 26 or 52). Their holiday hours are shown for information only.
- Holiday: the approved holiday days that fall inside the period, at the rate saved when the holiday was approved (see How holiday hours are calculated).
A shift with no pay rate goes in at £0 and is listed in a warning on the run so you can fix it and recreate the run, or add a manual adjustment.
What approval is for
Payroll → Approvals lists completed shifts that nobody has reviewed yet: shifts that have been clocked out, shifts that ended and never needed a clock-in, absences, and shifts that were clocked out but never clocked in (shown in red at the top, with a choice of Approve as worked or Mark absent, and listed there even if someone has already approved them). Approving is how you record that you've checked the shift. It doesn't decide whether the shift is paid: the run pays it either way. Approvals is the place to catch a shift that shouldn't be paid as scheduled, so mark it absent or change its hours there, before or after the run.
The draft run shows three counts so you can see what hasn't been checked: shifts not yet approved, shifts scheduled but not yet worked, and shifts with no clock-in recorded. All of them are in the run.
Changes after a run is finalised
Once a run is finalised its shifts are paid. You can still change them on the rota, and Shyftr records what has to be put right in the next run:
| What you do to a paid shift | What the next run does |
|---|---|
| Mark it Absent (Unpaid) | Claws back the whole shift from the employee |
| Clear the employee, or give the shift to someone else | Claws back the whole shift from the employee who was paid |
| Approve a holiday that frees the shift | Claws back the shift, and pays the holiday for that day instead |
| Give the shift to a different employee | Claws back the whole shift from the employee who was paid, and pays the new employee for it (Cover: …) |
| Shorten it | Claws back the hours removed (shorten it again and only the further difference is taken) |
| Lengthen it | Pays the hours added (Top-up: Hours added (6h → 10h) …) |
| Try to delete it | Refused: This shift has been paid. Mark it absent or unassign it instead. |
Each adjustment appears on the next run as a line like Clawback: Unassigned 12 Nov 2026 at Granite House Offices (8h), against the employee who was paid, at the rate the shift was paid at; a cover or top-up is a positive line for the employee who is owed. The pay run page lists them under the line items with the employee's name, and the export carries them in the Adjustments column.
While a run is still a draft, nothing has been settled: you can delete the draft and the shifts it adjusted go back to waiting, so the next run you create picks them up again with the same amounts. Finalising the run is what commits them. After that the shift's paid record is updated to what has now been paid (the new employee, the new hours), so a later change is measured from there.
One thing Shyftr can't do: a shift that was paid before 21 Oct 2026 and then unassigned has no record of who was paid. The run lists it in a warning so payroll can add the adjustment by hand.
Manual adjustments
While a run is a draft, anyone who can edit payroll can add an addition or a deduction for an employee: a bonus, an expense, an agreed correction, or the pay for a shift the warning above says Shyftr can't attribute. Open the run and click Add adjustment under the Adjustments heading, choose the employee (they don't have to be on the run: they get a £0 line to carry it), the type, the amount and a description. The description is required, because it's what payroll sees.
- The adjustment shows under the employee's line, in the Adjustments table with a Manual badge, in the Adjustments total and in the Net Total.
- You can edit or delete it for as long as the run is a draft. Once the run is finalised it's locked, like everything else on the run.
- If you delete the draft and create it again for the same period, the manual adjustments come back onto the new run. Only the clawbacks and other adjustments Shyftr works out itself are recalculated.
- The export carries each adjustment's amount in the Adjustments column and its description, with the sign, in Notes.
Holiday approved or cancelled after the run
- Approved after the run was finalised: the holiday day wasn't in the run, so the next run pays it as an adjustment (Holiday pay: 12 Nov 2026, approved after its pay run (8h)). Any paid shift the holiday freed is clawed back at the same time.
- Cancelled after the run was finalised: the holiday pay was already paid. Shyftr creates a payroll alert asking for a manual adjustment, and gives the freed shifts back to the employee. If one of those shifts had already been clawed back, a second alert says so, because the employee is now owed for it again.
Holiday pay settings
Payroll → Overview has a Holiday pay settings card next to the pay period. Anyone who can edit payroll can change it.
- Bank holiday region: England and Wales, Scotland or Northern Ireland. It decides which bank holidays attract the bank holiday premium, in the rate locked on new shifts, in the holiday pay rate and in the pay run's day types. Shifts already on the schedule keep the rate they were given when they were created.
- Count paid holiday weeks in the 52-week average: off is the usual choice for staff with normal hours; on may apply to zero-hours contracts. It changes the average behind holiday hours, holiday pay rates and entitlement; see How holiday hours are calculated. Ask your payroll adviser.
Common questions
A shift on the run hasn't happened yet. Why is it being paid? Because the run pays the period's schedule. If the shift isn't worked, mark it absent or unassign it, and the next run takes the pay back. If you'd rather not pay in advance, create the run after the period has ended.
Why can't I delete a shift? It has been paid in a finalised run. Deleting it would lose the record the clawback needs. Mark it absent (unpaid) or clear the employee instead; either way the next run recovers the pay.
I approved a shift by mistake. Does un-approving it stop the pay? No. Approval is a review mark. To stop the pay, mark the shift absent or change its hours.
Do I still need payroll to check the figures? Yes. Every figure here is an estimate from the rota. A qualified payroll professional or accountant must check each run before anyone is paid.