Managing Overtime and Additional Hours in NHS ESR: The Workflow Mistakes That Quietly Inflate Payroll

Overtime in a Trust looks like a payroll line item. It isn't. It is the downstream result of a workflow that starts in a roster, passes through several approvers, lands as an element entry in ESR, and shows up in a payslip three to six weeks later. By the time the number is wrong, the people who could have caught it have already moved on to the next pay cycle.

NHS ESR overtime management is one of the most consistently under-monitored workflows in Trust operations. On paper, it looks settled. Agenda for Change is clear about rates. The 2016 medical contract is documented. ESR has the right element types. Rostering systems have approval routes. And yet, in most Trusts, the gap between hours rostered, hours claimed, and hours paid is wider than anyone wants to admit.

This piece is for the Head of Digital, integration architect, or workforce systems lead who keeps getting asked why the overtime spend looks the way it does, and wants a real answer rather than a guess.

The conversation that shouldn't keep happening

Finance opens the month-end pack. The overtime line is materially higher than last month, and last month was already higher than the same period last year. Nobody has a clean explanation. The Director of Finance asks the Director of Workforce. Workforce asks operational managers. Operational managers say they approved what they were rostered to approve. Rostering says the hours came through correctly. Payroll says they processed what came in from ESR. The question lands, again, with IT and integration.

By the time the trail is followed, three things are usually true. A handful of retrospective claims from two months ago landed in this period rather than the period they belonged to. A part-time cohort had additional hours flowing through as overtime, because the element selection logic in the feed wasn't checking contracted hours against worked hours correctly. And a ward that ran short for ten consecutive shifts in March only filed its enhancement claims in May.

None of this is a payroll error. It is a workflow error, and it is the same shape of error that shows up in every healthcare integration where multiple systems share responsibility for one operational truth.

Overtime and additional hours are not the same thing

The first place NHS ESR overtime management goes wrong is conceptually, before any system gets involved.

For Agenda for Change staff, hours worked above the contracted figure but at or below whole-time equivalent are additional standard hours, paid at plain time (subject to the usual exceptions for unsocial hours and bank holidays). Hours worked above whole-time equivalent are overtime, paid at the enhanced rate set by national policy. The distinction matters because the rate is different, the ESR element is different, and the cost coding is different.

For medical and dental staff on the 2016 contract, the rules are different again, with their own definitions of additional hours, non-resident on-call, and enhanced rates tied to work schedules and rota patterns.

A workflow that does not make this distinction at the point of data capture is a workflow that will produce wrong figures downstream. Most do not make it cleanly. Element selection often happens in the integration layer, based on assumptions about contracted hours that may not be current.

Where the workflow actually breaks

Mapped end to end, the break points are predictable.

The point of capture. Hours are entered in the rostering system, often by a ward manager or shift coordinator at the end of a period. If the category entered (overtime, additional hours, bank, agency cover) is wrong here, every downstream system inherits the error.

The approval chain. Approvals often run in parallel rather than serial. The rota approver signs off the shift, the budget holder signs off the spend, and neither sees what the other approved. Discrepancies surface in payroll rather than in approval.

The element selection. When the file lands in ESR, an element has to be chosen. If element selection is rule-based on contracted hours, and contracted hours in ESR are stale (a recent contract change has not yet propagated), the element is wrong even though the rules are right.

The cut-off. Each payroll cycle has a cut-off date. Claims after cut-off carry into the next period. Retrospective claims from earlier periods carry forward to wherever they finally land. The result is that the overtime figure for any given month is rarely the overtime worked in that month.

The enhancement layer. Unsocial hours, night shifts, weekend, and bank holiday enhancements interact with the base overtime calculation. If the rostering system applies enhancements before sending to ESR, and ESR also applies enhancements based on the element used, the staff member is paid twice or paid once depending on which way the integration was configured.

Each of these has a fix at the workflow level. None of them has a fix at the payroll level, because by the time it reaches payroll, the data is already wrong.

Six places NHS ESR overtime management drifts

1. Misclassification at the part-time boundary. A part-time clinician picks up extra shifts that take them to whole-time equivalent in a given week. Below WTE, those hours are additional standard hours. Above, they are overtime. If the workflow does not recalculate the boundary per pay period for that individual, the wrong element is selected and the rate paid is wrong.

2. Retrospective claims with no period anchor. A claim submitted in May for hours worked in March should be costed and reported against March, not May. Most workflows post the claim to the period it lands in, which inflates the current month and hides the original underspend reporting. The audit trail still says May, but the operational reality was March.

3. Approval in parallel rather than serial. When the rota approver and the budget approver act independently, neither has the full picture. The result is that overtime which breached a budget threshold gets approved at the rota level because the budget impact was not visible at that step.

4. Enhancements applied twice (or not at all). Where unsocial hours, weekend, or bank holiday uplifts are calculated in both the rostering system and ESR, the result depends on the order of operations in the feed. Trusts often discover this only when a staff group raises a query about a payslip.

5. Cost centre drift. Overtime worked covering a different department or specialty should be coded to that cost centre, not the home cost centre of the staff member. The element entry in ESR has the right cost centre field. The workflow often does not populate it from the rostering reason code, so the spend lands against the wrong budget line.

6. No reconciliation between rostered, claimed, and paid hours. At the end of each pay cycle, rostered hours, claimed and approved hours, and paid hours should be the same number per staff member, per category, per period. In most Trusts, nobody runs that comparison until a variance forces it. Building it as a scheduled workflow that flags variance before pay run is the single highest-value control most workforce systems leads can put in place.

What good looks like: the workflow pattern that holds up

The Trusts that have stopped having the finance conversation at the top of this piece tend to share four properties in how their overtime workflow is designed.

They define a single source of truth for actual hours worked, separate from the source of truth for entitlement and contracted hours. The rostering system owns what happened. ESR owns what the person was contracted to do. The workflow is responsible for reconciling the two, not for picking a winner.

They centralise the element selection logic, so the rule that decides "is this overtime or additional hours?" lives in one place, is testable, and can be updated without touching the rostering or payroll systems individually.

They run approval in serial, not parallel, with the budget impact visible at the operational sign-off step. The budget holder sees what they are signing off in the context of the period budget, not as an isolated transaction.

They run a scheduled reconciliation before each pay cut-off. The output is a variance report by staff group, by ward or service line, by element type, ranked by absolute variance. It does not fix anything automatically. It surfaces the disagreements while there is still time to resolve them.

This is the pattern WeHub's workflow designer was built for, but the pattern matters more than the tool. Any Trust running a serious workforce integration should be able to point to all four of these properties in their architecture.

The bottom line

Overtime is not the most strategic spend line in your Trust. It is the one that exposes workflow weakness most reliably, because the cost is real, the cause is distributed, and the people who could explain it work in three different teams.

If the finance conversation at the top of this piece happens in your Trust more than once a quarter, the fix is not tighter budget approval. It is a reconciliation workflow between rostering, ESR, and payroll that runs before each pay cycle and surfaces variance before it becomes a payslip dispute or a finance question with no clean answer.

Start with one element type, one staff group, one pay period. Get the reconciliation working there before extending. The same pattern, once it holds for overtime, is the one that holds for every other workforce data flow where rostering and ESR share responsibility for the truth.