When a group close runs long and the consolidation does not tie, the finance team blames the consolidation system. Almost always, the consolidation system is not the problem. The problem is upstream, in the master data — the chart of accounts, the entity structure, the ownership hierarchy — that feeds every application that produces a number. When an entity is added in the ERP but not in the planning model, when two systems hold different versions of the same hierarchy, or when an acquired company arrives with its own chart of accounts that no one has mapped, the close breaks. And it breaks in a way that looks like a consolidation fault when it is really a governance gap.
This is the least glamorous problem in enterprise finance and one of the most expensive. It is also disproportionately a Gulf problem, because the organisations most exposed to it — diversified family conglomerates that operate across many sectors and geographies, grow by acquisition, and are now restructuring under national diversification agendas — are the backbone of the regional economy. Family businesses account for roughly 80 percent of non-oil GDP across the GCC, and the ones that thrived did so by expanding relentlessly across industries and borders. Every one of those expansions added an entity, a hierarchy, a chart of accounts — and rarely a governed way to keep them consistent.
Oracle Enterprise Data Management, EDMCS, is the system that governs that master data. It is not a consolidation tool, a planning tool, or a reporting tool. It is the place where a change to the chart of accounts, a new legal entity, or a restructured ownership hierarchy is requested, validated, approved, and then distributed — consistently — to every application that depends on it. For a group financial controller in the Gulf whose close is slow for reasons no one can quite pin down, understanding where EDMCS fits is often the missing piece.
The problem that arrives disguised as a close problem
The symptoms are familiar. Month-end runs late because someone discovers, halfway through, that a cost centre exists in the general ledger but not in the planning application. The group consolidation does not agree to the sum of its parts because two systems disagree about which entities roll up where. An acquisition closed months ago still cannot be consolidated cleanly because its accounts were never mapped to the group chart. A restructuring moved a business unit from one division to another, and the change was made in three systems out of five.
None of these presents itself as a data problem. Each presents itself as a close problem, a reporting problem, or a consolidation problem — and so the investment goes into the consolidation tool, the reconciliation process, or more people working longer at quarter-end. The underlying cause goes untreated because it is invisible from where the pain is felt. The chart of accounts, the entity list, and the ownership hierarchy are shared assets that more than one application consumes, and when there is no single governed source for them, every application eventually holds its own slightly different version. The divergence is the disease; the failed close is the symptom.
In a single-entity company this rarely becomes acute. In a conglomerate that adds and restructures entities continuously, it is chronic — and it compounds with every acquisition.
What Oracle EDMCS actually does
EDMCS governs enterprise data: the chart of accounts, organisation and cost-centre structures, legal-entity and ownership hierarchies, product and segment hierarchies, mappings, and the reference data that connected systems share. It holds these as a single, governed source of truth and manages how they change.
Four capabilities matter most for a finance group.
A single source of truth. The chart of accounts, the entity structure, and the hierarchies live in one governed place rather than being maintained separately in each application. There is one master, and everything else subscribes to it.
Governed change, not free edits. A change — a new account, a moved entity, a restructured hierarchy — is a request that goes through validation, workflow, and approval before it takes effect. The system records who asked, who approved, and what changed, so the master data carries an audit trail rather than a history of untracked edits.
Impact visible before the change is made. A proposed change can be modelled and compared side by side against the current structure before it is committed, so the group can see what a restructuring or a chart redesign will do to the hierarchies before it does it, rather than discovering the consequences at the next close.
Controlled distribution to every target — Oracle and not. Once a change is approved, EDMCS distributes it to the applications that subscribe to it: FCCS for consolidation, the Planning applications, ARCS, PCMCS, the ERP general ledger, and non-Oracle targets too. This last point matters enormously in the Gulf, where a conglomerate that grew by acquisition rarely runs one ERP; it runs several, often a mix of Oracle, SAP, and inherited systems, and the master data has to reach all of them consistently.
Put plainly: FCCS answers what is the consolidated result. EDMCS answers are all the systems that feed it working from the same chart of accounts, the same entities, and the same hierarchies — which is the precondition for the consolidated result being right at all.
Why the GCC conglomerate is the sharpest case
Three regional realities make master-data governance more urgent in the Gulf than almost anywhere.
Constant structural change. GCC family conglomerates grow across sectors and geographies as a matter of survival — historically at rates that meant continual acquisition and expansion. Each new business is an entity, a chart of accounts, and a place in the ownership hierarchy that has to be absorbed. A group that adds businesses every year is a group whose master data changes every year, and the ungoverned version of that is an ever-widening gap between what each system believes the group looks like.
A wave of restructuring under Vision 2030. The regional agenda is pushing diversified holding companies to consolidate portfolios, carve out units, separate ownership, and formalise governance. Diversified, sovereign-adjacent holding structures are reshaping whole sectors. Every consolidation, carve-out, and separation is a structural change to entities and hierarchies — precisely the events that break an ungoverned close.
Succession and formalisation. As founder-led groups pass to the next generation and bring in professional management, the informal, in-the-founder’s-head knowledge of how the group is structured has to become an explicit, governed model. Master-data governance is part of how a family group becomes institutionally legible — to its own management, its auditors, and its lenders.
A conglomerate carrying all three of these at once — and many Gulf groups are — is a conglomerate for which ungoverned master data is not a background inefficiency. It is a quarterly crisis waiting for the next acquisition to trigger it.
What the GCC build has to get right
Governing master data for a Gulf group requires several things that a generic implementation will miss. We treat each as core scope.
Bilingual master data. Account names, entity names, and cost-centre descriptions have to carry both Arabic and English, held as governed properties, because the consolidation and the management reporting downstream are expected to render in both. Bilingual metadata added as an afterthought means re-touching every node; designed in, it is a property that travels with the master.
Ownership hierarchy as a first-class structure — for zakat. In the Kingdom, the zakat calculation depends on ownership. The legal-entity and ownership hierarchy is not merely an organisational chart; it is an input to a tax outcome, and it has to be governed with the accuracy that implies. A mis-stated ownership percentage is not just a reporting inconvenience; it flows into the zakat position.
Entity tax classification. Which entities are zakat-liable, which are income-tax-liable, and which are mixed is a property that belongs on the governed entity master, so that Tax Reporting and consolidation both draw the classification from one place rather than each maintaining its own list.
Chart-of-accounts design, done deliberately. A conglomerate absorbing many acquired charts of accounts has a genuine design decision to make — how thin or thick the ledger should be, what belongs in the account segment versus a separate dimension — and EDMCS is the right place to design and hold the target chart while mapping the legacy ones into it. A migration to cloud EPM is the natural moment to do this rather than carrying old chart-of-accounts problems into a new platform.
Migration from legacy master-data tools. Many Gulf groups still run master data in Hyperion’s Data Relationship Management or in spreadsheets. EDMCS is the modern successor, and the migration is a defined piece of work: loading the hierarchies as they actually are, not as the documentation claims they are.
Distribution to a mixed system estate. Because the acquired-growth pattern leaves most conglomerates with more than one ERP, the governance model has to distribute approved changes to Oracle and non-Oracle targets alike, in the format each expects, with a defined behaviour when a target rejects a change.
Comparison: ungoverned versus governed master data
| Dimension | Ungoverned (spreadsheets, per-application edits) | Governed with EDMCS |
|---|---|---|
| Source of truth for the chart of accounts | Each application holds its own version | One governed master; others subscribe |
| Adding a new entity | Keyed separately into each system, inconsistently | One approved request, distributed to all targets |
| Change history | Untracked edits | Full audit trail — who requested, who approved, what changed |
| Impact of a restructuring | Discovered at the next close | Modelled and compared before it is committed |
| Absorbing an acquisition | Manual, error-prone mapping under close pressure | Legacy chart mapped into a governed target chart |
| Bilingual and ownership data | Maintained ad hoc, if at all | Governed properties on the master |
| Non-Oracle systems | Handled by hand | Distributed as controlled subscriptions |
The five ways this goes wrong in the Gulf
1. The problem is treated as a consolidation problem, so the wrong system gets the investment. A group frustrated by a slow, unreliable close pours money and effort into the consolidation tool and the close process, and the close stays unreliable — because the divergence between systems’ master data was never addressed. The consolidation tool was doing exactly what it was told; it was told different things by different systems.
2. An acquisition is consolidated before its chart of accounts is governed. A conglomerate closes a deal and rushes to bring the new entity into the group numbers, mapping its accounts by hand under quarter-end pressure. The mapping is inconsistent, the first consolidations including the entity do not tie, and the group spends the next several closes cleaning up what a governed mapping would have handled once.
3. A restructuring is made in some systems and not others. A business unit moves divisions, or ownership is reorganised, and the change is applied to the ERP and the consolidation but missed in the planning application — or vice versa. For a quarter or two the plan and the actuals describe two different group structures, and no one notices until the variance analysis makes no sense.
4. Ownership data is wrong, and the zakat position inherits the error. Because the ownership hierarchy was maintained loosely rather than governed, an ownership percentage is stated incorrectly, and the error flows into the zakat calculation. What began as a tidy-master-data omission becomes a tax exposure that surfaces at the worst possible moment.
5. Bilingual and non-Oracle requirements are deferred, then retrofitted at cost. Arabic naming and distribution to the group’s SAP or legacy systems are pushed to a later phase to simplify the first build. They return as a retrofit that touches every node and every subscription, on a live governed model, at higher cost and risk than designing them in would have carried.
How the model is built, and the two decisions that matter
The technical build is well understood: register the connected applications, design the viewpoints, node types, properties, and hierarchies, define the request workflows and approval policies, set the validations and business rules, configure the subscriptions that distribute changes downstream, and run the cutover that loads the existing hierarchies as they really are.
The two decisions that actually determine whether the implementation succeeds are not technical, and they deserve more attention than they usually get.
The first is which dimensions to govern centrally in the first phase. Governing everything at once is a way to govern nothing well. The disciplined choice is to start with the dimensions whose divergence causes the most pain — usually the chart of accounts and the entity and ownership hierarchies — and extend from there once the governance is working.
The second is who approves what. A governance model is only as good as its approval workflow, and the workflow is a set of business decisions about authority and control, not a technical configuration. Deciding that a new account requires the group controller’s approval, or that an entity restructuring requires finance and tax sign-off, is where the governance actually lives.
| Phase | Focus | Typical duration |
|---|---|---|
| Requirements to zero-level understanding | Which dimensions to govern first; the approval model; the target systems, Oracle and non-Oracle | 2–3 weeks |
| Design | Viewpoints, node types, properties (including bilingual and ownership), hierarchies, validations | 3–4 weeks |
| Workflow and distribution | Request and approval workflows, subscriptions to each target, rejection handling | 2–3 weeks |
| Migration and cutover | Load existing hierarchies as they truly are; map legacy charts into the target | 2–4 weeks |
| Validation | Prove that an approved change reaches every target correctly before go-live | 2 weeks |
The questions a CFO or CIO should ask
- When our close runs late, do we actually know whether the cause is the consolidation tool or the master data feeding it?
- Is there one governed source of truth for our chart of accounts, entities, and ownership hierarchy — or does each system hold its own?
- When we acquire a company, is absorbing its chart of accounts a governed process or a manual scramble?
- Can we see the impact of a restructuring on our hierarchies before we commit it?
- Is our ownership hierarchy governed with the accuracy our zakat position requires?
- Does our master data carry Arabic as a governed property, or is it retrofitted?
- Can approved changes reach our non-Oracle systems, not just the Oracle ones?
- Have we decided which dimensions to govern first and who approves what — or are we trying to govern everything at once?
Related Insights
- Oracle EPM, BI and automation for family conglomerates
- Oracle FCCS for Multi-Entity Organisations in the GCC and Egypt: The 2026 Implementation Guide
- M&A Financial Due Diligence and Post-Acquisition Finance Integration for GCC and Egypt Enterprises: The 2026 Guide
- Oracle EPM and Hyperion consulting for GCC and Egypt enterprises
Frequently Asked Questions
Q: What is the difference between EDMCS and FCCS? FCCS produces the consolidated result. EDMCS governs the master data — the chart of accounts, entities, and hierarchies — that FCCS and every other application consume. FCCS answers what the group’s numbers are; EDMCS ensures that all the systems feeding those numbers are working from the same chart of accounts and the same structure. A consolidation that does not tie is often an EDMCS-shaped problem being fought in FCCS.
Q: Do we need EDMCS if we only run Oracle systems? Even a pure-Oracle estate benefits, because the chart of accounts and hierarchies are still shared across FCCS, Planning, ARCS, and the ERP, and still diverge without governance. But the case is strongest for the typical Gulf conglomerate, which grew by acquisition and runs a mix of Oracle and non-Oracle systems that all need the same master data delivered consistently.
Q: Can Oracle EDM distribute changes to non-Oracle systems like SAP? Yes. EDMCS governs the dimensions and distributes approved changes to connected targets, and those targets do not have to be Oracle. The practical considerations are the format each target expects, how the change is delivered, and how a rejection is handled — which is exactly why the distribution model is a design decision rather than an afterthought.
Q: How does this help when we make an acquisition? An acquisition brings a new entity and a foreign chart of accounts. With governance in place, absorbing it is a controlled process: the legacy chart is mapped into the governed target chart, the entity takes its place in the ownership hierarchy through an approved request, and the change is distributed to every system at once. Without governance, it is a manual mapping done under close pressure, and it is where consolidations start to break.
Q: What master data does a zakat calculation actually need? The zakat position depends on the ownership structure, so the legal-entity and ownership hierarchy has to be accurate and governed, and each entity’s tax classification — zakat, income tax, or mixed — has to be held reliably. When these live as governed properties on the entity master, Tax Reporting and consolidation both draw from one source rather than maintaining separate, divergent lists.
Q: We still use Hyperion DRM. Is EDMCS the successor? Yes. EDMCS is the modern master-data governance service, and migrating from DRM is a defined piece of work — the key discipline is loading the hierarchies as they actually are today, not as old documentation describes them, so the governed model reflects reality from day one.
About Loop Wise Solutions
Loop Wise Solutions is an enterprise performance consultancy based in Cairo, serving organisations across the Arab world. We specialise in Oracle EPM, Business Intelligence, Intelligent Automation, and Business and Technical Consultancy — helping finance and operations leaders plan better, report faster, and make decisions with confidence.
Our consultants have governed master data and delivered consolidation for family conglomerates and diversified groups across Saudi Arabia, the UAE, and the wider Gulf — the organisations that grow by acquisition, run mixed system estates, and feel every ungoverned hierarchy at quarter-end. We treat the regional foundations — bilingual master data, ownership hierarchies governed to the standard a zakat calculation demands, and distribution to non-Oracle systems — as core scope, not a later phase. The people who design the governance model are the people who build it, and we stay in partnership through the first closes so the model proves itself under real conditions.
If your close runs long for reasons no one can quite name, the master data feeding it is the first place worth looking. We would be glad to help you find out whether that is where your problem lives.
Contact: contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
