At a glance
Total dollar value of refunds issued in the period, summed from refunded_amount across all orders where some refund activity has occurred. This is the finance view of refund activity, the number a CFO would want to see on a P&L. It is the dollar twin of BC Refund Count, and the pair must be read together: count tells you operational workload, value tells you margin damage.
Calculation
Worked example
A UK-based premium beauty brand on BigCommerce Enterprise running web (channel_id = 1), Amazon UK (channel_id = 1019847), and a small B2B Edition portal. Reporting window 14 Apr 26 to 13 May 26. All figures GBP, tax-inclusive at 20% VAT.
What’s interesting:
- The single B2B refund (£18,400) is 63% of the total refund value while contributing 0.4% of the count. Refund value is dominated by tail events on stores with B2B Edition exposure. Reading BC Refund Count alone you’d never see this; reading the value card alone you’d misread it as a systemic crisis when it’s actually one quote-cancellation. Always read count and value together.
- Web and Amazon average refund sizes are nearly identical (~£46) despite 4x difference in count rate, suggesting refunds cluster on the same SKUs across channels. Cross-reference BC Top Refunded to confirm; usually the same 5-10 SKUs explain 30-50% of refund value in both channels.
- Refund value as % of revenue is the trustworthy KPI, not absolute value. 1.7% on web is healthy for premium beauty; 8.1% on Amazon is at the upper edge of healthy (Amazon’s claim system structurally increases this); 12.4% on B2B is a single-quote artefact and not actionable as a metric. The headline “4.2% blended” hides all three signals.
- Margin damage is much larger than refund value. A £29,000 refund on a 60% gross margin product line means £17,400 of lost gross profit plus the refund-processing labour cost (~4-8 mins per refund × 231 = roughly 20-30 hours of CS time) plus return-shipping cost where applicable plus inventory write-off for damaged returns. The total cost of refunds is typically 1.5-2x the refund value figure.
- Investigate the B2B refund before any DTC analysis. Was it a legitimate cancellation, a quote-rebid, or a customer-service failure? B2B refunds at this scale should never be invisible to the owner.
- Pull BC Top Refunded for the period to find the SKU concentration. Reduce or relist the worst offenders; even a 20% reduction in their refund rate clears 5% of total refund value.
- Set up BC Alert Refund Rate Spike with a 50% week-over-week threshold. Refund-value spikes usually precede inventory issues by 7-14 days; early detection saves margin.
- Reconcile against Stripe Refund Value if Stripe is the gateway. The two should match within ±2% on the web slice. Larger gaps mean either gateway-side refunds bypassing BC’s refund flow, or BC refunds via a non-Stripe gateway (Klarna, Afterpay etc.) that don’t reach Stripe.
- Forecast quarterly refund liability by extrapolating: £29,000 / 30 days = ~£966/day average → ~£87,000 per quarter. Use this as the refund reserve in the finance plan; understatement here is a common cause of cash-flow surprises.
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 → Analytics → Insights (Plus and Enterprise tiers) where the Refunds card on the dashboard tile gives a 30-day refund-value figure. For per-order detail, Orders → View Orders, filter to Refunded and Partially Refunded statuses, and the Total Refunded column footer sums to the comparable figure. For finance reconciliation, the most authoritative BC view is the Store Credits + Refunds export: Settings → Data Solutions → Export → Orders. The CSV contains arefunded_amount column you can sum in spreadsheet for an audit-trail figure.
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/sessions/transactions through different lenses. Numbers should agree within tracking-gap accuracy. Divergence is a data-quality signal worth investigating.
Known limitations / merchant FAQs
Why is refund value so much higher than refund count × average order value? Two reasons. First, partial refunds inflate value without inflating count (a £30 partial refund on a £150 order adds £30 to value, 0 to count). Second, refunds disproportionately cluster on higher-value orders (customers refund expensive items more often than cheap ones, partly because they pay closer attention to expensive purchases). The “average refund” calculation is structurally biased upward versus the all-orders AOV. Does this include shipping refunds? Yes if you used BC’s refund flow with the shipping-refund toggle on. Therefunded_amount field aggregates merchandise + shipping + tax + handling. If you want to isolate shipping-only refunds, use the granular Refunds API or the BC Total Shipping card with status filters.
Why is my Stripe refund value 8% higher than this card?
Almost always because some refunds were issued in Stripe Dashboard directly (during chargeback handling or fraud disputes) without using BC’s refund flow. Stripe sees them; BC doesn’t. Train customer service to refund through BC, never gateway-side, otherwise this card under-reports refund value.
Are chargebacks included?
If the chargeback was processed through a BC refund flow (you refunded preemptively to avoid the dispute), yes. If the chargeback was lost and the bank pulled funds directly via the gateway without BC awareness, no. Chargebacks are a major reconciliation gap; use stripe.stripe_dispute_value for the authoritative figure.
Why is the B2B Edition refund showing in this card but not in the line-item breakdown?
B2B Edition’s quote-flow refunds sometimes don’t propagate the line-item detail back to the underlying order; they show as a single lump-sum refund against the order_id. The aggregate value lands here correctly, but BC Refunded Products may be blank for that order. Check the B2B Edition quote module directly for line-item refund detail.
Should I treat this number as my refund liability for finance?
No, treat the trailing 90-day figure (visible on BC Refunds Over Time) divided by 3 as your monthly run-rate refund liability. Single 30-day windows can be skewed by tail events (single B2B refunds, fraud waves, batch defects). Finance teams typically use a 90-day moving average for refund reserves.
My refund value spiked 200% this period, what should I check first?
In order: (1) one big B2B refund (check Recent Activity for any single refund >£10k), (2) a single-SKU defect batch (pull BC Top Refunded), (3) a fraud wave (look for refund clustering on similar customer profiles, similar payment methods, similar IP ranges), (4) a Channel Manager catchup flushing through marketplace-side refunds in bulk.
Does this number include refunded gift card purchases?
Yes. Gift card purchases that get refunded contribute to this card normally. If you want gift-card refunds isolated, filter by product type in Ask Viq.
The number changes when I switch currencies, why?
Because we store refund value per native currency without FX conversion. Switching the display currency in the UI just relabels the numbers; for stores trading in 3+ currencies, no single number is meaningful. Use BC Channel Currency Mix to understand the true currency exposure of refund liability.
Why is the value going up while count is flat?
Average refund size is rising. Three usual causes: (1) a shift in product mix toward higher-priced items, (2) an increase in partial-refund-as-customer-service practice (more shipping refunds, more partial-discount-as-apology refunds), (3) a single recurring high-value customer or B2B account starting to refund regularly. Pull BC Top Refunded to confirm which.
Can I get this card scoped to a single product / SKU?
Yes via Ask Viq: “what is the refund value for SKU XYZ-123 over the last 90 days?”. The underlying index supports SKU-level filtering on the refund line items where available; for partial refunds without line-item detail (B2B quote refunds typically), the SKU filter may exclude them.
Is this the gross refund or net of restocking fees?
Gross. BC’s refunded_amount is the dollar-out figure to the customer; if the merchant deducted a restocking fee, the customer received less and so this number is net of that. The customer-cash-out event is what we report. The restocking-fee revenue lives elsewhere on the order as handling_cost or in custom fields.