Integrating actuals from Workday Financial Management into Workday Adaptive Planning is not simply a data loading exercise.
A loader can complete successfully and the Planning numbers can still be wrong.
The real test is whether Finance can answer these questions:
- What data came from Workday?
- Which records were supposed to load?
- Which records were excluded and why?
- How were Workday accounts, companies, cost centers and worktags mapped?
- What value was submitted by the loader?
- What value landed in Adaptive Planning?
- Why does a variance exist if the two systems do not match?
- Can the integration safely be rerun?
A reliable Workday Financials to Adaptive Planning integration must therefore be designed around reconciliation from the beginning.
A practical architecture is:
Workday Financial Management
to
Workday report or journal line source
to
Adaptive Planning Workday Data Source
to
Adaptive Planning staging
to
mapping and transformation
to
Planning Data Loader
to
Adaptive Planning Actuals
to
reconciliation and reporting
Workday Adaptive Planning provides native integration components for this pattern. Workday Data Sources can import Workday report data, journal line summaries and metadata into staging. Planning loaders can then load accounts, levels, dimensions, attributes and financial data into Adaptive Planning.
The technology is only one part of the solution.
The architecture determines whether the resulting numbers can be controlled, explained and reconciled.
1. Define the reconciliation grain first
The first question should not be:
Which Adaptive Planning account should this data load to?
The first question should be:
At what grain must Workday and Adaptive Planning reconcile?
For a relatively simple income statement model, the required grain may be:
Company
Cost Center
Ledger Account
Period
A more dimensional Planning model may also require:
Fund
Location
Spend Category
Revenue Category
Project
Other Worktags
A detailed reconciliation process may require journal or journal line identifiers as well.
This decision is important because the reconciliation grain drives almost every downstream design choice.
It affects:
- Workday report design
- Fields retained in Adaptive staging
- Mapping keys
- Transformation logic
- Loader configuration
- Aggregation
- Exception reporting
- Drillback
- Reconciliation controls
If Workday contains journal line detail but the integration aggregates that data before the identifiers required for investigation are retained, the final Planning total may still be correct, but explaining individual differences becomes much harder.
Define the required reconciliation grain before building the loader.
2. Choose the correct Workday source
Workday Adaptive Planning supports Workday Data Sources that can import information from Workday.
The source may be based on Workday reports or supported Financial Management journal line summary functionality, depending on the requirement.
For custom Workday reports used with Adaptive Planning, Workday documentation specifies that they should be created as Advanced Reports and enabled appropriately for integration use.
For a financial actuals integration, the source should contain enough information to support both the Planning requirement and the reconciliation requirement.
Typical fields may include:
- Company
- Ledger Account
- Cost Center
- Accounting Date
- Amount
- Currency
- Required Worktags
- Journal Status
- Book
- Transaction reference
- Journal or journal line identifiers where required
Do not select fields only because they are required to make the loader run.
Retain the fields required to explain the result later.
3. Treat the Workday report as an interface
A Workday report feeding Adaptive Planning is not just a reporting artifact.
It is part of the integration interface.
That means changes to the report can affect the Planning process.
Consider these examples:
A Workday report filter changes from Posted journals to all journals.
A company filter changes.
A calculated field is modified.
A Worktag is removed.
The accounting period logic changes.
A new ledger account becomes available.
Any of these changes can alter the population received by Adaptive Planning.
The source report should therefore have clear ownership and controlled change management.
Stable source identifiers should also be preferred for mappings where practical.
Display names are useful for users.
Reference identifiers and codes are generally more reliable for integration keys.
4. Use Adaptive Planning staging as a control point
Data imported from Workday is available in Adaptive Planning staging before it is loaded into the Planning model.
This layer should be actively used for reconciliation.
Before loading anything into Planning, the integration should be able to answer:
How many source rows arrived?
Which periods are present?
Which companies are present?
Which ledger accounts are present?
What is the source amount total?
Which records have missing account mappings?
Which records have missing level mappings?
Which records will be excluded?
Which records are unexpected?
This creates an important separation between:
What Workday provided
and
What Adaptive Planning will load
Without this separation, troubleshooting usually starts too late.
5. Separate the source population from the eligible population
A common reconciliation mistake is comparing the complete Workday source with a deliberately filtered Adaptive Planning population.
Consider a source that contains:
- Gross expenses
- Net expenses
- Salary
- Balance sheet accounts
- Posted journals
- Cancelled journals
- Multiple companies
- Multiple books
- Records outside the planning scope
The Adaptive Planning loader may intentionally load only:
- Gross expenses
- Selected income statement accounts
- Posted transactions
- Approved companies
- Valid planning levels
- One defined planning population
The raw Workday total should not equal the Adaptive Planning total in this situation.
The populations are different.
The correct reconciliation is:
Workday raw population
minus documented exclusions
equals eligible population
Eligible population
equals loader population
Loader population
equals Adaptive Planning result
This distinction is fundamental.
A population difference is not automatically an integration error.
6. Make exclusions explicit
Exclusions are normal in financial integrations.
What matters is whether they are controlled and explainable.
Examples may include:
- Balance sheet accounts
- Cancelled journals
- Companies outside Planning scope
- Specific books
- Unsupported transaction types
- Historical periods
- Expense categories outside the model
- Records missing required planning attributes
A good integration should distinguish between:
Included
Excluded because of an approved business rule
Unmapped and requiring investigation
Invalid source data
Unexpected record
This is better than silently dropping rows through a SQL filter.
A finance user should be able to understand why the Workday source population became the Adaptive Planning load population.
7. Design Workday to Adaptive Planning mappings explicitly
Workday Financial Management and Adaptive Planning do not always use the same structures.
For example, Workday may organize financial information using:
Company
Cost Center
Ledger Account
Worktags
Adaptive Planning may use:
Level
Account
Dimension values
A common mapping pattern is:
Workday Cost Center plus Workday Company
to
Adaptive Planning Level
Another common mapping is:
Workday Ledger Account
to
Adaptive Planning Account
In some designs, multiple Workday fields are required to create one Adaptive Planning mapping key.
Workday documentation describes using SQL columns in staging to combine source values for mappings.
For example:
Company ID + Cost Center ID
can create the source key used to identify an Adaptive Planning level.
This is particularly useful where the same cost center code may exist across multiple companies.
8. Expose mapping status before loading
Do not wait for the loader to fail before identifying mapping problems.
A useful staging design can expose fields such as:
Source Company
Source Cost Center
Source Ledger Account
Target Adaptive Account
Target Adaptive Level
Mapping Status
Exclusion Reason
For example:
Included
Excluded – Balance Sheet
Excluded – Cancelled
Excluded – Outside Planning Scope
Unmapped – Account
Unmapped – Level
Review Required
This provides a controlled view of the population before Planning data changes.
It also makes support much easier.
9. Understand the Planning Data Loader
Adaptive Planning Planning Data Loaders move data from staging into Planning.
Workday documentation describes Planning Data Loaders as supporting loads into:
- GL accounts
- Cube sheets
- Modeled sheets
- Transaction tables
Loaders can also use:
- Mapping profiles
- SQL filters
- Business rules
- Loader parameters
- Preview
- Integration Tasks
The loader is therefore another control point.
Before running it, validate:
Source staging table
Amount field
Period field
Account mapping
Level mapping
Dimension mappings
Filters
Version
Target
Business rules
Do not assume that correct staging data automatically results in a correct Planning load.
10. Use loader preview as a reconciliation control
Loader preview should be part of the validation process.
Before loading data, inspect what Adaptive Planning is about to receive.
Questions include:
How many records or intersections are being submitted?
Which accounts will receive values?
Which levels will receive values?
Which periods are included?
Are there unmapped records?
Are unexpected companies present?
Are excluded accounts still appearing?
Does the loader population total equal the expected eligible source population?
This can identify many issues before Planning data is changed.
Reconciliation should begin before the load, not after it.
11. Validate the amount field
Financial source systems can contain several amount fields.
Examples include:
Transaction currency amount
Company base currency amount
Ledger currency amount
Reporting currency amount
Calculated converted amount
The correct field must be defined explicitly.
Do not select an amount because its column name appears appropriate.
Validate it against known transactions.
For example:
Source transaction
to
Workday report amount
to
Adaptive staging amount
to
loader output
to
Adaptive Planning value
The amount field should be proven using controlled samples before a large load is executed.
12. Validate currency separately
Currency problems can be difficult because the error may not appear at the leaf level where the data is loaded.
Suppose the source amount has already been converted to USD.
The value is then loaded to an Adaptive Planning level whose currency is GBP.
If the Planning model interprets the loaded value as GBP and performs translation at a parent level, the resulting rollup may differ even though the source, staging and loader values match.
The investigation must therefore separate:
Source currency treatment
from
Adaptive Planning currency treatment
A useful test is:
Source transaction
to
staging amount
to
loader output
to
Adaptive leaf value
to
Adaptive parent rollup
If the source, staging, loader and leaf value all match but the parent result does not, the issue is probably not the Workday extraction.
Investigate the Planning model, account configuration, level currency and rollup behavior.
13. Test at leaf level before testing parent totals
A top level P&L contains many variables.
A single account and level contains far fewer.
When troubleshooting, choose a controlled intersection.
For example:
One account
One level
One period
Then compare that same intersection through every layer.
Workday
Adaptive staging
Loader preview
Adaptive Planning leaf value
Parent rollup
Once that works, expand the reconciliation.
This is much faster than starting with an annual P&L variance and trying to work backward.
14. Do not change model configuration just to eliminate a variance
A zero variance is not useful if nobody understands why it became zero.
When Workday and Adaptive Planning do not match, possible causes include:
- Different source populations
- Incorrect report filters
- Account mapping
- Level mapping
- Missing dimensions
- Wrong amount field
- Currency treatment
- Loader filters
- Duplicate records
- Stale Planning values
- Formula behavior
- Hierarchy configuration
- Different accounting periods
Changing Adaptive configuration until the total happens to match is not reconciliation.
Identify the cause first.
Then change the layer responsible for the problem.
15. Separate source reconciliation from Planning reconciliation
These are different control activities.
Source reconciliation
The objective is to prove that the approved staging population represents the intended Workday population.
Validate:
- Row counts
- Account totals
- Company totals
- Period totals
- Transaction status
- Gross or Net scope
- Required Worktags
- Exclusion rules
Planning reconciliation
The objective is to prove that the approved population loaded correctly into Adaptive Planning.
Validate:
- Account
- Level
- Period
- Dimensions
- Amount
- Currency
- Hierarchy rollup
- Existing data
- Rerun behavior
A source can reconcile correctly while Planning still contains a problem.
Planning can also be correct while the original comparison uses the wrong source population.
Keep these investigations separate.
16. Reconcile record counts as well as values
Finance teams often reconcile only the monetary value.
That is not enough.
Two populations can have the same total while containing different transactions.
Useful controls include:
Source row count
Eligible row count
Excluded row count
Loader output count
Loaded intersection count
Unmapped account count
Unmapped level count
Exception count
Amount reconciliation
Count reconciliation and value reconciliation should both be part of the control framework.
17. Reconcile progressively
Do not immediately reconcile every dimension at once.
Start broadly and progressively increase the grain.
For example:
Total
then
Period
then
Company
then
Account
then
Level
then
Dimension
then
Transaction or journal line where required
Suppose the total matches but one company does not.
The investigation is now limited to that company.
Suppose the company matches but one account does not.
The problem is smaller again.
This approach is faster than inspecting the complete integration every time.
18. Design reruns before automating
An actuals integration will eventually be rerun.
Reasons include:
- Source correction
- Mapping correction
- Reopened accounting period
- New transactions
- Reversed journals
- Failed integration
- Workday report change
- Planning model correction
The architecture therefore needs to define what happens on the second run.
Questions include:
Does the loader append or replace?
What existing Planning data is affected?
Can old values remain if they disappear from the new source population?
Can the same data load twice?
Which periods are cleared or replaced?
What happens if a mapping changes?
How is a failed load recovered?
How is rollback handled?
Automation should not be introduced until these behaviors are understood.
Workday Adaptive Planning Integration Tasks can schedule and orchestrate integration processes, but automation only repeats the design that already exists.
A bad integration does not become reliable because it runs automatically.
19. Use Integration Tasks after the process is proven
A practical implementation sequence is:
- Build the Workday source
- Import into Adaptive staging
- Validate the staging population
- Build mappings
- Preview the loader
- Run a controlled test
- Reconcile
- Test rerun behavior
- Resolve exceptions
- Automate
Adaptive Planning Integration Tasks can then be used to schedule the required steps.
This sequence reduces risk because automation is added only after the manual process has been proven.
20. Use drillback where it adds value
Adaptive Planning supports Workday External Systems that can be associated with mapping profiles.
Where correctly configured, this can enable users to drill from Adaptive Planning data into Workday.
This can improve investigation because Finance can move from a Planning result toward the underlying Workday information.
Drillback does not replace reconciliation.
It improves traceability.
21. Use a clear troubleshooting sequence
When Workday Financial Management and Adaptive Planning do not match, trace the data in order.
Step 1. Workday
Does the transaction exist in Workday?
If no, the issue is not in Adaptive Planning.
Step 2. Workday source
Does the Workday report or journal line source return the record?
If no, investigate the Workday report, filters or source configuration.
Step 3. Adaptive staging
Did the Workday Data Source import the record?
If no, investigate the data source import.
Step 4. Eligibility
Should this record be included in the Planning population?
If no, classify the exclusion.
Step 5. Mapping
Does the record resolve to the correct Adaptive account, level and dimensions?
If no, investigate mapping.
Step 6. Loader
Does the record appear in the loader preview?
If no, investigate loader filters or business rules.
Step 7. Adaptive Planning
Did the value land at the correct leaf intersection?
If no, investigate the load.
Step 8. Rollup
Does the parent result match the expected value?
If no, investigate hierarchy, formula or currency behavior.
The first point where the data changes unexpectedly identifies the layer that requires investigation.
Example from a real implementation pattern
Consider an expense actuals integration where the source contains a much larger population than the Planning model.
The initial comparison shows a significant difference between the source total and Adaptive Planning.
Possible causes might appear to include:
Currency
Loader calculation
Account formulas
Planning hierarchy
However, the correct first question is:
Are both comparisons using the same population?
In one implementation pattern, the raw source contained records that were not part of the approved Planning population.
These included different expense populations and accounts outside the intended Gross load.
Once the comparison was aligned to the same:
Expense type
Account scope
Level scope
Transaction status
Period
and applicable business filters
the load-ready source population reconciled correctly.
Only after source reconciliation was complete did it make sense to investigate the remaining Planning differences.
This illustrates an important architecture rule:
A source scope problem and a Planning calculation problem require different fixes.
Do not investigate the Planning model until the source population is proven.
Common causes of Workday to Adaptive Planning reconciliation differences
Workday report filters
The source report and the Planning process use different company, date, journal status or book populations.
Incorrect account mapping
A Workday ledger account maps to the wrong Adaptive Planning account or remains unmapped.
Incorrect level mapping
A company and cost center combination does not resolve to the intended Adaptive Planning level.
Missing Worktags
A required source Worktag is missing or does not map to the Planning dimension.
Gross and Net scope
One comparison includes Gross and Net while the Adaptive process loads only one population.
Balance sheet accounts
The Workday source includes accounts intentionally excluded from the Planning model.
Cancelled or reversed transactions
The Workday source and Adaptive loader apply different rules for transaction status.
Currency treatment
The selected source amount and Adaptive Planning currency behavior do not represent the same basis.
Incorrect amount field
The loader uses a different currency or amount field than the one used for the source reconciliation.
Stale Adaptive Planning values
Values from an earlier load remain in Planning even though they are absent from the current source.
Period differences
Accounting Date, fiscal period and loader period parameters are not aligned.
Aggregation
The source data is aggregated before required reconciliation attributes are retained.
A practical Workday to Adaptive Planning control framework
| Layer | Control |
|---|---|
| Workday | Confirm the authoritative financial population |
| Workday report | Validate filters, fields, grain and runtime |
| Workday Data Source | Confirm the expected reports and data are imported |
| Adaptive staging | Validate counts, amounts, scope and derived fields |
| Mapping | Identify included, excluded and unmapped records |
| Planning Data Loader | Validate target mappings, filters and preview |
| Adaptive Planning | Confirm values at leaf intersections |
| Hierarchies | Validate account, level and currency rollups |
| Rerun | Confirm repeatable and controlled reload behavior |
| Reporting | Reconcile the final Finance output |
Recommended design principles
A reliable Workday Financials to Adaptive Planning actuals integration should follow several principles.
Architecture before configuration
Define the source, grain, mapping, controls and reconciliation process before configuring loaders.
Keep source and business logic understandable
Do not spread critical financial logic across many disconnected technical objects.
Preserve useful source identifiers
Do not aggregate away the information required for investigation.
Make mappings visible
Finance and integration support should be able to understand how Workday values become Adaptive Planning structures.
Document exclusions
Every intentional exclusion should have a business reason.
Validate at leaf level
Do not rely only on top level financial statements for integration testing.
Test reruns
A production integration must work correctly more than once.
Automate after proving the process
Scheduling should be the final step, not the first.
Reconcile from source to target
Do not wait until management reporting to discover an integration problem.
Frequently Asked Questions
How does Workday Financial Management integrate with Adaptive Planning?
Adaptive Planning can use a Workday Data Source to import Workday reports, journal line summaries and metadata into staging. Planning loaders then map and load the required information into Adaptive Planning.
Can Workday actuals be loaded into Adaptive Planning?
Yes. Workday supports importing Financial Management information into Adaptive Planning and loading the resulting staging data into Planning.
What is an Adaptive Planning Data Loader?
A Planning Data Loader maps staging data and loads it into Adaptive Planning. Depending on the target, Planning Data Loaders can load GL account data, cube sheet data, modeled sheet data and transaction data.
Can Workday reports be used as an Adaptive Planning source?
Yes. Workday Data Sources can use qualifying Workday reports. Workday documents specific requirements for reports used with Adaptive Planning, including Advanced Report configuration and integration settings.
Can multiple Workday fields map to one Adaptive Planning level?
Yes. Where required, SQL columns can be created in staging to combine source values such as Company and Cost Center into a mapping key.
Should Workday and Adaptive Planning totals always match?
Only when both sides represent the same population, grain, period, account scope, organizational scope, dimensions and currency basis.
A difference between two differently scoped populations is not automatically an integration error.
How should Workday to Adaptive Planning reconciliation be performed?
Reconcile progressively from Workday source data through Adaptive staging, loader output and Adaptive Planning leaf values before validating higher level rollups and reports.
What is the best way to troubleshoot a Workday to Adaptive Planning variance?
Trace one controlled record or intersection through Workday, the Workday source report, Adaptive staging, mapping, loader preview, Adaptive Planning leaf data and hierarchy rollups.
Find the first layer where the value or population changes unexpectedly.
Can Adaptive Planning drill back into Workday?
Workday supports Workday External Systems and associated loader mapping profiles that can enable drill-through from Adaptive Planning into Workday when the required configuration is in place.
Should actuals integration be automated immediately?
No. First validate the source population, staging, mappings, loader behavior, Planning results, reconciliation and rerun behavior. Once the process is reliable, Integration Tasks can be used to schedule the integration.
Conclusion
A Workday Financial Management to Adaptive Planning actuals integration should not be viewed as:
Workday
to
Adaptive Planning
The stronger architecture is:
Workday source
to
controlled interface
to
Adaptive staging
to
validated population
to
governed mappings
to
controlled Planning Data Loader
to
Adaptive Planning
to
reconciliation
The most useful troubleshooting rule is simple:
Find the first layer where the data diverges and fix the problem there.
Do not fix a Workday source problem with an Adaptive Planning formula.
Do not fix an account mapping problem with a reporting adjustment.
Do not change currency configuration simply to make a variance disappear.
Do not consider an integration complete because the loader finished successfully.
A good Workday Financials to Adaptive Planning integration is one where Finance can trace, explain and reconcile the result.
About EPMLogic
EPMLogic specializes in Workday Adaptive Planning architecture, implementation, integration and optimization.
Our approach starts with architecture, data ownership, planning grain, mappings, controls and reconciliation before configuration.
For organizations integrating Workday Financial Management with Adaptive Planning, the objective is not only to automate actuals loading. The objective is to build a Planning process that Finance can operate, reconcile and support.