Data Management (DM) — formerly known as FDMEE (Financial Data Quality Management Enterprise Edition) in on-premise Hyperion environments — is Oracle EPM Cloud’s built-in data integration and quality management application. It provides the governed pathway for loading financial actuals from ERP and other source systems into Oracle EPM Cloud applications (PBCS, EPBCS, FCCS, PCMCS) — handling source system connections, data mapping from source dimension values to EPM target dimension members, transformation and rounding rules, period mapping, load method configuration, and validation controls that verify the loaded data against source totals. Data Management is the application layer that sits between the ERP extract and the EPM application’s Essbase or FCCS database — ensuring that data flowing into the EPM is correctly mapped, transformed, and validated before it is available for planning comparisons, consolidation, and management reporting.
Data Management Components
| Component | Function | Key Configuration Decision |
|---|---|---|
| Source System | Defines the connection to the data source — file-based, JDBC via EPM Agent, or Oracle cloud adapter | File-based vs API-based vs EPM Agent |
| Import Format | Defines the structure of the source data file — column positions, delimiter, header rows | Column mapping to DM staging fields |
| Location | Grouping configuration unit — associates source system, target application, period mapping, and logic group | One location per source-system/target-application combination |
| Period Mapping | Maps source system period identifiers to EPM target periods | Calendar vs fiscal period alignment |
| Dimension Mapping | Maps source dimension values (GL account codes, cost centre codes) to EPM target dimension members | Explicit, Like, In, Between, and wildcard mapping rules |
| Data Load Rule | Orchestrates the full load: import from source, map, transform, validate, load to target | Load method (Replace, Add, Subtract, Replace by Security) |
| Check Report | Validates that loaded EPM data matches source data totals by account and entity | Tolerance thresholds; escalation rules |
Mapping Rule Sequence: A Critical Design Detail
Data Management’s dimension mapping rules are evaluated in a defined sequence — and this sequence determines which rule applies when multiple rules could match the same source value. DM processes mapping rules in this order: Explicit (exact match on source value), Like (contains match), In (member of a defined list), Between (range match), and then wildcard rules. Within each rule type, rules are evaluated in the order they are defined in the mapping table. The first matching rule wins — subsequent rules are not evaluated. A wildcard rule that is positioned above a more specific explicit rule will match every source value it covers, preventing the explicit rule below it from ever being applied. Mapping rule sequence errors produce silent mismapping — the load completes without error but the data appears in the wrong EPM target members, discovered during reconciliation.
GCC Multi-ERP Data Management Architecture
GCC enterprise groups with multiple ERP instances feeding a single Oracle EPM Cloud consolidation application — Oracle EBS for Saudi entities, SAP for an acquired UAE subsidiary, Oracle Fusion for a new Egyptian entity — require a multi-source Data Management architecture. Each ERP instance is a separate Source System definition in DM; each has its own Import Format (the ERP’s extract file structure); each has its own dimension mapping rules (the ERP’s account and entity codes map to the same EPM target dimension members, but through different mapping rule sets). Managing three separate mapping rule sets that must all produce consistent results in the same EPM target application requires strict mapping governance — new chart of accounts additions in any source ERP must trigger a corresponding mapping update in DM, or the new accounts’ data is silently excluded from the EPM.
What Goes Wrong in Practice
The most frequent Data Management failure in production environments is a period mapping that breaks at fiscal year rollover — because the period mapping was configured for the prior fiscal year and was not updated before the new year’s data load. DM’s period mapping defines which source period identifier (January, Month 1, 01-2025) maps to which EPM target period (Jan, FY25_Jan). When the calendar year changes and the source system’s period identifiers advance (January 2026, Month 1 2026), but the DM period mapping still points to the prior year’s EPM periods, the new year’s data loads to the wrong EPM periods. Period mapping maintenance at fiscal year rollover is a mandatory operational step that must be included in the year-end close runbook.
How Loop Wise Solutions Designs Data Management
We document every Data Management configuration component — source systems, import formats, period mappings, dimension mapping rules, and load rule parameters — in a Data Management specification that is maintained alongside the EPM application configuration. This documentation enables any EPM administrator to understand, maintain, and troubleshoot the data integration independently of the implementation team.
