The Case for Making Loaded Comp Match the Books

Every headcount model carries a loaded-comp assumption — some fully-burdened number per hire that rolls up into forward burn. The problem is what happens after the plan is signed. The number in the model and the number payroll actually ran diverge within a quarter, and most teams close that gap by hand. Making loaded comp match the books is the difference between a plan that tracks reality and one that quietly drifts until the variance report forces a reckoning. The reconcile is real work — usually a spreadsheet, a payroll export, and a couple of hours a month spent explaining why the two don't agree.

Where the drift comes from

The model assumes clean starts and steady-state costs. Payroll doesn't run that way.

A rep who starts on the 18th costs roughly 40% of a monthly loaded figure that month, not the full amount the plan booked. Multiply that across a cohort of Q1 hires and the first-quarter comp line is materially lighter than modeled — which reads as underspend until the second month catches up and the trend reverses.

Bonus timing does the same in the other direction. If the model spreads variable comp evenly but the business pays it in March and September, two months carry a spike the plan never anticipated. Benefit true-ups — the annual reconciliation on health plans, the 401(k) match that lands unevenly — add smaller, harder-to-predict bumps. The IRS publishes the contribution and match limits that drive some of this, but timing within the year is a payroll-calendar question, not a policy one.

Then there's productivity ramp, which the model usually ignores entirely. A sales hire budgeted at 100% of quota-carrying capacity is closer to 25% in month one. The comp is real; the assumed contribution isn't. That gap doesn't show up in the payroll reconcile at all — it shows up later, in the conservative-versus-aggressive hiring scenarios that were built on optimistic ramp curves.

What a fully-burdened number should actually include

"Loaded comp" gets used loosely. A defensible number includes base salary, target variable, employer payroll taxes, benefits, and any per-head software and facilities allocation. SHRM's guidance on the cost of an employee and standard BLS employer-cost-for-employee-compensation data both put benefits and taxes at roughly 30% on top of wages — enough that a model using base salary alone will understate burn by a third.

The trap is treating that 30% as a static multiplier. Employer FICA caps out at the Social Security wage base, so senior hires carry a lower marginal tax load than the blended rate implies. Benefit elections vary by employee. A flat load applied uniformly will be wrong for exactly the highest-cost hires, where being wrong matters most.

This is where the model's loaded-comp figure and the general ledger start speaking different languages. The plan carries one blended number; QuickBooks or the ERP carries the actual posted cost by department, by pay period, net of true-ups. The reconcile is the translation layer, and it's usually manual.

The cost of planning off stale figures

The reconcile isn't the expensive part. The expensive part is what you decide while it's stale.

If your loaded-comp number is three months behind reality, every downstream decision inherits the lag. Forward burn built line by line off headcount compounds the error — a $15K-per-head understatement across 40 hires is $600K a year the runway math never saw. Runway is where this bites hardest, which is the whole argument in the case for planning headcount to protect runway rather than just record hires.

The stale-data problem is structural, not a discipline failure. Payroll data lives in ADP or Paylocity. Cash movement lives in bank feeds — often piped through Plaid — and posts to the GL on its own schedule. The planning model lives in a spreadsheet or an FP&A tool, and it only knows what someone last typed into it. Three systems, three refresh cadences, one human bridging them at month-end. The pieces on our visibility desk keep returning to the same point: the lag isn't in the tools, it's in the reconciliation between them.

Closing the gap

There's no single right stack, and anyone selling one is overselling.

The spreadsheet approach still works at small scale: export the payroll register from ADP or Paylocity, pull actuals from QuickBooks, and reconcile against the model monthly. It's cheap and fully auditable. It also breaks down somewhere north of 50 employees, when the export-and-match cycle stops fitting in an afternoon and starts eating a full day near close.

Dedicated planning tools — Runway, Mosaic, Pigment, and others — connect to payroll and the GL directly and refresh the actuals underneath the model, which shortens the reconcile from hours to a review. The tradeoff is implementation cost and the discipline to keep the integrations mapped correctly; a mis-mapped department feed produces confident, wrong numbers, which is worse than a spreadsheet you don't trust. Our tools coverage gets into the specifics of where each fits.

The question worth asking, whatever you land on, is how far the loaded-comp figure in your model sits from the last payroll run. If the answer is "I'd have to reconcile to know," the plan is drifting.

The stronger version of this closes the gap continuously — the model reads live payroll and cash instead of waiting for someone to reconcile it at month-end. Worth understanding what live-data planning changes about the cadence. →

The reconcile will always exist as a control. The question is whether it's the thing standing between you and knowing your real burn, or a monthly confirmation of a number you already trust. The operations case for the second version is simple: decisions made off live loaded comp are decisions made off the books, not off a memory of them.