Oracle Fusion
Oracle Fusion Cloud carries finance, procurement and supply chain for many of the largest organisations in the Kingdom. Most of the questions it generates are asked by people who will never be given a login to it.
Oracle Fusion Cloud carries finance, procurement and supply chain for many of the largest organisations in the Kingdom. Most of the questions it generates are asked by people who will never be given a login to it.
What Oracle Fusion holds, and why that matters here
Fusion is a suite rather than a single system — financials, procurement, supply chain planning, project management and often human capital, sharing one data model. That breadth is why it sits at the centre of so much internal contact: the answer to almost any operational question lives in it somewhere, and finding it requires knowing which module to look in.
The people asking are usually suppliers chasing payment, employees chasing an approval, or customer service staff chasing a delivery. None of them will get a Fusion licence, and none of them should. What they need is one fact, phrased as a sentence.
- Financials — invoices, payments, supplier balances, approval state.
- Procurement — requisitions, purchase orders, receipts, supplier records.
- Supply chain — inventory positions, shipments, order promising.
- Projects — budget, commitment and spend against a project code.
- Approvals — where a document is sitting and who it is waiting on.
Questions Elbi can answer from Oracle Fusion
Has our invoice been approved?
Approval state and the stage it is at, which is the single most common supplier enquiry and the one that generates the most repeat calls.
When will we be paid?
Payment schedule and status against a supplier account, answered without a finance team member opening the system.
Where is my requisition?
Which approver a requisition is waiting on, so employees stop emailing to ask and start seeing it themselves.
What is left in the project budget?
Budget against commitment and actual spend for a project code, which is the question project managers ask most and get slowest.
Has the PO been received?
Goods receipt status, which determines whether an invoice can even be paid.
Who approves this?
The approval chain for a document type and value band — process knowledge that is usually tribal and frequently wrong.
How Elbi reads Oracle Fusion Cloud
- Through Oracle's published REST APIsFusion Cloud Applications publish REST APIs for each pillar — Financials, Procurement, Supply Chain, Project Management — documented by Oracle alongside the product. The assistant reads through those rather than through screens, which keeps the connection on an interface Oracle maintains through its regular updates.
- An integration user with a custom, view-only roleYour Fusion security administrator creates a user for the assistant and gives it a custom role built from view-only duties — viewing invoices rather than entering them, viewing purchase orders rather than buying. Data access is then limited to the business units, ledgers or projects in scope, with the same tools your administrators already use for staff.
- OAuth or basic authentication, as your policy prefersFusion's REST APIs accept OAuth tokens issued through Oracle's identity service as well as basic authentication over HTTPS. Most security teams prefer OAuth, with the client registered and controlled on your side.
- Suppliers and staff are identified before anything is readA supplier asking about a payment is matched to their supplier record and sees only the invoices and payments on it. An employee asking about a requisition sees their own. Identity comes from your sign-in, not from what someone claims in the chat.
- Approval questions read the workflow rather than guess it"Who is my requisition waiting on" is answered from the approval task assigned in Fusion, naming the approver or their role as your policy allows. The approval rules themselves stay in Fusion; the assistant reports them and approves nothing unless you deliberately enable it.
- Statuses become sentencesPayables statuses such as "Needs revalidation", or an invoice hold, are turned into a plain sentence in Arabic or English about what happens next and who is dealing with it.
Security roles, data access and what stays yours
| Direction of access | View-only duties by default. Anything that creates or changes a transaction — a requisition, a receipt, a supplier update — is enabled per action and can be held for a person to confirm. |
|---|---|
| Who can see what | Data access follows business unit, ledger and project, set for the assistant's user as it would be for anyone else. Within that, suppliers see only their own supplier record and employees only their own documents. |
| Credentials | The integration user and any OAuth client are created on your side. Deactivating the user or revoking the client ends the connection immediately, without involving us. |
| Where data goes | Invoice and payment details fetched from Fusion answer the question at hand and are not kept. Conversation content is destroyed within 24 hours, generally when the conversation ends, and is never passed to an external AI service. |
| Audit | Each lookup can be logged — question, record read, agent, conversation — so a later dispute about what a supplier was told can be settled from the log rather than from memory. |
| If it is unavailable | Fusion is taken down for scheduled maintenance when updates are applied. During those windows, or any outage, the assistant says it cannot reach Oracle and offers a person; it does not guess a payment date. |
What this replaces in a Fusion organisation
The distinctive cost with Fusion is not customer contact — it is internal contact. Large organisations running it typically have a shared services function whose day is substantially made up of answering "where is it" about documents already visible in the system to anyone who knows where to look.
That work is invisible in most business cases because it never becomes a ticket. It arrives as a call, a passing question, a message in a group chat. Connecting an assistant makes it visible by removing it, and the difference is usually most obvious in the last week of a month.
For suppliers the effect is external. Payment enquiries are a large, predictable and entirely unproductive contact category. Answering them automatically, accurately and out of hours removes a cost that most organisations have simply accepted.
How Fusion organisations in different sectors use it
Government and semi-government
Supplier payment and PO status, where volume is high and the reputational cost of slow answers is disproportionate.
Large enterprise finance
Approval state and month-end queries, concentrated into the few days when the finance team has least capacity.
Construction and projects
Budget-versus-commitment questions asked constantly by people on site.
Healthcare groups
Procurement and stock questions against clinical supply chains where delay carries real consequence.
Getting value from Oracle Fusion
Start with payables. Supplier questions about invoice approval and payment are the most predictable contact a Fusion organisation receives, they come from people who will never have a login, and each one has a definite answer in the system.
Requisition and approval status is the natural second step: the askers are internal, so identity is simpler, and the saving lands on the shared-services team in the last week of the month. Project budget questions come after that, once data access by project has been agreed with finance.
Keep analysis where it already lives. Fusion has OTBI and BI Publisher for spend, trend and period questions; the assistant is for the status of one specific document, answered in a sentence.
What connecting Oracle Fusion involves
- Pick the module and the questions togetherPayables and procurement first, in most organisations. The questions decide which REST resources are needed — invoices, payments, purchase orders, receipts — and nothing beyond them is requested.
- Work through your Fusion administrators and partnerThey know the custom roles, descriptive flexfields and approval rules in your environment, and they own the security changes. Most of this step is theirs to approve rather than ours to build.
- Build the role and assign data accessA custom role made of view-only duties, data access for the business units and ledgers in scope, and nothing inherited from a broad predefined role.
- Map flexfields and your own termsDescriptive flexfields, custom lookups and your own names for business units and document types are mapped, so the answer reads as if your finance team had written it.
- Rehearse in a test environmentAn invoice on hold, a partially received purchase order, a supplier with several sites, someone asking about another supplier's payment. The unhappy paths are tried outside production first.
- Launch for one audience at a timeSuppliers or employees, not both at once. Widen once a month of real questions has been answered well.
Personal and financial data in Oracle Fusion
Fusion often holds human capital data alongside finance, and that changes the risk. Even when the assistant is scoped to payables, the same environment may hold employee records, salaries and bank accounts, so the role has to be built to exclude them, not merely left unasked. Under the Saudi Personal Data Protection Law, the processing you can justify is the processing you scoped.
Supplier bank details deserve the same treatment. A supplier checking a payment date never needs their account number read back, and an assistant able to recite it would be an invitation to payment fraud. Keep the role view-only, keep the lookup log, and make sure suppliers and staff know their records are read during a conversation.
What Oracle Fusion organisations typically see
Other ways Fusion organisations handle this
Oracle offers its own routes. The Supplier Portal lets registered suppliers see their purchase orders, invoices and payments; Oracle Digital Assistant provides conversational skills for Fusion users; and Oracle has been adding AI agents inside Fusion itself. For the people who use those tools, they are often the right answer.
The gap is usually everyone else: suppliers who never registered on the portal or rarely log in to it, and staff who need one fact and do not open Fusion from one month to the next. An assistant on your own channels reaches them without another login.
Where projects go wrong in Fusion is copying a predefined role for convenience. It brings far more access than the questions need, and a security review will find it. The other trap is analysis: a quarter's spend by category is a job for OTBI, not a chat.
Plan, too, for the unhappy path — an update window, an invoice number the supplier has mistyped, a supplier with several sites. A clear "I could not find that in Oracle" and a route to a person are worth more than a confident guess.
Common questions about Oracle Fusion
Whichever you scope it to. Most deployments start with payables and procurement because that is where the contact volume is, then widen.
Yes — that is usually the point. A supplier can be identified well enough to answer about their own account without being given access to your ERP.
It reads them rather than replacing them. The assistant reports where a document sits; it does not approve anything unless you deliberately enable that.
No. The assistant uses the integration user and role your administrators created, with the data access you assigned to it. You control its credentials and can deactivate it at any time without going through us.
The published REST APIs are meant to stay stable across updates, so reads are not normally affected. It is still worth re-checking the scoped lookups in your test environment after each update, because flexfields and approval rules are where changes tend to surface.
Only if you enable it, one action at a time, and it can wait for a person to confirm. Read-only is usually the right place to stay for a while, because the value in Fusion is in answering status questions rather than creating transactions.
Connect it to your own systems
A working assistant against your own records, in both languages.