Monday morning in a payroll bureau
You look after a mix of clients. Some pay weekly on a Friday, some fortnightly, a few four-weekly, most monthly, on the last working day, the 25th, the 28th or the last Friday. Each has a cut-off for sending changes, a date the payroll must be approved, and a date the money has to leave.
The master list is a spreadsheet or a wall planner. Someone updates it every year and patches it when a client changes their pay date. When a bank holiday falls awkwardly, somebody has to spot which runs it moves, and the whole team crosses its fingers.
Why the calendar is fragile
Pay dates are rules, not dates: last working day of the month, every other Friday, the Thursday before if Friday is a bank holiday. A spreadsheet stores the results of those rules, typed in by hand, so every change of rule or unusual holiday means retyping. Four-weekly and fortnightly cycles drift against calendar months, which makes them easy to get wrong in a monthly view.
The calendar also shows dates but not progress. Whether a run's data has arrived, whether it has been processed, approved and submitted, is tracked somewhere else, if at all.
What a missed or late run costs
A late payroll is the one mistake a bureau cannot afford: employees not paid on time, a furious client, and possibly lost business. Near misses are almost as damaging, because they mean overtime, stress and rushed checking. Workload also bunches invisibly around month end, so the team is overloaded on the same days every month without anyone planning for it.
| Pay rule | Where it catches people out |
|---|---|
| Last working day of the month | Bank holidays and weekends |
| Every other Friday | Drifts against monthly views |
| Four-weekly | Thirteen periods in a year |
| Fixed date, e.g. the 25th | Falls on a weekend |
| Pay date moved by the client | Old dates stay in the spreadsheet |
How we build a live pay run calendar
- We record each client's pay rules as rules, not dates: frequency, pay day, what happens on weekends and bank holidays, cut-off for changes, approval deadline and funding date.
- The calendar generates every run for the year ahead from those rules and the published UK bank holidays, including the right number of periods for weekly, fortnightly and four-weekly clients.
- Each run is assigned to an administrator and a checker, from a default per client that can be changed for holidays.
- Stages are tracked per run: changes received, processed, sent for approval, approved, funded, submitted. Where your payroll software, such as BrightPay, IRIS or Sage, exposes status through an API or export, stages update from it.
- A daily view shows each person the runs they need to move today and anything overdue for its stage, and a manager view shows the week ahead across the bureau.
- When a client changes their pay date, the rule is updated once and every future run moves, with a note of the change.
The calendar does not run payroll. It tells your team what is due, when, and where each run is up to.
A bureau that can see its week
Nobody maintains the wall planner. Bank holidays are handled by the rules, not by someone remembering. Each administrator starts the day with their own list. Managers see pile-ups coming weeks ahead and can move work. And the question 'has client X been done?' is answered by looking, not by interrupting someone mid-run.
Is your pay calendar a risk?
- Pay dates are kept in a spreadsheet or on a planner.
- Bank holidays mean someone checking every client by hand.
- Four-weekly or fortnightly clients have caused near misses.
- You find out a run's status by asking the person doing it.
- The same few days every month are overloaded.