The client
The client is a global investment fund. They run Workday Financial Management, Workday HCM and Workday Adaptive Planning. Their workforce plan uses headcount and cost per employee, loaded from Workday every period.
The problem
Firm-wide headcount in Workday Adaptive Planning comes in higher than expected, and the budget shows a variance that finance can’t explain. The employee data from Workday looks right. So the question is simple: if the source is right, where do the extra heads come from?
First, how levels get into the model
In Workday Adaptive Planning, a level is an organisational unit, such as a cost center or a cost center within a company. Levels form a hierarchy. Every level rolls up to a parent, all the way to the top. Levels drive both security and where numbers roll up.
In this model, levels come in through two loaders.
The first loader builds the financial reporting hierarchy from the Workday Financial Management cost center structure. It has an exclusion rule, so levels marked “do not use”, and a short list of excluded cost centers, never load.
The second loader watches Workday HCM for new levels. It compares the cost centers in HCM with the levels already in Workday Adaptive Planning, and only loads the ones that don’t exist yet.
A separate data loader then brings in headcount and cost per employee, per cost center, per period. This one does not create levels. It only loads numbers against levels that already exist.
There is also a third way to create a level: by hand, in model management. That skips both loaders and every rule built into them.
What we find
We trace the extra headcount to four cost centers in one department group. They are real cost centers. They exist in Workday Financial Management and in Workday HCM, they roll up correctly in Workday, and they have real employees.
In the loader staging data, these four are not excluded, so the financial level loader brings them in under the right parent.
But at some point, someone also creates these four levels by hand in Workday Adaptive Planning, under a different parent. Now the same cost centers appear in two places in the hierarchy, and headcount counts under both the correct rollup and the wrong one. The firm total goes up, and that flows straight into the budget variance.
The data is fine. The structure is not.
The fix, in the right order
Deleting levels in a live planning model is not something to rush, so we lay out the fix as two clear paths and one check that decides between them.
The check is to confirm whether the four levels exist in two places right now: once under the correct parent from the loader, and once as manual copies under the wrong parent.
If they do, we delete only the manual copies, keep the loaded versions, and change nothing in the loaders.
If finance decides these cost centers should not be in the plan at all, we add them to the exclusion rule, add the same exclusion to the headcount loader, remove every instance from the model, and agree with finance what happens to those employees in the plan.
Either way, nothing is deleted until the check is done and finance agrees.
The result
Finance gets a clear explanation of an unexplained variance. The cause is a structure problem from levels created outside the loaders, not bad data from Workday. They also get a documented, low-risk fix with a single check before any change. The loader logic, the exclusion rule and the data flow are now written down, so the team knows how levels enter the model.
What we learn
When headcount looks too high, check the hierarchy before the data. Duplicated structure looks exactly like duplicated people.
Create levels through the loader, never by hand. Manual levels skip every rule the loader enforces.
Know which loader creates structure and which only loads numbers. Mixing them up is how gaps and duplicates appear.