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.
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.
What the merchant should immediately notice:
- 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.
The 138 refunds without a corresponding return are the merchant’s leakage:
- 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
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:
Cross-connector reconciliation (when both connectors are connected for this merchant):
These connectors view the same orders/transactions through different lenses. Counts should agree within tracking-gap accuracy. Divergence is a data-quality signal worth investigating.
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.