Oracle Fusion 26D Receivables: What Changes for AR Teams, and What to Test First

Oracle Fusion 26D receivables is the release where Oracle’s agents start doing more of the work themselves: much more of it in cash application, still with a user’s confirmation, and some of it in collections without one. In 26C the Cash Processing Agent could investigate an unapplied receipt and apply it to one invoice after a user said yes. In 26D it can split it, spread it across several invoices, refund the excess and attach a customer to cash nobody could place.

Collections changes more. Collector Workspace picks up Fusion Claw, the execution layer Oracle announced on 29 September, and can now carry out eligible collection actions without waiting for a collector. That is a different control question for a CFO than a smarter worklist. This guide sets out what 26D changes for receivables and collections, what is on by default and what needs setup, and what to test in the two weeks between your test and production updates.

What changes in Oracle Fusion 26D receivables

Oracle’s 26D Financials What’s New was first published on 4 September 2026 and has been revised every week since. These are the changes on the credit-to-cash path:

Advanced Collections in its classic form, Lockbox and AutoMatch get no standalone 26D entries. The movement is all in the agents and the API underneath them.

The Cash Processing Agent in 26D: from investigating cash to applying it

The 26C version gathered receipt-creation exceptions and unapplied or unidentified receipts into one conversational workspace, and it applied a receipt to an invoice only after a user confirmed. The 26D update keeps that confirmation step and widens what can be confirmed:

• Apply the available receipt amount, or a specified amount when only part of the receipt or the invoice balance should move.
• Apply one receipt across several selected transactions in a single flow.
• Assign a customer to an unidentified receipt, which turns it into an unapplied receipt ready for application. Oracle is explicit that assignment does not apply it.
• Refund eligible unapplied amounts through the existing Receivables refund rules.

It also gets better at recognising who paid. When a user confirms the customer behind a bank statement reference, that mapping is kept and used the next time a similar reference arrives, so recurring payers stop landing as unidentified. Remittance advices of up to 2,000 reference lines can be read.

Oracle states the agent remains enabled by default with no extra setup for these enhancements. Access comes through assistant duty roles that the predefined Accounts Receivable Specialist and Manager job roles already include, so on a standard role design your AR team will see the new actions on the day your environment updates. If you run custom job roles, the roles have to be added before anyone sees anything.

For a controller, the practical change is who can move cash and how fast. A partial application or a refund that used to mean a trip through the receipts pages is now a sentence and a confirmation. Worth deciding before the update which roles should have the refund path at all. It is worth getting right, because every unidentified or unapplied receipt leaves an invoice open on the aging report after the customer has paid it, which overstates DSO and hides working capital you already hold.

Collector Workspace and Fusion Claw: collections that act on policy

Oracle announced Fusion Claw on 29 September 2026 as a governed execution runtime, launching with 25 new applications across finance, HR, supply chain and sales. Each run ends in what Oracle calls an Outcome Receipt, an auditable record of the authority applied, the evidence used and the actions taken. In receivables it lands in Collector Workspace.

The 26C Collector Workspace ranked a collector’s worklist and drafted replies. In 26D, with Fusion Claw, it does three further things:

• Assesses each account’s payment risk from exposure, payment behaviour, promise adherence, disputes and customer responses.
• Adapts each customer’s collection path as that risk changes, instead of running a fixed sequence.
• Executes eligible next-best actions automatically, governed by the controls, approvals and thresholds in your policy, for outreach, credit reviews and escalations.

Around it, 26D detects promises to pay in call notes and records them, reads more intents in incoming email (disputes, invoice copy requests, purchase order and contact updates), and opens from the ERP Agents menu. Oracle states Fusion Claw is available for customer uptake starting with 26D Cohort A.

What the setup actually involves

Nothing here switches itself on. The collections policy is uploaded as a DOCX or PDF through the Policy Node in AI Agent Studio, which needs administrator access. The Collections Policy Execution Assistant that did this in 26C is gone from 26D; a policy already published with it carries forward. Incoming email intelligence needs a registered mailbox.

The governance point is the one to take to the audit committee. Once actions execute within policy, the policy document stops being guidance for collectors and becomes the control itself. The thresholds, approval rules and exclusions in it are now settings, and they deserve the same review as a credit limit or a write-off threshold.

Billing Operations Workspace: disputes settled within policy

The third piece sits between billing and collections. In the Billing Operations Workspace, the Collections Email Response Assistant turns customer emails about billing problems into traceable disputes, and the Billing Agent evaluates each one against the evidence and your policy. For eligible cases it approves or rejects the dispute itself. Approved disputes go through your financial approval workflow, and the credit memo is created after that approval.

The scope is narrow for now: incorrect price and duplicate invoices only. The same workspace detects invoices whose delivery failed and resends them, which removes one of the quieter reasons an invoice ages past terms. A routine price dispute that waits a week for someone to read it is a week of cash flow held on that invoice. Setup is required, and the workspace runs on its own billing policies.

Four new receipt actions in the Oracle 26D REST API

The What’s New pages do not mention this, but the 26D Standard Receipts API reference lists four actions that are absent from the 26C reference:

• bulkApplyReceipt applies one receipt to several invoice installments in a single request.
• unapplyReceipt reverses an application and returns the amount to the receipt’s unapplied balance.
• refundReceipt refunds all or part of a receipt using a refund amount and payment method.
• reverseReceipt reverses a receipt with a reversal category and reason.

They sit on top of the single-installment applyReceipt action that arrived in 26C, which the Oracle Fusion 26C cash application guide covers in detail. Their shape mirrors what the agent can now do in conversation, which suggests the agent and outside integrations will share the same operations, though Oracle does not say so.

For a finance leader the point is simpler. From 26D, an integration can correct its own application, refund an overpayment or reverse a bounced receipt through the API instead of handing the work back to the AR team. Whether a given integration does any of that is a question to ask its vendor rather than assume.

When does 26D reach my environment?

Oracle publishes the rule in its guide to quarterly updates: test environments update on the first Friday of the cohort month and production on the third. Cohort A takes February, May, August and November; Cohort B March, June, September and December; Cohort C April, July, October and January. Applied to 26D, the fourth 2026 release, the rule gives these dates. They are derived, not published:

The Cohort C test date falls on New Year’s Day, so treat it as the date to confirm with Oracle rather than the date to plan around. Cohort B production lands a week before the holidays and in the middle of year-end, which is when a change to who can apply and refund cash is least welcome. If you are not sure which cohort an environment belongs to, the 26B receivables guide explains how the cohorts work across an estate.

What to test before your 26D update

Two weeks between test and production is enough if the list is short and owned. For receivables and collections it comes down to six checks:

1. List who holds the predefined AR Specialist and Manager roles, because they inherit the new apply and refund actions without any setup.
2. In test, apply a receipt partially and across two invoices through the agent, then confirm the balances and the accounting match what a manual application produces.
3. Run one refund end to end, including your refund approval and payment method, before anyone does it in production.
4. If you plan to use Fusion Claw, review the collections policy line by line, decide which actions may execute without a person, and set the thresholds before switching it on.
5. Check that any integration posting receipts into Oracle still behaves, especially if your team will now also apply, unapply or refund the same receipts by hand or through the agent.
6. Make sure only one system talks to each customer. If Collector Workspace starts acting on its own and another tool also sends reminders, decide which one owns outreach for which accounts.

Where Finero fits with Oracle Fusion 26D

Finero runs collections on top of Oracle Receivables. It reads invoices and their installments from Oracle on every sync, contacts customers, and collects against a specific installment on a hosted payment page through the processor you already use.

It records each payment in Oracle as a Standard Receipt carrying the remittance reference of the installment it collected against. Where 26C receipt application is confirmed on your environment, it also asks Oracle to apply the receipt to that installment. Oracle’s AutoMatch often allocates first, so Finero reads back the allocation Oracle actually made and reports that. It never marks an invoice paid, and it does not use the new 26D receipt actions: unapplying, refunding and reversing stay with your team and your Oracle controls.

So the 26D agents and Finero do different jobs. Oracle’s agents help your people work inside Oracle faster. Finero does the customer-facing collection outside it and leaves the receipt in Oracle with its identity attached, so there is less unidentified cash for the Cash Processing Agent to investigate in the first place, and the collection work gets done without adding headcount to the AR team. The one thing to settle up front is the sixth check above: which system owns outreach for which customers. See how Finero works with Oracle Fusion, how it applies cash, and the wider guide to cash application.

FAQ