A group with legal entities spread across KAFD and Al Malaz outgrew mid-market systems for a reason, and the implementation needs to match that scale from day one.

Fusion is a large, capable suite, and that breadth is both its strength and its risk. Implemented with discipline it gives a multi-entity group one ledger, one procurement process and one reporting layer. Implemented as a straight lift of global templates it produces a system that technically works but fights Saudi accounting, payroll and e-invoicing at every turn. Our practice covers the full Fusion footprint, with Financials, SCM and HCM as the modules Riyadh clients most often deploy first.

Designing the enterprise structure for Riyadh

The decisions that matter most are made in the first weeks: how legal entities, ledgers and business units map to your actual corporate structure, how the chart of accounts is built so Zakat and VAT reporting fall out of standard ledgers rather than side calculations, and how intercompany is configured so multi-entity consolidation is automatic. These are difficult to change after go-live, which is why we spend disproportionate time on them up front.

ZATCA, payroll and localization

Fusion's Saudi localization handles Arabic reporting, Hijri calendars and VAT, but ZATCA Phase 2 e-invoicing integration, GOSI and WPS payroll connectivity and bank file formats for the major Saudi banks each require deliberate configuration and, in some cases, integration components. We specify these in the design phase and test them against real transactions, not sample data, before cutover.

Implementation approach

Fusion projects are run in phases aligned to business risk. Core financials and procurement typically go first, establishing the ledger and control foundation. Supply chain, projects and HCM follow once the finance backbone is stable. Each phase has its own conference room pilot, user acceptance testing with your transactions, and a cutover plan sequenced around Saudi fiscal, payroll and reporting deadlines.

A common Saudi scenario

A Riyadh-headquartered holding company with subsidiaries in contracting, real estate and trading has been consolidating from three different systems in spreadsheets. Fusion is implemented with one primary ledger per entity, a shared chart of accounts with segment values reflecting each business, and intercompany rules that eliminate manual elimination entries. The group closes its consolidated accounts in six working days instead of twenty.

Ongoing operation

Oracle releases quarterly updates to Fusion Cloud. Managing these, testing that your configuration and integrations still work, and taking advantage of new functionality without disrupting operations is a discipline in itself, which is why implementation is followed by structured Oracle support rather than a hand-off and departure.

Data migration as its own workstream

Moving history into Fusion is not a technical afterthought. Open balances, open purchase orders, customer and supplier masters, fixed asset registers and, for groups migrating mid-year, year-to-date transaction detail all need extraction, cleansing, transformation and reconciliation. We run migration as a separate workstream with its own plan and its own acceptance criteria, because it is the part of a Fusion programme most likely to set the go-live date.

Local context

Contracting and real estate groups in Riyadh tend to adopt Fusion Projects early for cost control.