Opex and headcount planning with AI

Headcount is most of opex and the line that plans worst, because the number moves for reasons the plan cannot see until payroll runs. A driver-based plan computes cost from the requisition and offer behind each hire, keyed to a real start date rather than a typed-in FTE count. Slip a start or lose an offer, and salary, ramp, and loaded burden recompute on their own.

Ask a finance team where their opex plan is weakest and most will point at people cost without much hesitation. The rest of opex is comparatively docile. Software renews on a known date, rent is a contract, cloud is a usage curve you can watch. Headcount is the line where a single delayed start date, a backfill nobody logged, or a reorg that moves twelve people between cost centers can throw the quarter, and it does so quietly, because the source of truth for what actually happened lives in the ATS and the HRIS, not the model.

Plan the person, not the FTE count

The first mistake is planning headcount as a number of FTEs per department per month. That representation throws away everything you need to track the number as it changes. A department with 40.0 planned FTEs tells you nothing about who is in it, when they started, what they cost fully loaded, or which of them is a backfill for someone who left in March.

Plan at the level of the position instead. Each planned hire is a record with a start date, a fully loaded cost that carries salary plus employer taxes plus benefits plus the seat cost your finance policy attaches, a ramp curve if the role is quota-carrying, and a link to the requisition it corresponds to. The department FTE count and the opex line become sums over those records, computed, never typed.

Once positions are first-class, the arithmetic that used to be done by hand falls out of the model:

• Partial-month cost from a mid-month start date, prorated correctly instead of rounded to a whole month
• Merit and promotion increases that land on a review date and change the run rate from that month forward
• Attrition modeled as a hazard on filled positions rather than a flat percentage haircut on the total, so the backfill it triggers is a new position with its own lead time
• Location and currency carried on the position, so a plan built across entities does not collapse everyone into one blended rate

That last point is where multi-entity plans usually go wrong. A blended cost per head is fine until half your hiring moves to a market with different employer tax, and the loaded burden the model assumed no longer matches what payroll posts.

Wire the plan to hiring reality

A headcount plan that does not read the ATS and the HRIS is a snapshot that starts decaying the day it is approved. The point-in-time discipline here is the same one the close demands. What did we know about this position, and when did we know it. A requisition opened, an offer extended, an offer accepted with a start date, a start confirmed by the first payroll run, a termination filed. Each of those is a state change with a date, and the plan should consume them as they land.

Entity resolution is the unglamorous core of this. A planned position, a requisition in the ATS, and an employee record in the HRIS are three representations of the same eventual person, created in three systems that share no key. Matching them is where the automation earns its place and where it is easy to be careless. A wrong match double-counts a hire or hides a departure, and both errors flow straight into the opex line. We build the matching against a labeled eval set of known-correct position-to-requisition-to-employee links, hold a false-positive budget for auto-matched pairs, and route anything below the confidence threshold to a human queue rather than letting it post. Every match carries lineage back to the source records, so a flagged number can be traced rather than guessed at.

Reconciliation closes the loop. Each period, actual people cost from payroll reconciles back to the sum of filled positions in the plan. When the two disagree, the difference is a real event the plan missed, not noise: a signing bonus, a severance accrual, a contractor reclassified as an employee. The reconciliation is what keeps the plan and the ledger from telling two stories about the same month.

Let AI assemble and explain; leave the decisions to people

The useful work for a model here is assembly and diagnosis, the same as in the rest of FP&A. It can propose the loaded-cost build for a new position from comparable roles, or map a posted payroll line back to the position it belongs to. When the opex line comes in over plan, it drafts the variance commentary and points at the driver: three starts planned for the first of the month landed on the fifteenth, so the month runs about a salary and a half light, and here are the position IDs.

What it should not do is move the establishment on its own. Closing a requisition, changing a start date, writing in an attrition rate, deciding a backfill is not needed. Those are decisions with an owner, and in workforce planning the audit trail matters more than usual, because you are reconstructing why the largest line in the P&L moved and, sometimes, defending a specific person’s cost. Every proposal the model makes should be reviewable, every override should be a named node with a reason, and nothing should reach the plan without a path back to the source record that justified it.

Drift is the failure mode to watch. The mapping between the chart of accounts, the cost-center tree, and the position records was built by different people at different times, and a reorg or a new benefits vendor breaks it silently. Test the mappings so they fail loudly when a code changes, instead of routing a department’s cost into the wrong node for a quarter before anyone reconciles closely enough to notice.