Skip to main content
Card class: HeroCategory: Ecommerce Platform
First canary on a quality issue or deploy regression.

At a glance

Share of Salesforce Commerce Cloud orders that produced a Return or Credit Memo in the period. Computed as COUNT(orders with refund) ÷ COUNT(orders). The first canary on a quality regression, sizing issue, or deploy defect. Pair with the value-weighted view in finance reporting.
What it countsCOUNT(orders WHERE has_return = true OR has_credit_memo = true) ÷ COUNT(orders). An order with either a Return record (physical goods inspected) or a Credit Memo (financial refund issued) increments the numerator once. Both states together still count once per order.
VAT / tax treatmentn/a, this is an order-count ratio. The value-weighted refund-rate companion card is VAT-inclusive.
Shippingn/a, ratio metric.
Discountsn/a, ratio metric.
RefundsThis card measures refunds. The numerator is “orders with at least one refund event in the window”.
Cancelled / voided ordersCancellations before fulfilment that produce only a Credit Memo (no physical Return) are counted. CANCELLED orders without a Credit Memo are not counted (no money was taken).
Partial refundsCounted. An order with a £20 partial refund on a £200 order increments the numerator the same as a fully-refunded order. The value-weighted view (refund_value ÷ order_total) is the right tool for the magnitude side.
Currencyn/a for the count. The denominator pools orders across every currency / locale on the realm.
Channels / sourcesMulti-site by design. B2B trade portals (typical 0.3 to 1.5% refund rate) and DTC fashion sites (typical 8 to 25%) pool together. Per-site filtering is the right operational view; the realm headline is dominated by the highest-volume site.
Window basisThe numerator counts orders whose refund event fell in the period. The denominator counts orders whose confirmation date fell in the period. This means the rate is slightly lagging: refunds requested 30 days after a Christmas-season order count against a different window than the order itself.
Time window30D vsP (default 30 days vs prior 30 days)
Alert trigger>5% (cross-category default), driven by sentiment_key: refund_rate. Tune to >15% for fashion DTC, >1.5% for B2B portals.
Rolesowner, operations, finance

Calculation

Calculated automatically from your Salesforce Commerce 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 Fortune-500 fashion retailer running on Salesforce Commerce Cloud. Window covers 14 Mar 26 to 12 Apr 26.
siteIdSiteOrdersOrders with refundRefund Ratevs prior 30D
RefArch-USUS DTC apparel184,20022,46012.2%11.8% (up 0.4pp)
RefArch-UKUK DTC apparel62,4009,08014.6%13.9% (up 0.7pp)
RefArch-DEDE DTC apparel41,8007,44017.8%17.4% (up 0.4pp)
RefArch-JPJP DTC apparel28,6001,9406.8%6.5% (flat)
RefArch-B2BB2B trade portal1,420181.3%1.2% (flat)
Headless-SubbrandSub-brand on SCAPI12,8001,92015.0%12.4% (up 2.6pp)
Realm-wide (volume-weighted)331,22042,85812.9%12.4%
What’s interesting:
  1. The headless sub-brand jumped 2.6pp in 30 days. That is the actionable signal. Three usual culprits in order. (a) Quality issue on a launch SKU: check Top Products for any new SKU with refund rate >3× category average. (b) Sizing/fit issue, common when a buyer-marketing change brings new customers who don’t know the brand’s fit; size-guide updates and PDP video typically cut this within 4 to 8 weeks. (c) A deploy regression, SFCC deploys via Code Replication often take effect at 02:00 UTC; if the inflection landed on a specific Wednesday, look at the Tuesday release.
  2. DE refund rate (17.8%) is structurally high. German consumers exercise statutory return rights more aggressively than US or UK, and DE apparel sites typically run 16 to 22% refund rates. Per-site thresholds matter, the >5% cross-category default would alert daily on a healthy DE site. Tune the alert to >20% for DE apparel.
  3. JP refund rate (6.8%) is structurally low. Japanese consumers return at much lower rates (typical 3 to 7% across categories) due to cultural and shipping-cost reasons. A JP refund rate climbing to 10% would be a serious signal that gets lost in the realm-wide reading.
  4. B2B refund rate (1.3%) is normal for trade portals. Trade orders are mostly buying-team-vetted, scheduled, and often non-returnable by contract. The 18 B2B refunds are likely either damaged-in-transit or order-error replacements. A B2B refund rate above 2% would point to a process failure (wrong SKUs shipped, mis-priced contracts).
  5. Realm-wide refund rate (12.9%) is up 0.5pp vs prior period. The card alerts when the realm-wide rate crosses >5%, which it always does on this fashion realm; per-site alerts with category-tuned thresholds are the right layer for this kind of merchant. The prior-period delta is the real signal.

Sibling cards merchants should reference together

CardWhy pair it with Refund Rate
Total RevenueThe denominator. Refund Rate climbs are only meaningful in the context of the revenue base; a 1pp move on a 300Mrealmisadifferentoperationalimpactfroma1ppmoveona300M realm is a different operational impact from a 1pp move on a 3M one.
Total OrdersThe order-count denominator. Useful for the value-vs-count distinction.
Top ProductsThe product-level decomposition. Most refund spikes trace to one or two SKUs. Filter to category x site and look for outliers.
Out-of-Stock ProductsA counter-intuitive pair: when OOS spikes, customers buy back-up SKUs they end up returning. OOS-driven refund rate is real.
New CustomersFirst-time buyers refund 1.5 to 2× as often as returners. A new-customer surge mechanically lifts refund rate.
Conversion RateReturns-policy tightening cuts refund rate in the short term but can cut conversion rate in the medium term, watch the pair.
Repeat Customer RateRefunded customers are 30 to 50% less likely to repeat-purchase. Refund rate is a leading indicator of repeat-rate erosion.
adobe_commerce.refund_rateClosest enterprise-tier peer. Documentation cross-link only.

Reconciling against the vendor’s own dashboard

Where to look in Business Manager: SFCC’s admin tool is Business Manager at https://<realm>.business.demandware.net. The closest like-for-like view is Merchant Tools, Site, Reports & Dashboards, Returns for any single site. Set the same date range, ensure status filter includes both Returns and Credit Memos (BM may default to Returns only), and look at the Return Rate column. The cross-site rollup view is Reports & Dashboards, Operations which weights by orders. Other Business Manager views that look like the same number but aren’t:
  • Reports & Dashboards, Returns by Reason: lists return reasons, useful for diagnosis but is not a rate.
  • Order Search, filtered to “has return”: counts orders matching a filter, can be used to hand-compute the rate.
  • Einstein returns dashboard: refund rate within the Einstein-personalised audience, narrower than this card.
Why our number may legitimately differ from Business Manager:
ReasonDirectionWhy
Order-count vs value-weighted. BM’s standard report is value-weighted (refund_value ÷ revenue); this card is order-count. The two move in similar directions but rarely match exactly.Either, drift can be 1 to 3ppUse BM’s value-weighted view to reconcile against finance reports.
Returns vs Credit Memos. BM may filter by Return only, omitting cancellation-refunds (Credit-Memo-only with no physical return). This card pools both.Vortex IQ higherSet BM to include Credit Memos.
Site filter scope. BM defaults to one site; Vortex IQ aggregates the realm unless filtered.Direction depends on per-site mixUse per-site filtering to compare apples-to-apples.
Window anchor. BM’s “Return Rate” can anchor on order date OR refund date depending on the report. Vortex IQ anchors on refund date for the numerator and confirmation date for the denominator (a slight lag).Either, drift small except after spikesThe ratio differs most after a refund-spike week.
Time-zone. BM uses site time zone; Vortex IQ runs on UTC.Boundary days offAverages out for 30-day windows.
Partial-refund threshold. Some BM reports filter out refunds below a $-amount threshold (“administrative noise”); Vortex IQ counts every refund event.Vortex IQ slightly higherThe administrative threshold is a finance preference, not a quality gate.
Internal identity (within SFCC): This card is order-count weighted. The companion value-weighted view is sfcc.refund_value ÷ sfcc.total_revenue (separate card, when added). The two should track within ~1pp on most realms; a divergence of >3pp means refunds are concentrated on either high-AOV or low-AOV orders disproportionately. Cross-connector reconciliation:
CardExpected relationshipWhat causes legitimate divergence
stripe.stripe_refund_rateStripe refund rate ≤ SFCC refund rate (Stripe sees only refunds processed back through Stripe)If the merchant uses multiple PSPs, each PSP sees only its own refunds. SFCC’s refund rate is the realm-wide truth; PSP rates are slices.
cybersource.cybersource_refund_rateSame shapeCommon SFCC PSP, expect a substantial overlap on enterprise realms.
Net of all PSPs: if you sum CyberSource refunds + Adyen refunds + PayPal refunds + Worldpay refunds, the total should sit close to this card’s numerator. A persistent gap > 5% means a PSP is missing or a manual / store-credit refund channel is bypassing the PSPs entirely.

Known limitations / merchant FAQs

Why is my refund rate climbing this month? Three usual root causes in order of likelihood. (1) Quality issue on a recently-launched SKU. Check Top Products by Revenue for new entries; any SKU with refund rate >3x its category average is the smoking gun. (2) Sizing or fit issue, common in apparel. Returns spike when a buyer-marketing change brings in customers unfamiliar with the brand’s fit; size-guide updates and PDP video typically cut this within 4 to 8 weeks. (3) Deploy-related defect. Check the deploy / release log against the inflection point. SFCC deploys via Code Replication often take effect at 02:00 UTC; if rate jumped on a Wednesday-09:00 read, look at Tuesday’s deploy. Does this card include B2B refunds? Yes. SFCC stores B2B and DTC returns in the same Return and CreditMemo objects on the order; the card sums both. B2B refund rates are typically much lower than DTC (sub-1% vs 8 to 25% for fashion DTC) so they pull the realm rate down. If you want the DTC-only view, filter out the B2B siteIds. Why doesn’t the gross Total Revenue card move when refund rate spikes? By design. Total Revenue is gross (sum of order_total at original confirmation); refunds live on separate Return / Credit Memo objects and do not retroactively edit the original order. This card and Total Revenue measure two different layers, both useful: Total Revenue tells you “what we sold”, this card tells you “how much we kept”. The unrendered “net revenue” view is on the connector roadmap. Is the rate computed by order count or by refund value? By order count for this card: count(orders with at least one return) / count(orders). The companion value-weighted view (refund_value / order_total) is a separate card. Order-count rate is the right read for product-quality and CX-team operations; value-weighted rate is the right read for finance. SFCC has both Returns and Credit Memos in its data model. Which counts? Both, an order with either a Return or a Credit Memo (or both) increments the numerator. The two are different SFCC concepts: a Return tracks the physical goods (received, inspected, restocked); a Credit Memo tracks the financial event (refund issued, store credit issued, partial). Most customer-facing refunds produce both. Order-cancellations before fulfillment often produce only a Credit Memo with no Return. The card pools them. Why does Business Manager show a different refund rate? Three reasons. (1) Order-count vs value-weighted. BM’s standard report is value-weighted; this card is order-count. (2) Site-scope. BM defaults to one site; this card aggregates the realm. (3) Window. BM “Last 30 days” is rolling; some BM dashboards show fiscal-month-to-date. Confirm the window is identical before comparing. What is a “good” refund rate on SFCC? Wildly category-dependent. Useful benchmarks. (1) B2B trade portals typically 0.3 to 1.5%. (2) DTC fashion / apparel typically 8 to 25% (peak return season is post-Christmas through January). (3) DTC beauty / health / supplements typically 1.5 to 4%. (4) DTC electronics / accessories typically 4 to 10%. The >5% alert threshold is a reasonable cross-category default; tune per-site for fashion realms. My refund rate dropped suddenly. Could that be bad? Yes, more often than merchants expect. Two suspicious patterns. (1) A returns-portal outage stops customers requesting refunds; CS tickets spike a week later when the backlog clears. Check returns-portal uptime and CS ticket volume for the same week. (2) A returns-policy tightening (e.g. dropping free returns, shortening the window) cuts refund rate in the short term but can cut conversion rate at checkout in the medium term. Pair this card with Conversion Rate over a 90-day window after any policy change. How does refund rate flow into the customer LTV calculation? Net revenue per cohort drives LTV; refund rate sets the gap between gross revenue (this card’s complement) and net revenue. A 1 percentage-point reduction in refund rate at a 10% gross rate is worth roughly 11% of refunded revenue back to LTV (depending on how the cohort is bucketed). This is why refund-rate work pays back faster than acquisition work on most fashion DTC realms.

Tracked live in Vortex IQ Nerve Centre

Refund Rate is one of hundreds of KPI pulses Vortex IQ tracks across Salesforce Commerce 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 or book a demo to see this metric running on your own data.