When we work in Workday Adaptive Planning, Model Management is where we configure and maintain the structure of the planning application.
This includes versions, time, accounts, levels, dimensions, sheets, formulas, rules and other settings that control how data is entered, calculated and reported.
Before we create a new budget, change an account, or troubleshoot a calculation, we need to understand how these components are connected.
In this article, we first look at Model Management and then focus on Version Management, including Actuals, Actuals subversions, budgets, forecasts and common planning scenarios.
1. What is Model Management?
We access Model Management from:
Modeling → Model Management
The page brings together the main configuration areas of Workday Adaptive Planning.
The screenshot shows eight sections.
| Area | What we manage |
|---|---|
| Versions and Time | Actuals, budgets, forecasts, planning versions and calendar settings |
| Levels and Dimensions | Organization hierarchies, dimensions and attributes |
| Accounts | General Ledger, Metric, Custom and Assumption accounts, account attributes and formula validation |
| Rules | Allocation and elimination rules |
| Sheets | Level-assigned and user-assigned sheets |
| Intelligent Planning | Predictive Forecaster and Anomaly Detection |
| Planning Center | Model configuration, sheet usage and performance metrics |
| Others | Currencies, exchange rates, transactions, consolidation percentages and announcements |
Each section has a different purpose, but they work together within the same model.
For example, suppose Finance needs to prepare a department expense budget for 2027.
We need an appropriate Plan version, the relevant time periods, department levels, expense accounts and an input sheet.
If the company also plans expenses by location or business unit, we may need custom dimensions.
If costs are distributed between departments, allocation rules or formulas may also be required.
So, creating a budget is not only about creating a new version. The model structure must support the complete planning requirement.
2. How Model Management components work together
Every planning value belongs to a particular intersection.
For example:
| Component | Example |
|---|---|
| Account | Travel Expense |
| Level | Finance Department |
| Version | 2027 Budget |
| Time | January 2027 |
| Dimension | Business Unit A |
| Amount | 25,000 |
The amount of 25,000 belongs to that particular combination.
If we change the version to 2027 Forecast, we are looking at a different planning dataset.
If we change the department, account, period or business unit, we are looking at another intersection.
This is important when troubleshooting data differences. Two reports can show different amounts simply because they use different versions, levels, periods or dimensions.
The model components define where the data belongs. Versions help us maintain different sets of data within that model.
3. What is a version in Workday Adaptive Planning?
A version represents a particular set of financial or operational data used for planning and reporting.
Workday Adaptive Planning supports two main version types:
- Actuals versions
- Plan versions
Actuals versions represent historical results.
Plan versions contain budgeting, forecasting and other planning data.
These versions use the same underlying model structure, although availability and certain settings can differ by version.
For example, we may have:
| Version | Purpose |
|---|---|
| Actuals | Historical financial results |
| 2027 Budget Working | Budget preparation |
| 2027 Budget Approved | Approved annual budget |
| 2027 Forecast | Latest expected results |
| 2027 Forecast Scenario | Alternative planning assumptions |
| Long Range Plan | Multi-year financial planning |
These are example names, not predefined Workday version names.
We create versions based on the planning process. We do not need a separate version for every report or business question.
4. Understanding the Actuals version hierarchy
We open Version Management from:
Modeling → Model Management → Versions
The screenshot shows the following hierarchy:
- Actuals
- Pre-Elimination
- Source System
- Adjustment JEs
- Allocations
- Pre-Elimination
This is an Actuals structure with multiple layers.
The names and hierarchy reflect how this particular model is configured. They are not a mandatory structure for every Adaptive Planning implementation.
Actuals
Actuals is the root version.
It provides the historical results used for financial reporting, variance analysis and comparison with plans.
When Actuals contains subversions, the parent displays the combined values from the versions underneath it.
Pre-Elimination
Pre-Elimination is a parent subversion in the screenshot.
It combines the values from its child versions before any separate elimination layer that may exist elsewhere in the Actuals hierarchy.
Because this parent has children, its values are calculated through the version rollup rather than entered directly into the parent.
Source System
The Source System subversion is intended in this example to store actuals loaded from an external source, such as Workday Financial Management or another ERP system.
We may load account balances or other supported financial data through an integration.
The important point is to maintain a clear distinction between imported source data and adjustments made within the planning application.
Adjustment JEs
Adjustment JEs is a journal entry version.
Where the Workday Adaptive Planning consolidation functionality is enabled, journal entry versions support balanced accounting adjustments.
These entries can be used for corrections, accruals or reclassifications without changing the original imported actuals.
Journal entries are managed through the journal entry functionality, not by directly typing values into cells of the journal entry version.
Allocations
The Allocations subversion is used in this example to separate allocation-related results from imported actuals and journal adjustments.
Allocation rules can distribute costs between levels using a defined allocation basis.
For example, shared costs may be allocated to departments based on headcount.
The exact accounts, source versions, target versions and calculation behavior depend on the configured allocation rules.
A subversion named Allocations does not automatically calculate anything simply because it exists.
5. How Actuals subversions roll up
Let’s take a simplified example.
Assume we are reviewing one expense account, one department and one month.
| Actuals layer | Amount |
|---|---|
| Source System | 100,000 |
| Adjustment JEs | 5,000 |
| Allocations | 10,000 |
| Pre-Elimination | 115,000 |
In this example, the adjustment increases the expense by 5,000 and the department receives an additional allocation of 10,000.
Pre-Elimination therefore displays 115,000.
The journal entry must also contain its balancing debit or credit elsewhere. The table shows only the effect on the selected expense account.
If the root Actuals hierarchy includes additional sibling versions, such as Eliminations, those values also contribute to the final Actuals rollup.
This is why we check the complete version hierarchy when reconciling Actuals.
Can we edit the parent Actuals version?
When an Actuals version has child versions, it becomes a rollup version.
We cannot directly edit the parent version’s data.
For normal Actuals subversions, data entry or import is possible at leaf versions, subject to access controls and other restrictions.
Journal entry versions are a special case because adjustments are posted through balanced journal entries.
This separation helps us identify where an amount originates.
6. Creating and managing Actuals subversions
To create an Actuals subversion, we open Versions, select the intended parent and use the toolbar option to create an Actuals version.
We then configure the name, description and access settings.
If consolidation is available, we can create a journal entry version when balanced adjustment entries are required.
There is an important point when creating the first Actuals subversion: Workday documents that existing root Actuals data moves into that first child version and continues rolling up to the root.
We therefore review existing data, integrations and reporting dependencies before changing the hierarchy.
Important Actuals settings
| Setting | What it controls |
|---|---|
| Start of Version | Earliest available Actuals period |
| End of Version | Latest available Actuals period |
| Completed Values Through | Latest completed period used for Actuals overlay |
| Lock Leading Months Through | Historical periods protected from editing |
| Access Control | Who can view, edit, import or access version data, depending on version type |
| Audit Trail | Tracking changes to supported data and formulas |
Most time-related settings are maintained at the root Actuals version, with inherited behavior for its descendants.
For example, after Finance completes and validates August actuals, the Completed Values Through setting may be updated to August.
This matters when a forecast uses Actuals overlay.
7. What is a Plan version?
Plan versions contain budget or forecast data.
Unlike the Actuals hierarchy, where subversions roll up into parent Actuals, normal Plan versions represent separate planning datasets.
For example:
- 2027 Budget Working
- 2027 Budget Approved
- 2027 Forecast
- 2027 Forecast Optimistic
- 2027 Forecast Conservative
Each serves a specific planning purpose.
A Working Budget allows planners to change inputs.
An Approved Budget preserves the agreed financial targets.
A Forecast reflects the latest expected performance.
An alternative forecast allows Finance to test different assumptions without replacing the main forecast.
Plan versions can also be organized into folders to make the version list easier to manage.
8. Creating a new Plan version
We navigate to:
Modeling → Model Management → Versions
We select the source version, then use the toolbar to create a Plan version.
Depending on the requirement, we can create a version with blank data, copy selected structures and settings, or copy planning data from another version.
Workday provides options for copying data, shared formulas, overrides, modeled rows, dimension splits and notes.
We review these options rather than assuming everything automatically copies.
For example, when creating the 2027 Budget Working version from an existing budget, we may want to copy:
- Account data and formulas
- Modeled sheet rows
- Dimension splits
- Relevant assumptions
- Planning values from the source version
For a fresh planning cycle, we may instead copy the required structure and leave the numbers blank.
After creating the version, we check that the source settings, formulas, rows and planning data were copied as intended.
Key Plan version settings
| Setting | Purpose |
|---|---|
| Left Scroll Limit | Earliest visible period in the Plan version |
| Start of Plan | First period of plan data and boundary for Actuals overlay |
| End of Plan | Last period in the planning horizon |
| Actuals Version for Overlay | Actuals version used in the plan, where applicable |
| Locked Version | Restricts changes after a version is finalized |
| Lock Leading Months Through | Protects specified historical planning periods |
| Default | Identifies the default version for users |
| Access Control | Controls version availability and editing permissions |
These settings influence both the planning process and reporting behavior.
9. Scenario 1: Annual budget planning
Let’s assume Finance prepares the 2027 annual budget.
We create:
2027 Budget Working
The planning period covers January through December 2027.
Department planners enter expenses, workforce costs, revenue assumptions and other required values.
After Finance reviews and approves the budget, we can create or preserve an approved version:
2027 Budget Approved
We lock the approved version to prevent normal planning edits.
The Working version can remain available for further analysis or controlled updates.
This gives us two clear datasets:
- Working Budget: Planning activity
- Approved Budget: Financial target used for reporting
We should remember that locking a Plan version does not completely isolate it from every structural change to the model. Changes to accounts, dimensions, levels and some calculations can still affect locked versions.
Where stronger historical preservation is required, we review the Archive Version option and its limitations.
10. Scenario 2: Rolling forecast using Actuals overlay
Actuals overlay allows a Plan version to display actual historical values alongside future plan values.
For example, Finance prepares a forecast in September 2026.
Actuals are completed through August 2026.
The expected result is:
| Period | Forecast view |
|---|---|
| January–August 2026 | Actuals |
| September–December 2026 | Forecast |
We configure the Actuals version and Plan version so that the completed periods display actual results and future periods display planned amounts.
Two settings are particularly important:
Completed Values Through, maintained in Actuals, and Start of Plan, maintained in the Plan version.
Actuals overlay stops at the earlier applicable boundary.
We also check the account-level Actuals overlay settings because an account can be configured to show plan data instead of actuals.
Example: When the periods do not align
Suppose Actuals are completed through August, but the forecast’s Start of Plan is October.
September may display plan data rather than Actuals because September falls after the completed Actuals period but before the start of the new planning period.
That may be intentional, or it may indicate that the forecast settings need to be reviewed.
We should not assume every account and period automatically switches to Actuals.
11. Scenario 3: Creating alternative forecast versions
Suppose management wants to understand how a change in revenue assumptions affects profitability.
We have the current forecast:
2027 Forecast Base
We create another Plan version:
2027 Forecast Conservative
We copy the required data and formulas from the base forecast, then change selected assumptions in the new version.
For example:
| Driver | Base Forecast | Conservative Forecast |
|---|---|---|
| Revenue growth | 8% | 4% |
| Salary increase | 5% | 5% |
| Operating cost growth | 6% | 7% |
These are illustrative planning assumptions.
We can then compare revenue, expenses and profitability between the versions.
The key benefit is that the base forecast remains available while the alternative version uses its own planning data.
We still need to verify shared formulas, dependencies and any links that may reference other versions.
12. Scenario 4: Reconciling Actuals against Budget
Assume Finance reviews monthly department spending.
| Version | Expense |
|---|---|
| Actuals | 120,000 |
| 2027 Budget Approved | 100,000 |
| Variance | 20,000 |
Here, Actuals exceed Budget by 20,000.
We can create reports to compare the two versions at the required account, period, level and dimension intersections.
If the values do not reconcile, we verify:
- Which Actuals version or subversion the report uses.
- Whether the Budget version is the approved or working version.
- Whether both versions use the same level, account and dimension filters.
- Whether period, currency and time aggregation settings match.
- Whether allocations, journal entries or other adjustments affect the reported Actuals.
A version comparison only makes sense when we compare the correct data intersections.
13. Scenario 5: Controlling access and protecting historical versions
During a planning cycle, multiple versions may exist at the same time.
Some need to remain editable. Others are used only for reporting.
Workday supports different version access settings, including locking and hiding versions.
For example:
| Version | Typical treatment |
|---|---|
| Current Working Forecast | Editable for authorized planners |
| Approved Annual Budget | Locked |
| Prior Forecast | Locked or hidden where appropriate |
| Temporary Scenario | Restricted to the relevant planning users |
| Historical Actuals | Completed periods locked based on the close process |
The exact permissions depend on the user types, access controls, levels and version settings.
We review these controls before giving users access to planning sheets.
A user having access to a sheet does not automatically mean the selected version is editable.
14. What we check before changing versions
When we review Version Management in an existing model, we focus on the following:
Version purpose: Do we know why each version exists and who uses it?
Actuals structure: Do source data, journal entries, allocations and other layers roll up correctly?
Plan setup: Are the planning periods, assumptions, source versions and copy settings appropriate?
Actuals overlay: Are completed historical periods and future planning periods displayed correctly?
Access: Can the right users view or edit the required versions?
Reporting: Are reports pointing to the intended Actuals, Budget and Forecast versions?
Governance: Are approved budgets protected, and are old or unused versions handled appropriately?
We also check integration dependencies before deleting, renaming or restructuring versions.
15. Summary: Actuals and Plan versions
| Scenario | Version type | Main consideration |
|---|---|---|
| Historical GL results | Actuals | Correct source data and mappings |
| Accounting adjustments | Actuals journal entry version | Balanced and controlled journals |
| Allocation results | Actuals subversion, where configured | Correct rule scope and allocation amounts |
| Annual budget | Plan | Planning inputs and approved baseline |
| Rolling forecast | Plan | Actuals overlay and future periods |
| Alternative scenarios | Plan | Separate assumptions and calculations |
| Historical comparison | Actuals and Plan | Correct versions and matching report intersections |
Conclusion
Model Management defines the structure of Workday Adaptive Planning. Versions determine how different sets of actual, budget and forecast data are managed within that structure.
Actuals subversions help separate imported values, journal adjustments and other actuals-related activity.
Plan versions support budgeting, forecasting and alternative scenarios.
When we design or troubleshoot a model, we need to understand both the version hierarchy and the underlying accounts, levels, dimensions, time periods, formulas and access settings.
A clear version structure makes the planning process easier to operate, reconcile and maintain
