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.
| What it counts | SUM(refunded_amount) WHERE refunded_amount > 0. Includes both fully refunded (status = Refunded) and partially refunded (status = Partially Refunded) orders. Each order contributes the sum of all refund events posted against it. |
| VAT / tax treatment | Tax-inclusive. BC’s refunded_amount is the customer-billed total returned, including any VAT / sales tax that was originally collected. For an ex-tax view, divide by (1 + average_tax_rate); the platform does not store the tax-portion of refund separately on the legacy v2 endpoint. |
| Shipping | Included if the merchant refunded shipping. BC’s refund flow lets the merchant choose to refund shipping or not; the resulting refunded_amount rolls subtotal + shipping + tax + handling into a single number. To see refunded-shipping separately, use the granular Refunds API or pair this card with BC Shipping Methods. |
| Discounts | Discounts on the original order do not change the refund value; what was paid is what gets refunded. A £100 order with a £20 discount that was refunded shows £80 here, matching the customer-paid amount. |
| Refunds | This card is the refund metric. The financial event of money returned. Distinct from physical returns, which are tracked on BC Return Status. On BigCommerce, refund and return are different lifecycle events that need not coincide. |
| Cancelled / voided orders | Excluded. Cancelled orders do not generate a refunded_amount; the customer was never charged. Declined is similar. Both contribute zero to this card. |
| Currency | Multi-currency without FX. Each refund stays in its currency_code bucket. The headline figure on the card uses the merchant’s display currency or the dominant currency in the period; stores with three-or-more-currency exposure should pair with BC Channel Currency Mix for clarity. |
| Channels / sources | All channel_id values aggregate. Marketplace refunds (Amazon Channel Manager especially) appear here once Channel Manager syncs them; expect 24-72h lag versus the marketplace-side dashboard. |
| Partial refunds | Included, unlike BC Refund Count. A £150 order with a £30 partial refund contributes £30 to this card and 0 to the count card (because the order’s status is still Partially Refunded, not Refunded). This intentional asymmetry is why the two cards do not divide cleanly into an average refund size; use BC Refund Rate for that. |
| Time window | 30D vsP (rolling 30 days versus prior 30 days). |
| Alert trigger | None directly on the value; the rate-spike alert fires off BC Alert Refund Rate Spike. |
| Roles | owner, operations |
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.
| Bucket | Refund count | Refund value (£) | Average refund | Refund value as % of revenue |
|---|---|---|---|---|
| Web (DTC) | 96 | £4,420 | £46.04 | 1.7% |
| Amazon UK | 134 | £6,180 | £46.12 | 8.1% |
| B2B Edition | 1 | £18,400 | £18,400 | 12.4% |
| Total | 231 | £29,000 | £125.54 | 4.2% |
- 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
| Card | Why pair it with Refund Value |
|---|---|
| BC Refund Count | Mathematical twin. Value alone is dominated by tail events; count alone is dominated by low-value goodwill refunds. Read together. |
| BC Refund Rate | Denominator-aware version. Refund value rising in absolute terms might just be revenue rising; rate strips out the growth artefact. |
| BC Refunds Over Time | The time-series view. A £30,000 refund value on a stable trend is normal; the same value as a step-change is investigative. |
| BC Top Refunded | Product-level attribution. Most refund value clusters on a small SKU set; finding the top three is the highest-leverage action. |
| BC Return Status | The physical-goods counterpart. Reconciling refund-value vs return-units finds the goods you paid back for but never received. |
| BC Channel Refund Rate | Per-channel split. Marketplace refunds (especially Amazon) skew this card high. |
| Total Revenue | The denominator for refund-as-% calculations. Always interpret refund value as a percentage of revenue, not in absolute. |
| BC Alert Refund Rate Spike | Anomaly detector. Watches the rate to fire before this card’s number gets scary. |
| Stripe Refund Value | Cross-connector reconciliation. Should match within ±2% on Stripe-paid orders. |
| PayPal Refund Value | Same idea for PayPal-paid orders. |
| BC Refunded Products | Line-item attribution for the partial-refund scenarios this card aggregates. |
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:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | BC uses store time zone; we use UTC. For 30-day windows this averages out within ±1%. |
| Sync lag | Ours lower for last 30 minutes | OpenSearch index refreshes every 15-30 min via webhook; the most recent refunds are not yet visible. |
| Multi-currency without FX | Either | Our card sums per-currency without conversion; BC Insights converts to display currency at a daily-average FX rate. Discrepancies of ±0.5-2% are normal on multi-currency stores. |
| Partial refunds | Either | Some BC reports show only fully-refunded orders; ours includes partials. If BC’s number is meaningfully lower, this is the cause. |
| Channel Manager lag | Ours lower for marketplace | Amazon and eBay refunds initiated marketplace-side take 24-72h to flow into BC. The marketplace dashboard shows refunds instantly; we lag accordingly. |
| Refund issued via gateway only | Theirs lower | If a merchant refunds via Stripe Dashboard / PayPal Resolution Centre without going through BC’s refund flow, BC never updates refunded_amount. The gateway has the event; BC and we do not. This is the #1 reconciliation gap on stores using mixed-channel refund processing. |
| B2B Edition quote refunds | Either | Quote-cancellation refunds don’t always update refunded_amount on the underlying order until the next quote sync. |
| Currency rounding | Trivial | BC stores refunded_amount as decimal-string; some exports round to 2dp, others to 4dp. Cumulative rounding can shift totals by pennies on high-volume stores. |
| Card | Expected relationship | Notes |
|---|---|---|
stripe.stripe_refund_value | Should match within ±2% on Stripe-paid orders | Treat Stripe as authoritative for the cash-out event; treat BC as authoritative for the order-state event. Persistent gaps >5% mean refunds are happening gateway-side without BC awareness, fix the workflow. |
paypal.pp_refund_value | Should match within ±2% on PayPal-paid orders | Same logic. PayPal Resolution Centre refunds frequently bypass BC; train CS to use BC’s refund flow. |
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.