AI Agents for the Oracle
Fusion Close
The Fusion close is a dependency chain. Most of the working time is the gap between one step finishing and the next person noticing.
- Every close step except reporting can be prepared before the period ends. The work does not shrink, it moves to a week when nobody is under deadline pressure.
- Unaccounted transactions block a period close and are discovered on day one because nothing looks for them earlier. Every one can be found the day it is created.
- Track how long the average unaccounted transaction existed before anyone looked. Continuously is a control, at close is a fire drill.
- In a worked 62,000 subledger difference, two of four causes were structural and expected and two were permanent fixes that will otherwise recur every month.
- Reconcile intercompany at transaction level. Two errors in opposite directions net to something small that passes a totals review and leaves both sides wrong.
AI agents for the Oracle Fusion month end close assemble the payables, receivables and accounting exception populations before the period ends, find unaccounted transactions continuously rather than at close, and reconcile subledger to ledger by cause rather than reporting a single difference. ChatFin prepares everything as a proposal for a named person to release.
The Fusion close is a dependency chain. Subledgers close, accounting is created, the ledger closes, reporting runs, and each step waits on the last. That means a small delay early becomes a delay everywhere, and most of the elapsed time is not work at all, it is the gap between one step finishing and the next person noticing. Everything except the final reporting step can be prepared in advance.
The Fusion close is a dependency chain, and most delay is waiting
Subledgers close, accounting is created, the ledger closes, then reporting runs. Each step waits on the one before, so a delay early is a delay everywhere. Most of the working time is not the tasks themselves, it is the gap between one finishing and the next person noticing.
| Step | What holds it up | What can be prepared in advance |
|---|---|---|
| Payables period close | Invoices on hold and unaccounted transactions | The hold population grouped by cause, before day one |
| Receivables period close | Unapplied receipts and AutoInvoice rejections | The unapplied population grouped, and the rejection list |
| Create accounting | Events that will not account | The exceptions, read and explained rather than discovered |
| Ledger close | Subledger to ledger differences | The reconciliation, run continuously rather than at close |
| Reporting | Everything above | Nothing. This one genuinely waits |
Every row except the last can be prepared before the period ends. The work does not get smaller, it moves to a week when nobody is under deadline pressure.
ChatFin assembles the payables, receivables and accounting exception populations before the period closes, so day one starts with a work list rather than an extract.
Unaccounted transactions, the close blocker nobody schedules
A subledger transaction that will not create accounting stops a period close and the reason is usually mundane. It is discovered on day one because nothing looks for it earlier.
Run the unaccounted check continuously, not at close
Every one of these can be found the day the transaction is created rather than three weeks later when it blocks a close.
Group by cause, not by transaction
A missing derivation rule producing forty exceptions is one fix. Listed individually it looks like forty problems.
Report new causes separately from known ones
A cause seen for the first time this period is worth a person's attention. A recurring one is a rule that should have been fixed.
A worked subledger to ledger reconciliation
Payables subledger is 62,000 away from the ledger control account. It is 0.4 percent of the balance, it gets signed on judgement, and it is four things that each recur.
| Cause | Amount | Items | Whether it repeats |
|---|---|---|---|
| Transactions accounted in a later period | 31,000 | 74 | Every month, by design |
| A derivation rule sending one supplier type to an unexpected account | 18,000 | 41 | Every month until the rule is fixed |
| Manual journals posted straight to the control account | 9,000 | 6 | Whenever somebody does it. Should be blocked |
| Reversals paired across the period boundary | 5,000 | 12 | Every month, by design |
| Rounding | negative 1,000 | n/a | Report as residual |
Two of the four are structural and expected. Two are fixable and will otherwise reappear indefinitely. Reported as a single 62,000 difference, none of them ever gets addressed because the total is below anybody's materiality threshold.
Accruals prepared from the same read as the holds
Received not invoiced overlaps almost entirely with the awaiting receipt hold population, and the two are usually built separately by different people. They then disagree, and somebody spends a morning working out why.
Build both from one read
Receipts against invoices on the same purchase order line. ChatFin produces the accrual and the hold analysis together so they reconcile by construction rather than by checking.
Exclude invoices already on hold
An invoice on hold has arrived and is recorded. Accruing for it as though it had not double counts, and it is the most common error when the hold queue is large.
Price from the purchase order
The committed price is on the order. An average turns a calculable figure into one that has to be defended in a review.
Report the aged tail as a process failure
Receipts older than a quarter with no invoice are not a timing difference. Calling them an accrual hides the thing worth fixing.
ChatFin prepares the accrual journal with its receipts attached and posts nothing. A named person reviews and releases it.
Intercompany, drawn from both sides at once
In a multi ledger Fusion group intercompany is mechanical, recurring and always late. The reason is that each side is drawn separately and the totals are compared.
ChatFin draws both sides of an intercompany pair at once and reconciles at transaction level, which is the only way an offsetting pair of errors becomes visible.
Where this underperforms on Oracle Fusion
Three, and none is solved by a tool.
Deeper in the Oracle Fusion close
Three use cases sit under this hub, in build and shown rather than linked.
Worked on this page
Close task monitoring · Close exception identification · Flux analysis
Covered as sections here
Unaccounted transactions · Subledger to ledger reconciliation · Intercompany · Accruals · Period close sequencing
Questions Oracle Fusion close teams ask first
What blocks an Oracle Fusion period close most often?
Unaccounted transactions, and the causes are mundane: a missing account derivation rule for a combination nobody anticipated, a code combination somebody end dated while open transactions still point at it, a subledger period not open, or a transaction in an unexpected status. Every one could be found the day the transaction was created. ChatFin runs the check continuously and groups by cause, so a rule producing forty exceptions reads as one fix rather than forty problems.
Why does the subledger to ledger difference never get resolved?
Because it is reported as one number below a materiality threshold. In a worked reconciliation, 62,000 was transactions accounted in a later period, a derivation rule sending one supplier type to an unexpected account, manual journals posted straight to the control account, and reversals paired across the period boundary. Two of those are structural and expected. Two are permanent fixes that recur monthly until somebody sees them separately.
How should intercompany be reconciled in a multi ledger Fusion group?
At transaction level, with both sides drawn at once. Reconciling at totals lets two errors in opposite directions net to a small difference that passes review while leaving both sides wrong. Most differences turn out to be one entry booked in a different period, so naming the document and the period on both sides in a single row ends the exchange in one message instead of an email thread.
Prepared before the period ends, not discovered on day one.
ChatFin assembles the payables, receivables and accounting exception populations before the period closes, runs the unaccounted transaction check continuously, and groups every finding by cause.
Subledger to ledger is reconciled by cause and intercompany at transaction level from both sides. Everything is a proposal a named person releases.
Bring one period's unaccounted transactions. 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 period's close exceptions.
We will group the unaccounted transactions by cause through ChatFin and rebuild your subledger to ledger difference into the causes behind it.