Planning, cataloged where it actually hurts
Budgets and forecasts get built in Planning; getting them out, and getting the rules underneath them fast, is where implementations stall. Twenty-two pages, each anchored on a documented issue.
Note: Oracle EPM is the cloud suite finance teams run planning, consolidation, and close on. Planning, which practitioners still call EPBCS, is the module where budgets and forecasts are built: Financials, Workforce, Capital, and Projects, each planned by entity and rolled up for approval.
Part of the Oracle EPM catalog, beside the close and reconciliation modules.
◆ The module, mapped, all twenty-two pages, grouped by what they answer.
Planning's pain concentrates in two places: getting plan data out, and rule or aggregation design. Every page below anchors on a documented issue or a doc-verified behavior, per Oracle's module reference. The dictionary defines the objects, the reports answer the questions a CFO actually asks of a plan, the exports move the data to a warehouse you own, and the guidance pages hold the design rules Oracle scatters across three guides. Strategic Modeling exists as a fifth process; it is niche enough that it lives in this paragraph.
| Dictionary | |
|---|---|
| Account | The chart the plan is written in, and where custom members belong. |
| Entity | Who plans, and the approval machinery bolted to the dimension. |
| Scenario | Budget, Forecast, Actual: lanes with their own time ranges. |
| Version | Working, what-if, final. Approvals ride scenario plus version. |
| Period & Years | Two dimensions for time, steered by substitution variables. |
| Currency | Simplified against standard multicurrency, and what exports carry. |
| Workforce objects | Employee and Job granularity, the component tree, the earnings ceiling. |
| Capital & Projects objects | Asset classes, project types, and the hierarchy that must agree. |
| Reports | |
|---|---|
| Budget vs actual | Level-0 truth against form truth, and where variance belongs. |
| Forecast accuracy | Version against version over time. The app never holds this still. |
| Workforce roster & cost | Headcount tied to money, by component. |
| Capital rollforward | In service, in flight, requested, and depreciation to the P&L. |
| Driver & trend | Which drivers moved the forecast. |
| Approval status | The promotional path, the seven states, and the export the screen refuses. |
| Exports, guidance, and the model | |
|---|---|
| Level-0 BSO export | DATAEXPORT done right, numeric-only stated plainly. |
| ASO and hybrid export | The columnar gap, the three routes, the hybrid caveat. |
| Smart Lists & text | Text IDs, the Groovy route, the annotations gap. |
| Rule design | The verified best-practice set, with the block and recursion traps. |
| Workforce rules | The OWP_ dictionary, the 2.0 transition, the silent load defaults. |
| Aggregation strategy | BSO, hybrid, ASO: the leaf-level rule and the serial drop. |
| Data model | The plan star, conformed with the close and reconciliation catalogs. |
One sample world runs through every page: the sixty-entity group from our close and reconciliation catalogs, now planning FY26: revenue budget 842.0M, June forecast 851.4M, and entity 1010-CL, the group's Chilean subsidiary, carrying the story as usual.
The problem: The plan lives in cubes, so every question about it needs an administrator and a retrieval.
What we build: A 10-day engagement: nightly level-0 and approvals exports land in a warehouse you own on GCP, AWS, or Azure, gated before anyone reads them.
What you get: Budget against actual against forecast, any entity, any period, answered by one query. No administrator in the loop.
- EPBCS
- The old name for Planning with modules. Everyone still says it.
- cube
- Where Planning stores data. Easy to load into, hard to query out of.
- level 0
- The leaf grain. The only export grain that reloads cleanly.
- the two flanks
- Data out, and rule design. Where the pain concentrates.