Author: Vibha Baid

Days sales outstanding is the finance version of a locked storeroom: the goods have moved, the invoice exists, and the cash is still standing outside with its hands in its pockets. If your annual credit sales are 33,000 away from operations for that month. That is not a small reporting wobble. That is payroll, supplier trust, and breathing room. 

The odd part is that most of the evidence is already inside Oracle Fusion Receivables. Invoices, receipts, credits, adjustments, disputes, collection notes, and customer profiles all leave a trail. Days sales outstanding, or DSO, simply asks whether finance teams are reading that trail early enough to act. 

This piece is the educational half of a two-part series. The paired Orbrick how-to is How to pull a live DSO breakdown in Oracle Fusion Receivables. Keep this article open when you use that guide. It explains what you are looking for before you start clicking through the system. 

What is days sales outstanding, and what does one extra day really cost? 

DSO measures how long cash waits after a credit sale. The plain formula is: 

Average accounts receivable divided by credit sales, multiplied by the number of days in the period. 

The daily credit sales run near 33,000. Move DSO from 60 days to 55 days and you have not just “improved a metric.” You have pulled about $165,000 back into working capital. 

The formula matters because it turns a vague feeling into a question you can assign. Is cash late because invoices are going out late? Are disputes taking too long? Are collectors missing the right accounts? Are payment terms drifting because credit overrides have become habit? 

Oracle Fusion Cloud Financials stores the transaction trail needed for that investigation across Receivables invoices, receipts, adjustments, credit memos, customer accounts, and collections activity. Oracle’s Using Receivables Credit to Cash is the right external reference for those product capabilities. The finance work is not to admire the data. It is to convert the data into a cash movement you can prove. 

For Orbrick, this maps directly to the CFO persona outcome DSO Optimization. DSO is not a vanity measure. It is a working-capital signal that affects liquidity, borrowing pressure, supplier confidence, and the credibility of the cash forecast. 

Where does cash hide inside the receivables cycle? 

Cash usually hides in four waiting rooms. 

First, billing is delayed. The work is delivered, but the invoice does not leave the system quickly enough. In some teams, that delay is blamed on approvals, missing purchase order references, or manual checks that should have been fixed months ago. 

Second, dispute delays. The customer questions a line item, tax code, delivery reference, discount, or service milestone. The invoice moves from “collectable” to “someone is checking.” That phrase can be swallowed for weeks. 

Third, collection delays. Follow-up depends on a person remembering which customer needs a nudge, which invoice has a promise to pay, and which account has stopped responding. When notes sit in inboxes rather than the receivables record, the process becomes folklore. 

Fourth, credit policy drifts. Teams make reasonable exceptions during pressure periods, then forget to reset the policy. A customer gets longer terms for one project. Another gets a shipment despite open balances. Over time, exception becomes culture. 

Call this the Receivables Waiting Room. Nothing looks broken from far away. Revenue is booked. Invoices exist. Teams are busy. Yet the cash has not arrived. 

The way out is segmentation. Review DSO by customer group, business unit, region, payment term, collector, dispute reason, and invoice age. If one segment carries most of the delay, the answer is rarely “collect harder.” It is usually a specific decision that needs a better owner. 

How should a CFO diagnose DSO inside Oracle Fusion Receivables? 

Start with a baseline. Pull DSO for the full portfolio, then split it into segments that match how your finance team actually works. Customer type, collector, region, business unit, payment term, and invoice age are useful for first cuts. 

Next, isolate the top delay pockets. You are not looking for every late invoice. You are looking for a few segments that explain most of the cash wait. A Pareto view is useful here: which 20 percent of customers, dispute types, or invoice routes are creating most of the trapped cash? 

Then assign ownership by cause, not by symptom. Billing delay belongs to the order-to-cash process owner. Dispute delay belongs to the team that can resolve root causes. Credit drift belongs to finance policy. Collection delay belongs with the collection operating rhythm. 

Finally, measure the change after one cycle. If the segment DSO improves but bad debt rises, you have moved too aggressively. If DSO improves while disputes fall and forecast accuracy rises, you have changed the system rather than only chasing harder. 

The paired how-to, how to pull a live DSO breakdown in Oracle Fusion Receivables, should include these cuts: aging bucket, invoice status, adjustment history, dispute reason, collections activity, customer profile, and payment terms. Oracle’s Financials documentation is the external reference for the Receivables capability set. The business question is yours: where is the cash waiting, and who owns the wait? 

That question also protects the team from a common trap. Finance leaders often ask for a single DSO number. A single number is useful for the board. It is not enough for action. Action lives in the segment. 

Which decisions push DSO up before anyone notices? 

DSO moves before the dashboard becomes embarrassing. 

Late invoicing is the first quiet decision. If invoices are not issued on time, the collection clock starts late. No collector can recover the days that billing gave away. 

Loose credit overrides are the second. Exceptions are sometimes necessary. The problem begins when exceptions do not expire. A temporary customer concession becomes the new default. 

The dispute backlog is the third. A dispute is not only a collections problem. It may point to pricing errors, contract ambiguity, delivery proof gaps, tax setup issues, or weak master data. Treating every dispute as a one-off is like mopping the floor while the tap is still running. 

Manual collection notes are the fourth. If the promise-to-pay date is in one person’s inbox, the company does not own the promise. The person does. That is fragile. 

Stale customer segmentation is the fifth. A customer that paid well two years ago may now need a different risk view. A new customer may be growing quickly but still deserves a tighter rhythm. Finance policy has to move with behaviour. 

This is where Business Value Maximization (BVM) matters. BVM powered by SEER framework gives the work a sequence: Sense, Evaluate, Execute, Retrospect and Refine. Sense the DSO baseline. Evaluate where cash value is trapped. Execute focused process changes. Retrospect and Refine by proving whether cash actually moved. 

Notice the order. It does not start with a sales pitch. It starts with the reader’s own receivables data. 

How do you turn DSO reduction into a measured Oracle Fusion outcome? 

Use a simple outcome ledger. 

First, write the baseline: current DSO, cash value per day, top delay segment, and the owner. Second, name the change: faster invoice release, tighter dispute routing, updated credit override rules, or a better collections cadence. Third, record the expected value: days reduced multiplied by cash value per day. Fourth, review the result after the next close. 

That ledger keeps the work honest. If the expected value is five DSO days and the next cycle shows only one, the team has learned something useful. Maybe the root cause was wrong. Maybe the action was too slow. Maybe the segment moved, but another segment worsened. Either way, the metric becomes a management conversation, not a dashboard decoration. 

Inside a Value Discovery engagement, Second Sight can act as an in-engagement capability that baselines process and KPI issues across Oracle Fusion data. It is not a stand-alone product purchase. It is part of a consulting engagement designed to connect ERP signals with measurable outcomes. 

That distinction matters to Orbrick. Orbrick is a boutique management consultancy firm that specialises in Oracle’s existing Fusion Applications customers and also takes new customers. The differentiator is outcome-based, at-risk pricing. Orbrick is Oracle Cloud consulting firm operating fully on at-risk, outcome-based pricing, paid only on measurable business impact. 

For the reader, the useful lesson is simpler. If DSO is rising, do not begin with blame. Begin with the waiting room. 

What should your finance team do this month? 

Run a 30-day DSO diagnostic with five steps. 

1. Calculate the current DSO and the cash value of one day. 

1. Split DSO by customer group, payment term, aging bucket, and dispute reason. 

1. Pick the top three delay pockets. 

1. Assign one owner and one action to each pocket. 

1. Review movement after the next billing and collection cycle. 

Keep the action narrow. Do not launch a transformation programme because one metric moved. If late invoices explain most of the delay, fix the invoice release. If disputes explain it, fix dispute routing. If collection notes are scattered, move ownership back into the system. 

This is also where the Orbrick concept of Tiny Transformations fits. Small, specific changes can shift ERP value faster than broad programmes that take months to define. A better credit override review. A cleaner dispute owner. A live DSO breakdown. Cash returns when the work is specific enough to be owned. 

What should you avoid when trying to reduce DSO? 

Avoid three traps. 

The first trap is treating DSO as a collection-only problem. Collections are the last mile. Many DSO delays begin earlier. When billing rules are unclear, customer master data is stale, contract terms are inconsistent, or disputes are created by preventable invoice errors. If the team only pressures collectors, the same issues will return next month wearing a different invoice number. 

The second trap is setting one aggressive target across every customer group. A public-sector customer, a healthcare provider, and a manufacturing account may all behave differently. The right target depends on terms, dispute profile, payment method, customer risk, and relationship history. Segment first, then set targets. A single target is tidy. A segmented target is useful. 

The third trap is celebrating a lower DSO without checking the side effects. Did bad debt rise? Did customer disputes increase? Did the team become too restrictive with credit and slow good revenue? A finance metric can improve while the operating model gets worse. Pair DSO with bad-debt movement, dispute aging, write-offs, and customer experience signals before declaring victory. 

This is why DSO work needs a named owner and a small review rhythm. Once a month, ask four questions: where did the DSO move, which segment drove the move, which decision caused it, and what cash value changed? The answer should fit on one page. If it takes a committee deck to explain, the action is probably too broad. 

For more KPI-led thinking, read the free Tiny Transformations e-book, which covers ERP value, KPIs, and post-go-live ROI. If you want to baseline the Receivables Waiting Room inside your own Oracle Fusion setup, request a Value Discovery session. For the technical half of this series, pair this piece with How to pull a live DSO breakdown in Oracle Fusion Receivables and use Second Sight as the outcome-baselining capability inside the engagement. 

Picture this. It’s Monday morning. A customer has sent in a consolidated payment, one wire transfer covering seventeen invoices from the last two months. The remittance advice? A rough Excel attachment with some invoice numbers, some PO references, and a few line items that don’t match anything in the system cleanly.

Somewhere in a shared service centre, an AR analyst opens Oracle, pulls up the unapplied receipts queue, and starts the familiar ritual. Cross referencing the bank statement, the remittance email, the customer’s payment history, trying to figure out where each rupee belongs.

This scene plays out in organizations every single day. And what makes it frustrating is that in most cases, Oracle Fusion already has the capability to handle a significant portion of this automatically.

The tools are there. The question is whether they have been set up to reflect how customers actually pay, not how finance teams wish they would.

Turning Customer Communication into a Cash Flow Accelerator

When organizations look to improve cash application, the first instinct is often to fine-tune internal processes or invest in more automation. While those initiatives certainly help, one of the biggest improvements often comes from a much simpler area: better communication with customers.

In many of the projects we have worked on, a significant number of receipt application delays were not caused by system limitations but by missing or incomplete remittance information from customers. Without clear references such as invoice numbers or payment details, even the most efficient finance teams are forced into manual investigation and follow-up.

To address this challenge, we helped clients provide customers with greater visibility into their outstanding balances and payment information through tools such as Customer Statements and Self-Service Customer Portals. By putting the right information in customers’ hands at the right time, they were better equipped to provide accurate payment references, making the entire process smoother for both parties.

The results were tangible. Organizations saw a 20% to 30% improvement in receipt application efficiency, a reduction in unapplied cash, faster collections, and a better overall customer experience. Sometimes, the key to improving cash application is not another internal process change but enabling customers to help you get it right the first time.

The Setup Nobody Revisits

Early in any AR assessment, one of the first places I look is Receivables System Options.

Most implementation teams configure this during go live and never touch it again. But this setup quietly shapes how Oracle interprets every incoming payment. How it reads customer references, how aggressively it tries to match invoices, and how it decides what is a clean match versus what needs a human eye on it.

Here is what typically happens. A customer sends a payment with their own internal reference codes instead of Oracle invoice numbers. Oracle tries to match, cannot find an exact hit, and parks the receipt as unapplied. The AR team gets a notification. Someone manually investigates. The receipt gets applied two days later.

Multiply that by a hundred receipts a week, and you have a team that is permanently behind. Not because the work is complex, but because the system has not been told how to handle the real world.

A few targeted adjustments to System Options, tuning how Oracle interprets customer references and how aggressively it attempts partial matches, and suddenly a large chunk of those manual receipts start resolving themselves.

The capability was always there. It just had not been aligned with operational reality.

AutoCash Is Your Cash Application Strategy, Not Just a Setting

I once worked with a client whose cash application team was manually processing thousands of receipts every month. The volume was not the problem. It was the pattern. Customers were consistently combining multiple invoices into single payments, sometimes with small rounding differences, sometimes with deductions for early payment discounts.

The AutoCash setup they had was built around a single rule of exact invoice matching. Logical, clean, and completely misaligned with how their customers actually paid.

So here is what was happening was happening in that project. A customer sends a payment covering four invoices. Oracle looks for an exact match. Finds none. Parks the receipt. An analyst picks it up, manually identifies the four invoices, applies the receipt, notes the short payment, and moves on. Repeat, daily, indefinitely.

But here is what most implementations get wrong. They pick one rule and call it done.

To execute this correctly, study how the business’s customers behave in practice. Do they pay invoice by invoice? Do they send consolidated payments? Do they take discounts? Do they have overdue balances sitting alongside current ones? Once that picture is clear, we build a rule set that is a carefully ordered group of these rules, sequenced so that Oracle works through them logically from the most precise match down to the most flexible fallback.

For a customer who sometimes references invoices and sometimes just pays a round number, you might sequence Match Payment with Invoice first, then Apply to the Oldest Invoice First, then Clear the Account. Oracle tries each rule in order and stops the moment one produces a clean application.

For a business where customers frequently take early payment discounts, Combo Rule earns its place in the hierarchy because a receipt will almost never match the invoice face value exactly, and without that rule in the sequence, every discounted payment lands in the unapplied queue.

For organizations managing customers with a mix of overdue and current balances, placing Clear Past Due Invoices or Clear Past Due Invoices Grouped by Payment Terms earlier in the sequence ensures aging gets addressed automatically rather than piling up for the collections team.

Once we redesigned the AutoCash rule set for that client, replacing their single rule with an intelligently ordered group that reflected how their customers were actually paying, the change was immediate. The majority of those receipts that once required manual review started applying on their own.

AutoCash is not a switch you turn on. It is a hierarchy you design. And when that hierarchy is built around the actual payment behaviour of your customers rather than a theoretical ideal, it stops being a configuration and starts being a genuinely effective cash application strategy.

Another Infrastructure Beneath the Surface: Receipt Classes and Methods:

Here is something that often gets underbuilt during implementation. Receipt Classes and Receipt Methods.

These configurations determine how different payment channels behave inside Oracle. A manual receipt entered by an analyst. A lockbox file imported from the bank. An electronic transfer initiated by the customer. Each of these follows a different path with different remittance processing, different clearing behaviour, and different reconciliation logic.

What I have seen in several implementations is that organizations put all of these through the same receipt structure because it was simpler to set up that way. Over time it creates friction. Reconciliation inconsistencies, mismatched clearing entries, and remittance flows that do not quite behave as expected.

The bank account setup underneath this is where it gets particularly important. Oracle uses the remittance bank account to determine which receipt class and method to apply during processing. In high volume environments, getting that relationship right is what keeps receipt creation, remittance, and reconciliation running cleanly across every payment channel.

A well designed receipt architecture is also easier to extend. When a new bank, a new payment channel, or a new legal entity gets added later, the expansion fits naturally rather than requiring a workaround.

When Human Judgment Hits Its Limit and Where AI Agents Can Help?

Even in organizations that have done all of the above well, solid System Options, thoughtful AutoCash, clean receipt architecture, there is still a category of receipts that has historically required human judgment.

The customer who sends a payment with incomplete remittance details. The receipt that almost matches three invoices but not quite. The deduction that might be a pricing dispute, a freight claim, or an early payment discount but nobody is sure without digging into the history.

This is where AR teams have always spent their remaining time. Not processing the straightforward receipts because AutoCash handles those, but investigating the ambiguous ones.

Traditionally, an analyst would pull up the customer’s payment history, review open invoices, check the last few transactions, apply some judgment, and make a call. Useful work, but slow, repetitive, and dependent on institutional knowledge.

This is exactly where Oracle’s ERP Agents are beginning to change the operating model.

Instead of waiting for an analyst to investigate, Oracle can now analyse the broader transaction context automatically. It reviews payment patterns, open balances, historical matching behaviour, and customer references, and then surfaces a set of recommended applications ranked by likelihood of accuracy.

The finance team does not lose control. They still review and approve. But instead of starting from a blank slate and reconstructing the picture manually, they are reviewing a recommendation that has already done most of the analytical work.

For lockbox environments, where customer references often do not match invoice numbers exactly, this is especially valuable. Instead of defaulting to an exact match or escalation, the system can present the three most likely applications and ask which one is correct.

Short payments get the same treatment. Rather than an analyst manually checking whether a deduction relates to freight, tax, a pricing dispute, or a discount, Oracle begins categorising these patterns and recommending resolution paths based on context.

The workload does not disappear. But it shifts. Instead of investigating every exception from scratch, AR teams are reviewing, confirming, and approving, which is a fundamentally different use of their time.

What This Actually Means for AR Operations?

Oracle Fusion 26B reflects something larger that has been building across finance operations for a few years now. The gradual shift from rule based automation toward context aware processing.

Receipts can now be automatically created directly from bank statement lines, while remittance advices across multiple formats can be ingested, interpreted, and matched to receipts within a unified process.

Rule based automation is powerful but brittle. It works beautifully when the world conforms to the rules. When customers pay in unexpected ways, when remittance details are incomplete, when a receipt is close but not exact, rules reach their limit.

Context aware automation, the kind that ERP Agents are moving toward, is built for the messy real world. It reasons across patterns rather than matching against a fixed list.

But here is the part that is easy to miss. Intelligent automation performs best when the foundational configuration is already mature. ERP Agents do not replace strong AutoCash design, well structured receipt methods, or thoughtful System Options. They build on top of them.

An organization that has not tuned its AutoCash strategy will not suddenly get perfect cash application from AI assistance. But an organization that has done the foundational work well will find that intelligent automation extends their capability significantly further.

The Bigger Picture

One thing that becomes clear across receivables transformation projects is that most AR teams are not overworked because cash application is inherently complex. They are overworked because the automation framework was never fully aligned with how their customers actually behave.

Oracle Fusion has always had the capability to automate a significant portion of cash application. What is changing now is that the remaining portion, the ambiguous cases, the incomplete remittances, the almost matching receipts, is also becoming automatable with the right configuration and the right tools in place.

The future of receivables is not processing receipts faster. It is building an operation where the routine takes care of itself, and the team’s energy goes toward exceptions, customer relationships, and decisions that genuinely require human judgment.

That shift is already underway. The question is how quickly organizations choose to move.