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.
| What it counts | The numerator: distinct orders that have any Credit Memo (full or partial) created in the period. The denominator: orders created in the period. The window aligns the order-creation date with the Credit Memo creation date, this is the “in-period refund rate”, not the cohort refund rate (orders created this month, refunded later, would not be reflected here until they are refunded). |
| API field | Numerator from GET /rest/V1/creditmemos joined to orders by order_id. Denominator from GET /rest/V1/orders filtered on created_at. |
| VAT / tax treatment | n/a, the card is a count ratio, not a value ratio. For value-weighted refund rate (SUM(creditmemo.grand_total) ÷ SUM(orders.grand_total)) use the value variant available in custom dashboards. |
| Shipping | n/a for the rate. Shipping-only Credit Memos count as “an order with a Credit Memo” so they push the rate up; merchants tracking product-only refund rate should configure a manifest filter to exclude subtotal=0 Credit Memos. |
| Discounts | n/a. |
| Cancelled orders | Included in the denominator, excluded from the numerator. A canceled order has no Credit Memo (cancellation reverses pre-capture authorisation) so it is in the order count but never in the refund count. This drags the rate slightly down compared to a denominator of “captured orders only”. For a captured-orders-only rate, exclude state=canceled from the denominator via manifest tweak. |
| Partial refunds | Each refunded order counts once in the numerator regardless of how many Credit Memos it has. So an order with 3 Credit Memos contributes 1 to the numerator (and 1 to the denominator). Use Refund Count for the document-count perspective. |
| State filter | All state values included in the denominator: new, pending_payment, processing, complete, closed, canceled, holded, payment_review. The numerator naturally excludes pending_payment, payment_review, and canceled because Credit Memos cannot be issued on those states. |
| Currency / multi-store | The rate is unitless. All Store Views aggregated by default; Store View slicing available. |
| Time window | 30D vsP, rolling 30-day with prior-period comparison. |
| Alert trigger | >5% absolute or +25% vs prior period. The 5% absolute threshold is a soft DTC norm; B2B-heavy merchants should override to 2%. |
| Sentiment key | refund_rate |
| Roles | owner, operations |
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:| Slice | Orders created | Distinct orders with any Credit Memo | Refund rate |
|---|---|---|---|
| All orders | 4,820 | 358 | 7.43% |
| DTC orders only (non-B2B Customer Group) | 4,512 | 341 | 7.56% |
| B2B orders (Adobe Commerce Companies) | 308 | 17 | 5.52% |
Excluding canceled from denominator | 4,684 (canceled = 136) | 358 | 7.65% |
| Window | Refund rate | Threshold (5%) | Threshold (+25% vsP) |
|---|---|---|---|
| 14 Apr to 13 May 26 | 7.43% | breached | (vs prior 4.78%, +55%, breached) |
| 15 Mar to 13 Apr 26 | 4.78% | clean | - |
| Sentiment | degraded | both alert conditions tripped |
- 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
| Card | Why pair it with Refund Rate |
|---|---|
| Refund Count | The numerator. Spike in count without rate-change suggests order volume rose proportionally (no problem). |
| Refund Value | Money out the door. Value-weighted view of the same trend. |
| Refunds Over Time | Day-by-day shape of the rate. |
| Top Refunded Products | The SKU concentration. Often 5 SKUs drive 50%+ of the rate. |
| Cancellation Rate | Pre-capture cancellations. Different problem (payment failure, fraud rejection, wrong-shipping-address rejection) but related signal. |
| Total Orders | The denominator. Slowing order volume can spike the rate even with stable refund volume. |
| Return Status | RMA pipeline. Approved RMAs are the next month’s refunds. |
shopify.refund_rate | Shopify peer for cross-platform agencies. |
stripe.stripe_refund_rate | Payment-side rate. Should approximately match for Stripe-paid orders. |
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.
| Reason | Direction of divergence |
|---|---|
| Time-zone. Admin grids run in Store View locale; this card runs UTC. Orders and Credit Memos at day-edges shift between days. | ±1 day at edges |
| Cohort vs in-period framing. This card divides “orders with Credit Memos in the period” by “orders created in the period”. A merchant manually computing might use “orders refunded in period / all-time orders refunded ever” which is a different ratio. | Material divergence |
Canceled in denominator. This card includes canceled orders in the denominator by default. Some merchants prefer captured-only. The card output toggles via manifest. | Vortex IQ rate slightly lower than captured-only view |
| Reports indexer lag. The Reports module reads from the nightly-refreshed aggregated table. This card reads live OpenSearch (5-15 min behind). | This card more current |
| Distinct-order vs document-count. This card counts distinct refunded orders. A merchant counting Credit Memos directly will get a higher numerator (multi-memo orders) and an inflated rate. | Merchant manual rate higher |
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.