At a glance
Daily time-series of refund value (and an overlay of refund count) over the rolling 90-day window. The chart that turns “we refunded £29k this month” into “and £18k of it was on three days, and those days correlate with a single SKU release”. This is the diagnostic card refund-investigation always starts on; the single-number cards (BC Refund Count, BC Refund Value) tell you the magnitude, this card tells you the shape.
| What it counts | SUM(refunded_amount) GROUP BY DATE(refund_date) plus a count overlay per day. Bucketed daily by default; toggleable to weekly for stores with low refund volume where daily resolution is too noisy. |
| VAT / tax treatment | Tax-inclusive. Same refunded_amount field that powers BC Refund Value, so tax-treatment is consistent across cards. |
| Shipping | Included. refunded_amount blends merchandise + shipping + tax. |
| Discounts | n/a, refunds reflect customer-paid amount post-discount. |
| Refunds | This is the refund population. The financial event of money returned, distinct from physical returns. |
| Cancelled / voided orders | Excluded (no refunded_amount). |
| Currency | Multi-currency without FX. Each currency has its own line on the chart if multi-currency is enabled in display settings. Stores transacting in 3+ currencies see overlapping lines that need careful reading. |
| Channels / sources | Toggleable: by default all channels aggregate; the chart legend exposes per-channel_id lines. Marketplace lines (Amazon, Facebook Shop) typically lag DTC by 24-72h due to Channel Manager sync. |
| Bucket size | Daily on the 90D window by default. Stores with <10 refunds/day should switch to weekly to see the trend through noise. |
| Time window | 90D (rolling 90 days). Settings allow 30D, 90D, 180D, 365D. |
| Alert trigger | None on the time series itself; rate-spike anomalies fire from BC Alert Refund Rate Spike. |
| Roles | owner, operations |
Calculation
Calculated automatically from your BigCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US apparel brand on BigCommerce Plus, 90-day window 14 Feb 26 to 14 May 26. The chart shows daily refund value (£) with refund count overlaid as a secondary axis.| Period | Daily refund value (avg) | Daily refund count (avg) | Average refund (£) | Notes |
|---|---|---|---|---|
| 14 Feb 26 to 28 Feb 26 | £620 | 14 | £44 | Baseline |
| 1 Mar 26 to 14 Mar 26 | £660 | 15 | £44 | Baseline (stable) |
| 15 Mar 26 to 21 Mar 26 | £2,140 | 22 | £97 | Spike day cluster |
| 22 Mar 26 to 31 Mar 26 | £710 | 16 | £44 | Returned to baseline |
| 1 Apr 26 to 14 Apr 26 | £640 | 14 | £46 | Baseline |
| 15 Apr 26 to 30 Apr 26 | £680 | 15 | £45 | Baseline |
| 1 May 26 to 14 May 26 | £950 | 16 | £59 | Drift up, average refund rising |
- The 15-21 Mar 26 cluster jumps out immediately on the chart. Refund value rose 3.3x while count rose only 1.5x, meaning average refund nearly doubled. This is the classic signature of a single high-value SKU defect batch; ~£20k of incremental refund value over 7 days, attributable to roughly 8-10 high-value orders going wrong. Investigation revealed a winter coat batch with faulty zips; merchant pulled the SKU and issued goodwill credits to affected customers.
- The 1-14 May 26 drift is the more dangerous signal. Average refund crept from £44 to £59 (a 34% rise) over two weeks while count stayed flat. Drift like this is hard to spot on the single-number cards but obvious on the time series. Drift usually predicts a brewing quality issue 7-14 days before it becomes a spike. Investigate before it escalates: pull BC Top Refunded for the most recent 14 days and look for a SKU appearing for the first time.
- Baseline refund value is remarkably stable at £620-£710/day for the months without incident. This is the normal merchant signal that the operation is running well. Once you know the baseline, you can ignore single-day anomalies and focus on cluster movements (3+ days deviating).
- Weekend dip pattern is real. If you zoom into the daily chart you’ll see Saturdays and Sundays sit ~30% below the weekday baseline; this is partly because refund-processing is a CS-business-hour activity (refunds get queued over the weekend and processed Monday) and partly because customer refund requests follow customer-service-hour patterns. Don’t read weekend dips as improvement.
- Marketplace refund stacking effect. Around the 5th of each month you’ll see a small spike (~+30% above baseline) because Amazon Channel Manager batches refund sync at end-of-billing-period. Build this into your baseline mental model to avoid raising false alarms on the 5th of each month.
- Establish the baseline first. Look at the median day-value over the last 30 days, ignoring spikes. That’s your normal.
- Watch for clusters of 3+ days at >150% of baseline. Single-day spikes are usually noise; sustained clusters point to a real cause.
- Watch for drift in average refund. A flat count with rising value over 2-3 weeks is the early-warning signal for a quality issue.
- Cross-reference with BC Refunds By Day of Week to disentangle weekly seasonality from genuine signals.
- Build the chart-screenshot habit into your weekly ops review. A stable baseline with no clusters is the cleanest possible signal that refund management is healthy; merchants who skip this card spend disproportionate time chasing single-day anomalies.
Sibling cards merchants should reference together
| Card | Why pair it with Refunds Over Time |
|---|---|
| BC Refund Count | The single-number aggregate. Use this card to see the shape, that one to see the magnitude. |
| BC Refund Value | Same, dollars instead of orders. |
| BC Refund Rate | The denominator-aware view. A spike in refund value during a sales surge may be normal in rate terms; this card alone can mislead. |
| BC Top Refunded | When you see a spike here, this card tells you which SKUs caused it. |
| BC Return Status | The physical-returns time series. Lag the return curve by 7-14 days against this card; the goods come back later than the cash goes out. |
| BC Revenue Over Time | The denominator. Refund spikes during revenue spikes are normal; refund spikes during revenue troughs are red flags. |
| BC Cancelled Over Time | The cancellation time series. Cancellations + refunds together = revenue that didn’t stick. Watch them in tandem. |
| BC Alert Refund Rate Spike | The anomaly detector that watches this curve. |
| BC Channel Refund Rate | If a spike appears here, segment by channel to find the source. |
| Stripe Refund Value Over Time | Cross-connector validation. The Stripe curve should track this card’s web slice. |
| BC Discount Over Time | Promotional periods drive refund spikes 5-14 days after the promotion ends. Reading the two charts together reveals this lag. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce’s own dashboard: The closest native chart is BC Control Panel → Analytics → Insights → Refunds (Plus and Enterprise tiers only). Set the date range to 90 days and you’ll see a comparable line chart. Insights buckets to weekly by default for ranges over 30 days; toggle the resolution to daily for direct comparison. For finance audit the export is more reliable than the chart: Settings → Data Solutions → Export → Orders, filter onrefunded_amount > 0, and pivot by refund_date in spreadsheet.
Why our number may legitimately differ from the vendor’s:
| Reason | Direction | Why |
|---|---|---|
| Time-zone bucketing | Days shifted | BC charts use store time zone; we use UTC. The first and last days of the range may carry different totals. |
| Sync lag | Today/yesterday lower | Webhook fanout introduces a 15-30 min lag for the most recent orders; for “today” the curve is slightly under-reported. |
| Daily vs weekly bucket | Either | If BC defaults to weekly bucketing on long ranges, granular daily spikes in our chart may look like a smoothed bump in BC Insights. Toggle BC Insights to daily for fair comparison. |
| Channel Manager backlog flush | Marketplace dates wrong | Amazon refunds frequently arrive in BC 24-72h after the marketplace dashboard shows them. Our chart bucket-dates by refund_date as recorded in BC, so the date appears later than reality on Amazon-heavy stores. |
| Multi-currency | Per-currency vs converted | Our chart shows per-currency lines; BC Insights converts to display currency at daily-average FX. Persistent gaps of 0.5-2% on multi-currency stores are normal. |
| Card | Expected relationship | Notes |
|---|---|---|
stripe.stripe_refund_over_time | Curve shape should match within ±2% on Stripe-paid orders | Stripe’s refund time-series is the authoritative cash-out event log. If shapes diverge, the gap usually points to gateway-side refunds bypassing BC. |
paypal.pp_refund_over_time | Same idea for PayPal-paid orders | PayPal Resolution Centre refunds bypass BC frequently; reconciliation gap >5% is the cause. |
Known limitations / merchant FAQs
Why is the chart so spiky on a daily resolution? Refund processing is bursty by nature: customers refund based on weekly delivery patterns, customer-service teams batch-process refunds in the morning, and marketplace channels (Amazon especially) batch-sync. Switch to weekly buckets if your daily volume is below ~10 refunds per day; the shape will be much cleaner. Why does the chart show a flat line on weekends but BC Insights shows the same level as weekdays? We bucket byrefund_date (when the refund was processed); BC may bucket by order_date (when the original order was placed). Refunds are processed in business hours, so our chart drops on weekends; BC’s chart smooths because the underlying orders are spread evenly across the week.
The chart shows a spike on the 5th of every month, what is that?
Almost certainly Amazon Channel Manager’s monthly billing-period sync. Amazon refunds initiated marketplace-side flow into BC in batches at month-end; that’s the spike. It is not a real spike in actual refund activity, just a sync artefact. To see the un-sync-distorted curve, exclude the marketplace channel and look at web-only.
My average refund value is rising over the last 14 days but no SKU stands out, why?
Three possibilities: (1) gradual mix shift toward higher-value SKUs (check BC Top Refunded for trending SKUs over 7 vs 14 days), (2) increase in partial refunds for shipping-delay apologies (these inflate value without single-SKU clustering), (3) seasonal effect (winter coats refund more in January than t-shirts refund in July). Each calls for a different investigation.
Can I see refunds segmented by reason code?
Yes via Ask Viq: “show refunds over time grouped by reason for last 90 days”. The reason field is BC’s free-text refund-reason from the refund flow; merchants typically have ~5-10 distinct codes in practice. The chart legend will show one line per reason.
Why doesn’t my retail partner see the same curve I see?
If you operate B2B Edition with channel-specific access controls, your retail partner’s view is filtered to their channel only. Your owner view is aggregate. Toggle the channel filter in the legend to match the partner view for direct comparison.
Should I be worried about a single high-value spike day?
Usually no. Single-day spikes typically reflect one big event (a single B2B quote refund, a fraud chargeback, a one-day product-launch issue). Pull the underlying orders for that day; if it’s 1-3 orders explaining the entire spike, that’s normal noise. Worry about clusters (3+ days deviating from baseline) and about drift (gradual upward trend in average refund).
Why does the chart only go back 90 days?
Default window is 90 days for performance reasons (the OpenSearch aggregation gets expensive on long windows). Toggle to 365D in settings if you need the annual view; expect a 5-10s load. The underlying index typically retains 13 months of refund data.
How does this differ from BC Insights’ “Net Sales” chart?
Net Sales = Gross Sales - Refunds, so it folds two signals into one line. This card shows refunds in isolation, which is what you need for refund-specific investigation. Use Net Sales for finance reporting; use this card for operational refund management.
Can I overlay revenue on the same chart?
Yes via the chart’s overlay toggle. The default refund-only view is cleaner for refund investigation; the revenue overlay is useful when checking “is this refund spike just tracking a sales spike?”.
Does this respect customer-group filters?
No, the chart aggregates across all customer groups. Use Ask Viq for filtered views: “show refunds over time for customer_group_id 5 over last 90 days”.
My chart shows zero on a recent day but I know there were refunds, what’s wrong?
Sync lag. The most recent 30-60 minutes of refund activity may not be indexed yet. Wait an hour and reload; the day’s bar should populate. If it persists past 2-3 hours, check Settings → Integrations → BigCommerce for a webhook delivery failure; the index refresh depends on order/refunded webhook events firing reliably.