At a glance
Daily refund value over the last 90 days, plotted as an area chart. The time-series companion to Refund Value and the trend lens that distinguishes “always was like this” from “this is new”. The shape of the curve is the value here; the headline lives on the value card.
| What it counts | DATE_HISTOGRAM(refund.createdAt, interval=1d) → SUM(refund.totalRefundedSet.shopMoney.amount). Each refund event contributes its full amount to its createdAt calendar day (in UTC). Partial refunds are included with their actual partial amount. |
| API endpoint | Admin GraphQL. Order.refunds[].createdAt and Order.refunds[].totalRefundedSet.shopMoney.amount. The bucketing key is the refund’s createdAt, not the original order’s. |
| What “refund date” means | The day Shopify processed the refund through the gateway, not the day the original order was placed and not the day the merchant approved the RMA. A refund processed on 12 May for an order placed on 30 Apr lives on 12 May’s bar. |
| VAT / tax treatment | Inherits each refund’s tax treatment from the original order. UK / EU stores have VAT-inclusive bars; US stores have sales-tax-exclusive bars. |
| Shipping | Included if refunded as part of the refund. |
| Discounts | Refund amounts are post-discount (the customer’s actual paid amount). |
| Partial refunds | Included with full partial amount. The card is the dollar time series, not the count. |
| Cancelled / voided orders | Excluded. VOIDED orders never captured payment. |
| Currency | Multi-currency arithmetic sum WITHOUT FX conversion. Multi-currency stores see a meaningless aggregate; the curve shape is informative within each currency, the absolute level is not. |
| Channels / sources | All channels aggregate. Online Store, POS, marketplaces, Buy Button all contribute. POS refunds typically post the same day; marketplace refunds (TikTok Shop, Amazon-via-Shopify) lag 24 to 72 hours into the chart via Channel Manager. |
| Disputes / chargebacks | Generally excluded. Chargebacks resolved at the network level don’t flow through Order.refunds. |
| Bucket interval | Fixed at 1 day. A 90-day window produces 90 bars. Days with no refunds appear as zero, not as missing. |
| Time window | 90D (default). The 90-day window catches both weekly seasonality and monthly cycles, including delayed-refund patterns (a 30-day return policy means refund spikes lag the original sale spike by 30 days). |
| Alert trigger | None on the time series itself. The companion sentiment lives on the headline Refund Rate. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Shopify 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 UK DTC apparel brand on Shopify Plus, GBP single-currency. Window: 12 Feb 26 to 12 May 26 (90 days). Daily reference points from the chart:| Date / window | Daily refund value | Notes |
|---|---|---|
| Average baseline (Feb to early Mar 26) | £820/day | Steady-state refund flow from normal returns activity |
| Mon 16 Feb 26 | £1,850 | Post-Valentine’s spike, sized-up gift returns |
| Wed 25 Feb 26 to Tue 03 Mar 26 | avg £2,200/day | Quality-batch issue on a hoodie SKU; refund spike began 28 days after the bad-batch sale |
| Mon 09 Mar 26 | £4,800 | Single B2B wholesale refund (cancelled order, full pallet) |
| Sat 14 Mar 26 to Sun 15 Mar 26 | £180/day | Weekend low; CS team off, refunds not processed |
| Mon 16 Mar 26 | £3,400 | Backlog catch-up after the weekend |
| Wed 22 Apr 26 to Sun 26 Apr 26 | avg £1,400/day | Spring-Sale aftermath, sized-wrong returns |
| Mon 11 May 26 | £960 | Approaching baseline again |
- The Mon 09 Mar single B2B refund (£4,800) is a single-event distortion. The chart looks alarming but it’s one transaction. Always pair this card with Refund Count on the same daily granularity: if count moved 1 and value moved £4,800, you’ve spotted a single-large-refund event, not a trend. If count moved 30 and value moved £4,800, you’ve spotted volume.
- The Feb 25 to Mar 03 plateau is a quality-batch signature. Sustained 3x baseline for 6 days, after a return-policy-window-aligned delay (28 days, matching the brand’s 30-day return policy). The original sale spike was around 28 Jan; the refund tail showed up exactly when policy timing predicted. Refund tails lag sales spikes by approximately the return-policy duration; this is how to forensically identify which sale spike caused which refund spike.
- Weekends drop because CS is off. Sat/Sun refund value is typically 20 to 30% of weekday baseline because customer-service reps process fewer refunds on weekends, not because customer demand for refunds is different. Monday catches up the backlog. Stores running 24/7 CS teams have flatter weekend curves; volunteer-staffed startups have spikier Mondays.
- Sale-event refund tails are predictable. The 22 to 26 Apr Spring Sale generated heavy original sales; refunds began arriving 5 to 14 days later (impulse-buy regret, sizing-wrong) and continued for 30 days under policy. Plan refund-volume forecasts around sale events: 5 to 8% of sale revenue typically refunds within 30 days.
- The card is most useful for forensic root-causing. When Refund Value shows a 2x lift, the time series tells you when the lift started, whether it’s a single day or a sustained shift, and what the original sale window was that fed it. The headline number alone can’t answer any of those questions.
Sibling cards merchants should reference together
The time series is a forensic tool. Pair it with these to find the root cause:| Card | Why pair it with Refunds Over Time |
|---|---|
| Refund Value | The single-number summary. Read them together: chart shows when, number shows how much. |
| Refund Count | The order-count time-series partner (planned). Lets you separate “many small refunds” from “one big refund” on the same day. |
| Orders Over Time | The original sales side. Refund spikes follow sale spikes by approximately the return-policy duration; pair these on the same chart to spot the lag. |
| Total Revenue Over Time | Revenue twin. Refund value as a % of revenue tells you whether refunds are eating margin. |
| Refund Rate | Time-series rate (refund value ÷ revenue per day). Less noisy than absolute value when revenue is volatile. |
| Top Refunded Products (planned) | SKU concentration. A daily spike usually maps to a single SKU. |
datadog.dd_incident_count | Fulfillment incidents 5 to 14 days prior often map to refund spikes now. |
stripe.stripe_refund_value_over_time | The gateway-side time series; should match shape on the Stripe-paid subset. |
bigcommerce.refunds_over_time | Same definition. Documentation cross-link. |
adobe_commerce.refunds_over_time | Adobe uses Credit Memo time series; same intent. Documentation cross-link. |
Reconciling against the vendor’s own dashboard
Where to look in Shopify Admin:Analytics → Reports → “Refunded sales over time”The closest twin in Shopify Admin. Set the date range to match this card and the daily bars should align bar-for-bar within sync-lag tolerance. Other Shopify Admin views adjacent:
- Reports → Sales over time: revenue side. Useful when overlaid with this card to see refund tails vs sale spikes.
- Orders → Returns: physical-goods returns time series; not a financial figure.
- Finances → Payouts: cash-flow view including refund deductions; useful for cash reconciliation, not for trend analysis.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days | Shopify Admin uses store time zone; Vortex IQ uses UTC. Daily bars on the boundary days can shift slightly. |
| Anchor date | Either | Shopify Admin can plot by original order date or refund date depending on report variant. This card always uses refund date (when the money actually went out). When backlogs flush, the two views diverge sharply. |
| Multi-currency aggregation | Either | Shopify’s report converts to shop primary currency at refund time; this card sums without FX. Multi-currency stores see headline-level differences; per-currency views match. |
| Multi-currency rounding | Tiny gap | Cent-level rounding on each refund. |
| Test orders | Ours slightly higher | Order.test = true not yet filtered. |
| Sync lag | Ours lower for “today” | Webhook-driven, 5 to 15 minute lag. |
| Channel Manager lag | Ours lower for marketplace | TikTok Shop, Amazon refunds lag 24 to 72 hours. |
| Plan tier reporting access | n/a | ”Refunded sales over time” is Plus/Advanced only; Standard merchants reconstruct from the Orders list. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_refund_value_over_time | Daily refund $ should match shape on Stripe-paid subset | Stripe sees the cash event; Shopify sees the order-refund relationship. They match exactly minus rounding when both connectors are synced. |
paypal.pp_refund_value_over_time | PayPal-paid subset only | Same reasoning. |
google_analytics.ga_refund_value_over_time | GA4 refund event time series | Subject to ad-blocker / consent gap; typically 10 to 25% lower than Shopify. |
datadog.dd_incident_count | No direct money relationship; trailing-correlation lens | Fulfillment / 3PL incidents 5 to 14 days prior often correlate with refund spikes here. |
Known limitations / merchant FAQs
Why does the refund-spike date not match the sale-spike date? Because the chart plots by refund processed date, not original order placed date. Refunds typically arrive 7 to 30 days after the original sale (within the return policy window), so refund spikes follow sale spikes by exactly that lag. To trace a refund spike to its causing sale window, look 5 to 30 days earlier on Orders Over Time. The lag is approximately your average return window. My weekend bars are tiny, is something wrong with the data? No, that’s CS staffing. Customer-service teams typically don’t process refunds Sat/Sun, so refund value drops 70 to 80% on weekends. Monday catches up the backlog. Stores running 24/7 CS see flatter curves. The pattern is structural and not a data issue. Why is one day a 5x spike? Three usual causes: (1) a single very large refund (B2B, premium SKU, full-pallet wholesale), (2) a backlog flush (CS team caught up after a delay), (3) a marketplace-channel refund batch flowing in (TikTok Shop / Amazon-via-Shopify Channel Manager sync). Pair with Refund Count on the same day: if count moved 1 and value spiked, it’s (1); if count moved a lot, it’s (2) or (3). Are partial refunds plotted? Yes, with their actual partial amount. A £200 order partially refunded for £40 contributes £40 to that day’s bar. The card is the dollar time series, not the count. How do I do year-over-year comparison? The card itself shows 90 days. For YoY, ask Ask Viq directly (“show me refund value this April vs last April”) or pull both windows from Refund Value using the period picker. The 90-day chart is for trend within the period. Multi-currency stores, how should I read the chart? With caution. The headline-level chart sums all currencies arithmetically, which is mathematically meaningless. Drill into per-currency views for any multi-currency store; the curve shape is informative within each currency, the absolute level across currencies is not. Use Ask Viq with a currency filter or Shopify Admin’s Markets-aware reports. Subscription pro-rated refunds, do they show on the chart? Yes. Each subscription pro-rated refund (when a customer cancels mid-cycle) is a normal refund event with acreatedAt timestamp; it plots on the day it processes. Subscription-heavy stores often see a “first-of-month” pattern as recurring billings generate cancellations and pro-rated refunds at cycle boundaries.
Why is the most recent day always shorter?
Because the day isn’t over. The most recent bar fills throughout the day as refunds post. By midnight UTC the bar is final.
Shopify Plus vs basic plan, behavioural differences?
None for the time series mechanics. Plus stores have access to “Refunded sales over time” report in Shopify Admin (Plus and Advanced only) for direct comparison. Standard plan stores reconstruct from the Orders list.
B2B vs DTC, do they read differently?
Yes. B2B refunds are large and lumpy (one £15,000 refund moves a daily bar dramatically), DTC refunds are small and frequent. A blended chart shows B2B-driven spikes superimposed on DTC steady-state. Stores with material B2B should view per-purchasing-entity-type to see the two distinct shapes.
Refresh cadence?
Webhook-driven, 5 to 15 minute index lag. Marketplace-channel refunds lag 24 to 72 hours.
The chart shows zero refunds on a public holiday, is that right?
Probably yes. Bank holidays mean payment-gateway processors and CS teams are off, so refunds queue up and process on the next working day. The next-day bar will be inflated by the holiday backlog.
Action playbook for diagnosing a refund spike:
- Confirm whether the spike is one transaction or many. Pair with Refund Count on the same day.
- If it’s many, look at SKU concentration via Top Refunded Products. One or two SKUs = quality issue. Even spread = fraud or sync.
- Look back 7 to 30 days on Orders Over Time. The original sale window that fed the refund spike is usually visible.
- Cross-reference
datadog.dd_incident_countfor fulfillment / 3PL events 5 to 14 days prior. Carrier issues often manifest as refund spikes within 2 weeks. - If nothing explains it, check the gateway dashboard for a fraud-rule change or risk-engine update that might have triggered preemptive refund processing.