A financial data model is the formal specification of how financial data is structured, related, and defined within an analytical system — defining the entities (Account, Entity, Period, Scenario), their attributes (account type, currency, consolidation operator), and the rules that govern how values are calculated, aggregated, and combined. In Oracle EPM, the financial data model is embodied in the Essbase dimensional structure — the dimension hierarchy, the dense/sparse designation, the member formulas, and the business rules that collectively determine what every cell in the multidimensional database means. In a BI data warehouse, the financial data model is the star or snowflake schema — the fact tables, dimension tables, and calculated measures that define the analytical dimensions and metrics available for reporting.
The Three Levels of Financial Data Model Design
Financial data model design operates at three levels of abstraction that must be aligned — misalignment between levels is the most common source of reporting inconsistencies in enterprise finance stacks.
| Level | What It Defines | System Where Implemented |
|---|---|---|
| Conceptual | The business entities and relationships: what is a “segment”, what is a “period”, what does “revenue” mean to this organisation | Finance policy documents; data dictionary |
| Logical | The data structure: which dimensions exist, how they relate, what aggregation rules apply | EPM dimension design; data warehouse schema design |
| Physical | The implementation: Essbase cube configuration; SQL table definitions; API data contracts | Oracle EPM Cloud; Oracle Analytics Cloud; Power BI |
Dimensional Model vs Relational Model in Finance
The two foundational approaches to financial data modelling reflect different analytical priorities. A dimensional model — the approach used by Oracle Essbase, Oracle Analytics Cloud, and BI warehouse star schemas — organises data around the question “how much?” (measure) and “by what attributes?” (dimensions). It is optimised for aggregation, slicing, and comparison across multiple analytical dimensions simultaneously. A relational model — the approach used by ERP transactional databases — organises data around the question “what happened?” and is optimised for accurate recording and retrieval of individual transactions. Finance reporting requires the dimensional model; finance transaction processing requires the relational model. The ETL/ELT process between ERP and EPM or BI is the transformation from relational to dimensional — and the financial data model design determines how that transformation is defined, governed, and maintained.
GCC-Specific Data Model Considerations
Multi-currency is a fundamental design dimension in any GCC financial data model. The model must store values in at least three currency contexts: the entity’s functional currency (SAR, AED, EGP, USD), the group reporting currency (typically USD or the parent entity’s functional currency), and in some cases a constant-currency view for period-over-period performance comparison. Each currency context requires a defined translation mechanism — Oracle FCCS applies IFRS-compliant currency translation (average rate for income statement, closing rate for balance sheet, historical rate for equity) automatically when the data model correctly tags each account member with its translation rate type. A data model that does not include currency translation rate type as an account attribute cannot automate IFRS-compliant translation.
What Goes Wrong in Practice
The most common financial data model failure in GCC EPM environments is a dimension hierarchy designed to satisfy the current reporting structure that cannot accommodate the business changes that occur after go-live: entity acquisitions, cost centre restructuring, new product lines. When the EPM dimension hierarchy was designed with a fixed depth assumption — three levels from group to entity, two levels from entity to cost centre — and the business acquires a subsidiary that requires a fourth organisational level, the dimension structure must be redesigned with cascading impact on all business rules, forms, and reports that reference the hierarchy. Data models designed with flexibility as an explicit goal — using alternate hierarchies, configurable rollup structures, and parameterised business rules — accommodate business change with less structural disruption.
How Loop Wise Solutions Designs Financial Data Models
We design financial data models from the reporting outputs — working backward from the management pack, the consolidation output, and the regulatory disclosure requirements to the dimensional structure that must exist to produce them. Data model design that starts from the source system structure and works forward to reporting almost always produces a model optimised for the data’s origin rather than for the business’s analytical needs.
