The CFOs running large enterprises across the Gulf and Egypt in 2026 are managing finance functions that were not built for the environment they are now operating in. The reporting relationships created by Vision 2030 programme participation, the multi-entity complexity of growing regional conglomerates, the speed at which boards and sovereign fund principals now expect performance data, and the regulatory requirements introduced by ZATCA, UAE corporate tax, IFRS 18, and Egypt’s ETA mandate have all fundamentally changed what the finance function needs to do — and how quickly it needs to do it.
Most finance functions in the region are not keeping pace. Not because the people are inadequate, but because the operating model — the processes, the organisational design, the planning rhythms, the decision-making architecture — was built for a simpler environment and has not been redesigned to match the current one.
Technology is the most common response to this gap. A new ERP, an Oracle EPM implementation, a BI platform, an automation programme. Sometimes the technology investment delivers. More often it delivers less than expected, because the business case was built on assumptions rather than evidence, the requirements were defined by the technology rather than the business, the processes being automated were not understood well enough to be automated correctly, and the finance team that was supposed to adopt the new system was not ready to absorb it alongside their operational responsibilities.
The missing step — consistently, across the Gulf and Egypt — is business advisory: the structured, honest assessment of what the finance function actually needs before any technology is selected or built. This guide is about that step — what it involves, why it matters more than the technology investment it precedes, how to find an advisor who can deliver it with genuine regional fluency, and what the outcome looks like when it is done well.
What Business Advisory for Finance Functions Actually Covers
Business advisory in the context of enterprise finance is not financial consulting — it is not about the numbers. It is about the operating model of the finance function itself: how it is organised, how it plans, how it closes, how it reports, how it partners with the business, and whether those processes, rhythms, and capabilities are matched to what the organisation actually needs from its finance function in its current and planned operating environment.
The specific services that constitute business advisory for finance functions are:
Finance Operating Model Assessment: A structured evaluation of how the finance function currently operates — its organisational design, process map, technology landscape, capability profile, and the gap between its current state and the demands being placed on it. The output is an honest picture of where the finance function is, not where it should be.
Finance Transformation Strategy: A defined plan for how the finance function will move from its current state to the target operating model — specifying what changes in process, technology, and capability are required, in what sequence, with what investment, and what the measurable outcomes of each stage are. This is the document that makes a technology investment decision coherent rather than reactive.
Business Requirements Definition: The translation of finance function requirements into a specification that can be used to evaluate, select, and implement technology — written from the business perspective, not the technical one. What the finance team needs to do, at what level of detail, at what frequency, in what language, for which audience, and with what controls. This is the input that makes an Oracle EPM or ERP implementation configure to the actual business rather than to a generic template.
Business Case Development: The financial and operational justification for a technology investment — built from the organisation’s own data, not from vendor benchmarks. What the current state costs, what the improved state delivers, what the investment requires, and what the return timeline is. Built at the level of specificity that a CFO or board would apply to any capital investment decision.
Organisational Change and Readiness Advisory: An honest assessment of whether the finance team and the organisation around it are ready to absorb the change that a technology investment or transformation programme requires — and a plan for addressing the gaps that are identified. This is the advisory that most technology programmes skip, and whose absence is the most consistent explanation for adoption failures after go-live.
Finance Business Partnering Design: The design of how the finance function delivers analysis, insight, and decision support to operational business units — the processes, forums, reporting rhythms, and capability development that transform the finance function from a reporting service into a genuine business partner.
Why This Advisory Is Consistently Skipped — and What It Costs
The pressure in most technology investment cycles is to move quickly toward a vendor selection and an implementation contract. The business advisory work — the operating model assessment, the requirements definition, the business case — is treated as a preliminary that can be done quickly or compressed into the early stages of the implementation.
The result is predictable. Requirements that were not defined independently get defined during vendor demonstrations, and the vendor’s system becomes the reference point for what is possible rather than the business’s actual needs. Business cases that were built from vendor benchmarks rather than the organisation’s own data do not survive contact with the board’s scrutiny. Transformation programmes that did not assess organisational readiness encounter it as an obstacle during implementation — at the point when addressing it is most expensive.
The cost of skipping business advisory is not the cost of the advisory engagement. It is the cost of the implementation that does not deliver what it was supposed to, the system that the finance team works around rather than through, and the transformation programme that required a second project to complete what the first one promised.
That cost, measured honestly across the organisations in the GCC and Egypt that have experienced it, is consistently larger than the advisory investment that would have prevented it.
The Regional Context That Makes Business Advisory Structurally Different in the GCC and Egypt
Vision 2030 and the Finance Function’s Expanded Mandate
For Saudi enterprises participating in Vision 2030 programmes, the finance function’s mandate has expanded materially in a short time. Reporting to government programme offices, sovereign fund principals, and international investors simultaneously requires a finance function that can produce multiple reporting formats, at different frequencies, with different levels of granularity — and that can do so reliably and quickly, not as a one-off effort but as a repeatable operational process.
Business advisory for Vision 2030 participants needs to account for this expanded mandate explicitly. A finance transformation strategy that is designed around the current reporting requirements will be partially obsolete by the time the transformation is complete. A strategy designed around where the reporting requirements are going — and what the finance function needs to be capable of to meet them — produces an operating model that the organisation can grow into rather than one it immediately strains against.
The Family Conglomerate Finance Challenge
A significant proportion of the large enterprises across the GCC that are investing in finance function transformation are family-owned conglomerates — groups with multiple business lines, complex ownership structures, concurrent GAAP reporting obligations, and governance arrangements that reflect decades of business development and succession planning.
The finance function of a GCC family conglomerate is structurally different from the finance function that most Western consulting frameworks were designed for. The consolidation complexity, the intercompany transaction volume, the management reporting requirements of the family office, and the regulatory reporting obligations across multiple jurisdictions all require business advisory that understands this structure from the inside — not a framework adapted from a listed company reference case.
Business advisory for family conglomerates in the GCC needs to address the group finance architecture explicitly: where does the planning happen and at what level of the group, how does the consolidation process work across entities with different GAAP bases, how is management reporting structured for the family principals versus the operational leadership, and what does the technology investment need to support across all of these simultaneously.
Arabic-Language Finance Operations
The business requirements of a GCC or Egyptian finance function are not translatable into English-language system requirements without losing something. The planning process that a Saudi finance team runs in Arabic, the close process that an Egyptian finance team manages in an Arabic-language ERP, the management reporting that a GCC family office receives in Arabic — these are the actual business requirements that the technology needs to support.
Business advisory that defines requirements in English for an organisation whose finance function operates in Arabic produces an incomplete requirements document. The Arabic-language dimensions of every process — which steps, which documents, which communications, which reports, which system interactions are in Arabic — need to be captured in the requirements definition, because they determine what the technology must do to actually support the process it is being configured to replace.
IFRS 18 and the Reporting Redesign Requirement
IFRS 18 — effective for annual periods beginning on or after January 1, 2027 — introduces mandatory changes to income statement presentation, management performance measure disclosure, and comparative period reporting that require finance functions to redesign their close-to-reporting process before the first IFRS 18 reporting period arrives.
This is a business advisory requirement before it is a technology requirement. The income statement restructuring, the MPM disclosure framework, and the comparative period presentation all need to be designed at the business level — which accounts move into which mandatory IFRS 18 categories, which management metrics will be subject to formal MPM disclosure requirements, how the finance team will produce the IFRS 18 comparative presentation — before the EPM or reporting system is configured to produce them.
Organisations that approach IFRS 18 as a technology configuration task rather than a business process redesign task will configure their EPM systems to produce the new presentation format without ensuring the underlying process changes are in place to sustain it. The result is a compliant first filing and a structurally misaligned process that requires manual intervention at every subsequent close.
Types of Business Advisory Firms: An Honest Assessment
| Advisory Type | Strength | Typical Weakness | Best Fit For |
|---|---|---|---|
| Big Four Consulting Firms | Finance function transformation methodology depth, large team capacity, brand credibility for board presentations, access to global benchmarks | Finance advisory teams are often separate from technology delivery; transformation strategies frequently require separate implementation partners; senior-to-junior ratio on delivery is unfavourable; GCC and Arabic-language finance fluency varies significantly by team | Large, politically complex organisations where board-level credibility and organisational change management depth are the primary requirements |
| Global Management Consulting Firms (McKinsey, BCG, Bain) | Strong strategic frameworks, CEO and board relationships, rigorous analytical methodology | Finance technology implementation depth is very limited; recommendations are frequently abstract because the advisors have not delivered the systems they are recommending; GCC regional specificity is inconsistent | Organisations that need a strategic framework for finance transformation and will handle the operational and technology advisory separately |
| Finance Function Specialists (CFO-focused boutiques) | Deep finance operating model expertise, FP&A and business partnering design depth, finance team credibility | Technology implementation capability is often limited; recommendations may not account for what is actually achievable in the available technology and within the implementation budget | Organisations where the operating model redesign is the primary work and the technology implementation will be handled by a separate firm |
| Generalist Regional Consulting Firms | Local market relationships, cultural fluency, Arabic-language advisory capability | Finance-specific depth and structured methodology are inconsistent; GCC finance regulatory knowledge varies significantly by firm and team | Organisations prioritising local relationships and cultural fit over methodological rigour |
| Specialist Performance Consultancies (like Loop Wise) | Finance advisory grounded in implementation delivery experience; business requirements defined by people who have also built the systems; genuine GCC and Arabic-language finance fluency; senior-led throughout | Smaller team capacity limits scale on very large multi-workstream transformation programmes | Organisations where the business advisory and the technology implementation need to be connected — where the requirements definition must produce something that can actually be built |
The Critical Distinction: Advisory Grounded in Delivery Experience
The most consistent weakness in business advisory for finance technology is the separation between the people who design the strategy and the people who implement it. A finance transformation strategy designed by a team that has never implemented an Oracle EPM system or managed a financial close in an Arabic-language ERP environment will contain requirements that are either unachievable in the available technology, scoped incorrectly for the implementation budget, or specified at a level of abstraction that the implementation team cannot configure against.
Business advisory that is grounded in delivery experience — produced by practitioners who have built the systems they are designing requirements for — produces strategies that are feasible, requirements documents that implementation teams can work from, and business cases that reflect what the implementation will actually cost and deliver. This is the standard we hold our own advisory work to, and it is the standard worth applying when evaluating any business advisory engagement.
Business Advisory: Scope, Timeline, and Cost Reality
| Advisory Scope | Realistic Timeline | Professional Services (USD) | Key Variables |
|---|---|---|---|
| Finance operating model assessment | 4–6 weeks | 20,000–60,000 | Finance function size, number of entities in scope, documentation quality |
| Finance transformation strategy (single function) | 5–8 weeks | 28,000–75,000 | Scope of transformation, number of scenarios modelled, regulatory complexity |
| Finance transformation strategy (group / multi-entity) | 8–14 weeks | 60,000–150,000 | Number of entities, GAAP complexity, GCC multi-jurisdiction scope |
| Business requirements definition (single system) | 4–7 weeks | 22,000–65,000 | Scope of system, process complexity, Arabic-language requirements capture |
| Business requirements definition (ERP + EPM + BI combined) | 8–14 weeks | 60,000–140,000 | Combined scope, number of finance processes, stakeholder breadth |
| Business case development | 3–5 weeks | 15,000–40,000 | Investment complexity, availability of current-state operational data |
| Organisational readiness and change advisory | Runs alongside implementation · 4–12 weeks | 20,000–60,000 | Finance team size, change complexity, training programme scope |
| IFRS 18 process redesign advisory | 4–8 weeks | 20,000–55,000 | Current reporting model complexity, MPM disclosure scope, number of entities |
| Finance business partnering design | 4–7 weeks | 18,000–50,000 | Number of business units, existing partnering maturity, process design scope |
| Full pre-implementation business advisory (assessment + strategy + requirements + business case) | 14–22 weeks | 90,000–220,000 | Combined scope, organisation size, regulatory complexity |
Notes:
- Fees are for advisory only — separate from any subsequent implementation work.
- Arabic-language requirements capture and GCC regulatory mapping (IFRS 18, ZATCA, UAE CT) are included in scope for GCC and Egyptian clients — not deferred.
- The return on business advisory is realised in implementation quality, timeline reduction, and scope accuracy — not in the advisory engagement itself.
- Timeline starts from scope agreement and stakeholder availability, not contract signature.
The Five Most Consequential Business Advisory Failures in the GCC and Egypt
1. The Strategy Was Built Around the Technology, Not the Business
The transformation strategy was produced after the technology was selected — or concurrently with the vendor evaluation, shaped by what the selected vendor’s system can do. The result is a strategy that describes how the business will adapt to the technology rather than how the technology will be built to serve the business. The implementation delivers what the vendor’s system does. The finance function redesigns its processes to match. The gap between the target operating model and what the finance team actually needed is absorbed as a permanent compromise.
2. The Business Case Was Built From Vendor Benchmarks
The investment justification was built from industry-average ROI figures provided in vendor materials: “organisations implementing Oracle EPM reduce their close cycle by 30–40 percent.” The board approved the investment on that basis. The actual close cycle reduction was 12 percent, because the specific conditions that produce 30–40 percent improvement — clean data, well-documented processes, a finance team with capacity to participate in the implementation — were not present and were not assessed before the business case was submitted. The investment is technically delivered. The business case is not.
3. Requirements Were Defined at the Wrong Level of Abstraction
The requirements document described what the finance function needs at the level of outcomes: “the system should support driver-based forecasting” or “the consolidation process should close in five days.” These are goals, not requirements. The implementation team had no documented understanding of how the business actually plans, what drivers are relevant to the business model, what the current close process actually involves step-by-step, or where the five-day target was going to come from. The system was configured against the implementation team’s interpretation of the requirements. The finance team arrived at UAT and found a system that did not match how their work actually operates.
4. Arabic-Language and Regional Requirements Were Captured as an Afterthought
The requirements definition was conducted primarily in English, by a team without Arabic-language finance operations experience, in a series of workshops where English was the working language and the Arabic-language dimensions of the finance process were not systematically captured. The system was built. The Arabic-speaking finance team encountered an environment configured for English-language operation. Adoption was partial. The gap was addressed through a post-go-live change programme that cost more than including Arabic-language requirements in the original scope would have.
5. Organisational Readiness Was Assumed Rather Than Assessed
The finance team was assumed to have capacity to participate in the implementation alongside their operational responsibilities. The assumption was wrong — the team was fully occupied with the current close cycle, the planning process, and the regulatory submissions that arrived concurrently with the project. UAT was compressed because the finance team could not commit the required time. Training was delivered to people who were not available to attend fully. Go-live happened on schedule. Adoption did not.
What to Look For in a Business Advisory Partner: The Questions That Matter
On understanding of regional finance operations: “Describe the finance planning and close process at a GCC family conglomerate or a Vision 2030 programme participant — specifically the intercompany complexity, the dual-GAAP reporting requirements, and how those shape a finance transformation strategy.” A partner with genuine regional finance operations experience will give a specific, detailed answer. A partner whose experience is primarily Western or generic will give a framework answer that is correct in principle and incomplete in practice.
On IFRS 18 and regional regulatory advisory: “How is your team advising finance functions on IFRS 18 implementation — specifically the income statement restructuring, the MPM disclosure framework, and the comparative period presentation? How does that connect to the process redesign required before the EPM configuration?” The answer should be specific and process-oriented, not a reference to accounting standards.
On Arabic-language requirements definition: “How do you capture Arabic-language requirements in a finance function operating model assessment? Specifically — how do you document the Arabic-language dimensions of close processes, management reporting, and planning cycles in a way that produces actionable requirements for an implementation team?” An advisory firm that has not done this before will describe an approach that sounds reasonable but has not been tested against the reality of an Arabic-language GCC finance environment.
On connection between business advisory and technology delivery: “What happens between the requirements definition you produce and the implementation? Specifically — is the requirements document you produce something an Oracle EPM implementation team can configure against directly, or does it need to be translated into technical specifications by a separate team?” The answer reveals whether the advisory is grounded in delivery experience or produced at a level of abstraction that creates a handover gap.
On business case methodology: “Walk us through how you build a finance technology business case — specifically, how you determine the current-state cost baseline, how you model the improvement case without relying on vendor benchmarks, and how you account for the organisational readiness factors that determine whether the improvement case is achievable.” A specific, methodology-grounded answer distinguishes genuine business case expertise from business case template completion.
On transformation sequencing: “If we are starting a finance transformation programme that includes EPM, BI, and automation investment, what is the sequence you recommend, and why? What are the dependencies between each stage that make the sequence matter?” The answer should be specific to the GCC context and should address the data foundation and process design prerequisites that determine whether technology investment delivers its intended return.
Summary: A Decision Framework for CFOs
Commission the business advisory before the technology RFP. The requirements definition and business case that precede a technology investment should be complete before vendor demonstrations begin. Requirements defined after a vendor demonstration reflect the vendor’s system. Requirements defined independently, from the finance function’s actual operating model, reflect the business. The system that gets implemented is configured against whichever version of requirements it receives.
Require that regional fluency is demonstrated, not claimed. Ask specifically how the advisory firm has handled Arabic-language requirements capture, IFRS 18 process redesign, Vision 2030 reporting complexity, or GCC family conglomerate consolidation structure in previous engagements. Specific answers to specific questions reveal genuine experience. Framework answers do not.
Connect the business advisory to the technology delivery. Business requirements that are produced at a level of abstraction that a technology team cannot configure against do not produce the implementation quality they were intended to. The business advisory that produces the highest return is produced by people who understand both what the business needs and what the technology can do — so that the gap between strategy and implementation is minimised from the start.
Assess organisational readiness honestly before the programme begins. The finance team capacity, the data quality in source systems, the process documentation maturity, and the leadership commitment to the programme are all assessable before the implementation begins. Programmes that assess these factors honestly and address the gaps before the project starts consistently deliver better outcomes than those that assume readiness and discover the gaps mid-project.
Sequence the transformation deliberately. The business advisory investment should produce a sequenced transformation plan — data and process foundation before EPM, EPM before BI, automation after the first two layers are stable — not a shopping list of technology investments ordered by the most visible pain point. The sequence determines whether each investment builds on a solid foundation or encounters the same structural problems in a more expensive context.
Frequently Asked Questions
Q: What is the difference between business advisory and management consulting for finance? Business advisory for finance technology is specifically focused on the operating model, processes, and requirements of the finance function as they relate to technology investment — what the finance function needs to do, how it currently does it, where the gaps are, and what a technology investment needs to deliver to close those gaps. General management consulting for finance covers a broader strategic scope — organisational design, operating model at the corporate level, finance function benchmarking — but typically without the technology implementation depth that makes business requirements actionable. The most useful business advisory for a GCC CFO evaluating an Oracle EPM or ERP investment is produced by people who understand both the finance function’s strategic needs and what the technology can be configured to deliver.
Q: How long does a finance operating model assessment take for a GCC enterprise? A focused finance operating model assessment — covering the core processes of planning, consolidation, close, and reporting for a single-country enterprise — takes four to six weeks from kick-off to final output. A broader assessment covering a multi-entity GCC group with multiple GAAP bases and regulatory jurisdictions takes eight to twelve weeks. The most significant variable is access to the finance team: assessments that include structured workshops with the CFO, planning managers, and close team move faster and produce more useful outputs than those conducted through document review alone.
Q: How do we build a business case for an Oracle EPM or ERP investment that will convince our board? A business case that convinces a board is built from the organisation’s own operational data, not from vendor benchmarks. It quantifies the current-state cost in terms the board can verify — close cycle days multiplied by finance team cost, planning cycle duration, error rate and reconciliation time — and models the improvement case from specific, contractually committable changes in those metrics rather than from industry-average ROI figures. It includes a realistic total cost of ownership, not just implementation fees, and it accounts explicitly for the readiness investments — process design, data quality remediation, training — that determine whether the improvement case is achievable. The business advisory engagement that builds this case also stress-tests the assumptions, because a business case that does not survive internal scrutiny will not survive a board.
Q: What does IFRS 18 mean for our finance function’s processes — not just our accounting? IFRS 18 requires the finance function to redesign how it produces the income statement — restructuring presentation into five mandatory categories, designing a formal disclosure process for management performance measures, and producing comparative period reporting in the new format. Each of these is a process change before it is a system change: the finance team needs to agree which accounts fall into which mandatory categories, design the MPM disclosure workflow, and determine how the comparative period will be restated — before any EPM configuration work begins. Finance functions that approach IFRS 18 as a system configuration task without the preceding business process redesign will produce a technically compliant first filing and discover the process gaps at the second close.
Q: How do we know if our finance function is ready for a major transformation programme? Readiness has four components, each measurable before the programme begins. Data quality: can the data in your source ERP produce clean, consistently mapped actuals that an EPM or BI system can depend on without manual correction? Process maturity: are your planning, close, and reporting processes documented at the level of detail a system can be configured against, including the exception handling and informal logic that institutional knowledge currently holds? Team capacity: does the finance team have genuine time — beyond their operational responsibilities — to participate in design, testing, and training at the depth a quality implementation requires? Leadership commitment: is the CFO or CIO sponsoring the programme actively engaged throughout, not nominally assigned? A gap in any one of these factors will produce implementation problems. An advisory engagement that assesses them honestly before the programme begins either confirms readiness or produces a gap-closure plan — which is more valuable than discovering the gaps after the project has started.
Q: Should our business advisory and technology implementation be handled by the same firm? There are genuine arguments for both approaches. A single firm handling both advisory and implementation produces continuity — the business requirements are not handed over to a separate team that may interpret them differently, and the advisory team’s understanding of the business carries through into the configuration decisions. The risk is that the advisory recommendations are shaped by the implementation team’s comfort zone rather than by the business’s actual requirements. A separate advisory firm and implementation partner produces genuine independence in the advisory phase — the recommendations are not influenced by implementation revenue — but requires a structured handover between the two teams that can create gaps if the advisory output is not specified at the right level of detail. The right answer depends on whether you can find a single firm with genuine depth in both, or whether independence in the advisory phase matters more than continuity into the implementation.
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 advisory work covers finance operating model assessment, transformation strategy, business requirements definition, business case development, and organisational readiness — grounded in the implementation experience that makes our advice actionable rather than abstract.
We work with CFOs and senior finance leaders who are making significant technology investment decisions and want the business advisory to be produced by people who understand both what the finance function needs and what the technology can deliver. Every engagement is led by senior practitioners throughout.
If you are planning a finance transformation programme, evaluating a major technology investment, or working through why a previous investment has not delivered what was expected, we are happy to have a direct conversation.
Contact: Contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
