At a glance
Total dollar value refunded back to customers in the period. The financial-impact twin of Refund Count. Critically, this card sums all refund value (including partial refunds), unlike the count card which only credits fully-refunded orders.
| What it counts | SUM(Order.totalRefundedSet.shopMoney.amount) over the period. Every refund event contributes its full amount, regardless of whether the parent order is REFUNDED (full) or PARTIALLY_REFUNDED (partial). The card sums the actual money returned. |
| API endpoint | Admin GraphQL. Order.refunds[] and Order.totalRefundedSet.shopMoney.amount. Each Refund object on an order is a separate refund event with its own createdAt; the card sums by the refund’s date, not the original order date. |
| Refund timing | A refund processed on 12 May for an order placed on 30 Apr counts toward this card’s 12 May window. The original order’s revenue still sits in Total Revenue for 30 Apr, so a 30-day window can show refund value > revenue if a backlog of older orders refunds heavily. |
| VAT / tax treatment | Inherits the original order’s tax-inclusivity. UK / EU stores with taxesIncluded = true see VAT-inclusive refunds; US stores see tax separately. The refunded VAT is also returned to the customer (tax authorities reclaim via your VAT return), but the card sums the gross refund. |
| Shipping | Included if the merchant refunded shipping. Most refunds for “wrong item” or “didn’t arrive” include shipping; refunds for “return for store credit” often exclude shipping. The card sees whatever the merchant chose; can’t decompose. |
| Discounts | The refund amount is the post-discount amount the customer paid. A £100 order discounted to £80 then refunded contributes £80, not £100. |
| Partial refunds | Counted, with their actual partial amount. A £200 order refunded £40 (one item of five) contributes £40. This is the key behavioural difference from the count card. |
| Cancelled / voided orders | Excluded. VOIDED means no payment was captured; nothing to refund. |
| Currency | Multi-currency arithmetic sum WITHOUT FX conversion. Refunds in GBP, EUR, and USD all sum into a single number with no normalisation. Use a currency-filtered view for any store transacting across currencies. |
| Channels / sources | Not filtered. POS refunds, Online Store, marketplace channels all contribute. POS refunds tend to be smaller and more frequent (impulse-purchase apparel returns); marketplace refunds vary. |
| Disputes / chargebacks | Generally excluded. A chargeback that wins refunds the customer via the network, not via Shopify’s refund flow. The dispute amount sits at Order.disputes, not in totalRefunded. |
| Time window | 30D (default rolling 30 days). |
| Alert trigger | None on the value. The corresponding alert lives on Refund Rate. |
| Roles | owner, operations |
Calculation
Worked example
An EU multi-currency electronics retailer on Shopify Plus, transacting in EUR (DE, FR, NL), GBP (UK), and USD (US web). Period 12 Apr 26 to 11 May 26.| Currency / region | Total revenue | Full refunds (count) | Partial refunds (count) | Refund value (this card) | Refund value % of revenue |
|---|---|---|---|---|---|
| EUR (Germany / France / Netherlands) | €842,000 | 412 | 184 | €58,400 | 6.94% |
| GBP (UK) | £312,000 | 168 | 72 | £18,200 | 5.83% |
| USD (US) | $148,000 | 88 | 38 | $11,400 | 7.70% |
| Headline (multi-currency arithmetic sum) | (meaningless) | 668 | 294 | 88,000 (no currency) | (meaningless) |
- The headline number is multi-currency without FX, so 88,000 has no unit. It’s the arithmetic sum of €58,400 + £18,200 + $11,400, treated as if currency labels didn’t exist. For multi-currency stores this card is misleading at the headline level; always drill into the per-currency split. Use Ask Viq with a currency filter, or filter by Market in Shopify Admin.
- Per-currency refund-value-as-percentage-of-revenue is the actionable comparator. Germany 6.94%, UK 5.83%, US 7.70%. Differences here are real: US electronics buyers refund more than UK buyers, possibly due to retail-store-comparison shopping (“Best Buy is cheaper”) or stricter consumer protection. The 1.87 percentage-point gap is structurally meaningful for margin planning.
- Partial refunds are a big share of value. 294 partial refunds from 668 full refunds means partials are 44% of the count base; the value they contribute is captured here but invisible on Refund Count. On stores with many multi-line orders (electronics with peripherals, fashion bundles), partials drive 30 to 50% of refund value. Pair with the count card and you’ll always under-estimate financial impact.
- VAT recovery is implicit. German and UK refund values are VAT-inclusive; the merchant claims back the VAT via their VAT return. The cash-out is the full headline figure here; the net-of-VAT cost (the actual loss) is roughly 16 to 21% lower depending on jurisdiction. Finance teams reading this card should know which view they want.
- Shipping refunds are included in the value. A “didn’t arrive” refund (Royal Mail lost the parcel) returns merchandise + shipping, both flowing through
totalRefundedSet. A “returned for store credit” refund typically excludes shipping. The card can’t tell you the breakdown, but the dollar twin matches the cash-out exactly.
Sibling cards merchants should reference together
| Card | Why pair it with Refund Value |
|---|---|
| Refund Count | The count twin. Count counts only fully-refunded orders; value sums all refund money including partials. They diverge whenever partials are common. |
| Refund Rate | Refund value ÷ revenue. Rate normalises for sales growth so you can see if refunds are structurally rising. |
| Refunds Over Time | The time series. Catches one-off spikes vs sustained shifts. |
| Total Revenue | The denominator. Refund value as percentage of revenue is the canonical “refund leakage” metric. |
| Net Revenue (planned) | Revenue minus refund value. The card finance teams care about. |
| AOV | Refund value ÷ refund count = average refund size. Compare to AOV; a refund-AOV materially higher than order-AOV means premium SKUs refund more (a quality concern). |
| Top Refunded Products (planned) | SKU concentration of refund value. |
stripe.stripe_refund_value | When Stripe is the gateway, dollars should reconcile within ±2% on the Stripe-paid subset. |
paypal.pp_refund_value | PayPal-paid subset only. |
bigcommerce.refund_value | Same definition. Documentation cross-link. |
adobe_commerce.refund_value | Adobe uses Credit Memo total; same conceptual amount. Documentation cross-link. |
Reconciling against the vendor’s own dashboard
Where to look in Shopify Admin:Analytics → Reports → “Refunded sales over time” (Plus and Advanced tiers)The closest twin in Shopify Admin. Shows refund value over the chosen window. For Standard plan stores, reconstruct from the Orders list filtered by Refunded / Partially Refunded and summing the refund amount per row. For finance reconciliation: Finances → Payouts shows Shopify Payments payouts net of refunds. Useful for cash-flow reconciliation against this card; not a 1:1 match because PayPal / Klarna / external gateway refunds aren’t in payouts. Other Shopify Admin views adjacent:
- Analytics → Dashboards → Overview: shows refund $ as a tile for last 30 days. Headline-level only.
- Orders → Returns: physical-goods returns; not a financial figure.
- Reports → Sales by product: per-SKU revenue with refunds netted; useful for SKU-level refund value.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days | Shopify Admin uses store time zone; Vortex IQ uses UTC. |
| Refund timing | Either | Shopify Admin’s “Refunded sales over time” can plot by original order date or refund date depending on the report variant. This card uses refund date (when the money went out). The two views can differ materially when a backlog of older orders refunds in a recent window. |
| Multi-currency rounding | Tiny gap | Each refund stores its money to 2 decimal places per currency; sums can differ by a cent or two due to rounding order. |
| Multi-currency aggregation | Either | Shopify’s report converts everything to the shop’s primary currency at the time of the refund. This card sums without FX. For multi-currency stores, the headline numbers will differ; per-currency views match. |
| Shipping refund attribution | Either | Shopify Admin can show “merchandise refunds only” or “all refunds”; this card sums all totalRefundedSet. |
| Sync lag | Ours lower for last 5 to 15 minutes | Webhook-driven indexing. Refunds processed within the last sync interval are not yet indexed. |
| Test orders | Ours slightly higher | Test refunds not filtered. |
| Channel Manager lag | Ours lower for marketplace | Marketplace-side refunds (TikTok Shop, Amazon-via-Shopify) take 24 to 72 hours to flow through. |
| Card | Expected relationship | Notes |
|---|---|---|
stripe.stripe_refund_value | Within ±2% on Stripe-paid subset | Stripe’s view is canonical for cash movement; Shopify’s view is canonical for the order-refund relationship. They should match exactly minus rounding. |
paypal.pp_refund_value | Within ±2% on PayPal-paid subset | Same reasoning. |
google_analytics.ga_refund_value | GA4’s refund event with value parameter | Subject to ad-blocker / consent gap; usually undercounts by 10 to 25%. |
Known limitations / merchant FAQs
Why does this card show a bigger number than Refund Count would suggest? Because Refund Value includes partial refunds; Refund Count only counts fully-refunded orders. A £200 order with a £40 partial refund contributes £40 to value, 0 to count. If you have many partial refunds (typical for multi-line apparel or electronics with peripherals), value diverges materially upward from what count alone implies. This is the central design of the two cards: count for operational workload, value for financial impact. My multi-currency store shows a single headline number, what currency is it in? None. The card sums across all currencies arithmetically without FX conversion, which is mathematically meaningless but operationally common. Always drill into the per-currency view for any multi-currency store; the headline single number is misleading. The roadmap includes an FX-converted view; for now, use Ask Viq with a currency filter or Shopify Admin’s Markets-aware reports. Does the figure include VAT / sales tax? Inherits the original order’s tax-inclusivity. UK / EU stores withtaxesIncluded = true see VAT-inclusive refunds (matches the cash going out to the customer). US stores see merchandise refunds with sales tax tracked separately. The card sums the gross refund either way; for a net-of-tax view, subtract the inclusive tax via the refund-line VAT field.
Why is my refund value sometimes higher than my revenue for the same period?
Because refunds and revenue use different anchor dates. Revenue uses the order’s createdAt; this card uses the refund’s createdAt. A 30-day window where many older orders refunded heavily (a recall, a quality-batch issue, a 60-day return policy in apparel) can have refund value > new revenue. This is correct behaviour; it’s a leading indicator that something failed 30 to 60 days ago.
Are chargebacks counted?
Generally no. A chargeback that the merchant accepts (by issuing a full Shopify refund) shows up here as a normal refund. A chargeback that the network resolves directly without a Shopify refund flow does not. For a clean dispute view, see stripe.stripe_dispute_value or the equivalent gateway card.
Is shipping refund counted?
If the merchant refunded shipping as part of the refund (typical for “didn’t arrive” or “wrong item”), yes. If the merchant excluded shipping (typical for “returned for store credit, customer pays return shipping”), no. The card sums whatever’s in totalRefundedSet; can’t decompose merchandise vs shipping vs tax.
Subscription pro-rated refunds, are they counted?
Yes. When a subscription customer cancels mid-cycle and the app issues a pro-rated refund, the refund event flows through Order.refunds and contributes here. The card sees it as any other refund.
Multi-currency rounding, is it material?
Generally no. Each refund stores money to 2 decimal places per currency; the rounding error is a few cents per refund. Across thousands of refunds the total is sub-£10 in most stores. Only matters for forensic accounting reconciliation.
Shopify Plus vs basic plan, behavioural differences?
None for the underlying field. Plus stores using Shopify Functions to customise refund flows can route refund money differently (e.g. to a wallet credit) but totalRefundedSet still reflects what came out of the gateway. B2B Edition refunds work the same way; the customer is a PurchasingCompany rather than an individual.
B2B vs DTC, how should I read this card?
Segment them. B2B refund counts are low but values are high (one £18,000 PO refund moves the headline materially). DTC refund counts are high but values are typically £30 to £200 each. A blended view obscures both stories. Stores running B2B Edition should always view per-purchasing-entity-type.
Refresh cadence?
Webhook-driven, 5 to 15 minute index lag. Marketplace-channel refunds lag 24 to 72 hours.
The number jumped from £4,000 to £18,000 last week, what should I check first?
- Refund Count. If count moved proportionally, it’s volume; if count barely moved but value spiked, you had a big-ticket refund (B2B, premium SKU, expensive bundle).
- Top Refunded Products. Look at SKU concentration. One or two SKUs = quality issue. Even spread = fraud or sync.
- Cross-reference Datadog incidents for fulfillment / 3PL events 5 to 14 days prior.
- Check for a single high-value refund that’s distorting the headline. A £15,000 wholesale refund on its own can move this card meaningfully on a small store.