Budget against actual, built to be trusted

The first report anyone asks of a plan is also the easiest to build wrong: totals pulled from forms, keys that almost match, and a spreadsheet nobody can reproduce. The trustworthy version has two rules, and both are about grain and keys, not formatting.

Note: In Planning, Oracle's module where budgets and forecasts are built, the first question anyone asks is how actuals compare to the plan. This page is where that comparison should live and at what grain, so the answer is trustworthy.

The whole module is mapped on the Planning index.

RuleCompare at level 0, on one shared set of entity and account keys, with the scenario named on every row.

Neverbuild the comparison from form totals. Dynamic parents can compose differently per retrieval, and the argument that follows is unwinnable because both sides are right.

◆ The table, and the two rules, the footed June comparison, grain, and keys.

The comparison in the sample world, June year to date:

Line	Budget	June forecast	Move
Revenue	842.0M	851.4M	+9.4M, +1.1%
Operating expense	512.6M	518.2M	+5.6M

Two rules make this table trustworthy. Grain first: the comparison is built from level-0 rows, the leaf grain, because a total pulled from a form can include dynamically computed parents whose composition depends on the outline, and two people can retrieve two different totals in good faith. Level-0 rows sum the same way for everyone. Second, keys: plan and actual land on the same account and entity keys, the tree from the Entity page, so the variance for 1010-CL, the Chilean subsidiary, is one subtraction, not a mapping exercise.

Where each side comes from: the plan side is the nightly level-0 export, and the actual side is the ledger data your close catalog already lands. The scenario column names the lane on every row, per the Scenario page, so budget, forecast, and actual never blur.

THE USE CASE, SIMPLIFIED

The problem: Budget against actual is rebuilt in spreadsheets every month, at whatever grain the export happened to be.

What we build: Level-0 plan data and actuals land side by side in your warehouse, on the same account and entity keys.

What you get: One variance view, any entity, any account, any month, and every number drills to the rows behind it.

Monthly variance pack still assembled by hand?

We land level-0 plan rows beside your actuals nightly, on one key set, and the variance pack becomes a view that is current every morning.

Talk to us

Terms on this page

level 0: The leaf grain. Sums the same way for everyone.
form total: May include dynamic parents. Fine on screen, unfit as a source.
one key set: Same entity and account keys on both sides. The whole trick.
the lane column: Scenario on every row, so budget and forecast never blur.