> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # AR Aging on Customers with Active Ecom Orders, Oracle ERP Cloud > AR Aging on Customers with Active Ecom Orders is a cross-channel table of customers with 60+ day overdue AR in Oracle Receivables who are still placing new ecommerce orders. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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** | Four things to notice: 1. **Two systems, one finding.** Oracle Receivables knows Atlas Wholesale is $284,000 overdue. BigCommerce knows Atlas just placed $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. 2. **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](/nerve-centre/kpi-cards/oracle-erp/orders-on-credit-hold) and [Credit Hold Spike](/nerve-centre/kpi-cards/oracle-erp/credit-hold-spike). 3. **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. 4. **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](/nerve-centre/kpi-cards/oracle-erp/a-r-aging-detail) and [High-Value Overdue Invoices](/nerve-centre/kpi-cards/oracle-erp/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](/nerve-centre/kpi-cards/oracle-erp/high-credit-risk-customers) | The Credit Management classification this card says should have fired. | | [Orders on Credit Hold](/nerve-centre/kpi-cards/oracle-erp/orders-on-credit-hold) | Where these new orders should have landed if credit policy reached the storefront. | | [Customer Credit Utilisation](/nerve-centre/kpi-cards/oracle-erp/customer-credit-utilisation) | How much of each customer's credit limit is already consumed. | | [AR Aging Detail](/nerve-centre/kpi-cards/oracle-erp/a-r-aging-detail) | The full per-customer aging behind the 60+ day filter. | | [High-Value Overdue Invoices](/nerve-centre/kpi-cards/oracle-erp/high-value-overdue-invoices) | The specific invoices driving each customer's overdue balance. | | [AR Aging 60+ Days](/nerve-centre/kpi-cards/oracle-erp/ar-aging-60-days) | The aggregate 60+ day exposure across all customers, not just those still ordering. | | [Days Sales Outstanding](/nerve-centre/kpi-cards/oracle-erp/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. **Why our number may legitimately differ from Oracle's reports:** | 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. | ## Known limitations / merchant FAQs **Why is this a cross-channel card?** Because the finding only exists when you join two systems. Oracle Receivables knows who is overdue; the commerce platform knows who is still ordering. Neither raises a flag alone. The card joins aged AR in Oracle Fusion to live order activity on the storefront for the same customer, which is the exact situation credit policy is meant to prevent. **Shouldn't Oracle Credit Management already block these orders?** In a clean setup, yes. A customer in deep arrears should hit a Credit Authorization rule and new orders should be held. When a customer appears on this card, it usually means the ecom order path bypasses the credit check, or the storefront account was never linked to the Oracle credit profile. The card is the evidence that credit policy is not reaching the storefront. **Why 60 days as the threshold?** 60+ days overdue is the point where a balance moves from a routine collections matter to a genuine credit-risk signal. A customer one cycle late and still ordering is normal trade; a customer two or more cycles late and still ordering is exposure that finance should review. **Does the new-order value reconcile to Oracle?** No, and it should not. Those orders are still on the commerce platform and have not become Receivables transactions yet, so they appear in no Oracle Receivables report. That column is the cross-channel half of the card; expecting it to match Oracle misunderstands the join. **What action does this card support?** A credit decision. For each customer, finance can hold the new orders, require payment of the aged balance first, tighten the credit limit, or accept the risk knowingly. The card surfaces the trade-off so it is a deliberate choice rather than an oversight. **Can Vortex IQ place the orders on hold?** No. Holding orders and changing credit limits are controlled actions inside Oracle Fusion Credit Management and your order system. Vortex IQ surfaces the cross-channel exposure and notifies owner and finance; your team makes and applies the credit decision in Oracle. *** ### Tracked live in Vortex IQ Nerve Centre *AR Aging on Customers with Active Ecom Orders* is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.