Payroll Bureau Software: Fixing the 90-Client Crunch Week

Why payroll bureau software makes or breaks a multi-client bureau

A payroll bureau does not have a payroll problem. It has a multiplication problem. One client running 40 employees on Xero Payroll or BrightPay is a solved thing. Ninety clients, each with their own pay frequency, their own pension provider, their own timesheet format, their own approver who goes quiet until 4pm on the day before the pay date, is a completely different business. The calculation engine handles a small slice of the work. The rest is chasing, importing, checking, filing and explaining.

Most bureau owners recognise this week. It is the 26th. Your payroll manager has 31 clients on a monthly cycle landing in the same four days. Client data arrives as a CSV from a Deputy export, a photographed timesheet in a WhatsApp thread, an email that says "same as last month but Priya left on the 12th and Tom is now 40 hours", and a Google Sheet that a restaurant owner updates live while you are reading it. Your team keys those into BrightPay or IRIS Payroll Professional or Sage 50cloud Payroll, one client file at a time, each in its own instance, each requiring a separate login or a separate open-close cycle. Nobody can see across all 90 payrolls at once. The master view is a spreadsheet called PAYROLL TRACKER 2026 v4 FINAL.xlsx with conditional formatting that somebody built in 2019 and nobody dares touch.

The cost of that is concrete. In the bureaus we have scoped, a processor handling 90 payrolls spends roughly 45 minutes per client per cycle on admin before any calculation happens. That is around 68 hours a month spent moving data between systems that already hold the data, most of a full-time role, and it is the exact work that makes people quit. It is also where the errors live. One transposed hours figure on a 22-person client is a corrected filing, an apology call, and a client who now checks everything you send for the next six months. Bureaus rarely lose clients over price. They lose them over the third mistake.

Problem: every client sends data differently, and nobody will change

You have told your clients for years to use the template. Roughly a third do. The rest send what they send, because the salon owner is not going to learn your spreadsheet and the construction firm's site manager has been photographing the same paper sheet since 2011. So your team does the translation, manually, ninety times a cycle.

Off-the-shelf payroll software cannot solve this because it starts one step too late. BrightPay, IRIS Payroll Professional and Sage all assume clean input already exists inside their import format. Their CSV importers are rigid: wrong column order, a merged header row, a date written as 12/03 instead of 2026-03-12, and the file bounces. They are built for one company's payroll clerk, not for a bureau absorbing 90 different data cultures.

What a custom build does: an ingestion layer sitting in front of whatever engine you keep. Each client gets a stored mapping profile: this client's file always has hours in column D, always uses employee nickname not payroll ID, always sends Monday-to-Sunday weeks. The profile is learned once, on the first import, and reused forever. Fuzzy-matched employee resolution handles "Tom B", "Thomas Bennett" and "T.Bennett" resolving to the same payroll record with a confidence score, and anything under threshold gets queued for a human to confirm rather than silently guessed.

AI earns its keep here in one narrow way. Document extraction on photographed and PDF timesheets works well now: a vision model reads the sheet, pulls names, dates and hours into structured rows, and flags low-confidence cells for review rather than asserting certainty. Same for the "same as last month except" email. A model parses the free text into proposed deltas, leaver on the 12th, hours changed to 40, and presents them as a diff against last period for one-click confirmation. The processor stops typing and starts approving. In our delivery experience, that single change is the biggest hour reduction in the whole build.

Problem: filings and deadlines live in a spreadsheet and someone's head

Real Time Information (RTI) submissions, pension uploads to NEST or The People's Pension, year-end documents, new starter declarations, each with its own deadline and its own consequence for being late. In most bureaus the tracking for this is a tab in the master spreadsheet, updated by hand after the fact. The system of record for "did we file for client 47" is a green cell that someone remembered to colour.

Desktop payroll tools know whether a submission succeeded for the file that is currently open. They do not give you a portfolio view. There is no single screen that says: across all 90 clients, three Full Payment Submission (FPS) filings failed, one pension upload bounced on a member ID mismatch, and two clients have not approved their pay run 18 hours before the pay date. You find out by opening files one at a time, or by a client finding out first.

A custom build makes the filing obligation itself a first-class record, not a side effect. Every client has a schedule of obligations generated from their pay calendar. Each obligation has a state: due, submitted, accepted, rejected, corrected. Submission responses are captured and stored against the record with the raw response, so when the tax authority disputes something eight months later you have the receipt rather than an argument. The dashboard is ranked by risk, not alphabetically: hours-to-deadline against current state. Alerting escalates by role, from processor at T-48 to payroll manager at T-24 to director at T-6. Nothing gets discovered on the pay date.

Problem: chasing approvals is a job nobody has, done by everybody

You cannot run the payroll until the client confirms. The client confirms when they feel like it. So your team sends emails, then follow-up emails, then texts, then calls, and the compressed four-day window gets more compressed. Every bureau has one client whose approval reliably arrives at 5:40pm on the last possible day, and the whole team knows their name.

Generic tools have no concept of this. Xero Payroll and QuickBooks Payroll assume the person approving is the person running the payroll. There is no bureau-to-client approval loop, so bureaus reconstruct one out of email threads, and the audit trail for "you approved this" is a forwarded message.

What to build: a per-client approval workflow with a hard deadline derived from the pay calendar, a mobile-friendly approval view showing the pay run summary with variance flags against last period, and named approvers with delegation for holidays. Approval is a recorded event with a timestamp and a person, which ends the "we never agreed that bonus" conversation permanently. Sequenced reminders fire automatically at the intervals you set, through the channel that client actually reads, whether that is email, SMS or a WhatsApp Business message. AI drafts the chase copy in your bureau's tone, references the specific missing items and the specific deadline, and after two ignored nudges escalates to a human with context attached rather than sending a fourth identical email. In our experience, automated sequenced chasing pulls the median approval time forward by more than a day and takes the emotional labour out of the week.

Problem: the client portal you have is not really yours

Bureaus want to look like a payroll department, not a reseller. But the portal your clients log into is branded by your software vendor, has a feature set you cannot change, and quietly teaches your clients the name of the tool you use. Some of those clients will eventually work out they could buy it directly at the vendor's list price.

Vendor portals also stop at payslips. They do not hold your engagement letter, your fee schedule, your document requests, or the conversation history for that client. So the client experience fragments: payslips over there, documents in Dropbox, questions in email, invoices in Xero.

A custom portal, white-labelled to your bureau, consolidates it: employee self-service for payslips and P60s, employer view for pay run history and cost reports, a document vault with request-and-chase built in, and a message thread per client that lives against the client record so it survives staff turnover. Add role-based access so the finance director sees totals and the site manager sees only their site. This is also the natural place to put an AI assistant that answers the volume questions employees ask, why is my net pay different this month, where is my payslip from March, what is this deduction, grounded strictly in that employee's own payslip data, with anything ambiguous handed to your team. Those questions are a meaningful share of bureau inbound and none of them need a human.

Problem: you cannot see whether a client is actually profitable

Most bureaus we work with price per payslip, sometimes with a monthly minimum. Then reality happens. One 30-employee client sends clean data on the 2nd and takes 20 minutes. Another 30-employee client sends chaos, changes three things after approval and generates six phone calls, and takes four hours. You charge them the same. You have no data that says otherwise, so at renewal you raise everyone by 5 percent and lose the good ones.

No off-the-shelf payroll product measures this, because it is not a payroll question. It is an operations question about your bureau.

A custom build instruments the work itself: time-to-process per client per cycle, number of corrections after approval, chase count, inbound query volume, rerun count. Set that against fee and you get effort-adjusted margin per client, ranked. Suddenly the repricing conversation is evidence, not instinct: this client generates 11 chases a cycle and 3 post-approval corrections, here is the revised fee or here is the process change that fixes it. Forecasting on top of that history is useful too, predicting which clients will run late this cycle based on their own pattern so you can front-load the chasing before the crunch instead of during it.

What this costs and how long it takes

Digital Heroes delivery bands across 2,000-plus projects. A focused first release for a bureau, meaning the ingestion engine with per-client mapping profiles, the obligations and deadline dashboard, and the approval workflow, typically lands at $60k to $130k and ships in 12 to 16 weeks. A full platform with the white-labelled portal, document vault, employee AI assistant, billing integration and profitability analytics typically runs $150k to $400k phased over 6 to 12 months, released in stages so the bureau gets value from the ingestion layer in month three rather than month eleven.

What pushes price up in this category, specifically:

Number of upstream integrations. Each timesheet source, Deputy, Planday, TSheets, a client's homegrown Access database, is real work. Five sources is fine. Twenty-five is a project of its own. Pension provider integrations are worse than they look: NEST and The People's Pension behave differently and file-format edge cases eat weeks.

Whether you keep or replace the calculation engine. Wrapping BrightPay or IRIS and driving it through import and export is dramatically cheaper than building gross-to-net and statutory calculations yourself. Building your own engine means owning legislation changes forever, which is an annual cost, not a one-time one. We steer bureaus away from this almost always.

Multi-jurisdiction. One tax authority is a build. Three is three builds with a shared shell.

Historical migration. Bringing 90 clients' history across from desktop instances, with employee records, year-to-date figures and prior filings, is often 15 to 25 percent of first-release cost and is the thing most estimates forget.

Build or buy: take the position

Buy if you are under about 40 clients, your team is two or three people, and your clients are mostly small and similar. BrightPay Bureau or IRIS plus a decent tracker works, and a few thousand a year of licences beats $90k of build. Buy if you are growing fast enough that your process changes every quarter, because you should not automate a process you have not settled.

Build when these show up together. Your headcount grows in step with your client count, which means you have no operating leverage and you are a staffing agency with extra steps. You have hired a person whose actual job is chasing and keying. You are turning down clients because the four-day window is full. A client has left over an error that was a data-entry error, not a payroll error. Your portal has a vendor's logo on it and your clients are getting curious. And the tell that matters most: your best processor has built a shadow system of macros and personal spreadsheets that nobody else understands, because that is a specification you already paid for and cannot yet use.

The position we take: almost no bureau should build a payroll engine. Almost every bureau past 80 clients should build the layer around one. The engine is a commodity you rent. The ingestion, the obligations tracking, the approval loop and the portal are where your margin and your client relationship actually live, and no vendor will ever build those for a bureau because the vendor's customer is the employer, not you.

How to choose a developer for payroll bureau software

Ask them to model your data before they quote. A developer who has done this will draw the bureau, client, pay group, pay run, employee, pay period structure without prompting, and will ask about effective dating within the first ten minutes. Effective dating is the whole game: a pay rate change dated the 6th when the period runs 1st to 30th, a leaver processed after the run, a retrospective correction to a period already filed. If they treat employee records as rows you update rather than facts that are true for a date range, they will build you something that cannot produce a correct historical payslip, and you will find out at year end.

Ask what they will do when the tax authority's API rejects a submission at 4pm on a Friday. The answer you want covers retry logic, dead letter queues, the raw response stored against the obligation record, and a human alert. If the answer is "we'd handle the error", they have not run production payroll infrastructure.

Check the integration track record concretely, not by logo. Have they actually pushed data into a pension provider's file format, driven a desktop payroll product's import and export cycle, and dealt with a bank payment file? These are unglamorous, poorly documented, and the difference between an eight-week and a twenty-week timeline. Ask for a specific story about one that went wrong.

Ask about data handling before they ask you. Payroll data is salaries, national insurance or social security numbers, bank details, court orders, sick pay. You want field-level encryption for the sensitive columns, an access log per client record showing which of your staff opened whose data, retention rules, and a defensible answer on where the AI extraction step sends a photographed timesheet and whether that data trains anything. If the developer is casual about the last part, walk. You will be the one signing the data processing agreement with your clients, not them.

Finally, own the code. Full repository access, deployment you control, no per-seat lock. You have already been on the wrong end of a vendor relationship. Do not build a new one.