Payroll Bureau Software Problems: The 7 That Cost You Clients, and How to Avoid Them

Why does a bureau build stop at the import screen?

Because the pain is loudest there. Everybody in the bureau can describe the keying, so the requirements describe the keying, and the project gets scoped as an import tool with a dashboard bolted on. The import is genuinely worth building. It is just not the part that decides whether the system is correct.

What gets skipped is the payroll data model underneath. A bureau is not one payroll, it is bureau, client, pay group, pay run, employee and pay period, with effective dating running through all of it. Every fact about an employee has a date range in which it is true: this pay rate from the sixth, this bank account from last month, this pension contribution rate from the start of the tax year, this leaver date entered three days after the run.

A developer who treats employee records as rows to update will build something that produces correct payslips this month and cannot reproduce last April's. You discover that at year end, in front of a client, which is exactly when a bureau cannot afford to look uncertain.

The fix is to make the data model the first deliverable rather than the first assumption. Ask any bidder to draw it before they quote, and listen for the phrase effective dating inside the first ten minutes. If it does not come up unprompted, they have built subscription billing and are about to learn payroll on your clients.

What goes wrong when you migrate ninety clients off desktop payroll instances?

The trouble is that you are not migrating one dataset, you are migrating ninety, each maintained by a different processor over several years with its own quiet conventions.

Year to date figures are the first hazard. They have to land exactly, because they drive statutory calculations for the rest of the tax year, and an out by one on a single employee produces a wrong payslip that nobody spots until the annual reconciliation. Prior filings are the second: you need the submission history to answer a query about a period you did not process, and desktop exports rarely include the raw responses.

Then there is the layer that never exports at all. The note in a processor's own file that this client's director takes a fixed drawing and the rest is dividend. The attachment of earnings order recorded as a manual deduction because the old system could not hold it properly. The employee whose surname is spelled differently in the payroll file and the pension scheme, reconciled every month by hand.

What works is migrating in waves grouped by pay frequency so you are never migrating during a crunch week, running at least one full cycle in parallel per cohort and comparing outputs line by line rather than in totals, and treating migration as a named phase with its own budget. In our delivery experience it is routinely a significant share of first release cost and it is the line most estimates forget entirely.

Why do pension, bank file and payroll engine integrations break after launch?

Because all three are file based, and file based integrations fail without errors.

Pension provider uploads are the worst offenders. Providers behave differently from one another, member matching is done on identifiers that clients change without telling you, and a file that is rejected for one member is frequently rejected for all of them. The rejection arrives as a report you have to go and look at rather than as a message that finds you, so the failure is discovered when a member notices a missing contribution.

Bank payment files break on formatting and on timing. A file that is structurally valid but submitted after the cutoff pays everybody a day late, which is the one error a client will never treat as minor.

Driving a desktop payroll engine through its import and export cycle breaks on version. The vendor updates the product, a column moves, and your automation keeps running against the old shape until somebody reconciles a total.

Three defences. Validate every outbound file against the provider's own specification before sending, not after rejection. Store the raw response to every submission against the record it belongs to, so a query eight months later is answered with a receipt rather than an argument. And run an automated check nightly against each interface that fails loudly when the shape changes, because in payroll the silent failure is always more expensive than the noisy one.

What happens when filing obligations and data handling are not covered?

Filing is the gap that bites first. In most bureaus the record of whether a submission went in is a coloured cell in a tracker, updated after the fact by whoever remembered. Desktop tools know the status of the file currently open. Nothing gives you a portfolio view, so there is no screen that tells you three submissions failed, one pension upload bounced on a member identifier, and two clients have not approved their pay run eighteen hours before the pay date.

Make the obligation a first class record. Every client has a schedule generated from their pay calendar, each obligation carries a state of due, submitted, accepted, rejected or corrected, and the dashboard ranks by hours to deadline against current state rather than alphabetically. Escalate by role as the clock runs down, so nothing is discovered on the pay date.

Data handling is the gap that bites hardest. You are a processor acting for your clients, and what you hold is salaries, national insurance or social security numbers, bank details, court orders and sick pay. That means field level encryption on the sensitive columns, an access log showing which of your staff opened whose record, defined retention rules, and a clear answer to where a photographed timesheet goes when a document extraction step reads it and whether that data trains anything. Your clients will ask, because their own advisers are telling them to. Being unable to answer costs you the tender.

Should you build custom or configure what you already own?

Under about forty clients with a team of two or three and a largely similar client base, do not build. BrightPay Bureau or IRIS plus a disciplined tracker works, and a few thousand a year of licences beats a six figure project comfortably. Do not build while you are growing fast enough that your process changes every quarter either, because you should not automate a process you have not settled.

Configure harder first. Bureau editions of the major products have batch features, portal options and reporting that a meaningful number of bureaus never switch on, usually because the person who set the system up has moved on. It is worth a week of someone's time to find out what you already have.

Build when the signals arrive together. Headcount grows in step with client count, which means every new client costs you a hire. Somebody's actual job is chasing and keying. You are turning down clients because the four day window is full. A client has left over a data entry error rather than a payroll error. Your portal carries a vendor's logo and your clients are getting curious about it.

One position we hold firmly: almost no bureau should build a payroll calculation engine. Building gross to net and statutory calculations means owning legislation changes forever, which is a permanent annual cost rather than a one off build, and it is the one part of the stack where off the shelf is genuinely good. Rent the engine, build the layer around it.

How do hidden costs get into the quote?

Upstream integration count is the first and the easiest to understate. Each timesheet source is real work, and a client's homegrown database is not equivalent to a mainstream rota product. Five sources is manageable. Twenty five is a project of its own.

Pension providers are the second, and they are worse than they look because the edge cases in file formats consume weeks rather than days.

Whether you keep or replace the calculation engine is the third and the largest single swing in the number.

Multi jurisdiction is the fourth. One tax authority is a build. Three is three builds sharing a shell, and the shared shell saves less than you would hope.

Historical migration is the fifth, described above, and it is the one that most often appears as a footnote in a proposal.

The sixth is document extraction quality. Reading photographed timesheets works well, but the review queue for low confidence rows is a workflow with its own screens, permissions and audit trail, not a checkbox on the importer.

Ask for each as a named line. If a quote has one figure labelled integrations, nobody has looked at your client list yet.

What separates a bureau build that works from one that fails here?

First, effective dating is in the foundation rather than added later. Everything else in payroll depends on being able to answer what was true on a given date, and retrofitting that into a system built on updatable rows is the most expensive rebuild in this category.

Second, failures are loud. When a submission is rejected at four on a Friday afternoon, the right answer involves retry logic, a queue for messages that could not be processed, the raw response stored against the obligation, and a human alerted. A developer who says they would handle the error has not run production payroll infrastructure.

Third, extraction proposes and humans confirm. Read a photographed sheet or a same as last month except email into proposed changes shown as a difference against last period, with low confidence rows queued rather than asserted. The processor moves from typing to approving, and the audit trail records which human agreed.

Fourth, you own it. Full repository access, deployment you control, no per seat licence back to the developer, agreed before work starts rather than at handover. You have already been on the wrong end of a vendor relationship, which is most of why you are reading this. Do not sign a new one.