Don't pick the wrong payroll model: decision criteria, RACI templates and a 6‑month change checklist

Most companies don't actually choose their payroll operating model. They inherit it. Somebody in finance ran payroll back when there were 18 people, then the company doubled, opened a second location, acquired a small competitor, and suddenly there are three people in three departments all touching pay data with no clear line between who owns what. That's not a model. That's an accident that happens to work most months.

The reason this matters isn't organizational tidiness. It's that the operating model quietly decides how fast errors get caught, who's accountable when a garnishment gets missed, and whether your payroll survives the next 40% headcount jump. Pick the wrong structure and you spend the next two years firefighting handoffs that shouldn't exist.

So here's a breakdown of the three real options, when each one actually fits, and — the part everyone skips — how to move from one to another without the whole thing falling apart in month three.

The three models, and what they really cost you

There are basically three shapes a payroll function takes as a company grows. Everyone knows the names. Almost nobody thinks clearly about the tradeoffs, because the tradeoffs don't show up until you're already committed.

Centralized means one team owns end-to-end payroll for the whole organization. All the inputs flow to them, they run everything, they file everything.

Hub-and-spoke keeps a central "hub" that owns policy, systems, compliance, and the actual pay runs — but pushes data collection, timecard approval, and first-line questions out to "spokes" in each region or business unit.

Embedded puts payroll people (or payroll responsibilities) directly inside each business unit, location, or entity, with light central coordination.

One thing worth saying clearly: none of these is "the mature model." A well-run embedded setup for a holding company with five genuinely different businesses can be far healthier than a forced central team that doesn't understand any of the local rules.

Why companies end up with the wrong one

The pattern is pretty consistent. Centralization happens because it feels like control. A CFO gets burned by a surprise tax notice in a location they didn't know existed, and the reflex is to pull everything into one team. That works — until the central team is running payroll for 22 states and 4 countries and nobody on it has ever set foot in half those places.

Embedded models usually aren't a decision at all. They're what's left over after acquisitions. You buy three companies, each came with its own payroll person and its own system, and integrating them looks expensive, so you just… don't. Two years later you've got four chart-of-accounts variations, three benefits deduction conventions, and no single place to answer "what did we actually spend on payroll last quarter."

Hub-and-spoke is the one people choose on purpose, and it's also the one that fails most often — because the split between hub and spoke gets described in a slide, never in a real responsibility matrix. Everyone assumes someone else owns the gray zone. The classic gap: who validates that a new hire's tax setup is correct before the first run? The spoke says "the hub runs payroll, that's their job." The hub says "we run what you send us." First paycheck goes out wrong, and now it's a retro correction and an unhappy new employee in week one.

The core mistake across all three: teams design the structure and forget to design the decision rights. Boxes on an org chart don't tell you who approves an off-cycle payment or who signs off before filing. That's what actually determines whether the model works.

The decision criteria that actually predict success

Forget headcount thresholds as the primary driver. Headcount matters, but four other things predict the right model far better.

1. Regulatory spread. Count your distinct jurisdictions — states, countries, local tax authorities. If you're in one or two states, centralization is almost always right and everything else is overhead. Once you cross into a dozen jurisdictions with real differences, a pure central team either becomes a bottleneck or a compliance liability, because no single group can hold that much local nuance well. This is the same tension that drives a lot of the pain in a multi-jurisdiction payroll compliance operating model — the structure has to match where the rules live.

2. How different your business units actually are. Not "do they feel different" — do they have genuinely different pay structures? A staffing agency and a manufacturing plant under the same parent have almost nothing in common at the payroll level. Different pay frequencies, different overtime rules, different union situations. When units are truly distinct, forcing them into one process creates more exceptions than it eliminates. When they're basically the same business in different cities, centralize hard.

3. Where your talent sits. This one gets ignored constantly. If your payroll expertise is concentrated in two senior people at HQ, you cannot run an embedded model — you'll be staffing local roles with people who don't know what they don't know. If your knowledge is spread across capable regional folks, hub-and-spoke can lean on them.

4. Your tolerance for latency vs. drift. Centralized trades local speed for consistency. Embedded trades consistency for speed. Be honest about which failure hurts you more. A company where a slow off-cycle payment triggers turnover in a competitive labor market may genuinely need embedded responsiveness even at the cost of some standardization.

Run those four, and the model usually picks itself. Where it doesn't — where you're genuinely torn between hub-and-spoke and embedded — default to hub-and-spoke, because it's the only one of the three you can tune later without a full reorg.

When each model is actually a bad idea

Centralization is a bad idea when: you have several genuinely distinct businesses with different pay rules, or your jurisdictions have local nuances the central team can't realistically master. Forcing it here just moves the complexity into an ever-growing "exceptions" pile that one overloaded team manages by memory and heroics.

Hub-and-spoke is a bad idea when: you can't clearly define and enforce the boundary. If your spokes are volunteers doing payroll on the side with no real accountability, the hub ends up doing everything anyway plus chasing the spokes. You've got the cost of two layers and the benefit of one.

Embedded is a bad idea when: you need consolidated reporting, you're heading toward any kind of audit or financing event, or your total headcount is under a few hundred. The duplication is real money, and the lack of a single source of truth makes finance's life miserable. Anyone preparing for scrutiny — investors, auditors, a sale — should be consolidating, not scattering.

Who should not touch this at all right now: if you're under ~50 employees in one or two states and payroll runs cleanly, don't reorganize anything. Tighten your controls, document your process, and revisit when you hit a real trigger — new state, new entity, headcount doubling. Restructuring a working small-company payroll is a solution looking for a problem.

The RACI that makes any of these models real

A model without decision rights is just a diagram. This is the part that determines whether payroll actually works, and it connects directly to broader payroll governance for mid-market companies — the RACI is where governance stops being a policy document and starts being who-does-what on Tuesday.

The version that fails is the one that lives in a slide deck. The version that works is printed, referenced in your SOPs, and pulled up in the meeting when someone asks "wait, whose job was that?"

1. 1
   Every activity has exactly one A. The single most common RACI failure is two "Accountable" boxes on one row. That's not shared accountability — that's nobody being accountable.
2. 2
   The spoke owns inputs, the hub owns processing and compliance. If you blur that line, you get the new-hire-first-paycheck disaster from earlier. Write it down explicitly: the spoke is accountable for data being correct before it reaches the hub.

“

Print the RACI and link it in your SOPs so people can reference it during incident reviews.

The version that works is printed, referenced in your SOPs, and pulled up in the meeting when someone asks "wait, whose job was that?"

Career ladders — because a model needs people who can grow into it

This is the piece almost nobody plans, and it's why hub-and-spoke setups slowly rot. You build the structure but not the roles people can climb, so your good spoke coordinators leave, and you're back to running everything from the hub.

1. 1
   Payroll Coordinator / Spoke Admin — owns local data quality, timecards, first-line employee questions. Entry point. Knows the process, not yet the compliance depth.
2. 2
   Payroll Specialist — runs pay cycles, handles garnishments, deductions, corrections. Understands why, not just how.
3. 3
   Senior Payroll Analyst — owns pre-run validation, reconciliations, multi-jurisdiction filing, exception handling. This is where real expertise lives.
4. 4
   Payroll Manager / Hub Lead — owns the operating model itself, vendor relationships, controls, and the RACI. Runs the function.
5. 5
   Payroll Director — owns strategy, transformation, cross-functional coordination with finance and HR leadership.

The mistake that keeps showing up: companies hire coordinators and directors with nothing in between, then wonder why the coordinators can't handle anything complex and the director is stuck doing specialist work. The middle rungs are what let expertise transfer instead of walking out the door. If you're moving toward hub-and-spoke, you need at least a couple of Senior Analysts before the spokes can safely own anything.

The 6-month change checklist that protects adoption

Changing your payroll operating model is a change-management problem wearing a technical costume. The technical migration is the easy 30%. Adoption is the 70% that fails.

PAYROLL MODEL TRANSITION — 6-MONTH ROLLOUT Month 1 — Baseline and decide ↓ Month 2 — Design the operating model ↓ Month 3 — Build and pilot (single unit) ↓ Month 4 — Train and transfer knowledge ↓ Month 5 — Roll out in waves ↓ Month 6 — Stabilize and measure

Month 1 — Baseline and decide

1. 1
   [ ] Document the current-state process honestly, including the undocumented workarounds
2. 2
   [ ] Run the four decision criteria; pick the target model and write down why
3. 3
   [ ] Identify every person who currently touches payroll, even informally
4. 4
   [ ] Name a single executive sponsor who will actually show up

Month 2 — Design the operating model

1. 1
   [ ] Draft the RACI and pressure-test it against real recent incidents ("who owned this last time it broke?")
2. 2
   [ ] Map new roles to real people; find your gaps in the career ladder
3. 3
   [ ] Define the boundary between hub and spoke (or central and everything) in plain language
4. 4
   [ ] Write down what "done right" looks like for each handoff

Month 3 — Build and pilot

1. 1
   [ ] Pick one region or unit as the pilot — never migrate everything at once
2. 2
   [ ] Configure systems and access to match the new RACI, not the old habits
3. 3
   [ ] Run parallel for at least two full pay cycles before cutting over
4. 4
   [ ] Log every exception during the pilot; these are your future training material

Month 4 — Train and transfer knowledge

1. 1
   [ ] Train spokes on inputs and central/hub on processing — separately, on their real jobs
2. 2
   [ ] Document SOPs from the pilot's actual behavior, not the theoretical design
3. 3
   [ ] Set up the escalation path and make sure everyone can name it
4. 4
   [ ] Start the career-ladder conversations so people see a future, not a demotion

Month 5 — Roll out in waves

1. 1
   [ ] Migrate remaining units in sequence, hardest-and-most-different last
2. 2
   [ ] Hold a short weekly adoption check; watch for people routing around the new process
3. 3
   [ ] Track error rates per unit as you go — a spike means the handoff isn't clear
4. 4
   [ ] Kill the old process access deliberately, so there's no fallback to old habits

Month 6 — Stabilize and measure

1. 1
   [ ] Review against baseline

   error rates, time-to-run, exception volume

2. 2
   [ ] Formalize the RACI and SOPs as the official record
3. 3
   [ ] Set the recurring cadence — who reviews the model quarterly, who owns changes
4. 4
   [ ] Decide what's still manual and worth fixing next

The six-month rollout typically follows this workflow:

That last point connects to something worth doing after the model is stable, not during: once your handoffs are clean and consistent, you can start to automate payroll by exception and let people focus on judgment calls instead of routine runs. Automating a broken model just gives you faster mistakes — get the structure right first.

A real scenario: from accidental embedded to working hub-and-spoke

A mid-market services company — around 900 employees across seven states, grown mostly through acquiring smaller regional firms — had ended up fully embedded without ever deciding to. Four separate payroll processes, three systems, and each acquired unit still running the way it always had. Finance couldn't get a clean consolidated number without two weeks of manual stitching. Error rates weren't catastrophic, but off-cycle corrections were running maybe a dozen a month across the units, and each one ate hours.

The trigger was a due-diligence process for a credit facility, where the lender asked basic questions the company couldn't answer quickly. That forced the decision.

They didn't centralize — the units were different enough that it would've created endless exceptions. They went hub-and-spoke: a central hub owning systems, filing, compliance, and pay runs; the local units kept as spokes owning timecard approval and first-line questions. The whole move took a little over five months, with a single-unit pilot in month three.

The change that mattered most wasn't the software or even the consolidation. It was the RACI. Once "the spoke is accountable for data being correct before it reaches the hub" was written down and enforced, the new-hire setup errors that had been generating half the corrections mostly stopped. Off-cycle corrections dropped to a handful a month. The consolidated reporting that used to take two weeks came down to a few days, because there was finally one process feeding one place.

Nothing about it was magic. They picked the model that matched their actual regulatory spread and business diversity, wrote down who owned what, and rolled it out in waves instead of all at once.

The part worth remembering

The operating model question isn't really "centralized or not." It's whether the way payroll is structured actually matches the shape of the business — and whether the people involved know exactly what they own.

Companies that get burned almost always got there by inheriting a structure and never revisiting it as they grew, or by drawing a new structure on a slide and never defining the decision rights underneath it. The four criteria — regulatory spread, business-unit difference, where your talent sits, and your tolerance for latency versus drift — will point you to the right shape. The RACI makes that shape real. And the six-month rollout, done in waves with a real pilot, is what keeps people from quietly reverting to the old way the moment things get busy.

Get those three right and the model mostly runs itself. Skip any one of them and you'll be doing this again in eighteen months.