Oracle FDMEE questions, answered clearly.

Oracle Financial Data Quality Management Enterprise Edition (FDMEE) is the on-premises data integration application in Oracle’s EPM System. It takes trial balances and other financial data from ERPs, files and relational sources, maps source accounts, entities and other codes to the target application’s dimensions, validates the result, loads it into HFM, Planning or Essbase, and keeps a full audit trail with drill-through back to the source. It runs on an Oracle Data Integrator engine underneath and ships with EPM System 11.1.2.4 and 11.2. Its cloud successor is Data Integration (formerly Data Management) in Oracle EPM Cloud.

Getting actuals into the EPM applications every period, reliably and with evidence. A location is defined per source and target, an import format describes the file or table layout, period and category mappings align ERP periods to EPM scenarios, and data load mappings translate ERP codes to EPM members. Each load runs through import, validate, export and check, with unmapped items stopped before they reach the target. Groups also use it for budget write-back to the ERP, for loading Excel trial balances from entities without an ERP, and for the audit trail that auditors ask for when a consolidated number is queried.

Control over the step where most consolidation and planning errors originate. Mappings are maintained once and applied every period, unmapped codes are caught at validation rather than discovered in a wrong total, and every loaded amount can be traced back to its source record. Loads can be scheduled and batched so month-end does not depend on someone running them by hand. Because the same mappings serve HFM, Planning and Essbase, a new company code or account is dealt with once. The alternative, spreadsheets massaged before upload, has no audit trail and fails quietly.

FDMEE is part of Oracle EPM System 11.2, which Oracle supports under its Applications Unlimited programme, so a group on 11.2 is on a supported product. FDMEE 11.1.2.4 is on Sustaining Support: it runs, but receives no new fixes or certifications. In Oracle EPM Cloud the same function is Data Integration, which uses the same concepts (locations, import formats, period and category mappings, data load mappings and rules) and adds pipelines, direct connections to Oracle Cloud ERP and an on-premises agent for other sources. Mappings and skills carry over, which is one reason FDMEE administrators find the cloud migration less disruptive than the applications themselves.

Indirectly, by making the numbers in the reports trustworthy. Validation stops unbalanced or unmapped data before it reaches the target, check rules confirm that key totals reconcile after each load, and drill-through lets a user in Smart View or Financial Reporting click from a consolidated figure through FDMEE to the source ledger lines. That removes the reconciliation exercise that otherwise sits between the ERP and the EPM report, and it means an auditor’s query can be answered from the application rather than reconstructed from spreadsheets.

Yes, that is its purpose. It ships with adapters for Oracle E-Business Suite, PeopleSoft, JD Edwards and Fusion, connects to SAP through the SAP adapter, reads any relational source through the universal data adapter, and loads flat files and Excel templates for everything else. In South Africa the common sources are SAP, Oracle E-Business Suite, JD Edwards, Microsoft Dynamics and Sage. Where an ERP has no adapter, a scheduled extract to file or a database view is the usual route, and the mapping and audit trail work the same way.

Yes. Registered targets include HFM, Planning, Essbase and, from FDMEE 11.1.2.4 patch levels onward, Oracle EPM Cloud services such as Planning Cloud and FCCS, so an on-premises FDMEE can feed a hybrid estate during a staged migration. It also moves data between EPM applications, for example HFM actuals into Planning as the forecast baseline, and can pull metadata for mapping validation. Financial Reporting and Smart View use its drill-through, and Data Relationship Management can supply the hierarchies the mappings depend on.

Each dimension has a set of data load mappings evaluated in order: explicit (one source code to one target member), between (a range), in (a list), like (a pattern with wildcards) and multi-dimension (conditions across several source fields). A source code that matches none of them fails validation and the load stops. The failures we see are almost always business changes that never reached the mappings: a new company code after an acquisition, a chart-of-accounts change in the ERP, a cost centre merged in the ledger, or a like-mapping that quietly catches a code it was never meant to. The fix is rarely technical; it is a process for telling the FDMEE administrator when the ERP changes.

Yes, the whole load cycle. Data load rules can be scheduled or run in batches so that actuals for every location load overnight after the ledger closes, with validation results emailed to the owners. Open batches process files as entities drop them in. Event scripts in Jython handle steps that used to be manual, such as pre-load checks, post-load consolidations in HFM or refreshes in Planning, and custom scripts run reconciliations. What stays manual is fixing the mapping for a genuinely new code, which is a decision rather than a task.

Users authenticate through Oracle Shared Services, usually against Active Directory, and FDMEE applies role-based security (administrator, run integration, create integration and so on) plus location security, so a subsidiary’s finance team can load and see only its own location. Source system credentials are stored in the application rather than shared with users. Every load is logged with who ran it, what was imported, what failed validation and what was exported, which is the audit trail auditors rely on. As with the rest of the 11.x family, the practical risk is an unsupported 11.1.2.4 environment rather than the product.

Any group loading more than one source into HFM, Planning or Essbase, especially with multiple ERPs, entities on different charts of accounts, acquisitions that keep adding company codes, or auditors who ask for drill-through evidence. In South Africa that includes listed groups consolidating subsidiaries on SAP and other ledgers, mining and manufacturing groups with site-level systems, financial services groups with many licensed entities, and public sector bodies with multiple financial systems. A single-entity, single-ledger organisation can often load directly; a group cannot, safely.

When FDMEE loads data it keeps the source records in its staging tables with the mapping applied to each one. From Smart View or Financial Reporting, a user selects a cell in HFM, Planning or Essbase and drills through to the FDMEE landing page, which lists the source lines that make up that amount, and, where an ERP adapter is configured, drills a second time into the ERP itself. It only works for data loaded through FDMEE and only while the staging data is retained, so the retention and purge policy is part of the design. It is the single most useful feature for audit and for finance teams investigating a variance.

FDMEE is the integration layer of the on-premises EPM System, sitting between the ERPs and HFM, Planning and Essbase, alongside Data Relationship Management for master data and Smart View and Financial Reporting for output. In Oracle EPM Cloud the equivalent is Data Integration, which serves FCCS, Planning Cloud, Account Reconciliation and the other services. In a hybrid estate FDMEE can load both on-premises and cloud targets, which is how many groups run during a multi-year migration.

Yes, in bounded ways. Mapping suggestions for new source codes, based on the existing mappings and the code descriptions, can be generated for an administrator to confirm. Load results can be scanned for amounts that break pattern against prior periods before anyone consolidates. Validation failures can be classified and routed to the right owner automatically. Namandla applies these to the FDMEE data and logs you already have, with a person confirming every mapping before it is saved, because a wrong mapping is silent until the auditors find it.

Namandla is a South African consultancy whose senior team has designed and maintained FDMEE integrations for about two decades, across SAP, Oracle, JD Edwards, Dynamics and file-based sources, into HFM, Planning, Essbase and Oracle EPM Cloud. The person who reviews your mappings is the person who fixes them. We are independent on the on-premises versus cloud question and answer it on your sources, your targets and your skills. Contact info@namandla.com or 087 188 3388.