Saudi Arabia is no longer in the planning phase of its transformation. It is in the execution phase. Capital is moving. Giga-projects are scaling. International partnerships are active. Sovereign fund principals, institutional lenders, and global corporate partners are all demanding a standard of financial reporting, planning rigour, and governance transparency that did not exist as a baseline expectation in the Kingdom five years ago.
The CFO who was effective in the growth-story environment of Vision 2030’s early years — where ambition was the primary deliverable and financial reporting existed to support narrative — is now operating in an execution-heavy environment where accountability is the deliverable and financial reporting must support decisions, not describe outcomes.
The same shift is visible across the UAE, Qatar, Egypt, and every GCC market where the pace of institutional investment, regulatory sophistication, and governance expectation has accelerated faster than most finance functions have transformed.
The consequence is a specific and measurable gap: the gap between the finance function that GCC and Egyptian enterprises currently have — built for a private, owner-managed, growth-narrative environment — and the finance function they need — built for institutional capital, public market readiness, regulatory accountability, and real-time operational decision support.
This guide addresses that gap directly. It defines what a modern finance function looks like in the GCC and Egypt context in 2026, describes the technology architecture that enables it, maps the specific transformation steps from current state to target state, and identifies the sequencing decisions that determine whether the transformation delivers in twelve months or drags across four years.
What Vision 2030 Has Done to the Finance Function Standard
The finance function in a Saudi private company that engaged primarily with its founding family and its bank did not need to produce real-time dashboards, IFRS-compliant consolidated accounts within three weeks of month-end, driver-based forecasts that can be interrogated by an external investor, or a tax provision that reconciles to the nearest riyal under UAE corporate tax and Saudi zakat simultaneously.
It does now — or it will, within the next twenty-four months, as the organisations that constitute Vision 2030’s private sector delivery engine engage more deeply with PIF, sovereign wealth funds, Vision 2030 programme offices, international joint venture partners, and eventually public capital markets.
Four specific Vision 2030-driven forces have redefined the finance function standard for GCC enterprises:
The Regional Headquarters mandate and its finance implications. Saudi Arabia’s RHQ requirement — compelling multinationals to establish substantive regional headquarters in the Kingdom — creates a wave of new finance function design requirements. The RHQ finance function must serve both global corporate reporting (in the ERP and reporting standards of the parent) and Saudi regulatory reporting (SOCPA, ZATCA, Saudi PDPL, GOSI). The finance team must speak both languages — literally and technically. The systems must produce both sets of outputs from the same underlying data.
The sovereign fund counterparty standard. PIF subsidiaries, Vision 2030 programme participants, and entities that receive sovereign investment are subject to an implicit governance and reporting standard that the investor applies. This standard includes: quarterly financial reporting with management commentary within 45 days of quarter-end; driver-based financial projections for the next three to five years; IFRS-compliant consolidated accounts for multi-entity structures; and a budgetary control environment that the investor can review without needing to request additional information. The finance function that cannot meet this standard does not win sovereign capital — or loses it after the first audit cycle.
The institutional capital market expectation. Saudi Arabia’s Tadawul and Nomu continue to attract listings. UAE’s DFM and ADX are active. Egypt’s EGX is seeing renewed interest. The finance function of a company approaching a public listing — or engaging institutional private equity — faces the full public company standard for financial reporting, planning, audit-readiness, and governance. The sovereign cloud and data architecture article (linked above) covers the technical dimension; this article covers the operating model dimension of that same standard.
The competitive pressure of better-equipped regional peers. Across the GCC, the enterprises that have invested in finance function transformation — modern ERP, integrated EPM, real-time BI, governed automation — are making decisions faster, closing faster, reporting faster, and winning more institutional business than their peers who are still assembling management accounts from email attachments and Excel models. The competitive dynamic now rewards finance function maturity in a way it did not five years ago.
The Finance Function Maturity Model for GCC Enterprises
Before designing the transformation, the current state must be assessed honestly. The following maturity model describes four levels of finance function development — from the entry-level private company finance function to the institutional-standard environment that Vision 2030 and public capital markets require.
Level 1 — Transactional Finance
What it looks like: The finance function’s primary activity is recording transactions and producing periodic reports. The chart of accounts was designed for tax filing and bank reporting, not management decisions. Management accounts are produced monthly by the finance team, assembling data from the ERP into Excel and distributing a PDF. The budget is a top-down target entered annually. The close takes fifteen to twenty business days. Consolidation, if it exists, is in Excel. The CFO’s primary deliverable is the annual accounts.
Who this describes: Most GCC family-owned enterprises below SAR 500 million revenue that have not undergone a structured finance transformation. Also many enterprises that have implemented ERP but not EPM, and have BI dashboards that display data rather than support decisions.
The institutional gap: A transactional finance function cannot support sovereign fund reporting requirements, IPO preparation timelines, institutional investor due diligence, or the quarterly performance reporting cadence of a Vision 2030 programme participant. The gap between Level 1 and institutional standard is the most common root cause of delayed listings, failed due diligence, and regulatory findings in GCC finance functions.
Level 2 — Controlled Finance
What it looks like: The ERP is the system of record for all transactions, with a consistent chart of accounts across the group’s entities. The close takes eight to twelve business days. A budgeting process exists with department-level input and sign-off. Management accounts are produced from ERP data with some automation but still require significant manual assembly. Consolidation is in Oracle FCCS or equivalent — not Excel. Some reporting is automated; significant management reporting is still manual.
Who this describes: Large GCC enterprises that have implemented a modern ERP (Oracle Fusion, SAP S/4HANA, Microsoft Dynamics) and have made initial investments in finance systems infrastructure. This is the most common state for large Saudi and UAE enterprises that have undergone the first phase of digital transformation without completing it.
The institutional gap: A controlled finance function can produce accurate historical financial statements but cannot support real-time management decisions, rapid scenario modelling for strategic pivots, or the investor-grade forward-looking financial information that institutional counterparties require.
Level 3 — Analytical Finance
What it looks like: Finance produces not just what happened but why it happened and what it implies. Oracle EPM Planning connects the financial plan to operational drivers — revenue per unit, headcount per project, cost per transaction. The budget variance report shows not just the variance but the driver that caused it. BI dashboards replace PDF reports for the executive team. The close is eight business days or fewer. Forecast updates run within 48 hours of a business trigger, not on a monthly schedule. The CFO is a business partner, not a historian.
Who this describes: A smaller proportion of GCC enterprises — primarily those that have invested in both ERP and EPM, have configured driver-based planning models, and have built BI environments designed for decisions rather than data display. This is the target state for most GCC enterprises undertaking finance transformation, and the minimum standard for Vision 2030 programme reporting counterparties and pre-IPO readiness.
The institutional gap: At Level 3, finance can support institutional reporting and investment-grade planning. The remaining gap is predictive capability — using historical patterns to inform forward decisions, not just to explain historical performance.
Level 4 — Predictive Finance
What it looks like: Oracle EPM’s Planning Agent monitors plan-versus-actual performance continuously and surfaces variance drivers and scenario implications before the monthly review. Predictive Planning generates the statistical baseline for the next forecast, which the FP&A team applies judgment to rather than building from scratch. The close is five business days. Quarterly reporting is produced within 30 days of quarter-end with full IFRS 18 compliance. Arabic and English versions are produced simultaneously from the same data model. The CFO’s function is strategic — applying financial intelligence to the organisation’s operating decisions in real time, not assembling information from the past.
Who this describes: The most advanced finance functions in the GCC — a small number of large enterprises that have completed the full finance function transformation journey. This is the aspirational target for institutions preparing for public capital markets or engaged as sovereign fund counterparties at the highest tier of Vision 2030 programming.
The Six Technology Decisions That Define Finance Function Maturity
The journey from Level 1 to Level 3 or Level 4 is not primarily an organisational or cultural journey. It is a technology architecture journey. The six technology decisions below determine where on the maturity model any finance function sits.
Decision 1: ERP — The Foundation That Everything Else Depends On
The ERP is the system of record for every transaction. Every other finance technology — EPM, BI, automation — draws data from the ERP. If the ERP foundation is wrong — inconsistent chart of accounts across entities, incomplete audit trail, manual journal entries outside the system, non-ZATCA-compliant invoice recording — every downstream finance technology investment produces outputs that cannot be trusted.
The ERP decision for GCC enterprises is covered in depth in the ERP comparison pillar (Oracle vs SAP vs Dynamics). The specific finance function transformation implications:
Chart of accounts design determines reporting capability. A chart of accounts designed for tax filing (the minimum required by Saudi accounting standards) cannot support management reporting by product line, cost centre, or business unit without a parallel management accounting structure. Many GCC enterprises are running their ERP on a tax-filing chart of accounts and building management accounts in Excel outside the system — which is the single most common cause of Level 1 finance function status regardless of how sophisticated the ERP is.
IFRS 18 alignment must be in the ERP from January 2026, not from 2027. As noted in the IPO readiness pillar, IFRS 18 requires comparative 2026 data in the new income statement category format. The ERP’s chart of accounts and its IFRS posting logic must be aligned to IFRS 18 categories from January 2026, not from the standard’s mandatory date of January 2027.
Decision 2: EPM — From Budget Entry to Connected Planning
Oracle EPM Planning (PBCS/EPBCS) is the technology decision that moves a finance function from Level 1 (top-down budget entry) or Level 2 (controlled but static budget) to Level 3 (driver-based, connected, continuously updated).
The EPM configuration decision that most determines planning maturity: whether the planning model is input-based (users enter financial line items directly — revenue is SAR 500M because the CEO said so) or driver-based (revenue is calculated from volume assumptions × price assumptions × capacity assumptions, which the business can update when any driver changes).
An input-based Oracle EPM Planning model is a budgeting tool. A driver-based Oracle EPM Planning model is a decision support tool. Most GCC enterprises that have implemented Oracle EPM have built input-based models — because input-based models are faster to configure, require less business process documentation, and look identical to driver-based models in a vendor demonstration. The difference only becomes visible when the business needs to reforecast quickly: an input-based model requires someone to decide what the new revenue number is; a driver-based model shows what the new revenue number implies given the changed driver assumptions.
The connection between EPM Planning and ERP actuals closes the plan-versus-actual visibility gap that characterises Level 1 and Level 2 finance functions. Oracle Fusion ERP actuals flow natively into Oracle EPM Planning — the same chart of accounts, the same entity structure, the same period definitions. Management accounts produced from Oracle EPM show actuals from the ERP alongside budget and forecast from the planning model in the same report.
Decision 3: Financial Close — From 15 Days to 5
The financial close cycle duration is the most visible measure of finance function operational maturity. A fifteen-day close is a Level 1 finance function. An eight-day close is Level 2. A five-day close is Level 3 or Level 4.
The technologies that reduce close cycle duration are covered in the Oracle FCCS and Oracle ARCS pillar articles. The finance function transformation implication: the close cycle duration is not primarily a technology problem. It is a process problem that technology solves. The most common reasons GCC finance functions have fifteen-day or longer close cycles are:
- Intercompany reconciliation performed manually, taking three to five days to match and resolve
- Account reconciliation performed in spreadsheets, taking four to seven days and dependent on specific individuals
- Consolidation performed in Excel, taking two to three days to run, check, and correct
- Tax provision assembled manually from a spreadsheet model, taking two to three days
Oracle FCCS automates the consolidation. Oracle ARCS automates account reconciliation and surfaces exceptions for investigation rather than requiring each account to be prepared from scratch. Oracle TRCS automates the tax provision. The process design that enables these tools to run efficiently is the finance transformation work — mapping the intercompany transaction flow, designing the reconciliation profile framework, aligning the close calendar across entities.
Decision 4: BI and Management Reporting — From PDF to Decisions
The management reporting output that most finance functions produce — a monthly PDF pack distributed by email — is a Level 1 or Level 2 deliverable. It answers what happened. It does not answer why it happened, whether it matters, or what to do about it.
The executive BI dashboard that answers all three questions is described in detail in the LWS BI Executive Dashboard design guide. The finance function transformation implication: the management reporting format is a proxy for the finance function’s analytical maturity. A finance team that produces PDF reports is using its senior capacity to assemble history. A finance team that operates real-time BI dashboards — designed around decisions, with alert logic, with drill-down to driver detail — is using its senior capacity to generate insight.
The technology enabler is not the BI tool — it is the data model that connects ERP actuals, EPM planning data, and operational metrics in a single governed layer that the BI tool can query. The BI platform comparison guide (Power BI vs Oracle Analytics vs Tableau) covers the tool selection; the finance function transformation implication is that the management reporting redesign must precede the BI tool deployment, not follow it.
Decision 5: Automation — From Transaction Processing to Thinking
A Level 1 finance function spends most of its time processing transactions — entering invoices, posting journals, reconciling accounts, assembling reports. A Level 3 or Level 4 finance function has automated the transaction processing layer and re-deployed its capacity toward analysis, business partnership, and strategic financial management.
The automation of accounts payable (AP automation pillar), procure-to-pay (P2P automation pillar), payroll compliance (payroll automation pillar), and account reconciliation (Oracle ARCS pillar) are each covered in dedicated LWS articles. The finance function transformation implication: these are not independent automation projects — they are workstreams within a coordinated finance function transformation programme. The sequencing matters:
- Start with ERP foundation (chart of accounts, IFRS alignment, audit trail)
- Add EPM Planning (driver-based model, actuals integration)
- Add Oracle FCCS (consolidation automation, close cycle reduction)
- Add Oracle ARCS (account reconciliation governance, close acceleration)
- Add AP/P2P automation (transaction processing efficiency, ZATCA compliance)
- Add BI (management reporting redesign, executive dashboard deployment)
- Add Oracle TRCS (tax provision automation, IFRS 18 compliance)
- Activate AI features (Planning Agent, Predictive Planning, GenAI narrative)
This sequence produces a finance function that is structurally transformed — not a collection of individual technology investments that each improve one process without connecting to the others.
Decision 6: Data Governance and Compliance Architecture
The sixth technology decision — data governance and compliance architecture — is the dimension that most GCC finance function transformations address last but should address first. The sovereign cloud and data architecture pillar covers this in detail; the finance function transformation implication is specific:
The ERP and EPM data that underlies the finance function must be hosted, governed, and protected in a manner that satisfies the data governance obligations of the organisation’s operating jurisdictions. A finance function built on a cloud architecture that is not PDPL-compliant is a finance function that carries regulatory exposure in every reporting period. This is not a systems project to be deferred — it is a governance design requirement that should be established before the ERP and EPM environments are deployed, not remediated after they go live.
The Finance Function Transformation Roadmap: Sequence and Timeline
The six technology decisions above are not independent. They build on each other, and the sequence in which they are addressed determines whether the transformation delivers within 18 months or consumes 48 months without reaching the target state.
The following roadmap is designed for a GCC enterprise at Level 1 or Level 2 targeting Level 3 within 18 to 24 months.
Phase 1 — Foundation (Months 1–8): Get the ERP Right
Before any EPM, BI, or automation investment produces reliable outputs, the ERP foundation must be sound. Phase 1 work:
Chart of accounts harmonisation across all entities — producing a consistent account structure that supports both statutory reporting and management reporting without a separate parallel structure. IFRS 18 category mapping in the ERP chart of accounts — configuring the income statement categories required by IFRS 18 from January 2026. ZATCA Phase 2 compliance validation for Saudi entities — confirming the ERP is fully ZATCA-certified and that invoice data is consistent with ZATCA registrations. UAE corporate tax configuration for UAE entities. Internal controls configuration — segregation of duties enforcement in the ERP workflow, approval controls for material transactions, audit trail activation and review. Data governance architecture — confirming data residency for PDPL, NCA cloud classification, and SAMA framework requirements.
Milestone: A clean, consistent, compliant ERP foundation that EPM, BI, and automation can reliably draw from.
Phase 2 — Close and Consolidation (Months 5–14): Reduce the Close to 8 Days
With a clean ERP foundation in place, the close cycle can be systematically reduced. Phase 2 work:
Oracle FCCS implementation — replacing Excel consolidation with a governed, automated consolidation environment that eliminates intercompany balances systematically, applies IFRS 10 rules consistently, and produces auditable consolidated accounts. Oracle ARCS implementation — automating account reconciliation for the balance sheet, configuring risk-based reconciliation profiles, and deploying Transaction Matching for bank and intercompany reconciliation. Close calendar redesign — aligning close timelines across all entities to the target close duration.
Milestone: Eight-day close, automated consolidation, and a reconciliation audit trail that external auditors can navigate without requesting additional evidence.
Phase 3 — Planning and Forecasting (Months 8–16): Build the Driver-Based Model
With a reliable close process, the planning environment can be built on clean actuals data. Phase 3 work:
Oracle EPM Planning implementation — driver-based financial model covering revenue, direct costs, indirect costs, headcount, and capital expenditure, with Oracle Fusion actuals feeding the plan-versus-actual view. Scenario planning capability — base, upside, and downside scenarios for the primary financial drivers. Saudization compliance integration for Saudi organisations — Nitaqat compliance tracking embedded in the workforce planning model.
Milestone: Driver-based planning model, first annual planning cycle completed in Oracle EPM, plan-versus-actual reporting available within 48 hours of close.
Phase 4 — Reporting and Automation (Months 12–20): Replace the PDF
With the planning and close environment stable, the management reporting layer can be redesigned. Phase 4 work:
Executive BI dashboard implementation — designed from the decision architecture described in the BI dashboard design guide, replacing the monthly PDF pack with real-time decision support. AP automation and P2P automation deployment — removing the transaction processing burden from the finance team. Oracle TRCS implementation — automating the tax provision, UAE DMTT calculation, and IFRS 18 disclosure output.
Milestone: Monthly PDF pack retired, executive BI dashboards live, transaction processing automated, finance team capacity freed for analytical work.
Phase 5 — AI Activation (Months 18–24): Move from Reactive to Predictive
With the EPM, BI, and automation layer stable and producing reliable data, AI capabilities can be activated. Phase 5 work:
Oracle Planning Agent activation — configuring signal detection rules and alert thresholds for the driver model built in Phase 3. Oracle Predictive Planning activation — enabling the statistical baseline generator for the quarterly forecast cycle. GenAI Narrative Reporting configuration — Arabic and English first-draft management commentary from the close and planning data. IPM Insights activation — anomaly detection and forecast bias identification.
Milestone: Finance function operating at Level 3 or Level 4 — producing real-time insights, continuously updated forecasts, and management commentary at a speed and depth that matches institutional investor expectations.
The Five Most Common Finance Function Transformation Failures in the GCC
1. EPM Was Implemented Before the ERP Was Fixed
The most common mistake in GCC finance function transformation. An Oracle EPM Planning and FCCS environment was implemented on top of an ERP whose chart of accounts was inconsistent across entities, whose audit trail was incomplete, and whose intercompany transaction recording was asymmetric. EPM produced consolidated accounts — but the consolidated accounts did not agree with the statutory accounts produced by the ERP, because the ERP data entering FCCS was incomplete. The ERP-EPM reconciliation became a permanent monthly task that consumed more time than the Excel consolidation it replaced.
2. Management Reporting Was Automated Without Being Redesigned
The finance team automated the production of the management pack — the same PDF, with the same structure, with the same metrics, produced faster. The management team continued to receive a document that showed what happened, not what it meant. The BI investment produced faster delivery of the existing report rather than a better report. The CFO continued to spend three days after distribution answering questions from the management team that the report did not answer directly. The management reporting redesign — starting from the decisions the management team needs to make — should have preceded the automation.
3. The Planning Model Was Input-Based and Called Driver-Based
Oracle EPM Planning was configured with revenue, cost, and headcount inputs at the department level. The model was described to the board as a driver-based planning environment. When the CFO needed to reforecast mid-year after a pricing change, the reforecast required the budget team to manually update every revenue line across every entity with a new figure. There were no price or volume drivers to adjust — the model was input-based with EPM’s formatting. The strategic planning value of EPM — the ability to run scenarios rapidly by adjusting driver assumptions — was not realised because the model design was not driver-based.
4. Finance Transformation Was Sequenced Technology-First, Not Process-First
The company invested in Oracle Fusion ERP, Oracle EPM, Power BI, and a suite of automation tools over three years. Each technology was implemented by a different implementation partner. The ERP chart of accounts was designed by the ERP partner for ERP purposes. The EPM dimension structure was designed by the EPM partner for EPM purposes. The Power BI data model was designed by the BI partner for BI purposes. None of the three shared a consistent dimension structure, a consistent entity hierarchy, or a consistent definition of what constituted “revenue” in each system. The management accounts from Power BI did not reconcile to the Oracle EPM consolidated output, which did not reconcile to the Oracle Fusion trial balance. The finance team spent more time reconciling three systems than it had spent producing manual reports.
5. The FP&A Team Was Not Involved in EPM Design
Oracle EPM Planning was designed and implemented by the IT team, based on the requirements gathered from the finance director. The FP&A team — the primary users of the planning environment — was consulted at the end of the implementation when the system was demonstrated for user acceptance testing. The model did not reflect how the FP&A team actually planned — it reflected how the finance director described the planning process, which was a simplification that omitted the specific allocation logic, the specific exception rules, and the specific reporting views that the FP&A team used every planning cycle. The EPM model was technically correct and operationally wrong. The FP&A team continued to plan in Excel alongside Oracle EPM.
The Finance Function Transformation Assessment: Starting Point
Before committing to a technology investment sequence, a structured finance function assessment produces an objective baseline — confirming the current maturity level, identifying the specific gaps that limit maturity, and defining the technology and process investments required to close those gaps in the right sequence.
| Assessment Component | Timeline | Professional Services (USD) |
|---|---|---|
| Finance function maturity assessment (all 6 technology dimensions) | 3–5 weeks | 18,000–45,000 |
| ERP foundation review (chart of accounts, audit trail, IFRS 18, ZATCA) | 2–4 weeks | 12,000–30,000 |
| EPM planning model assessment (driver vs input, actuals integration, scenario capability) | 2–3 weeks | 10,000–25,000 |
| Close cycle assessment (consolidation, reconciliation, timeline to Level 3) | 2–3 weeks | 10,000–22,000 |
| Management reporting redesign (decision architecture, BI readiness) | 2–4 weeks | 12,000–28,000 |
| Full transformation roadmap design (5-phase sequenced programme) | 4–6 weeks | 22,000–55,000 |
| Full finance function transformation programme (Levels 1–2 → Level 3) | 18–30 months | 300,000–800,000 |
Notes:
- The assessment should precede any technology implementation commitment. The assessment output defines which investments are required, in what sequence, and at what scope — preventing the most common failure mode of implementing EPM before fixing the ERP, or implementing BI before redesigning management reporting.
- The full transformation programme cost range reflects the variation in starting point (Level 1 vs Level 2) and the number of entities, countries, and systems in scope.
- Oracle platform licensing is additional to professional services.
Frequently Asked Questions
Q: What does a modern finance function look like for a GCC enterprise in 2026? A modern finance function in the GCC context in 2026 operates at what we call Level 3 or Level 4 maturity: it closes its books within eight business days using Oracle FCCS for automated consolidation and Oracle ARCS for governed account reconciliation; it produces a driver-based financial plan in Oracle EPM Planning that can be reforecast within 48 hours of a business trigger; it delivers management reporting through real-time BI dashboards designed around the decisions the executive team needs to make, not around the data the finance team has available; it has automated the transaction processing layer — AP, P2P, payroll compliance — so the finance team’s capacity is deployed toward analysis rather than data entry; and it produces IFRS 18-compliant financial statements with Arabic and English versions from the same data model. This is the standard that sovereign fund counterparties, institutional investors, and Vision 2030 programme offices expect in 2026.
Q: How long does finance function transformation take for a GCC enterprise? A GCC enterprise moving from Level 1 (transactional finance) to Level 3 (analytical finance) through a structured five-phase transformation programme typically takes 18 to 30 months from the start of the ERP foundation phase to AI activation. The most important factor in timeline is the starting point — specifically, the state of the ERP foundation. Organisations with a clean, consistent Oracle ERP already in place move through Phases 2 and 3 faster than those that must address chart of accounts harmonisation, IFRS 18 alignment, and ZATCA compliance in Phase 1. The single most consistent cause of timeline extension is discovering ERP foundation problems after EPM or BI implementation has begun, requiring the foundation work to be done retrospectively while the downstream implementations are paused.
Q: What is the right sequencing for finance function technology investment in the GCC? The sequence that reliably produces a functioning Level 3 finance function is: ERP foundation first (chart of accounts, IFRS 18, ZATCA, internal controls, data governance) — then close and consolidation (Oracle FCCS and ARCS) — then planning and forecasting (Oracle EPM Planning, driver-based model) — then management reporting (BI executive dashboards replacing the PDF pack) — then automation (AP, P2P, payroll compliance) — then AI activation (Planning Agent, Predictive Planning, GenAI narrative). The sequence that most commonly fails is EPM before ERP — implementing Oracle EPM on a poor ERP foundation produces EPM outputs that do not reconcile to the statutory accounts, which destroys confidence in the EPM environment and typically requires a rework programme that costs more than getting the ERP right would have.
Q: How does the finance function Vision 2030 requires differ from what most Saudi enterprises currently have? Most Saudi enterprises currently have a Level 1 or Level 2 finance function — accurate historical accounts, a controlled ERP environment, and a budgeting process that produces a number. What Vision 2030 programme participants, sovereign fund counterparties, and pre-IPO enterprises need is a Level 3 finance function — real-time management accounts from governed BI dashboards, driver-based financial forecasts that can be updated within 48 hours of a business change, a financial close completed in eight days or fewer, IFRS 18-compliant consolidated accounts, and Arabic-language reporting produced from the same data as English-language reporting without a translation step. The gap between current state and this target is primarily a technology gap — the organisational capability and finance team talent to operate at Level 3 exists in most large Saudi enterprises, but the technology environment does not support it.
Q: How much does finance function transformation cost for a GCC enterprise? A finance function transformation programme from Level 1 or Level 2 to Level 3 — covering ERP foundation, Oracle FCCS consolidation, Oracle ARCS reconciliation, Oracle EPM Planning, executive BI dashboard deployment, and AP and P2P automation — typically costs between USD 300,000 and USD 800,000 in professional services over 18 to 30 months for a mid-size GCC multi-entity group. Oracle platform licensing (EPM Cloud, FCCS, ARCS, Analytics Cloud) is additional, typically USD 100,000 to USD 300,000 annually depending on the modules and user count. The most reliable cost anchor is the finance function assessment — a three to five week engagement that defines the starting point, the gap, and the technology sequence required, producing a costed transformation roadmap before any implementation budget is committed.
Q: Should we do all six technology decisions simultaneously or in sequence? In sequence — always. The most expensive finance function transformation mistakes in the GCC result from parallel implementation of technologies that depend on each other. Implementing Oracle EPM while the ERP chart of accounts is being redesigned produces an EPM dimension structure that must be rebuilt when the chart of accounts changes. Implementing BI while the EPM planning model is being redesigned produces a data model that must be rebuilt when EPM changes. Implementing automation before the ERP internal controls are configured produces workflows that bypass the controls the automation is supposed to enforce. The sequence described in the transformation roadmap section above — ERP foundation, close automation, planning, reporting, automation, AI — is the sequence that produces a stable, connected finance function rather than a collection of individually functional technologies that produce reconciliation gaps between them.
About Loop Wise Solutions
Loop Wise Solutions is an enterprise performance consultancy based in Cairo, serving medium and large enterprises across Egypt, Saudi Arabia, the UAE, Qatar, and the broader Arab world. Our Business and Technical Consultancy practice designs and implements finance function transformation programmes — from the initial maturity assessment through ERP foundation, Oracle EPM and FCCS implementation, BI executive dashboard deployment, AP and P2P automation, and AI activation.
Every finance function transformation engagement we deliver begins with a structured maturity assessment — establishing the current state honestly, identifying the specific technology and process gaps that determine the maturity level, and producing a sequenced transformation roadmap before any implementation scope is committed. We are the firm that tells organisations what order to do things in before recommending what things to do.
If you are a CFO or CIO in the GCC or Egypt who recognises the gap between the finance function you currently have and the finance function your institutional relationships, Vision 2030 counterparties, or capital market ambitions require — we are happy to have a direct conversation about where you are and what the path to where you need to be actually looks like.
Contact: contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
