Oracle Just Put Teams of AI Agents Inside Finance and Operations: Can Businesses Automate Work Without Losing Control?

Oracle’s new agentic applications can automate parts of finance and operations without removing control, but only when authority is designed into the workflow.

For Sydney and NSW businesses, the practical issue is not whether an agent can match invoices, monitor ledgers or progress supplier actions. It is whether payment limits, segregation of duties, source evidence, exception ownership and audit records remain enforceable when several agents act across the same process.

Enterprise software is beginning to move beyond answering questions and drafting recommendations. It is being redesigned to carry work through connected systems.

Oracle has introduced Fusion Agentic Applications for finance and supply chain operations, describing coordinated teams of specialised agents that can reason over business objectives, access enterprise data and progress work through existing workflows, policies, permissions and approval hierarchies.

Oracle says 12 agentic applications were made available across its enterprise resource planning and supply chain platforms, including collections, cost accounting, sourcing, logistics, warehouse operations and maintenance.

Oracle has also detailed four finance agents in Fusion Cloud ERP Release 26B:

Ledger Agent. Expenses Agent. Payables Agent. Payments Agent. Their intended functions include monitoring financial activity, validating expenses, processing supplier invoices and evaluating payment timing.

These are not merely conversational assistants sitting beside a finance system. They represent an attempt to place AI inside the sequence by which transactions are examined, progressed, approved and executed.

That is commercially significant. It also creates a more demanding control question: when several agents contribute to one outcome, who can explain why the transaction moved?

The Software Is No Longer Waiting for One User Traditional enterprise systems usually wait for a person to enter data, run a report, approve an exception or release a payment. Even when automation is present, the workflow is commonly based on a visible sequence of predetermined rules.

A coordinated agent system can operate differently. One agent may extract information from an invoice. Another may compare it with a purchase order. A third may examine supplier history, cash conditions or policy limits. Another may recommend when the payment should be made.

The system may therefore progress a business outcome without any one employee manually moving through every screen.

Traditional software

Primary function: Records and processes human instructions. Typical control question: Did the authorised employee complete the required steps? Workflow automation

Primary function: Executes predefined rules and system triggers. Typical control question: Did the automation follow its configured conditions? AI assistant

Primary function: Explains, drafts or recommends. Typical control question: Did a person verify the output before acting? Coordinated agent team

Primary function: Interprets, coordinates and progresses an outcome. Typical control question: Was every material decision authorised, evidenced and reversible? The distinction matters because businesses cannot rely on the number of agent roles as evidence of segregation.

Four agents using the same credentials, source data and execution rights may still represent one uncontrolled authority path.

Real segregation of duties must be enforced by the underlying systems, not simulated through different agent names.

The Control Problem Moves From the Screen to the Sequence Many organisations still evaluate AI at the output level. They inspect whether a response is accurate, whether a summary looks reasonable or whether an invoice was categorised correctly.

Coordinated agents require a broader review. Management must examine the complete decision sequence, including:

Which source records were used. Which policy version was applied. Which agent proposed the action. Which system authorised it. Whether another agent challenged or validated it. What evidence was retained. What threshold triggered human review. Whether the action can be stopped or reversed. This is where businesses can lose control without observing an obvious system failure.

The transaction may be technically completed, the ledger may balance and the supplier may be paid, while the organisation remains unable to reconstruct why a disputed variation was accepted.

The most important risk is often not a spectacular act of rogue intelligence. It is silent process drift: policies interpreted differently over time, exceptions gradually normalised, supporting evidence bypassed and approval thresholds treated as suggestions.

Why This Matters in Sydney Property and Project Operations Finance and operations are closely connected in property, construction, renovation and infrastructure delivery.

A supplier invoice is rarely just an accounting document. It may depend on site access, quantities delivered, measured work, project variations, damage records, subcontractor completion, compliance documents and the status of the next trade.

Consider a Sydney flooring or refurbishment project where the original scope allows for concrete grinding and eight bags of levelling compound. Once the floor covering is removed, the site team discovers deeper substrate variation and requires another 20 bags.

An agentic workflow might:

Receive the supplier invoice. Identify that the quantity exceeds the purchase order. Search the project record for a variation. Compare the variation with site notes and delivery evidence. Update the project cost forecast. Recommend approval based on a financial threshold. Schedule payment according to cash and supplier terms. Each individual step may appear reasonable.

The control failure occurs when the workflow treats a delivery record as proof that the additional work was authorised, or treats an internal site note as an approved contractual variation.

The agent does not need to invent information for the business to lose control. It only needs to assign the wrong authority to information that already exists.

This expands on Elyment’s earlier analysis of why AI agents need accurate business context .

Context tells the system what happened. Control determines whether that information is sufficient to authorise what happens next.

A Finance Transaction Is Not One Decision Businesses often describe an automated process as a single task, such as “process the invoice” or “pay the supplier”.

Operationally, that task contains several different decisions with different risk levels.

Is the document a genuine supplier invoice?

Possible evidence: Supplier master data, invoice format, bank details and fraud checks. Appropriate authority: Automated validation within strict controls. Does it match the purchase order?

Possible evidence: Order number, quantity, price and agreed terms. Appropriate authority: Automated matching. Was the work or material received?

Possible evidence: Delivery record, site confirmation and completion evidence. Appropriate authority: Operational verification. Was an additional cost authorised?

Possible evidence: Approved variation and delegated authority. Appropriate authority: Authorised human or separately controlled system. When should the supplier be paid?

Possible evidence: Payment terms, cash position, discounts and dispute status. Appropriate authority: Treasury policy with defined execution limits. Can bank details be changed?

Possible evidence: Independent supplier verification. Appropriate authority: Restricted human-controlled process. A business should not grant one agent team an unrestricted instruction to “handle accounts payable”.

It should define which decisions may be automated, which may only be proposed and which must remain outside the agent environment.

The Seven Control Layers an Agent Team Needs 1. Transaction Boundaries Start with a narrow class of transaction.

A business might permit automated processing of recurring invoices from verified suppliers below a defined value, while excluding new suppliers, changed bank details, disputed work and unapproved variations.

2. System-Enforced Separation The agent that prepares or recommends an action should not automatically inherit the authority to execute it.

Proposal, approval and execution should be separated through credentials, application roles and technical permissions.

3. A Source-of-Truth Hierarchy The system must know which record has authority when documents conflict.

An approved variation may outrank an informal message. A signed contract may outrank an internal estimate. A verified supplier master record should outrank bank details contained in an emailed invoice.

4. Materiality and Confidence Thresholds Monetary thresholds alone are inadequate.

A small payment to a new bank account may create more risk than a larger recurring payment to a verified supplier. Escalation rules should consider transaction value, novelty, confidence, source conflict and operational consequence.

5. An Evidence Package Before Execution Before a material action is completed, the workflow should create a compact evidence package showing:

The source records. The policy applied. The checks performed. The exceptions identified. The approval obtained. The system identity responsible for execution. 6. Named Exception Ownership An exception queue without a responsible owner becomes a digital waiting room.

Every exception category should have a named operational role, response timeframe and escalation path.

7. Reconciliation, Suspension and Rollback Businesses need a practical way to compare expected and completed actions, suspend an agent immediately and correct downstream records.

A technically successful action is not operationally controlled when it cannot be reversed.

Who Owns the Exception? Agentic systems are frequently described as allowing people to focus on exceptions.

That model only works when exceptions are designed as part of the operating structure rather than left for employees to discover.

Invoice exceeds the approved order

Primary owner: Project or procurement manager. Required response: Confirm the variation and budget authority. Supplier bank details have changed

Primary owner: Finance control owner. Required response: Verify through an independent contact method. Delivery evidence conflicts with site records

Primary owner: Operations manager. Required response: Resolve the physical record before payment. Payment creates a cash-threshold breach

Primary owner: Finance or treasury lead. Required response: Approve timing or amend the payment run. Agent cannot identify the current policy

Primary owner: Process owner. Required response: Stop execution until policy authority is resolved. Repeated low-confidence decisions

Primary owner: System owner and risk lead. Required response: Reduce autonomy and review the workflow design. Exception ownership also changes workforce planning.

Automating data entry does not remove the need for operational knowledge. It concentrates that knowledge in fewer, more consequential decision points.

Reuters reported that Oracle expects repetitive execution work to be increasingly automated, while human employees focus more heavily on supplier negotiation and risk tolerance.

The implication is not that people disappear from the process. Their work moves closer to the points where commercial judgement changes the outcome.

Australian Governance Does Not Disappear Inside the Software An enterprise platform can enforce permissions, but it cannot transfer management accountability away from the organisation using it.

ASIC’s guidance on directors and financial reporting emphasises the importance of complete and accurate records, appropriate accounting policies, controls and processes.

An AI-generated transaction pathway still forms part of the system through which financial records are produced.

Businesses also need to preserve records that explain relevant transactions.

The Australian Taxation Office’s business record-keeping guidance remains relevant whether the record was produced manually, through conventional software or by an agentic workflow.

Where personal information is involved, organisations should assess the workflow against the Office of the Australian Information Commissioner’s Australian Privacy Principles guidelines .

This includes understanding:

Which information agents can access. Why the information is being used. How it is protected. Whether information is being disclosed to connected services. Access control, application hardening, patching, authentication and recovery also remain necessary around the agent environment.

The Australian Signals Directorate’s Essential Eight provides a recognised baseline for considering broader cyber security controls.

The practical principle is straightforward: an agent must not be able to reach a record or execute an action merely because the underlying employee account once had access to it.

A Safer Deployment Sequence Businesses do not need to choose between full autonomy and no automation.

A staged deployment can increase execution capacity while preserving control evidence.

Observe. Allow agents to monitor transactions and identify exceptions without changing records. Recommend. Permit the system to propose classifications, actions and payment timing, with all execution completed by authorised employees. Prepare. Allow agents to create draft transactions or payment batches that remain pending approval. Execute within limits. Automate low-risk, repeatable transactions that meet verified conditions. Expand by evidence. Increase authority only after exception rates, audit quality, reversals and financial outcomes have been measured. This sequencing complements Elyment’s guidance on preparing AI agents before production deployment .

Production readiness should include transaction authority, not only technical reliability.

What Management Should Measure Faster processing is not sufficient evidence that an agentic finance or operations system is working well.

Management should examine a balanced set of operational and control measures:

Percentage of transactions completed without human rework. Exception rate by supplier, transaction type and workflow stage. False approval and false rejection rates. Time taken to resolve material exceptions. Number of actions completed with incomplete evidence. Duplicate, disputed or reversed transactions. Policy overrides and the people authorising them. Financial value processed under each autonomy level. Time required to reconstruct a completed decision. Cost per controlled and successful outcome. The last measure is important.

Elyment’s analysis of the cost of one successful automated task examines whether labour, review and exception costs are being captured.

An agentic transaction should add another requirement: success must include control integrity, not merely completion.

Businesses should also monitor whether the workflow is creating hidden operational work.

A faster invoice process that produces more supplier disputes, project cost corrections or management escalations may be moving cost rather than removing it.

This is why cheaper AI does not make a poorly designed automation economical .

Greater autonomy can amplify both the value and the cost of the underlying process design.

The Board and Management Question Is Becoming More Specific The useful question is no longer, “Do we allow AI to make decisions?”

Businesses already rely on software rules, risk models, fraud systems, credit limits and automated reconciliations.

The more precise question is which decisions an agent may make, based on which evidence, within which limits and under whose continuing accountability.

Management should be able to answer:

What can the agent team observe? What can it recommend? What can it prepare? What can it execute? Which actions are prohibited? Who owns unresolved exceptions? How quickly can authority be suspended? Can the business reconstruct every material outcome? When those answers are vague, the organisation has not delegated work. It has introduced uncontrolled ambiguity into a financial or operational process.

Define the authority path before agent teams enter live finance and operations.

Review transaction boundaries, approval evidence, segregation of duties, exception ownership, system access, audit records and rollback requirements before expanding automation across project, finance or operational workflows.

Request an Operational Review

Automation Without Losing Control Is Possible, but It Is Not Automatic Oracle’s move towards coordinated agentic applications reflects a larger change in enterprise technology.

Software is being asked to progress outcomes rather than merely display information and wait for instructions.

That can reduce manual follow-up, fragmented handovers and repetitive transaction work. It can also make authority harder to see when several agents, systems and data sources contribute to the same outcome.

For Sydney and NSW businesses, the safest approach is not to place a human approval button at the end of every workflow.

It is to redesign the workflow so that evidence, decision rights, monetary limits, exception ownership and recovery controls are enforced throughout the sequence.

The businesses that retain control will not necessarily be those with the least automation.

They will be those that can explain what their agents were allowed to do, why each material action occurred and how the organisation would intervene when the conditions changed.

Sources and References Elyment: Why AI agents need accurate business context ASIC: Directors and financial reporting Australian Taxation Office: Record keeping for business Office of the Australian Information Commissioner: Australian Privacy Principles guidelines Australian Signals Directorate: Essential Eight Elyment: Preparing AI agents before production deployment Elyment: The cost of one successful automated task Elyment: Why cheaper AI does not make poor automation economical Elyment: Contact and operational review