Oracle Fusion 26B Receivables: What Changed, and What Did Not

Oracle Fusion 26B receivables changes deserve a second read. Every summary of the release was written in the spring, before a single production environment had it, and they all lead with the four AI agents, three of which are about paying money out. This guide is for the CFO or finance director looking the other way.

Two things changed for Oracle 26B receivables, and most customers cannot use the larger one. Cash processing can now create receipts directly from bank statement lines and read remittance advices, but only under an early adoption program. The Receivables Invoices REST API gained an action that restructures an invoice’s installments, and that one is live by default. Advanced Collections got nothing.

The first agent on the collections path is a 26C feature, and it ships switched off.

The four agents, and who they are for

Oracle’s own 26B feature list names four agents: a Ledger Agent for the general ledger, a Payables Agent for invoice ingestion and compliance, a Payments Agent for supplier payment options and execution, and an Expenses Agent for expense capture. Every one of them is marked setup required, which is Oracle’s standing rule for anything that changes how people work: it arrives disabled and waits for an opt in.

Read the list from the receivables side and the gap is obvious. There is no Receivables agent and no Collections agent. Scroll the whole document and there is no Advanced Collections heading at all. If your problem is money coming in late, 26B built the tooling for the people whose problem is money going out.

That is not a criticism of the release. It does explain why so many 26B write-ups have nothing to say to an AR manager, and why the two receivables features that did land got so little attention.

Cash processing from bank statements: the feature you probably cannot enable

The most consequential receivables item in 26B is Cash Processing from Bank Statements and Remittance Advices. Receipts are created directly from bank statement lines, in BAI2, MT940 and CAMT053 formats. Remittance advices, including PDFs, are read against trained templates and matched to those receipts in one flow. Anything with a missing reference or an ambiguous business unit is routed to an exception queue for a person to resolve.

For a team that keys receipts from a lockbox report or reconciles remittance PDFs by hand, this is exactly the headcount you would want back, and it is aimed squarely at the unapplied cash line. Then read the paragraph on switching it on. The feature is turned on by Service Request. For 26B, Oracle Development contacts selected customers under its Early Adoption program, and in Oracle’s words it is not available to be enabled outside that program.

So most finance leaders are in an odd position. The capability exists, it is on your release, and you cannot use it until Oracle invites you. Oracle describes it as a step toward a Cash Processing Agent vision, and the 26C release notes list two Cash Processing agents marked setup required, so the direction is clear. The timing is Oracle’s.

Two of Oracle’s own considerations are worth carrying into any planning conversation. It is switched on per bank account, so it can be rolled out by bank, region or legal entity rather than all at once. And the note is candid that accuracy depends on training the document formats, particularly customer-specific remittance layouts, which means the first months are a data-onboarding project rather than a switch.

What 26B does for cash you already know the identity of

Some of your cash arrives cold, and that is the only kind the bank statement feature addresses. A customer pays by bank transfer, the remittance detail is whatever their AP system chose to include, and somebody has to work out which invoices it settles. This is where unapplied cash comes from. While it sits there the invoices it should have closed still read as open, DSO is overstated by however long the cash has been in limbo, and the working capital position you report is worse than the one you have.

The rest of it arrives with its identity already attached. The customer paid a specific invoice, or a specific installment of one, on a payment page that knew what it was collecting. Nothing needs interpreting, and no amount of document training improves it. The only question is whether the system that took the payment tells Oracle precisely enough.

On 26B the answer is the same as it has always been. Oracle exposes no operation that marks an invoice paid; cash is recorded as a Standard Receipt carrying a remittance reference, and Oracle’s matching decides which installments it settles. That changed in 26C, where a receipt can be applied to a named installment synchronously. We covered that shift in the guide to Oracle Fusion 26C cash application, and it is the more important change for anyone running a collections layer on top of Oracle.

The installments API, and why collections teams should care

The other receivables feature that landed for everyone is Receivables Invoice Installment Creation Using a REST API. A new action lets software create or restructure an invoice’s installments, which until now was a manual job on the invoice. There is nothing to switch on; it is live by default. Oracle notes it came from a customer idea on Cloud Customer Connect, which tells you how long people had been asking.

The business case is payment plans. A customer with a disputed line and a clean remainder, or a large balance they can pay in three parts, is a customer you would rather schedule than chase, and cash in three parts beats a write-off in one. Splitting the schedule by API means the plan a collector agrees to on a call can exist in the ledger the same day, without a request to whoever has edit rights on the invoice.

Three of Oracle’s constraints matter to the people who will use it. The installment amounts must still sum to the invoice total, so a plan cannot change what is owed on the way through. A closed installment cannot be touched. And updating an installment automatically cancels any open promise to pay recorded against it in Advanced Collections, so a restructured schedule wipes the promise history on that line. That last one is sensible, and it will surprise a collector who did not know.

The other Oracle Fusion 26B receivables changes

Automated revenue recognition for sales invoices with prepayment applications removes a manual override on a specific invoice shape and needs no decision from anyone; it is on by default. Predictive Cash Forecasting with subledger traceability reaches general availability, with Receivables as one of its inputs; it is opt in, it needs a Service Request, and it lives in Cloud EPM rather than in Receivables itself. If your DSO reporting already feeds a cash flow forecast, this is the item to hand to whoever owns that model.

When your environment got 26B, and what comes next

Oracle publishes the cadence in its guide to quarterly updates: test environments update on the first Friday of your cohort month, production on the third Friday. Cohort A takes February, May, August and November; Cohort B March, June, September and December; Cohort C April, July, October and January. 26B was the second 2026 release, so it landed like this:

Every production environment has therefore been on 26B since 17 July 2026, and the fleet is already moving again. Cohort A production took 26C on 21 August, Cohort B test environments moved on 4 September with production due on 18 September, and Cohort C follows on 2 and 16 October.

The planning point is that “we are on 26B” stops being true for part of your estate before it stops being true for the rest, and the receivables behaviour that matters most, receipt application, differs between the two releases. Anything that writes payments into Oracle needs to know which release a given environment is on, rather than assuming a date from a press summary.

Where Finero fits

Finero runs collections on top of Oracle Receivables, and it was built for the 26B model before 26C existed.

It reads invoices and their installments from Oracle on every sync, and it decides what to collect from the invoice status and open balance Oracle holds, never from a status of its own. When the new installments API restructures a schedule, the next sync collects against the revised installments; Finero does not call that action itself, because deciding a customer’s payment plan is your team’s call and Oracle’s record.

It collects against a specific installment, on a hosted payment page, through the card or bank processor you already have. Because the buyer paid that installment, the payment arrives with its identity attached, so nothing has to be worked out afterwards. Finero records it in Oracle as a Standard Receipt with a remittance reference to the transaction. On 26B, Oracle’s matching allocates it, which is the correct behaviour on every environment. On 26C, where the newer capability is confirmed present on your environment, Finero applies the receipt to the installment it collected against, and falls back to the 26B path anywhere it is not.

Two things it does not do, on either release. It never marks an invoice or installment paid, because Oracle has no such operation and any tool claiming one is describing something else. And it never chooses an allocation on Oracle’s behalf: it names the installment it collected against or names nothing, and every balance it reports is read back from Oracle after the write. Oracle stays the ledger.

The bank statement feature and Finero address different cash. If Oracle admits you to the early adoption program, it will read the transfers that arrive cold. Finero closes the gap at the other end, by collecting in a way that leaves nothing to read. Both end up as receipts in the same ledger. How Finero applies cash covers the mechanics, the guide to cash application covers the wider discipline, and our pricing is a flat subscription rather than a per-action meter.

FAQ