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.

Four features touched Oracle 26B receivables. Two matter for collections, and most customers cannot use the larger one. Cash processing can now create receipts directly from bank statement lines and read remittance advices, but on 26B 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.

What’s new in Oracle Fusion 26B Receivables?

Oracle’s 26B Financials feature summary lists four features that touch Receivables: cash processing from bank statements and remittance advices, an installments REST API, embedded e-invoicing through Thomson Reuters, and automatic revenue recognition for invoices with prepayments. Advanced Collections has no 26B features, and there is no receivables agent.

If you have seen a “Receivables Inquiry” agent attributed to 26B, it is not in Oracle’s 26B Financials feature list. The agents there are for the ledger, payables, payments and expenses. Predictive Cash Forecasting also uses Receivables data in 26B, but it lives in Cloud EPM and is covered below.

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: early adoption on 26B, a setting on 26C

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. On 26B the feature is turned on by Service Request, and Oracle’s own note says it is not available outside its Early Adoption program. That restriction ends with 26C, where the Cash Processing Agent is enabled by default and receipt creation from bank statements becomes a per-bank-account setting under Setup and Maintenance.

So the practical position depends on your release. On 26B you wait for an invitation. On 26C you switch it on yourself. Oracle describes the 26B feature as a step toward its Cash Processing Agent vision, and 26C is where that agent arrives.

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 directly to a named installment. 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. Embedded e-invoicing through Thomson Reuters matters if you invoice into a PEPPOL country: Australia, Belgium, Denmark, Finland, Germany, the Netherlands, Norway, Sweden or the UK, with Italy, Poland, Malaysia, Saudi Arabia and the UAE listed as future clearance countries. It needs a Thomson Reuters agreement and a Service Request, and an invoice that reaches the buyer’s AP system in the format it expects is one fewer reason for it to sit unpaid. 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 was therefore on 26B by 17 July 2026, and the fleet then moved again. Cohort A production took 26C on 21 August, Cohort B test environments moved on 4 September and production on 18 September, and Cohort C followed on 2 and 16 October. Every environment has been on 26C since 16 October 2026.

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. The next step after 26C is covered in the Oracle Fusion 26D receivables guide.

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 also asks Oracle to apply the receipt to the installment it collected against and reads back the allocation Oracle made, 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. Once your environment is on 26C, or Oracle admits you early, 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.

Does Oracle Fusion 26B change how a receipt is applied to an invoice?

No. On 26B you still record cash as a Standard Receipt with a remittance reference, and Oracle’s matching decides which installments it settles. There is no operation that applies a receipt to a named installment and none that marks an invoice paid. That capability arrives in 26C, and an integration has to confirm it is present before using it.

What should an AR team do before the 26C update lands?

Find out which cohort each environment is on, because the update date differs by up to two months across an estate. Check whether the Cash Processing Agent should stay enabled and which bank accounts should create receipts from statements. Confirm that any integration writing payments into Oracle knows which release it is talking to.