.svg)
Curious how TeamOhana can help you? Talk to us.
In this article
Never miss new content
A finance lead at one of our customers described the problem in about fifteen seconds. Someone leaves. A few weeks later the manager asks to replace them, and the request comes in under a new ID. "How do I know that this is related to that?"
Without a way to connect the two records, Finance can't easily tell whether the request is a backfill or new headcount. They only know because someone remembers, or because an FP&A analyst checks the request against last month's roster. That works at 200 people. It gets shaky at 500, and past 1,000 it's a burden.
The distinction matters more than almost anything else in the headcount plan. A backfill replaces someone who left, so the approved total doesn't move and the cost is already in your run-rate. New headcount is new committed cost. The board reads them differently, and your approval process probably treats them differently too. So why is this the question systems handle worst?
Backfill vs. new headcount: A backfill refills a seat that already exists in the approved plan, so its cost is already in your run-rate. New headcount adds a seat that didn't exist before, which makes it new committed cost.
Where the answer goes missing
Many HR systems, especially in the mid-market, are built around the employee record. That makes sense given what they're for: paying people, running benefits, knowing who works here. The seat a person sits in isn't a record of its own. It's a set of fields on the person. ADP, for example, describes Workforce Now as a job-based structure built on reporting hierarchies, and Paycor's API updates position as an attribute of the employee.
When the person leaves, the employee record closes and those fields close with it. The seat opens, but nothing records the opening. When the manager later asks to fill it, the ATS creates a brand-new req with a brand-new ID, and nothing connects it to the seat that just emptied. Anyone downstream sees what looks like a request for new headcount.
Systems that do have a position object don't fully close the gap either. One Workday admin described terminated employees being replaced through a new req and a new position, leaving the team with "open ghost positions."
Someone can always trace the request back to the original position. The question is how many people it takes to make that connection, and how often they have to do it.
It gets messier than a clean replacement
There are simple cases. If Jim leaves and you replace Jim, that's a backfill. If Jim's team of one becomes a team of two, that's new headcount. The hard case sits in between: the role changes.
An FP&A lead at a digital health company walked us through a common one. Someone leaves, and the team decides not to rehire the same role. They want a different role with the same money. She still has to show executives and the board that the new role "is not net incremental to the plan." Without a record tying the new role to the old seat's budget, that's a manual footnote every time.
Promotions and transfers cause the same problem from the other side. Someone moves teams, and their old seat should become an opening. In employee-centric setups nothing records it, and the replacement shows up later as new.
Timing adds its own mess. If a backfill req opens before the departure is processed in the HRIS, the same seat gets counted twice for a few weeks, once as a person and once as an opening.
And plans move. A planning lead at a software company of about 500 summed it up: "We sign off a plan and then we hire people completely different." When the plan can't tell which hires replaced whom, nobody can say whether the gap was growth or just turnover.
The fix is to track the seat
The reliable way to settle backfill versus new headcount is to give every funded seat its own record. Workday and other position-based systems call this a position. It has an ID, a budget and a history, and it stays put when the person in it leaves.
What is a position? A position is a funded seat tracked as its own record, with an ID, a budget and a history, separate from whoever fills it. When the person leaves, the position stays open instead of disappearing with the employee record.
Once seats are records, the label is there before anyone decides anything. A request to fill a seat that already exists, in the same role, is a backfill. A request for a seat that never existed is new headcount. A seat whose role is being revised is its own case, and it can carry its budget to the new role, so the board footnote is already there.
A label isn't an approval, though. A backfill still commits money for another year or more, so it deserves the same second look as a new role: are the skills the same ones you hired for, and does the work need a person at all?
A transfer leaves the old seat open with its budget intact. And because the seat is either filled or open, a backfill can't be counted alongside the person it replaces.
When this isn't worth solving yet
If your headcount barely moves, you may not need any of this. Low turnover, few internal moves and one analyst who really does know every seat can carry a company a long way. The case gets stronger with motion: more departures, more transfers, more managers asking for heads, and a board that wants answers the same day.
Try it on your own positions
TeamOhana gives every seat on your org chart its own ID and budget, so backfills are labeled for you and the refill decision starts from the facts. It runs next to the HRIS you already use. See how it works.
See what connected headcount planning looks like for your finance team. Book a demo.
Take control of your headcount spend
FAQ
Simplifying TeamOhana: your questions, answered.
A backfill replaces an employee who left, so it refills a seat that already exists in the approved headcount plan. New headcount adds a seat that did not exist before. A backfill leaves the approved total unchanged, while new headcount increases it.
A backfill's cost is already in the company's run-rate, while new headcount is new committed cost. Boards and executives read the two differently, and most approval processes treat them differently. Mixing them up distorts both the forecast and the story told about growth versus turnover.
Many HRIS platforms are built around the employee record, with the seat stored as fields on the person. When the employee leaves, those fields close, and the replacement req is created in the ATS with a new ID that has no link to the vacated seat. Downstream, the request looks like new headcount unless someone manually connects the two.
When a team replaces a departing employee with a different role at the same cost, finance still needs to show the hire is not net incremental to the plan. The cleanest approach is to track the seat as its own record so its budget can carry over to the revised role. That keeps the link visible instead of relying on a manual footnote.
Double-counting happens when a backfill req opens before the departure is processed in the HRIS, so the seat appears once as a person and once as an opening. Tracking each seat as either filled or open, rather than tracking people and reqs separately, prevents the same seat from being counted twice.
Position-based tracking gives every funded seat its own record with an ID, a budget and a history that persists when the person in it leaves. Requests to fill an existing seat are labeled backfills automatically, and requests for a seat that never existed are labeled new headcount. Transfers leave the old seat open with its budget intact.
Companies with low turnover, few internal moves and an analyst who knows every seat can often manage without dedicated tracking. The need grows with motion: more departures, more transfers, more hiring requests, and leadership that expects same-day answers. Past a few hundred employees, manual reconciliation tends to become a recurring burden.
