A cross-channel table joining two systems: customers with aged AR (60+ days overdue) in Oracle Receivables who are still placing new ecommerce orders. The revenue you are extending to slow payers, in one view.
At a glance
This is a cross-channel card. It joins Oracle Receivables aging to live ecommerce order activity to answer one question no single system can: which of your slow-paying customers are you still selling to? A customer with 60+ days of overdue AR in Oracle Fusion who keeps placing new orders on your storefront is an open credit risk. In a clean setup, Oracle Fusion Credit Management would auto-classify that customer as high-risk via Credit Authorization rules and place new orders on hold. This card surfaces the cases where that did not happen: aged receivables on one side, fresh ecommerce revenue on the other, the same party. Each row is a customer, with their overdue AR balance, their aging bucket, and the value of the new ecom orders they have placed, so finance can decide whether to tighten credit before exposure grows.
| What it counts | Each row is one customer (Oracle Fusion party) with 60+ days overdue AR in Oracle Receivables who has also placed new ecommerce orders in the window. Columns show the overdue AR balance, the worst aging bucket, and the value of the recent ecom orders. |
| Cross-channel join | Oracle Receivables aging (the AR side) is matched to the ecommerce platform’s order feed (the demand side) on the customer party. The card exists because neither system alone shows both halves. |
| Currency | Overdue AR is shown in the customer’s transaction currency, rolled to the reporting ledger currency for the table total. New ecom order value is shown in the storefront’s currency. |
| What good looks like | An empty or short table. Oracle Fusion Credit Management should already hold or block new orders from customers in deep arrears via Credit Authorization rules. Long tables mean credit policy is not reaching the storefront. |
| Business Unit scope | Respects the dashboard’s selected Business Unit filter. By default rolls up every Business Unit the connected role can see. |
| Time window | 30D vsP (new ecom orders in the last 30D vs the prior 30D) |
| Alert trigger | any customer >60d AR with new ecom orders - a single matching customer raises the table |
| Roles | owner, finance |
Calculation
Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US Fortune 500 B2B-and-DTC retailer runs Oracle ERP Cloud for Receivables and Credit Management, with a BigCommerce B2B storefront feeding Order Management. The 30-day window covers 14 Mar 26 to 12 Apr 26. The cross-channel join surfaces three customers in deep arrears who are still ordering.| Customer (Fusion party) | Overdue AR (60+d) | Worst aging bucket | New ecom orders (30D) |
|---|---|---|---|
| Atlas Wholesale Co | $284,000 | 90+ days | $61,500 |
| Northgate Supply LLC | $142,000 | 61-90 days | $38,200 |
| Riverbend Trading | $97,500 | 90+ days | $12,400 |
| Total exposure | $523,500 | $112,100 |
- Two systems, one finding. Oracle Receivables knows Atlas Wholesale is 61,500 of fresh orders. Neither system raises a flag on its own. The cross-channel join is the whole point: it puts the aged balance next to the new demand for the same party.
- Credit Management should have caught this. In a clean Oracle Fusion setup, a customer 90+ days overdue would hit a Credit Authorization rule and new orders would be held. These three slipped through, usually because the ecom order path bypasses the credit check or the customer’s credit profile was never linked to the storefront account. Pair this with Orders on Credit Hold and Credit Hold Spike.
- The $112,100 of new orders is the decision point. This is revenue you are extending to customers who are not paying for what they already bought. Finance can choose to hold the new orders, demand payment first, or accept the risk; the card makes the choice explicit instead of invisible.
- The aging bucket matters as much as the balance. Riverbend’s $97,500 is smaller but it is all 90+ days, the bucket least likely to ever pay. A large 61-90 balance is a collections problem; a 90+ balance with fresh orders is a credit-policy failure. Pair with AR Aging Detail and High-Value Overdue Invoices.
Sibling cards merchants should reference together
This card lives at the join of Receivables and commerce. Pair it with the credit and aging cards on the Oracle side and the order cards on the commerce side.| Card | Why pair it with AR Aging on Customers with Active Ecom Orders |
|---|---|
| High Credit Risk Customers | The Credit Management classification this card says should have fired. |
| Orders on Credit Hold | Where these new orders should have landed if credit policy reached the storefront. |
| Customer Credit Utilisation | How much of each customer’s credit limit is already consumed. |
| AR Aging Detail | The full per-customer aging behind the 60+ day filter. |
| High-Value Overdue Invoices | The specific invoices driving each customer’s overdue balance. |
| AR Aging 60+ Days | The aggregate 60+ day exposure across all customers, not just those still ordering. |
| Days Sales Outstanding | The portfolio-level signal that aged AR is building. |
Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud: The AR side of this card maps to standard Oracle Fusion Receivables and Credit Management views; the ecom side comes from your commerce connector, so a full match requires both.Navigator → Receivables → Accounts Receivable → Manage Customer Account Activities (per-customer overdue balance and aging) Reports and Analytics → OTBI → Financials → Receivables - Aging Real Time (aging buckets per customer) Navigator → Credit Management → Manage Credit Cases / Credit Authorizations (the credit classification that should be holding new orders)The AR balances and aging buckets in this card should match the Receivables Aging report when scoped to the same Business Unit and as-of date. The new-order value will not appear in any Oracle Receivables report, because those orders have not yet become Receivables transactions; that column comes from the commerce platform. Common mistakes when comparing against Oracle’s own reports:
- Looking only in Receivables. The aged balance reconciles to Oracle, but the new-ecom-order column never will, because it is pre-Receivables order data from the storefront. That is the cross-channel value, not a discrepancy.
- Aging as-of date drift. Aging is sensitive to the as-of date. Use the same date the card used or buckets shift.
- Party vs account vs site. A customer can have multiple accounts and sites in the Oracle TCA party model. The card rolls to the party; an account-level Oracle view shows a subset.
| Reason | Direction | Why |
|---|---|---|
| Cross-channel by design | Card has extra data | The new-ecom-order column has no Oracle equivalent because those orders are not yet Receivables transactions. This is the point of the card, not an error. |
| Aging as-of date | Either | A different as-of date shifts balances between buckets and can add or drop a customer at the 60-day line. |
| Party model roll-up | Either | The card aggregates at the TCA party level; an Oracle account- or site-level view shows part of the balance. |
| Currency conversion | Small | Overdue AR rolled to the reporting currency uses the configured rate; an Oracle report in transaction currency reads differently. |