At a glance
Count of BigCommerce orders that have been fully refunded in the period, where status = Refunded. This is the order count view of refund activity (the dollar view lives on BC Refund Value). It is one of the few BC dashboard numbers that conflates the financial event (“the customer got their money back”) with the operational event (“the customer returned the goods”). They are not the same thing on BigCommerce, and merchants who mistake one for the other end up either over-restocking inventory they never received back or under-tracking warehouse receipts. This card counts the financial event.
| What it counts | COUNT(orders WHERE status = 'Refunded') over the period. Each refunded order contributes a count of 1 regardless of refund value. Orders with status = 'Partially Refunded' are NOT counted here, they sit on a separate split-view we expose elsewhere; the user-facing “refund count” merchants reach for in BC Control Panel matches this fully refunded definition. |
| VAT / tax treatment | n/a, this is a count metric. The corresponding dollar card (BC Refund Value) is tax-inclusive because it sums refunded_amount, which BC stores at the customer-billed total. |
| Shipping | n/a for the count; included in the value card. BigCommerce does not split refunded shipping from refunded merchandise unless the merchant uses the granular Refunds API; the refunded_amount field on the legacy v2 Order endpoint blends them. |
| Discounts | n/a for count. Discounts on the original order do not affect whether the order counts as refunded; a discounted £40 order that gets fully refunded still increments this card by 1. |
| Refunds | This is the refund population by definition; the question is not “are refunds deducted?” but “what counts as a refund?”. On BigCommerce, refund is the financial event (money returned to the cardholder via the gateway). It is distinct from return (item physically received back into the warehouse), which lives in the RMA / Returns module and is tracked on BC Return Status. A merchant can refund without a return (defective item, customer-keeps-it goodwill) and can receive a return without refunding (store credit, exchange). |
| Cancelled / voided orders | Excluded. status = 'Cancelled' and status = 'Declined' are different states; cancellation is for orders that never shipped, decline is for failed authorisation. Neither contributes to refund count. |
| Currency | Multi-currency without FX. Each currency_code is counted in its native bucket; the headline number is a count and therefore currency-agnostic, but if the merchant clicks through to view value, the figure splits per-currency. Stores using B2B Edition with quote-currencies different from the storefront currency see refunds bucketed in the quote currency, not the channel currency. |
| Channels / sources | All channel_id values aggregate, web (channel_id = 1), POS, Channel Manager (Amazon, Facebook Shop, eBay), B2B portal. Marketplace refunds are particularly worth segmenting: Amazon-side refunds (initiated by Amazon for A-to-Z claims) appear here once Channel Manager syncs them back, with a typical 24-72h lag. |
Incomplete orders | Excluded. An Incomplete order can never become Refunded directly; it would have to pass Awaiting Payment first. |
| Partial refunds | Excluded from this count, surfaced separately. A merchant who issues many partial refunds (typical for damaged-in-transit one-of-three-items scenarios) will find this card understates refund activity; pair with BC Refund Value which captures partial-refund dollar impact. |
| Time window | 30D vsP (rolling 30 days versus prior 30 days). |
| Alert trigger | None on the count itself; a sudden spike in count usually signals either a SKU-level quality failure or a fraud-chargeback wave. The corresponding alert lives on BC Alert Refund Rate Spike. |
| Roles | owner, operations |
Calculation
Worked example
A US-based mid-market home-fragrance brand on BigCommerce Plus, running web (channel_id = 1), Amazon Channel Manager (channel_id = 1019847), and a small B2B Edition portal (channel_id = 1020100). Reporting window 14 Apr 26 to 13 May 26.
| Bucket | Orders placed | Orders refunded (status = Refunded) | Refund count rate |
|---|---|---|---|
| Web (DTC) | 4,820 | 96 | 1.99% |
| Amazon Channel Manager | 1,610 | 134 | 8.32% |
| B2B Edition portal | 88 | 1 | 1.14% |
| Total | 6,518 | 231 | 3.55% |
- Amazon refund count is 4x the web rate. This is normal in absolute terms (Amazon’s A-to-Z claim system makes refunds operationally easier for the buyer than DTC), but 8.32% is at the upper end of healthy. Anything north of 10% on Amazon channel triggers Account Health Reviews; the merchant should cross-reference BC Top Refunded to find the SKUs driving Amazon-specific refunds.
- The B2B Edition single refund is the most expensive one. B2B orders typically have 4-15x DTC AOV, so even one refund moves BC Refund Value materially without moving this count card. Always pair this card with the value card on stores running B2B Edition, otherwise a single £18,000 quote-cancellation refund hides inside an apparent “all clear” count.
- The web 1.99% is healthy. Industry benchmarks for DTC home goods sit at 2-4%; below 2% generally means either great products or under-permissive return policy.
- 231 refunded orders is the operational workload number. Each refund typically takes a customer-service rep 4-8 minutes (longer for marketplace, shorter for self-serve). At a £25/h loaded cost this is roughly £160-£320 in CS labour for the period, before any restocking, shipping-back, or inspection time.
| Bucket | Refund count (this card) | Return count (warehouse RMA log) | Refund-without-return |
|---|---|---|---|
| Web | 96 | 71 | 25 (26%) |
| Amazon | 134 | 22 | 112 (84%) |
| B2B | 1 | 0 | 1 (100%) |
| Total | 231 | 93 | 138 |
- Some are legitimate (damaged-in-transit goodwill, low-value items not worth shipping back, “keep it” customer-service decisions).
- Some are unaccounted (the warehouse received the item but never logged the RMA, the customer kept the item without staff noticing).
- Amazon’s 84% refund-without-return is structurally normal: Amazon’s A-to-Z system frequently refunds the customer without requiring the item back if the dispute hits before a return label is issued. This is BigCommerce’s distinct refund vs return concept in action, and conflating them at the financial level overstates inventory recovery.
- Pull BC Top Refunded to find the offending SKUs. Refund counts cluster on a small number of products in most stores; finding the top three usually accounts for 30-50% of refund volume.
- Cross-reference BC Return Status for the same period to find refund-without-return cases. The gap is the leakage.
- For Amazon-driven refunds, log into Seller Central and review the Voice of the Customer report. It frequently flags the underlying complaint type (defective, wrong item, item not as described) which the BC dashboard does not.
- Watch the trend on BC Refunds Over Time. A flat refund count over 90 days is healthy; a step-change up usually points to either a single bad batch (carrier damage, supplier defect) or a fraud wave.
Sibling cards merchants should reference together
| Card | Why pair it with Refund Count |
|---|---|
| BC Refund Value | The dollar twin. Count is the operational view, value is the finance view. A flat count with rising value means refunds are getting more expensive (higher-value items returning); a rising count with flat value means more low-value goodwill refunds. |
| BC Refund Rate | The denominator-aware version. Count alone is unanchored; rate (count / orders) tells you whether refund volume is structurally rising or just tracking sales growth. |
| BC Refunds Over Time | The time series. Single-number cards can’t distinguish “it was always like this” from “this is new”; the time series can. |
| BC Top Refunded | The product-level breakdown. Refund counts cluster on a tiny minority of SKUs; the top-3 typically explains 30-50% of refund volume. |
| BC Return Status | The operational counterpart. This card is “money returned”; that one is “items received back”. Reconciling them surfaces leakage. |
| BC Channel Refund Rate | The per-channel split. Marketplaces (Amazon especially) have structurally higher refund rates than DTC. |
| BC Refunded Products | SKU-level refund attribution at the line-item rather than order-level granularity. Useful when a multi-item order is partially refunded. |
| BC Alert Refund Rate Spike | The anomaly detector. Watches this card and the rate card for sudden moves. |
| Stripe Refund Value (cross-connector) | When Stripe is the gateway, the dollars should reconcile within ±2% to BC’s refund_value. The count itself may differ because Stripe counts refund transactions while BC counts refund orders. |
| Cancellation Rate | A neighbour metric. Cancellations and refunds together form the “revenue that didn’t stick” universe; tracking both prevents one masking the other. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce’s own dashboard: The closest native view is BigCommerce Control Panel → Orders → View Orders, then filter the Order Status column to Refunded. Set the date range to match the card period and the row count at the bottom of the table is the directly-comparable figure. For a charted view, navigate to Analytics → Orders Report (Plus and Enterprise tiers only). The Orders by Status breakdown breaks the count out by status; the Refunded column matches this card. The Standard tier does not include this report, so Standard merchants should rely on the Orders list filter. For marketplace-specific breakdowns: BigCommerce Control Panel → Channel Manager → (select channel) → Orders. Each channel has its own filterable order list, but the status-filter pattern is the same. Why our number may legitimately differ from the vendor’s:| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | BC Control Panel uses the store’s configured time zone (Settings → Store Profile → Time Zone). Our card uses UTC. For 30-day windows the gap averages out; for “today” or “yesterday” comparisons the cutoff can shift the count by 0-12 orders. |
| Sync lag | Ours lower for last 30 minutes | OpenSearch index materialisation runs every 15-30 minutes via the BC webhook fanout. Refunds processed within the last sync interval are not yet indexed. |
| Partial refunds | Theirs may be higher | Some Control Panel views count Partially Refunded as a refund; our card does not. Cross-check by also filtering for Partially Refunded in the Control Panel. |
| Channel Manager lag | Ours lower for marketplace | Amazon, eBay, Facebook Shop refunds initiated marketplace-side take 24-72 hours to flow into BC via Channel Manager sync. The marketplace’s own dashboard shows the refund instantly; BC and our card lag accordingly. |
| Cancelled-then-refunded edge case | Either | If a merchant cancels and then refunds an order, BC may show status = Cancelled until the refund posts, then flip to Refunded. During the brief window between events the order appears in neither bucket. |
| B2B Edition quote refunds | Either | Quote-based orders on B2B Edition refunded via the quote module sometimes do not flip the order’s status_id immediately. Force-refresh the order in B2B Edition admin if the count looks off. |
| Card | Expected relationship | Notes |
|---|---|---|
stripe.stripe_refund_count | Within ±5% on web channel | Stripe counts refund transactions (one order can have multiple partial refunds = multiple transactions). BC counts refund orders. Gap of 5-15% normal on stores using lots of partial refunds. |
paypal.pp_refund_count | Should equal PayPal-paid refunds only | PayPal-only subset, useful for stores that split traffic between Stripe and PayPal at checkout. |
Known limitations / merchant FAQs
Why doesn’t this card include partial refunds? Because the operational decisions a merchant takes in response to refund count are different for full versus partial refunds. A full refund means the order failed for the customer (wrong product, defective, didn’t arrive); a partial refund usually means a small adjustment (one item of three, missing accessory, shipping refund for delay). Mixing them dilutes both signals. If you need the combined view, use BC Refund Value which captures the dollar impact regardless of full versus partial. My BC Control Panel shows 240 refunded orders but this card shows 231, where are the missing 9? Almost always a time-zone gap or sync lag. BC uses your store time zone (Settings → Store Profile); we use UTC. For a 30-day window the boundary can shift by up to 24 hours of orders. Check the Control Panel on a 31-day or 32-day window centred on your card period and the figures usually reconcile to within 1-2 orders. A customer was refunded but the order still showsAwaiting Fulfillment, why?
This is a BigCommerce data-entry quirk. If the merchant issued the refund via the gateway directly (Stripe Dashboard, PayPal Resolution Centre) without using the BC refund flow, BC’s status field never updates. The financial event happened, but BC doesn’t know. Always issue refunds through the BC Order Refund flow, not gateway-side, otherwise this card will under-count.
How does this differ from the Returns Centre count?
The Returns Centre tracks RMAs (Return Merchandise Authorisation) which are requests to return goods. This card tracks completed financial refunds. A merchant can have 50 RMAs open and 20 completed refunds; only the 20 are on this card. Returns and refunds are not the same lifecycle on BigCommerce; refund is the financial outcome, return is the physical-goods outcome.
Does this include chargebacks?
Yes if the merchant fully refunded the disputed order before the chargeback resolved (treating it as a pre-emptive refund); no if the chargeback was lost and posted directly via the gateway without a BC-side refund flow. For a clean chargeback view, use stripe.stripe_dispute_count or the equivalent gateway card.
My subscription product shows up in this count but it shouldn’t, the customer cancelled, they didn’t refund.
BC’s BigCommerce Subscriptions module historically used status = Refunded for subscription cancellations that issued a pro-rated refund of the unused period. If you see subscription orders here, that’s the cause. Filter them out by tag or product type if the count noise is meaningful.
Why is my Amazon channel refund count 4x higher than web?
Structurally normal. Amazon’s A-to-Z claim system makes refunds operationally easier for the buyer than DTC, and Amazon often refunds without requiring the item back. Industry benchmark for Amazon-channel refund rate sits at 4-9% (versus 1-3% on DTC). Above 10% you should worry about Account Health Reviews; below 4% your listing accuracy is well above average.
Can I export this list to my finance team?
Yes via Ask Viq: “export refunded orders for last 30 days as CSV”. The export includes order_id, customer_id, refunded_amount, refund_date, channel_id, payment_method, currency_code, and reason_code. The reason code is the merchant-entered free-text refund reason from the BC refund flow; it is not standardised.
The number jumped from 60 to 230 last week, what happened?
Three usual causes, in order of likelihood: (1) a fraud wave (one fraudulent gift-card-resale operation can refund hundreds of orders in a day), (2) a SKU-level quality failure (a bad batch with manufacturing defect), or (3) a Channel Manager sync catch-up (marketplace-side refunds backlog flushing through). Pull BC Top Refunded and look at refund concentration by SKU; if it’s one or two SKUs, it’s a quality issue; if it’s evenly distributed across many SKUs, it’s a fraud or sync event.
Does this respect the customer-group filter?
No. The card aggregates across all customer groups; B2B and DTC refunds are summed. Use BC Guest vs Registered and the customer-segment cards if you need the split. B2B Edition refunds are typically much larger in dollars but rarer in count, so the count card understates B2B impact.