Actuals in Adaptive Planning showing different numbers than your general ledger? This is one of the most common issues finance teams face — and the root cause is almost never where you first look. Here’s a structured way to find it.
Few things erode confidence in a planning system faster than actuals that don’t reconcile. Finance loads the period, opens a report, compares it to the GL — and the numbers are off. Sometimes by a rounding amount. Sometimes by millions.
The instinct is usually to suspect the model: a broken formula, a wrong account. In our experience, the model itself is rarely the problem. The discrepancy is almost always introduced somewhere along the data path between the source system and the sheet — and the fastest way to find it is to check each stage of that path in order, rather than jumping to the most visible symptom.
The actuals data path – where discrepancies hide
Actuals data in Workday Adaptive Planning passes through a chain of stages, and a mismatch can be introduced at any one of them:
1. Source extraction. What was actually pulled from the GL or ERP? If the extract runs before all journals are posted — or against the wrong ledger, book, or company — the data is wrong before Adaptive ever sees it. Check the extract timing against your close calendar. A common pattern: the extract runs on day 2 of close, late adjustments post on day 3, and nobody re-runs the load.
2. Account mapping. Source GL accounts must map to Adaptive account structures. Unmapped accounts are the silent killer here — depending on your loader configuration, they may be dropped without an error, which means the load “succeeds” while quietly missing balances. Any account created in the GL after the mapping was built is a candidate.
3. Period and calendar mapping. Source dates must translate to the correct Adaptive period. Fiscal calendars that differ from calendar months, 4-4-5 structures, and adjustment periods are all common failure points. An adjustment-period journal that has no home in Adaptive’s calendar either lands in the wrong month or disappears.
4. Level and dimension mapping. The balance arrived, in the right account and period — but posted to the wrong entity, cost centre, or custom dimension member. Totals at the top level may even reconcile while every level below is wrong. This is why reconciling only the grand total is never enough.
5. Loader configuration. Replace mode versus append mode is the classic issue. An append-mode loader run twice doubles the actuals. A replace-mode loader scoped too broadly wipes balances it shouldn’t touch.
6. The model layer. Only after all five upstream stages check out is the model itself the suspect — a linked account pulling from the wrong source, a calculated account overriding loaded data, or a formula translating the number after arrival.
A reconciliation method that actually works
Reconcile top-down, one dimension at a time:
First, compare the grand total in Adaptive against the GL trial balance total for the same period, same ledger, same currency basis. If the grand totals match but details don’t, your problem is mapping (stages 2–4). If the grand totals don’t match, your problem is extraction or loading (stages 1 and 5).
Then split by account. Find which accounts carry the difference. A small number of accounts carrying the whole variance points to mapping gaps. A uniform percentage difference across everything points to a currency or scaling issue.
Then split by entity and period within the broken accounts. At this point you usually have the discrepancy isolated to a specific account, entity, and month — small enough to trace the individual journal lines.
Fixing it so it stays fixed
Finding this month’s break is the small win. The durable fix is structural:
A zero-delta check after every load. The load process should end with an automated comparison of Adaptive totals against source totals — by account and by entity, not just the grand total. A load that doesn’t reconcile shouldn’t be considered complete.
A defined process for new GL accounts. Every new account in the source system needs a mapping decision before the next load, not after the next variance.
Documented load configuration. Replace scope, period range, version target, and mapping logic written down — so the person running the load next year isn’t guessing at what the person who built it intended.
Actuals that reconcile exactly, every period, without manual adjustment, is not an ambitious standard — it’s the baseline a properly built integration should deliver. If your loads require a manual “true-up journal” every month to force agreement, that’s not a workaround, it’s a signal that one of the six stages above is misconfigured and worth diagnosing properly.
