The data model is the architectural foundation of any EPM system. It defines how data is organized, how users interact with it and what questions the system can answer. A well-designed model makes planning intuitive, reporting flexible and analysis fast. A poorly designed model creates workarounds, performance problems and frustrated users.
This guide covers what dimensions are, common dimension types, hierarchy design principles, mapping strategies, performance considerations and common design mistakes.
What Is a Dimensional Model?
EPM platforms organize data using dimensions — categories like account, entity, department, time, scenario and product. Each combination of dimension members defines a data point. For example, "Revenue / US East / Q1 2026 / Budget" is a single intersection across four dimensions.
The number and structure of dimensions determines what questions the system can answer, how users navigate data and how the platform performs at scale.
Core Dimensions
Account
The chart of accounts — revenue, expense, balance sheet and statistical accounts. The most fundamental dimension. Usually hierarchical with accounts rolling into groups.
Entity / Company
Legal entities, business units or reporting segments. Drives consolidation, intercompany elimination and multi-entity reporting.
Department / Cost Center
Organizational structure for expense ownership. Typically maps to the budget owner hierarchy.
Time
Fiscal periods — months, quarters, years. Enables period-over-period comparison, YTD calculations and rolling forecasts.
Scenario / Version
Separates actuals from budget, forecast and what-if scenarios. Enables multi-version planning and comparison.
Custom dimensions
Product, project, geography, channel — any additional analytical axis the business needs. Add judiciously — each dimension multiplies complexity.
Design Principles
Design for the questions, not the data
Start with the reports and analyses leadership needs. Work backward to the dimensions required to produce them. Do not replicate ERP structure blindly.
Keep it as simple as possible
Every dimension adds complexity for users, administrators and performance. If a dimension does not drive planning decisions or required reporting, leave it out.
Separate structure from data
The model structure should be stable. Data changes every period, but dimensions and hierarchies should not require frequent restructuring.
Plan for change
Business structure changes — acquisitions, reorgs, new products. Design dimensions with enough flexibility to absorb change without rebuilding.
Map, do not replicate
Use mapping layers between source systems and the EPM model. The EPM structure should serve planning, not mirror the ERP chart of accounts.
Common Design Mistakes
• Too many dimensions — adds complexity without analytical value.
• Replicating the ERP chart of accounts without rethinking for planning.
• Flat dimensions that should be hierarchical — losing roll-up capability.
• No scenario/version dimension — making it impossible to compare plan vs actual.
• Designing in isolation — without input from the people who will use the system.
• Ignoring performance — large sparse intersections slow calculation and reporting.