Workforce planning starts with understanding the employees already working in the organization.
Before we calculate future hiring requirements or workforce costs, we need to know when employees join, when they leave, how long they remain active and how their compensation is calculated.
In Workday Adaptive Planning, we can use a modeled sheet to maintain employee-level information and calculate monthly headcount and workforce costs.
In this article, we look at a Current Workers modeled sheet, explain its account structure and work through practical examples of headcount, movements, compensation and employee-related calculations.
1. What is a Current modeled sheet?
A Current Workers modeled sheet maintains detailed workforce records.
Each row can represent an employee or another worker record, depending on how the model is designed.
A record may contain information such as:
- Worker or position identifier
- Department or cost center
- Job profile
- Start date
- End date
- Compensation rate
- Employment status
- Departure reason
These details drive calculations across the planning periods.
Unlike a cube sheet, where we generally enter and analyze values at dimensional intersections, a modeled sheet uses row-level information to calculate results.
For example, an employee’s start date can determine when the employee contributes to headcount, while the compensation rate and employment period can determine monthly salary cost.
Where do we configure it?
We navigate to:
Modeling → Model Management → Level Assigned Sheets or User Assigned Sheets → Select the Current Workers modeled sheet
From the Sheet Summary, we select Modeled Accounts to review the account hierarchy and formulas.
The screenshot shows a Current Workers account hierarchy containing headcount, departure categories, employee costs and other workforce calculations.
These accounts are part of a configured model, not a mandatory standard account structure in every Workday Adaptive Planning instance.
2. Understanding the account structure
The Current Workers model contains several calculated accounts and an initial balance account.
We can group the accounts by purpose.
| Group | Accounts | Purpose |
| Headcount | Starting, Arrivals, Departures, Movement, Ending, Average | Tracks employee balances and movement |
| Departure Reasons | At Will, Retiring, Restructuring | Classifies employee departures |
| Compensation | Salary, Benefits, Employer Taxes, Stock Compensation | Calculates workforce costs |
| Other Costs | Severance, Contingent Labor, Talent Acquisition | Calculates additional employee-related expenses |
| Workforce Measures | Age, Years of Employment, Support Hours, Average Compensation | Provides operational and financial measures |
| Input | Base Pay Rate | Maintains compensation input |
Most of these accounts are calculated.
This means the model uses formulas rather than requiring users to enter each monthly result manually.
3. Calculated accounts versus Initial Balance accounts
Workday Adaptive Planning supports different modeled account types.
Calculated accounts
A calculated account uses a formula to derive a value from row data, assumptions or other accounts.
For example, Headcount Movement can be calculated using Arrivals and Departures.
The result updates according to the formula and the current row information.
Initial Balance accounts
An Initial Balance account is created when we add an Initial Balance data-entry column to a modeled sheet.
It can store a starting value that supports calculations over time.
In this example, Base Pay Rate is an Initial Balance account.
The source configuration uses a cumulative account planned by Delta.
This supports tracking changes to the balance across periods.
For example, an employee’s annual pay rate may be updated during the planning cycle, and the salary calculation can use the applicable rate.
We need to verify how pay-rate changes are entered and applied in the actual sheet.
4. Calculating Starting Headcount
Starting Headcount identifies whether an employee belongs to the workforce at the beginning of a period.
The example model uses the employee’s Start Date and End Date to make this decision.
The calculation checks whether the current month falls after the employee’s start month and is not after the employee’s end month.
Example
Suppose an employee joins on February 10 and leaves on June 20.
| Month | Starting Headcount |
| January | 0 |
| February | 0 |
| March | 1 |
| April | 1 |
| May | 1 |
| June | 1 |
| July | 0 |
The employee does not contribute to February’s starting balance because the employee joins during February.
However, the employee contributes to March’s starting balance.
The employee also contributes to June’s starting balance because the departure occurs during June.
This is the difference between a beginning-of-period balance and employee activity during the month.
5. Headcount Arrivals
Headcount Arrivals identifies employees who join during the current period.
The calculation compares the current month with the employee’s Start Date month.
When the two months match, the row contributes one arrival.
Otherwise, it contributes zero.
For example:
| Employee | Start Date | February Arrivals |
| Employee A | February 10 | 1 |
| Employee B | January 15 | 0 |
| Employee C | March 5 | 0 |
The February arrival count is 1.
At a department level, the model can aggregate the arrivals from all relevant employee rows.
This provides the number of employees joining during the period.
6. Headcount Departures
Headcount Departures works in a similar way.
The calculation compares the current month with the employee’s End Date month.
If the employee leaves during the selected month, the departure account contributes one.
For example:
| Employee | End Date | June Departures |
| Employee A | June 20 | 1 |
| Employee B | August 15 | 0 |
| Employee C | Blank | 0 |
The June departure count is 1.
An employee without an End Date does not have a departure month identified by this calculation.
We still need to verify that missing dates represent active employment rather than incomplete source data.
7. Classifying employee departures
The model also contains separate calculated accounts for departure reasons:
- At Will
- Retiring
- Restructuring
These accounts use the departure count and the employee’s End Reason.
For example, if an employee leaves in June and the reason is Retiring, the retirement account records the departure for June.
| Departure Reason | June Departures |
| At Will | 2 |
| Retiring | 1 |
| Restructuring | 1 |
| Total Classified | 4 |
These are illustrative values.
Important configuration consideration
The example formula compares the departure reason with the account name.
This means the classification depends on the values matching the expected labels.
If the source contains a different description, such as Retirement instead of Retiring, the expected category may not populate.
When we troubleshoot departure classifications, we compare the values supplied by the source data with the configured model conditions.
We also check whether additional departure reasons exist.
The sum of the three categories may not equal total departures if some employees have other or missing departure reasons.
8. Calculating Headcount Movement and Ending Headcount
The relationship between arrivals, departures and closing headcount is straightforward.
Headcount Movement = Arrivals − Departures
Ending Headcount = Starting Headcount + Headcount Movement
Let’s look at an example.
| Account | January | February | March |
| Starting Headcount | 100 | 103 | 105 |
| Arrivals | 5 | 4 | 3 |
| Departures | 2 | 2 | 1 |
| Movement | 3 | 2 | 2 |
| Ending Headcount | 103 | 105 | 107 |
All figures are illustrative.
For January:
5 − 2 = 3
100 + 3 = 103
February then begins with a headcount of 103.
This allows the model to maintain a continuous workforce balance across months, provided the underlying employee records and calculation logic are consistent.
What happens if an employee joins and leaves in the same month?
An employee who joins and leaves during February has:
- Starting Headcount: 0
- Arrivals: 1
- Departures: 1
- Movement: 0
- Ending Headcount: 0
Although the ending balance is zero, the employee may still have worked part of February.
This is where Average Headcount becomes important.
9. Understanding Average Headcount
The Current Workers model uses a date-based calculation for Average Headcount.
It uses Workday Adaptive Planning’s MonthFraction function.
Workday documents that this function returns the portion of a month falling between two dates.
For workforce planning, it allows an employee to contribute a fractional headcount based on the employment dates within the month.
Example
Suppose an employee joins partway through June.
Instead of automatically counting the employee as one for the full month, the model calculates the portion of June covered by the employment dates.
An employee active for the entire month can contribute a value of 1.
An employee active for only part of the month contributes a fractional value.
The precise fraction depends on the dates and calculation parameters.
Why does this matter?
Starting and Ending Headcount represent balances at particular points.
Average Headcount is intended to represent workforce presence during the period.
This is useful when calculating costs based on time worked.
It also means that an employee can have an ending headcount of 1 but an average headcount below 1 in the month they join.
10. Calculating Salary
Salary is a periodic calculated account.
In this model, salary depends on:
- Average Headcount
- Workdays in the month
- Workdays in the year
- Base Pay Rate
The business calculation can be summarized as:
Salary Cost = Average Headcount × (Monthly Workdays / Annual Workdays) × Base Pay Rate
This example assumes Base Pay Rate represents an annual compensation amount.
Example
Suppose an employee has:
| Driver | Value |
| Annual Base Pay | 120,000 |
| Workdays in Month | 20 |
| Workdays in Year | 240 |
| Average Headcount | 1 |
Salary cost is:
120,000 × (20 / 240) × 1 = 10,000
If the average headcount is 0.5, the same calculation produces 5,000.
This is an illustrative calculation.
The actual salary result depends on the configured workday assumptions, employee dates and applicable pay rate.
Important consideration
We need to confirm whether the pay rate is annual, monthly or hourly before using it in a formula.
We also need to confirm the prorating method.
A date-based headcount fraction and a workday-based compensation factor serve different purposes. They should be combined only when that reflects the intended compensation policy.
11. Calculating Benefits
Benefits can be calculated using an employee’s headcount and a benefit cost assumption.
In the example model, the calculation uses Ending Headcount multiplied by a benefit amount per headcount.
A simplified calculation is:
Benefits Cost = Ending Headcount × Benefit Cost per Employee
For example:
| Driver | Value |
| Ending Headcount | 1 |
| Monthly Benefit Cost | 800 |
| Calculated Benefits | 800 |
This means the model uses the ending balance rather than Average Headcount for this expense.
We should confirm that this reflects the company’s benefit policy.
For an employee joining near month-end, a full monthly benefit charge may or may not be appropriate.
The calculation is a model design decision, not a universal Workday rule.
12. Calculating Employer Paid Taxes
Employer Paid Taxes is another calculated account.
The example model uses Salary and an employer tax rate.
The general relationship is:
Employer Paid Taxes = Salary × Employer Tax Rate
For example:
| Measure | Amount |
| Salary | 10,000 |
| Employer Tax Rate | 8% |
| Employer Paid Taxes | 800 |
The result is 800.
In an actual implementation, the applicable tax rate may vary by country, employee type, compensation component or payroll rules.
We should validate the rate assumptions and the salary components included in the calculation.
13. Calculating Other Employee Costs
The Current Workers model contains several additional cost accounts.
These include Stock Compensation Expense, Severance, Contingent Labor and Talent Acquisition.
The formulas use different combinations of employee status, compensation, prior-period values and assumptions.
Stock Compensation Expense
The model references a compensation rate and historical salary information.
The calculation also includes a headcount condition.
We need to verify the compensation policy and the meaning of the historical reference before assuming this represents a standard stock compensation calculation.
Severance
Severance uses departure information and supporting assumptions.
The model considers factors such as:
- Whether the employee departs
- Whether the employee is eligible for severance
- Years of employment
- Severance days per year
- Prior-period compensation
For example, a company may calculate severance based on completed years of service and an agreed number of days of pay per year.
The exact calculation depends on the applicable policy and legal requirements.
Contingent Labor
The model contains a Contingent Labor calculation that references prior-period salary and a particular departure classification.
This represents a model-specific planning rule.
It should not be interpreted as the standard method for calculating contractor costs.
Talent Acquisition
The Talent Acquisition account uses a departure condition and an earlier compensation value to calculate an expense.
This may represent a replacement or recruiting-cost assumption.
We need to confirm the intended business rule before describing the output as actual recruitment expense.
These examples show how modeled sheets can calculate different workforce costs from employee-level data and assumptions.
14. Calculating Age and Years of Employment
The model also contains calculated accounts for Age and Years of Employment.
Age
Age uses the employee’s birth date and the selected period.
The formula estimates age using the difference between dates.
We should validate the precision when exact birthdays are important, particularly around leap years and anniversary dates.
Years of Employment
Years of Employment uses the employee’s start date and the current planning period.
It derives completed years using the difference between the version months.
This is useful for calculations such as severance or tenure analysis.
However, the model’s calculation is based on whole-month and whole-year logic rather than an exact day-by-day anniversary calculation.
We verify the business requirement before using the result for a statutory or contractual payment.
15. Calculating Available Support Hours
Available Support Hours represents workforce capacity.
The example model uses:
- A worker eligibility indicator
- Workdays in the month
- Average Headcount
- Hours per workday
A simplified calculation is:
Available Hours = Eligible Worker Indicator × Workdays × Average Headcount × Hours per Day
For example:
| Driver | Value |
| Eligible Worker | 1 |
| Workdays | 20 |
| Average Headcount | 1 |
| Hours per Day | 8 |
| Available Hours | 160 |
This provides a planning estimate of support capacity.
The calculation assumes eight hours per day in this example.
For more complex workforce models, we may need separate assumptions for part-time employees, regional working hours, holidays, leave and other availability factors.
16. Current Workers versus Headcount Supply
The Current Workers modeled sheet calculates data at the individual worker-record level.
The Headcount Supply cube brings together workforce information for planning and reporting.
A simplified relationship is:
Current Workers → Headcount Supply → Headcount Targets
Each model has a different purpose.
| Model | Purpose |
| Current Workers | Calculates employee-level headcount, movement and workforce costs |
| Headcount Supply | Consolidates worker and requisition supply information |
| Headcount Targets | Compares workforce demand and supply and manages target movements |
The models may be connected using linked accounts.
For example, the Supply cube can receive total worker headcount from Current Workers.
We should validate these links at the correct level and dimension intersections.
17. How to Configure a Current Workers Modeled Sheet
When building a similar modeled sheet, we follow a practical sequence.
Step 1: Define worker records
Identify the information required for each employee or position.
This may include worker identifiers, start dates, end dates, compensation rates and organizational assignments.
Step 2: Create the modeled sheet
Use the Modeled sheet option under Level Assigned Sheets or User Assigned Sheets.
Step 3: Configure columns
Add the required text, date, number, dimension, selector and Initial Balance columns.
Step 4: Create modeled accounts
Create the calculated accounts required for headcount, movement and workforce costs.
Step 5: Configure assumptions
Maintain the required benefit rates, workday counts, tax rates and other drivers.
Step 6: Validate date formulas
Test the calculation behavior for employees joining, leaving and working for only part of a month.
Step 7: Validate compensation calculations
Compare calculated salary and other costs with independently calculated examples.
Step 8: Configure downstream links
Connect the modeled accounts to the Headcount Supply cube or other reporting accounts where required.
Step 9: Review security
Verify access to employee and compensation details before making the sheet available to users.
18. Common Issues in Current Workers Models
| Issue | What we check |
| Starting Headcount is incorrect | Start Date, End Date and period comparison |
| Employee arrival is missing | Start Date and selected planning month |
| Employee departure is missing | End Date and selected planning month |
| Departure reason is incorrect | Source reason and classification formula |
| Ending Headcount does not reconcile | Starting Headcount, Arrivals and Departures |
| Average Headcount is unexpected | Employment dates and MonthFraction calculation |
| Salary is incorrect | Average Headcount, pay rate and workday assumptions |
| Benefits appear overstated | Ending Headcount-based benefit calculation |
| Severance is incorrect | Eligibility, tenure and compensation assumptions |
| Available hours are incorrect | Worker eligibility, workdays and hours per day |
| Supply cube does not match workers | Linked account mappings, periods, levels and dimensions |
We should always begin with one employee record and one month.
Once the row-level calculation is correct, we can reconcile department and company totals.
This makes it easier to identify whether a difference comes from the employee data, the formula or the downstream aggregation.
19. Protecting Employee and Compensation Data
Workforce modeled sheets can contain sensitive employee information.
Workday Adaptive Planning provides Salary Detail security settings for modeled sheets.
When the sheet property requiring Salary Detail permission is enabled, users need the appropriate permission to view the detailed modeled sheet.
We configure this under:
Modeled Sheet → Columns and Levels → Sheet Properties → Security
We also review the permissions of users who access reports and linked accounts.
Protecting the modeled sheet does not automatically mean all aggregate results are hidden everywhere.
Workday documents additional considerations when sensitive modeled accounts are used in reports, charts, formulas and other sheets.
We therefore review the complete data-access path rather than relying on one security setting.
20. Summary
| Area | Main calculation or configuration |
| Starting Headcount | Employee active at the beginning of the period |
| Arrivals | Employee start month |
| Departures | Employee end month |
| Departure Reasons | Classification based on End Reason |
| Movement | Arrivals minus Departures |
| Ending Headcount | Starting Headcount plus Movement |
| Average Headcount | Active fraction of the month |
| Salary | Headcount fraction, workday assumptions and pay rate |
| Benefits | Headcount-based benefit assumption |
| Employer Taxes | Salary and employer tax rate |
| Severance | Departure eligibility, tenure and compensation |
| Support Hours | Workdays, headcount and daily hours |
| Base Pay Rate | Initial Balance account used in compensation calculations |
Conclusion
The Current Workers modeled sheet provides the detailed calculations behind workforce planning in Workday Adaptive Planning.
It uses worker records, employment dates, compensation inputs and planning assumptions to calculate headcount movements and workforce costs.
Starting Headcount, Arrivals, Departures and Ending Headcount describe the workforce balance.
Average Headcount uses the employee’s active portion of the month.
Salary, benefits, taxes and other employee expenses use these workforce measures together with compensation and policy assumptions.
When we build or troubleshoot the model, we first validate the employee-level calculations.
We then check how the results flow into Headcount Supply, Headcount Targets and financial reporting.
This approach helps us maintain consistent workforce calculations across the planning model.
