AI Agents for Oracle
Fusion Payables
Fusion is good at applying a hold. It does not tell you which supplier, requester and order type keep producing two hundred of them.
- Invoice holds are the payables backlog made visible, and Fusion reports them one invoice at a time, which is why they accumulate.
- In a worked population of 240 holds worth 1.9 million, 31 already had a receipt and were going to clear themselves on the next validation run.
- Manual holds with no note age worst. They outlive whoever placed them and nobody feels able to release them. Reporting them aged, with their placer, is a five minute query.
- Fusion separates supplier from supplier site, and terms, tax registration and remittance all live at the site. Resolving to the supplier default silently changes the due date.
- Report held value by hold reason and by supplier. The individual hold is an AP task, the pattern is a procurement or master data task, and only the second removes the work.
AI agents for Oracle Fusion accounts payable read the invoice hold population with the purchase order and receipt beside each one, group it by cause rather than by value, and resolve suppliers to the correct site rather than the default. ChatFin reads through Fusion REST services and prepares work for a named person to approve.
The specific thing worth automating here is the hold queue. Fusion applies holds correctly and reports them per invoice, so a team of three working two hundred and forty holds starts at the top by value and never reaches the tail. Grouped by cause that same population is six decisions with five different owners, and one of those groups was going to clear itself without anybody touching it.
What an agent reads in Oracle Fusion payables
Fusion exposes finance through REST services, with the file based data import framework for volume. Which of the two an agent uses matters, because they answer different questions and only one of them is interactive.
| Path | Good for | Where it is the wrong tool |
|---|---|---|
| REST services | Reading and creating individual records, interactively | Bulk operations across a whole period |
| File based data import | Loading volume through a defined interface | Anything that needs an answer in seconds |
| Subledger accounting entries | Tracing what payables did to the ledger | Not where the operational detail lives |
| Invoice holds | The exception population itself | The hold tells you it stopped, not why it will not clear |
The last row is the one worth dwelling on. Fusion is good at applying a hold and it does not tell you the pattern behind two hundred of them. The hold reason is a code. What a payables lead needs is which supplier, which requester and which purchase order type keeps producing it.
ChatFin reads holds with the invoice, the purchase order and the receipt beside them, so the output is a grouped population rather than a longer list.
Working the hold population by pattern
Invoice holds in Fusion are the payables backlog made visible. They are also reported one invoice at a time, which is why they accumulate.
| Hold pattern | What it usually is | Owner |
|---|---|---|
| Quantity received hold | Goods not booked in yet | Receiving or the requester |
| Price hold inside tolerance | A supplier price drift nobody flagged | Procurement, as a pattern rather than per invoice |
| Price hold outside tolerance | A genuine contract disagreement | Procurement, per case |
| Matching hold on a closed purchase order | The order was closed early | The requester |
| Tax or validation hold | A setup or master data gap | Finance, and it usually repeats |
| Manual hold with no note | Somebody stopped it and left | Whoever placed it, if findable |
The last row is the one that ages worst. A manual hold with no explanation outlives the person who placed it, and nobody feels able to release it. Reporting manual holds with their age and their placer is a five minute query that clears real money.
A worked hold population, 240 invoices
A month end shows 240 invoices on hold worth 1.9 million. Sorted by value that is 240 investigations and the team works the top twenty. Grouped by cause it is six decisions.
| Cause | Invoices | Value | What the evidence shows |
|---|---|---|---|
| Awaiting receipt | 96 | 742,000 | Receipts exist on 31 of them, booked after the cut off |
| Price inside tolerance, auto releasable | 51 | 188,000 | A rule already covers these |
| Price outside tolerance | 28 | 406,000 | Concentrated on four suppliers |
| Purchase order closed early | 24 | 221,000 | Requester closed the order before the final invoice |
| Tax validation | 23 | 94,000 | One supplier, one missing registration |
| Manual hold, no note, over 90 days old | 18 | 249,000 | Nobody currently owns these |
The 31 invoices in the first row already have a receipt and will clear on the next validation run without anyone touching them. Reporting that separately stops the team spending a morning on invoices that were about to resolve themselves.
Supplier resolution, and why Fusion makes this specific
Fusion separates the supplier from the supplier site, and a payables agent that ignores the site will get the terms, the tax treatment and the remittance wrong while appearing to match correctly.
ChatFin resolves to supplier and site together and states which site it used. Where the document does not support a site decision it asks rather than taking the default.
Accruals from open orders, calculated rather than estimated
Received not invoiced is knowable exactly in Fusion, and it is usually estimated because assembling it spans receipts, orders and invoices at once.
Take receipts with no matching invoice at the cut off
Read receipts against invoices on the same purchase order line. What remains is the population, and it is a fact rather than a judgement. ChatFin lists the receipts behind every line so the review is of a population, not a total.
Price from the purchase order
The committed price is on the order. An average rate turns a calculable number into one that has to be defended.
Separate held invoices from missing ones
An invoice on hold is received and recorded. Accruing for it as though it had never arrived double counts, and this is a common error when the hold queue is large.
Report the aged tail separately
Receipts older than a quarter with no invoice are a process failure rather than timing, and calling them an accrual hides that.
ChatFin produces the accrual and the hold analysis from the same read, so the two reconcile by construction rather than by somebody checking afterwards.
Where this underperforms on Oracle Fusion
Three, and all three sit upstream of any tool.
Deeper in Oracle Fusion payables
Three use cases sit under this hub, in build and shown rather than linked.
Worked on this page
Vendor follow up for missing invoices · AP inbox automation · Invoice intake and document extraction
Covered as sections here
Invoice holds · 3 way matching · Supplier and site resolution · Approval routing · Accruals from open orders
Questions Oracle Fusion payables teams ask first
Why do invoice holds accumulate in Oracle Fusion?
Because they are reported one invoice at a time. A hold reason is a code on a document, so a queue of 240 holds looks like 240 investigations and the team works the top twenty by value. Grouped by cause it is usually six patterns with five owners: awaiting receipt, price inside tolerance, price outside tolerance, order closed early, tax validation and manual holds. ChatFin groups and routes rather than lengthening the list.
What is the quickest win on Fusion payables?
The manual hold report. Manual holds with no note, aged, with whoever placed them. They outlive the person who applied them and nobody else feels able to release them, so they sit indefinitely. In a worked population, 18 of those were over 90 days old and carried 249,000. It takes minutes and needs nothing beyond read access.
Why does supplier site matter so much in Fusion payables?
Because payment terms, tax registration and remittance detail all live at the site rather than the supplier, and the same supplier can have different values per site. An agent resolving to the supplier default will appear to match correctly while silently changing the due date or producing a tax validation hold. ChatFin resolves to supplier and site together, states which site it used, and asks when the document does not support the decision.
240 holds become six decisions with five owners.
ChatFin reads the hold population with the purchase order, receipt and supplier site beside each invoice, groups it by cause and routes each group to whoever can resolve it.
It separates the holds that will clear themselves on the next validation run, and it prepares corrections for a named person to approve.
Bring one month of invoice holds. The comparison takes an hour.
Book a demoAll images are served from the Pexels content network. No third party product screenshots, vendor logos or licensed media are used on this page.
Bring one month of invoice holds.
We will run the same population through ChatFin, group it by cause and owner, and show you which holds were about to clear on their own.