A common situation in Gulf finance functions looks like this. The organisation runs its planning, budgeting, and consolidation in Oracle EPM — a governed, multidimensional environment that took real effort to implement. At the same time, the wider enterprise standardised on Microsoft years ago, so the FP&A team lives in Power BI and is expected to produce its analysis and dashboards there. Everyone assumes the two connect. They do not, at least not natively — and the way most teams bridge the gap quietly undoes part of what Oracle EPM was bought to achieve.
Here is the mechanism. Because there is no native connector, an analyst exports plan data from EPM into Excel, cleans it, and builds a Power BI report on that personal extract. The extract is manual, undated, and ungoverned; the next analyst builds a different one; and within a couple of cycles the organisation has a governed planning system feeding a set of ungoverned personal datasets — the exact spreadsheet problem, in a new tool. The dashboards look modern. The data lineage behind them is anything but.
The question worth answering is not whether FP&A should use Power BI. In most Gulf enterprises that decision was made long ago, and Power BI is a strong analytics and presentation tool. The question is whether the path from Oracle EPM to Power BI is a governed pipeline or a chain of personal exports — and, in this region, whether that pipeline handles Arabic, the Hijri calendar, and data residency as designed requirements rather than afterthoughts. This guide covers the connectivity reality, the architecture that fixes it, the Power BI versus Oracle Analytics Cloud decision, and the regional details that a global tutorial will never mention.
The connectivity reality: there is no native connector
The first thing to understand, because so much wasted effort follows from not knowing it, is that Oracle EPM Cloud does not offer a native Power BI connector, and Power BI does not offer a native connector for Oracle EPM Cloud. The reason is structural: EPM applications are multidimensional — Essbase-based OLAP cubes — while Power BI expects tabular, relational data. Power BI’s Essbase connector was built for on-premises Essbase and Oracle Analytics Cloud, and even there it is temperamental; against EPM Cloud it does not provide a clean, supported path. Attempting to point Power BI directly at an EPM Cloud application is how teams lose days to connection errors that have no reliable fix.
The supported paths are indirect, and choosing among them is an architecture decision:
Extract via the EPM REST API or Data Management, then connect Power BI to the extract. EPM Cloud exposes REST APIs that export cube data — level-zero or all data, to a file in the outbox, downloadable through EPM Automate — and Data Management can push extracts to files or a database on a schedule. Power BI then connects to that governed output rather than to the cube. This is the most robust and most common approach, and the right foundation for a proper FP&A analytics layer.
Bridge through Oracle Analytics Cloud. Where the organisation has OAC, it connects to EPM and Essbase natively, and Power BI can then connect to an OAC subject area through the Power BI connectivity that OAC provides. This adds a layer but keeps a governed semantic model between the cube and Power BI.
One operational detail matters in either case: running a full data export places the cube into read-only mode for the duration of the export, so extract timing has to be designed around planning and close activity rather than colliding with it. And because the source is multidimensional and the target is tabular, the extract design — which level of data, which point of view, how the dimensions are flattened — is not a detail. It is most of the work, and doing it badly produces a dataset that is technically connected and analytically useless.
Why the naive approaches fail
Three shortcuts recur, and each fails in a predictable way.
The personal Excel export is the most common. It works once, for one analyst, and it is invisible to governance. Multiplied across a team and across quarters, it becomes a sprawl of inconsistent extracts that no one can reconcile, which is the precise failure mode Oracle EPM was implemented to end.
The direct-connector attempt wastes time chasing a connection that is not supported for EPM Cloud, sometimes appearing to half-work through the on-premises Essbase connector before breaking under load or on refresh.
The point-to-point pipeline built once and forgotten connects a single extract to a single report with no semantic layer, so every new report needs its own extract, the definitions of measures drift between reports, and the organisation ends up with many dashboards that disagree with each other and with the source.
The common thread is the absence of a governed layer between the cube and the reports. That layer is what turns Power BI from a prettier spreadsheet into a trustworthy analytics surface.
The architecture that works for FP&A
A governed EPM-to-Power BI pipeline has three parts, and the value is in the middle one.
Extract, on a schedule, by design. A governed extract pulls the required plan, forecast, and actuals data from EPM through the REST API or Data Management, at a defined level and point of view, on a schedule that respects the planning and close calendar. This replaces the personal export with a single, dated, repeatable feed.
A semantic layer that combines and defines. The extracted EPM data lands in a modelled layer — a warehouse or a governed dataset — where it is combined with actuals from the ERP and with operational data, and where measures, hierarchies, and business definitions live once. This is where variance is defined consistently, where plan meets actual, and where the single version of a KPI is established, so that every report downstream inherits the same definitions rather than reinventing them.
Power BI as the presentation and self-service surface. With a governed model beneath it, Power BI does what it is genuinely good at — interactive dashboards, drill-down, variance analysis, self-service exploration for the FP&A team and their business partners — on data whose lineage runs back to the governed plan. The analyst explores and presents; they no longer curate their own private version of the truth.
This is the arrangement that lets a finance function have both things it wants: the modern, self-service analytics experience the business expects, and the governed, reconcilable numbers the CFO requires. The two are only in tension when the middle layer is missing.
Power BI or Oracle Analytics Cloud? A practitioner’s view
Because Oracle sells Oracle Analytics Cloud and Microsoft sells Power BI, the question is often posed as a loyalty test. It should not be. Both are capable, and the right answer is usually about the estate the organisation already runs.
For an enterprise standardised on Microsoft — Microsoft 365, Azure, Power BI already in every other department — Power BI as the presentation layer is the pragmatic choice, because it meets users where they already are and avoids introducing a second analytics tool to learn and license. The work, as above, is building the governed pipeline beneath it.
Oracle Analytics Cloud earns its place where the analytics need to sit close to the Essbase and EPM structures natively, where an OAC semantic model is the cleanest bridge to Power BI anyway, or where the organisation’s data estate is Oracle-centric enough that a second platform adds cost without adding reach. In some Gulf enterprises the honest answer is both — OAC providing the governed semantic bridge to the EPM cubes, Power BI providing the presentation surface the business consumes.
The mistake is treating it as an identity question rather than an architecture one. We take no doctrinal position on the tool; we take a firm position on the pipeline, because that is what determines whether the numbers can be trusted regardless of which surface displays them.
What the GCC build has to get right
This is where a global implementation and a regional one diverge sharply, and where the specific, unglamorous details decide whether the result is usable.
Arabic and right-to-left, with a real limitation to design around. Power BI supports Arabic data and right-to-left rendering in the published Service, but Power BI Desktop — where reports are actually built — does not support Arabic or Hebrew and has no canvas-level right-to-left toggle. The practical consequence is that a bilingual dashboard is designed in a left-to-right Desktop environment, its visuals are manually positioned into a right-to-left arrangement, and the Arabic rendering is verified by publishing to the Service and iterating. A team that does not know this designs an English report and assumes Arabic will follow automatically; it will not. Slicers and filters belong on the right, buttons and navigation order flip, and text alignment has to be handled deliberately.
One bilingual template, not two builds. Most GCC enterprises need Arabic and English both. Producing these as two separate reports doubles the maintenance and guarantees they will drift apart; producing them as one bilingual template is more work to design and far less to run. The choice should be scoped explicitly at the start, because the cost difference is significant and the drift risk is real.
Arabic numerals are a stakeholder decision, not a default. Many Gulf business users prefer Western Arabic numerals even when reading an Arabic report. That means numbers should be formatted to a fixed locale rather than inheriting the user culture automatically, and the preference should be confirmed with stakeholders early rather than discovered in review.
The Hijri calendar needs a custom date dimension. Power BI’s date handling defaults to Gregorian. Where reporting is expected against the Hijri calendar, a custom date dimension has to be built; it is not a setting to switch on.
Data residency is a live architecture decision. Financial data extracted from EPM into Power BI moves into the Microsoft tenant and its capacity, so where that capacity sits matters for PDPL and NCA obligations. Azure UAE North in Dubai and UAE Central in Abu Dhabi are live, tenant residency can be locked to keep datasets and dataflows in-country, and Qatar Central is available for Power BI workloads. Microsoft’s Saudi Arabia region is confirmed to come online in 2026 for in-Kingdom residency; until it is live, Kingdom workloads that are sensitive or classified are commonly kept on Power BI Report Server on-premises, while less sensitive workloads run through a nearby region under a documented cross-border transfer assessment. Fabric and Premium capacity can be pinned to a chosen region, and sensitivity labelling classifies the data flowing through. None of this is optional for regulated finance data; all of it is a design decision made at the outset, not a migration funded later.
Comparison: personal exports versus a governed pipeline
| Aspect | Manual Excel export → personal Power BI | Governed EPM-to-Power BI pipeline |
|---|---|---|
| Source of the data | Ad hoc personal extracts | Scheduled, governed extract by defined POV |
| Measure and KPI definitions | Reinvented per report | Defined once in a semantic layer |
| Plan vs actual | Reconciled by hand, if at all | Combined in the modelled layer |
| Reconcilability to EPM | Weak; lineage lost | Lineage runs back to the governed plan |
| Bilingual output | Retrofitted per analyst | Designed into the template |
| Data residency | Uncontrolled | Region-pinned by design |
| Refresh and timing | Manual, collides with close | Scheduled around the planning calendar |
The five ways this goes wrong in the Gulf
1. FP&A builds on personal EPM exports. Each analyst maintains their own Excel extract and their own Power BI report, and the organisation’s dashboards quietly stop agreeing with the plan and with each other. The governed planning system is intact; the analytics on top of it are not, and the CFO learns this when two reports show two different forecast numbers in the same meeting.
2. Weeks are lost trying to connect Power BI directly to EPM Cloud. A team assumes a native connection exists, and burns real time on connection errors before discovering that the supported path is an extract pipeline. The lesson is inexpensive if learned early and costly if learned during a reporting deadline.
3. The Arabic dashboard is designed as an afterthought. An English report is built in Power BI Desktop and Arabic is expected to follow, only for the team to hit the Desktop right-to-left limitation late. The bilingual version is then rushed, the RTL layout is wrong, and the Arabic report that goes to leadership looks unfinished next to the English one.
4. Residency is discovered after the data has moved. EPM financial data is extracted into a Power BI capacity in a region that does not satisfy the applicable residency obligation, and the problem surfaces in a compliance review after the fact. Designing the region and the tenant residency first would have made it a non-issue; addressing it afterwards is a migration.
5. No semantic layer, so the dashboards multiply and diverge. Reports are built point-to-point on separate extracts with no shared model, definitions drift, and the organisation accumulates many dashboards that disagree. The absence of the middle layer is felt as a slow erosion of trust in every number Power BI shows.
Implementation scope and sequence
| Phase | Focus | Typical duration |
|---|---|---|
| Requirements to zero-level understanding | The FP&A questions to answer, the EPM data and POV needed, the bilingual and residency requirements | 2–3 weeks |
| Extract and pipeline | REST or Data Management extract, scheduling around the close, landing in the modelled layer | 2–3 weeks |
| Semantic layer | Combine EPM plan with ERP actuals and operational data; define measures, hierarchies, variance once | 3–4 weeks |
| Power BI build | Dashboards, self-service model, bilingual template, Hijri date dimension where needed | 3–4 weeks |
| Residency and governance | Region pinning, tenant residency, sensitivity labelling, refresh and access governance | 1–2 weeks |
| Validation | Reconcile Power BI outputs back to EPM; verify Arabic rendering in the Service | 2 weeks |
Where the underlying EPM data itself is not yet trustworthy, the sensible sequence is to stabilise that first — a governed pipeline faithfully carries whatever it is given, including errors.
The questions a CFO, FP&A lead, or CIO should ask
- Is our path from EPM to Power BI a governed pipeline, or a set of personal Excel exports?
- Do our Power BI numbers reconcile back to the plan in EPM, with lineage we can show?
- Do we have a semantic layer where measures and variance are defined once, or does every report reinvent them?
- Have we designed for the Power BI Desktop right-to-left limitation, or assumed Arabic would follow the English build?
- Are we producing one bilingual template or maintaining two divergent builds?
- Where does our extracted EPM financial data physically reside, and does that satisfy PDPL and NCA?
- Have we chosen Power BI and Oracle Analytics Cloud on architecture grounds, or on habit?
Frequently Asked Questions
Can Power BI connect to Oracle EPM Cloud? Not natively. EPM Cloud is multidimensional and Power BI has no supported native connector for it, so the reliable path is to extract EPM data — through the REST API or Data Management — into a governed layer, or to bridge through Oracle Analytics Cloud, and connect Power BI to that. Pointing Power BI directly at an EPM Cloud application is not a supported, dependable approach.
What is the best way to get EPM data into Power BI? A scheduled extract into a modelled semantic layer, where EPM plan data is combined with ERP actuals and operational data and where measures are defined once, with Power BI as the presentation surface on top. This gives FP&A the self-service experience while preserving lineage back to the governed plan. Extract timing should respect the planning and close calendar, since a full export puts the cube into read-only mode while it runs.
Should I use Power BI or Oracle Analytics Cloud? It depends on the estate, not on loyalty. For a Microsoft-standardised enterprise, Power BI as the presentation layer meets users where they already are; Oracle Analytics Cloud earns its place where native EPM and Essbase analytics matter or where an OAC semantic model is the cleanest bridge — and some organisations use both, OAC bridging to the cubes and Power BI presenting. The decision that matters more than the tool is whether there is a governed pipeline beneath it.
Does Power BI support Arabic right-to-left dashboards? The published Power BI Service renders Arabic and right-to-left content, but Power BI Desktop — where reports are built — does not support Arabic and has no right-to-left canvas toggle. So bilingual dashboards are designed left-to-right, arranged manually for right-to-left, and verified by publishing to the Service. Knowing this in advance is the difference between a polished Arabic report and one that looks unfinished.
Where is Power BI data stored for UAE and Saudi residency? Azure UAE North and UAE Central are live and tenant residency can be locked to keep data in-country; Qatar Central is available for Power BI. Microsoft’s Saudi Arabia region is confirmed to come online in 2026 for in-Kingdom residency; until then, sensitive Kingdom workloads are commonly kept on Power BI Report Server on-premises. Because extracting EPM data moves it into the Microsoft capacity, the region should be chosen deliberately to match the obligation.
How do you handle the Hijri calendar in Power BI? Power BI defaults to the Gregorian calendar, so Hijri reporting requires a custom date dimension built for the purpose. It is a modelling task in the semantic layer, not a configuration switch, and it should be scoped where Hijri reporting is a genuine requirement.
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 build the governed pipelines that connect Oracle EPM to Power BI for finance teams across Saudi Arabia, the UAE, and the wider Gulf — teams that have standardised on Microsoft but plan in Oracle, and that need analytics the business will use and numbers the CFO will trust. We treat the regional design — bilingual right-to-left dashboards, the Hijri calendar, and in-region data residency — as core scope, not a later phase, and we are candid about where Power BI and Oracle Analytics Cloud each fit rather than selling a single answer. The people who design the pipeline are the people who build it, and we stay through the first reporting cycles so the analytics reconcile to the plan.
If your Power BI dashboards are built on personal EPM exports, the numbers behind them are less governed than they look. We would be glad to show you what a governed EPM-to-Power BI pipeline looks like against your own reports.
Contact: contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
