AR Aging on Customers with Active Ecom Orders, Sage

Customers carrying aged AR in Sage who are still placing new ecommerce orders. The cross-platform credit-risk join. How to read it, why it matters, and how to act on it.

Metrics type: Cross-Platform Metrics • Category: Ecommerce Platform

Customers carrying aged AR (60+ days) in Sage who are still placing new ecommerce orders. Each row is a customer you are extending more credit to while old invoices sit unpaid.

At a glance

A table of customers who owe you money on aged invoices in Sage (60+ days past due) and are at the same time placing fresh orders on your ecommerce channels. Each row is a credit decision you are making by default: you are extending more exposure to a customer who has not paid for the last batch. This is the cross-platform credit-risk join, and it is the kind of finding that is structurally invisible to either system alone, because Sage knows the unpaid AR but not the new orders, and the storefront knows the new orders but not the unpaid AR. Putting the two together is the whole point of the card.

What it counts	A row per customer who has both an AR balance aged 60+ days in Sage and at least one open or recent ecommerce order. Columns surface the aged AR amount, the oldest invoice age, the value of the new ecom orders, and the combined exposure. Sorted by combined exposure descending so the worst credit decision is at the top.
Aging basis	60+ days past due is the default trigger. The 60/90/120 buckets are shown per row so you can see how deep the aging runs. Configurable per workspace; tighter terms (Net-30 customers) often drop the trigger to 45 days.
Active-order definition	An order placed or still open within the comparison window (default 30 days). Includes orders on credit hold, because a customer ordering into a credit hold is itself a signal. The field map can exclude held orders if you only want orders that will actually ship.
Currency	Aged AR and new-order value are shown in the entity base currency, summed to reporting currency in Multi-Entity Console at the configured FX cadence. The combined-exposure column is the figure to govern by.
Entity scope	Card respects the dashboard entity filter. A customer trading with two entities is evaluated per entity, because credit is usually extended per entity.
Time window	30D vs prior
Alert trigger	any customer >60d AR with new ecom orders, sentiment credit_risk. Configurable per workspace. Most B2B operations leave it sensitive because each row is an active, compounding exposure.
Roles	owner, finance

Calculation

Calculated automatically by joining the Sage AR aging ledger against open and recent orders from your connected ecommerce platforms, keyed on the customer. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A UK B2B merchant on Sage Intacct (single entity, GBP) selling through a BigCommerce B2B portal on Net-30 and Net-60 terms. Snapshot 14 Apr 26, comparing the trailing 30 days against the prior 30. The card shows 6 customers carrying 60+ day AR who placed new orders in the window. The credit controller sorts by combined exposure.

Customer	Aged AR 60+d (GBP)	Oldest invoice age	New ecom orders 30d (GBP)	Combined exposure
Northgate Trade Supplies	84,000	118 days	31,000	115,000
Harbour Wholesale Ltd	52,000	74 days	22,000	74,000
Pennine Distribution	41,000	96 days	8,000	49,000
Coastline Retail Group	18,000	63 days	26,000	44,000
Moorland Supplies	22,000	88 days	6,000	28,000
Vale Trading Co	9,000	67 days	14,000	23,000
Total exposure (this card)	226,000		107,000	333,000

Five things to notice:

1. This table is a list of credit decisions you are making by default, and the card’s job is to make them deliberate instead. Every row is a customer your storefront accepted a new order from while Sage shows their last batch unpaid for 60+ days. Without the join, the credit controller sees the AR in Sage and the sales team sees the orders in BigCommerce, and nobody connects the two until the unpaid balance becomes a write-off. With the join, the controller decides, before the new order ships, whether to hold it, require payment of the aged balance first, or let it through with eyes open. The combined-exposure column is the number that drives that decision.
2. Northgate Trade Supplies at 115,000 combined and an oldest invoice at 118 days is the row to action today. An invoice approaching 120 days is into serious-doubt territory; a customer that old who is still ordering is either in genuine distress (ordering on credit because cash is tight) or treating your terms as an interest-free loan. Either way, shipping another 31,000 to them without addressing the 84,000 already owed is compounding a problem. The right move is usually a stop-order until the aged balance is cleared or a payment plan agreed, which is exactly the action Orders on Credit Hold operationalises.
3. Coastline Retail Group is the opposite profile and needs a softer touch. 18,000 aged at 63 days (just over the line) against 26,000 of fresh orders is a good customer who has slipped one cycle, not a distressed account. Treating them like Northgate (a hard stop-order) risks losing a valuable, normally-prompt account over a single late cycle. The card surfaces both on the same table; the judgement is in reading the oldest-invoice-age and the AR-to-new-order ratio together, not just the combined total.
4. The 30-day-vs-prior comparison is what turns a static list into a trend, and the trend is the real alarm. A customer appearing on this card for the first time is a watch item; a customer whose aged AR grew while their new orders also grew is an accelerating exposure. If Pennine Distribution’s aged balance climbed from 28,000 last period to 41,000 this period while they kept ordering, the trajectory is the story, not the snapshot. The card’s period comparison flags the customers getting worse, which is where the controller’s limited time should go first.
5. This is the cross-platform join that neither system can produce alone, and it is the clearest credit-risk finding Vortex IQ delivers for B2B. Sage knows the aged AR but has no idea the customer just placed three more orders on the storefront. The storefront knows the new orders but has no visibility into the customer’s payment history in the ledger. The sales team is incentivised on orders and the finance team is responsible for collections, and the gap between them is exactly where compounding credit exposure lives. On this account the join surfaced 333,000 of combined exposure that no single dashboard had ever shown together, and the controller put three accounts on hold within the day. This is the cross-platform finding that usually opens the Implementation Partner conversation with finance.

Sibling cards merchants should reference together

Card	Why pair it with AR Aging on Customers with Active Ecom Orders
A/R Aging Detail	The full aging ledger. This card is the slice of it that intersects with new orders.
Orders on Credit Hold	The action you take on the worst rows: hold the new order until the aged balance clears.
Orders Blocked on Inventory or Credit	Where the held orders land. Pairs the credit and stock blockers in one view.
Customer Credit Utilisation	The limit context. A customer over limit and aging is the most urgent case.
Overdue Invoice Value	The headline overdue total. This card attributes it to customers who are still buying.
Days Sales Outstanding	The portfolio-level collection efficiency. This card is the per-customer detail behind a rising DSO.
Customer Churn Signals	A customer who stops ordering and leaves aged AR behind is a different and worse case.
High-Value Overdue Invoices	The single-invoice view. This card is the customer-level roll-up with the order context added.

Reconciling against Sage

Where to look in Sage Intacct:

The native Sage Intacct views to run side by side with this card:

Reports → Accounts Receivable → AR Aging (the aging ledger this card joins; run at the same as-of date as the dashboard) Reports → Accounts Receivable → AR Aging Detail (invoice-level detail so you can see the oldest invoice driving each row) Accounts Receivable → Customers with the credit-limit and on-hold flags exposed, to see which flagged customers are still ordering Order Entry → Sales Orders for the flagged customers, to confirm the new orders the storefront placed (where orders sync into Intacct) Interactive Custom Report (ICR) on the AR data source listing CustomerID, aged-bucket balances, and oldest-invoice date, to align against the ecommerce open-order export by customer

The reconciliation discipline is the as-of date. AR aging is a point-in-time view; an aging report pulled yesterday and an order export pulled today will not line up. The card snapshots both sides at one moment. Also confirm the aging basis: due-date aging (days past the invoice due date) versus invoice-date aging (days since the invoice was raised) can move a customer between buckets and change whether they cross the 60-day trigger.

Common reconciliation pitfalls:

• Due-date vs invoice-date aging. A Net-60 invoice raised 80 days ago is only 20 days past due. Card uses due-date aging by default so terms are respected; a raw invoice-date aging overstates the aged cohort.
• Unapplied cash and credits. A customer with a 60-day invoice and an unapplied payment or credit memo may not actually owe the aged amount. Card nets unapplied cash where the field map allows; a gross aging report can overstate.
• Order-sync timing. New orders that have not yet synced from the storefront into Intacct will not appear in a Sage-only view, which is precisely the gap this card closes by reading the storefront directly.

Why our number may legitimately differ from a Sage AR Aging report:

Reason	Direction	Why
Due-date vs invoice-date aging	Either	Card uses due-date aging to respect terms; an invoice-date aging report ages a Net-60 invoice as if it were due on day one.
Unapplied cash and credits	Card may read lower	Card nets unapplied payments and credit memos against the aged balance where mapped; a gross aging report shows the full invoice.
New-order intersection	Card scopes down	The Sage report shows all aged AR; this card shows only the subset whose customers are also placing new ecom orders. The card total is always a subset.
Order-sync lag	Card may read higher	Card reads new orders directly from the storefront before they sync into Intacct, so it sees exposure a Sage-only view misses.
Disputed invoices	Card may read higher	An invoice formally in dispute still ages; the field map can exclude disputed invoices so they do not inflate the credit-risk read.
Credit-memo timing	Either	A credit memo issued but not yet applied moves the net balance; timing differences between the two pulls show as variance.
Multi-entity netting	Either	A customer with a credit balance in one entity and a debit in another is netted only if consolidated; per-entity reads differ.

Cross-connector reconciliation:

Card	Expected relationship	What the comparison reveals
bigcommerce.orders	New-order source	The B2B portal’s recent orders are the active-order side of the join. The customers placing them, cross-referenced against aged AR, are this card’s rows.
shopify.orders	New-order source	Shopify B2B (companies) orders feed the same join for merchants on that channel.
adobe_commerce.orders	New-order source	Adobe Commerce B2B company orders feed the join; company-to-customer mapping must be clean for the row to attribute correctly.
A/R Aging Detail	Aged-AR source	The Sage aging ledger is the other half of the join. This card is its intersection with active buyers.
Orders on Credit Hold	Action target	The orders you hold as a result of this card show up here. The two cards form the detect-then-act loop.
Customer Credit Utilisation	Limit context	A customer on this card who is also over their credit limit is the highest-priority hold.

The cross-platform high-leverage finding is the entire reason this card exists. Sage holds the truth about who owes you money and how long it has been outstanding. The ecommerce platform holds the truth about who is placing new orders right now. These two facts live in separate systems owned by separate teams with separate incentives, and the compounding credit exposure lives precisely in the gap between them: the sales team books the order, the finance team chases the old invoice, and no single screen ever shows that they are the same customer. This card is that screen. It turns an exposure that is normally discovered at write-off into a decision made before the next order ships. For a B2B merchant it is one of the fastest paybacks in the whole Nerve Centre, and it is where the Vortex IQ Implementation Partner usually starts the credit-control conversation with finance.

Known limitations / merchant FAQs

Why does a customer on Net-60 terms not appear until 60 days past due? Because the card uses due-date aging, not invoice-date aging. A Net-60 invoice is not late until 60 days after it was raised, so the aging clock starts at the due date. This respects the terms you actually granted. If you want the more conservative invoice-date view, the field map can switch, but due-date is correct for assessing genuine lateness.

Does an order on credit hold count as an active order? By default yes, because a customer placing an order into a credit hold is itself a meaningful signal: they are still trying to buy despite the hold. If you only want to see orders that will actually ship, the field map can exclude held orders. Most credit controllers keep them in, because the held-order count tells them how much demand is being suppressed by the hold.

How does the card handle unapplied cash and credit memos? Where the field map allows, the card nets unapplied payments and credit memos against the aged balance, so a customer who has paid but whose cash is not yet applied does not appear falsely aged. A gross Sage aging report shows the full invoice regardless, which is why this card can read lower than a raw aging pull.

What about disputed invoices? A formally disputed invoice still ages and would otherwise inflate the credit-risk read. The field map can exclude invoices flagged as in dispute, so the card focuses on genuinely overdue balances rather than contested ones. Whether to exclude is a policy choice; some controllers want disputes visible because a disputed invoice plus new orders is its own risk profile.

Why is this better than just reading the AR aging report? The AR aging report shows everyone who owes you money, including customers who have stopped trading and are simply slow to pay or in collections. This card narrows to the customers who owe you money and are actively buying more, which is the compounding-exposure cohort. It is a much shorter, much more actionable list, and it adds the new-order context the aging report cannot see.

How does the period comparison help? A snapshot tells you who is exposed today; the 30-day-vs-prior comparison tells you who is getting worse. A customer whose aged AR grew while their new orders also grew is an accelerating risk, and that trajectory is the signal worth acting on before it becomes a write-off. The comparison column is where the controller’s first attention should go.

Multi-currency, how is exposure summed? Aged AR and new-order value are held in the entity base currency and summed to reporting currency at the configured FX cadence. The combined-exposure column is the figure to govern by. Read the per-entity cut alongside the consolidated total, because credit is usually extended per entity and the hold decision is made per entity.

Does this card replace a formal credit-control process? No. It is the detection layer that feeds the process. The card surfaces the at-risk accounts; the controller still applies judgement (distress vs slow-payer), checks the credit limit, and decides hold-versus-ship. Pair it with Customer Credit Utilisation and Orders on Credit Hold to close the loop from detection to action.

Implementation Partner role on this metric? The Partner usually owns the AR aging configuration, the credit-limit and on-hold setup, and the order-sync mapping that lets the card see new orders against the right customer. If a customer’s new orders are not attributing correctly, the cause is almost always a customer-mapping gap between the storefront company account and the Sage customer. Bring the Partner in to confirm the customer mapping; it is the same mapping that drives the absent-customer and VAT-mismatch cards.

---

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 Sage 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 or book a demo to see this metric running on your own data.