A finance team in KAFD whose close gets disrupted by an untested quarterly Oracle update has a support gap, not bad timing.

Once Fusion or EPM Cloud is live, the implementation partner typically leaves and the client is left owning a platform they have operated for a matter of weeks. Support fills that gap: not a helpdesk that logs tickets with Oracle, but a team that understands your specific configuration, your integrations and your close calendar.

Managing quarterly updates

Oracle applies updates to a test environment first, on a fixed schedule. The work is testing your critical processes against that environment, payroll calculations, ZATCA invoice generation, bank file formats, custom reports and integrations, and identifying regressions before the production update lands. Groups that skip this discover problems during a live payroll run or a VAT filing deadline, which is a considerably worse time to find them.

Day-to-day operational support

Beyond updates, support covers what a finance team actually needs: adding a legal entity or cost center, adjusting an approval hierarchy after a reorganization, building a new report, investigating why a transaction did not post, and resolving integration failures with banks or ZATCA. Much of this is configuration rather than defect, which is why a support relationship with implementation-level knowledge is more useful than escalating everything to Oracle.

Saudi-specific monitoring

Kingdom compliance changes do not follow Oracle's release cycle. When ZATCA revises e-invoicing requirements, GOSI adjusts contribution rates, or a bank changes its payment file format, your system needs updating regardless of where you are in the update calendar. We track these changes and apply them proactively rather than waiting for a failed filing to surface the gap.

A common Saudi scenario

An Riyadh group goes live on Fusion Financials in March. In the July quarterly update Oracle changes behavior in tax reporting. The support team catches it in the test environment two weeks before production, adjusts the configuration, and the group's VAT return files normally. Without that testing window the issue would have surfaced during the filing deadline itself.

Support models

We structure support to match how much internal capability you have. Some clients need a full managed service covering all administration and change. Others have a capable internal team and need specialist backup for updates, integrations and complex configuration. The model is agreed on actual need rather than a standard package, and it is reviewed as your team's capability grows.

Knowledge transfer as a support objective

The best outcome of a support relationship is needing less of it. We document configuration decisions, build runbooks for recurring tasks and train your team on the changes they can safely make themselves, so that adding a cost center or adjusting an approval rule does not require a support ticket. This connects to process design, since many support requests are really symptoms of a process that was never properly defined, and to reporting where users repeatedly ask for variations of a report that should have been built once, properly, and made self-service.

Local context

Groups with entities across multiple Saudi cities often need support coverage aligned to different payroll and close calendars per entity, which is worth defining explicitly in the support arrangement rather than assuming a single group-wide schedule.