At a glance
The percentage of orders in the period that have at least one Credit Memo against them. Defined as COUNT(DISTINCT order_id WITH any Credit Memo created in the period) ÷ COUNT(orders created in the period) × 100. Industry-typical for Adobe Commerce merchants is 2-6% in apparel, 0.5-2% in B2B/wholesale, 5-12% in returns-friendly DTC verticals.
Calculation
Worked example
A B2B+DTC apparel merchant on Adobe Commerce 2.4.7. Period: 14 Apr 26 to 13 May 26. Order and refund counts:
Comparison to prior 30 days:
What this is telling Operations:
- Both alerts fire. Absolute rate (7.43%) is above the 5% threshold and the period-over-period jump (+55%) is well past the 25% relative threshold. This is not noise; it is a structural change.
- B2B refund rate jumped from 1.8% to 5.52%. B2B normally runs <2%; a 3x increase is the dominant signal. Cross-link with the Refund Value example: 12 B2B accounts returned bulk uniform-line shipments due to supplier sizing error.
- DTC rate also rose from 4.95% to 7.56%. Smaller relative jump but on a larger base; absolute volume growth in returns is mostly DTC.
- Canceled-excluded view (7.65%) is the more honest figure for ops because it removes orders that never got captured. Most “refund rate benchmarks” in industry reports use this version. Use it when comparing to peers.
- The dashboard’s “Reports > Sales > Refunds” report shows £46,220 / £950,000 = 4.86% (value-weighted). The refund rate by count (7.43%) is higher than by value (4.86%), meaning refunded orders skew lower-value than the order-set average. That makes sense: low-AOV DTC apparel returns more frequently than high-AOV B2B shipments. Both numbers are correct, they answer different questions.
- Action: investigate the supplier sizing issue immediately (highest-impact lever), and dig into Top Refunded Products to see whether the elevated DTC rate concentrates on the same uniform line or is broader.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin: Adobe Commerce does not expose refund rate as a single Admin number; it must be derived. The closest views:Reports > Sales > Refunds divided by Reports > Sales > Orders for the same period gives the value-weighted equivalent (which is not the same as this card’s count-weighted rate). Use this for sanity-checking the order-of-magnitude only.For count-weighted reconciliation:
Sales > Operations > Credit Memos, count distinctWhy our number may legitimately differ from a manual Admin computation:Order #column values for the period. Then Sales > Orders withPurchase Dateset to the same period, count rows. Divide. This matches this card to within sync-lag.
Internal identity (within Adobe Commerce):
refund_rate = COUNT(DISTINCT order_id WITH any Credit Memo) ÷ COUNT(orders) × 100
The legacy stub formula refund_count ÷ order_count is approximate, it equals the true rate only when every refunded order has exactly one Credit Memo. Real merchants average 1.05-1.20 Credit Memos per refunded order, so the legacy formula over-states by 5-20%. The card uses the distinct-order numerator.
Component cards (self-consistency, not reconciliation):
Known limitations / merchant FAQs
Why is my refund rate by count higher than by value? Refunded orders typically skew lower-AOV than the order-set average. A high-AOV B2B order is rarely returned; a low-AOV DTC apparel order is. So count-weighted rate is structurally higher than value-weighted rate for most merchants. This card uses count by default; the value-weighted variant is available in custom dashboards. My refund rate looks reasonable but my Reports > Sales > Refunds value is alarming, why? Two different lenses. A few high-AOV refunds drive value without moving the count-rate much. Look at average refund value (Refund Value ÷ Refund Count) to see if you have a “few whales” pattern.
Should canceled orders be in the denominator?
Depends on your business model. Cards default to including them because canceled-and-refunded orders are operationally similar (the customer didn’t get the goods). For pure-product return rate, exclude canceled via manifest. Note that “canceled before capture” cannot have a Credit Memo so they only push the denominator up, not the numerator.
The 5% threshold doesn’t fit my B2B merchant, can I customise?
Yes. The threshold is per-tenant configurable. B2B should typically run at 1.5-2% threshold; high-fashion DTC at 8-10%. The +25% relative threshold is more universally useful since it triggers on directional change regardless of base level.
Why is the rate higher than stripe.stripe_refund_rate?
Two reasons: (1) some refunds are issued via PayPal or manual bank transfer, never touching Stripe, but still in this card’s numerator; (2) Stripe’s rate denominator includes only Stripe-paid orders, this card’s includes all orders, the proportions differ if Stripe is not 100% of payment. To compare like-for-like, filter this card to Stripe-paid orders only.
Today’s value swung from 4.2% to 6.1% in one hour, is that real?
On low-volume stores (under 200 orders/day), one-hour numbers are noisy. A single batch of Credit Memos posted by Customer Service can spike the rate. The 30-day rolling smooths this. If your store is high-volume (over 1,000 orders/day) and you see hourly swings, that is real and worth investigating.
Multi-currency, does the rate differ across currencies?
The count-weighted rate is currency-agnostic. The value-weighted rate is sensitive to FX since grand_total is mixed-currency; use base_grand_total for FX-neutral comparison.
A canceled order is in the denominator. Doesn’t that artificially lower the refund rate?
It lowers it slightly because the numerator excludes canceled orders (no Credit Memo possible). For most merchants the cancellation rate is 1-3%, so the dilution is small. If your store has cancellation rate above 8% (often a payment-fraud or stock-out problem), exclude canceled from the denominator for a cleaner refund rate, then track Cancellation Rate separately.
My refund rate dropped to 0% on Sunday, why?
Customer Service teams typically don’t process refunds on weekends. The numerator is zero on those days, but the denominator (orders created) is non-zero. The rate dips, then catches up Monday-Tuesday as the weekend’s RMAs get processed. Use 7-day rolling rather than daily to avoid the weekly weekend dip.