Once Fusion or EPM Cloud is live, the implementation partner typically leaves and your team owns a platform it has only just started to operate. A finance team whose close is disrupted by an untested update has a support gap rather than bad timing.

Support fills that gap with a team that understands your specific configuration, your integrations and your close calendar, instead of a helpdesk that only logs tickets with Oracle.

Managing quarterly updates

Oracle applies updates to a test environment first, on a published schedule. The work is testing your critical processes against that environment: payroll calculations, ZATCA e-invoice generation, bank file formats, custom reports and integrations. Regressions are identified before the production update lands. Organizations that skip this tend to discover problems during a live payroll run or a filing deadline.

Day-to-day operational support

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

Saudi-specific monitoring

Saudi 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 wherever you are in the update calendar. These changes are tracked and applied proactively before a failed filing exposes the gap.

A hypothetical example

Imagine a Riyadh group that has gone live on Fusion Financials. A quarterly update changes how a tax report behaves. If the support team tests the update in the test environment first, the configuration can be adjusted before production, and the issue does not surface on the filing deadline.

Support models

Support is structured around how much internal capability you have. Some organizations 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 your actual need and 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. Configuration decisions are documented, runbooks are built for recurring tasks, and your team is trained on the changes it can safely make itself, so adding a cost center or adjusting an approval rule does not need a ticket. Many support requests are symptoms of a process that was never properly defined, which is where process design comes in. Users who keep asking for variations of the same report need reporting built once, properly, as a self-service report.

Service levels based on business impact

Response time alone is a weak measure. Service levels are set by the impact of the problem on the business. An issue that blocks payroll or a tax filing carries a different priority from a request for a new report, and the agreement should reflect that instead of giving every ticket the same priority.