Every client segment this series has covered runs on its own compliance calendar: CIS contractors file monthly, landlords file quarterly under Making Tax Digital, limited companies file annually, charities file to a public register. A payroll bureau running standard PAYE for employer clients doesn't have one calendar. It has four, running at the same time, for every single client on the book, and none of them wait for the others to clear.
Cycle One: Every Payday, Not Every Month
Real Time Information (RTI) means a Full Payment Submission (FPS) has to reach HMRC on or before the day employees are actually paid, not on a monthly filing date a bureau can plan around. If one employer client pays weekly, another fortnightly, and a third monthly, the bureau isn't working to one payroll deadline a month, it's working to however many distinct paydays its client book generates. Miss one, and HMRC can send a late filing notice and charge a penalty unless there's a valid reason for the delay, and a late or incorrect FPS can flow through to an employee's Universal Credit or other income-related benefits, which makes a missed submission a client's employee's problem as much as the bureau's.
Cycle Two: The Monthly HMRC Payment, With Its Own Earlier Cut-Off
Separately from the per-payday FPS, the tax and National Insurance an employer owes HMRC each month is due by the 22nd if paying electronically, or the 19th by post. Sitting inside that same month is a different submission entirely: an Employer Payment Summary (EPS), which an employer sends to claim reductions, for example statutory pay recovered, against what it owes. An EPS only reduces the amount due for a given tax month if it reaches HMRC before the 19th of the following month. So a bureau is tracking two different dates in the same monthly cycle, a reduction-claim cut-off and a payment due-date, for every employer client, every month.
Cycle Three: The Once-a-Year Jobs That Still Land on Hard Dates
Once a tax year ends, a fresh set of obligations lands with no pay-run flexibility attached. Employers must give every employee a P60 by 31 May. Where an employer provides expenses or benefits in kind, a combined P11D and P11D(b) return is due by 6 July, and any Class 1A National Insurance owed on those benefits is due by 22 July if paid electronically (19 July by post). None of this depends on how often that particular client runs payroll; it's a fixed date that applies regardless, and it lands at the same time of year across the bureau's entire client book at once.
Cycle Four: The Deadline Most Bureaus Only Think About Once Every Three Years
Automatic enrolment adds a cycle with a longer fuse but no less bite. Employers must carry out re-enrolment roughly every three years, putting back in any eligible staff who'd opted out or reduced contributions, and then submit a re-declaration of compliance within five calendar months of that third anniversary, even if no staff actually need re-enrolling. Because the three-year clock starts on each employer's own original duties start date, a bureau with clients that staged for auto-enrolment at different times isn't facing one re-enrolment deadline, it's facing a rolling, client-specific one that's easy to lose track of precisely because it only comes around once every three years per client.
Why This Is a Different Shape of Problem Than a Single Monthly Return
Want to see how this works in practice? Explore Osuria’s client portal
A CIS contractor has one demanding but singular rhythm: a CIS300 return and a set of subcontractor statements, every month, on overlapping but predictable dates. A payroll bureau running standard PAYE is stacking four rhythms with different periods, per payday, monthly, annual, and triennial, across every employer client simultaneously, and each client can sit at a different point in each cycle depending on its own pay frequency, benefits position, and auto-enrolment staging date. A spreadsheet built to track "this month's deadlines" has nowhere obvious to put a reduction-claim cut-off that only matters for one EPS a year, or a re-declaration that's eighteen months away for one client and two months away for another.
What a Structured Process Needs to Hold
Handling this well means a bureau needs a system that can show, per client, where that client sits on all four cycles at once, not just a single combined "payroll calendar" that flattens weekly FPS deadlines, monthly payment dates, annual P60/P11D dates, and triennial auto-enrolment dates into one view that loses the distinctions that actually matter. It also means a defensible, client-by-client record of what was filed and when, since each of these obligations carries its own penalty regime and its own proof-of-compliance expectation if HMRC or The Pensions Regulator ever asks.
A branded client workspace built around deadline visibility and document delivery, rather than a generic shared calendar, gives a bureau one place to see where every client stands across every cycle it's running, instead of four separate systems of record for four different clocks.
The Risk Compounds With Every Client Added
A bureau with five employer clients can hold all four cycles in someone's head. A bureau with fifty can't, and the client mix that grows a payroll book, weekly-paid clients alongside monthly, benefits-in-kind clients alongside simple salary-only ones, auto-enrolment staging dates scattered across a decade, means the cycles don't average out as the book grows. They just multiply. Bureaus that build a system to track all four cycles per client now are scaling their payroll book without scaling the risk of a missed FPS, a late EPS, a forgotten P11D, or a blown re-declaration window.
If your bureau's payroll workload is really four overlapping deadline problems wearing one name, it's worth seeing what a purpose-built, branded client workspace looks like in practice. Explore the Digital Workspace or start using Osuria to see how a structured process handles a client base where every client is running its own version of the same four clocks.