> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Refunded Orders, BigCommerce > Refunded Orders for BigCommerce stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) ## At a glance > Count of BigCommerce orders that have been **fully refunded** in the period, where `status = Refunded`. This is the *order count* view of refund activity (the dollar view lives on [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value)). It is one of the few BC dashboard numbers that conflates the financial event ("the customer got their money back") with the operational event ("the customer returned the goods"). They are not the same thing on BigCommerce, and merchants who mistake one for the other end up either over-restocking inventory they never received back or under-tracking warehouse receipts. This card counts the financial event. | | | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(orders WHERE status = 'Refunded')` over the period. Each refunded order contributes a count of 1 regardless of refund value. Orders with `status = 'Partially Refunded'` are NOT counted here, they sit on a separate split-view we expose elsewhere; the user-facing "refund count" merchants reach for in BC Control Panel matches this *fully* refunded definition. | | **VAT / tax treatment** | n/a, this is a count metric. The corresponding dollar card ([BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value)) is tax-inclusive because it sums `refunded_amount`, which BC stores at the customer-billed total. | | **Shipping** | n/a for the count; included in the value card. BigCommerce does not split refunded shipping from refunded merchandise unless the merchant uses the granular Refunds API; the `refunded_amount` field on the legacy v2 Order endpoint blends them. | | **Discounts** | n/a for count. Discounts on the original order do not affect whether the order counts as refunded; a discounted £40 order that gets fully refunded still increments this card by 1. | | **Refunds** | This is the refund population by definition; the question is not "are refunds deducted?" but "what counts as a refund?". On BigCommerce, **refund is the financial event** (money returned to the cardholder via the gateway). It is distinct from **return** (item physically received back into the warehouse), which lives in the RMA / Returns module and is tracked on [BC Return Status](/nerve-centre/kpi-cards/bigcommerce/return-status). A merchant can refund without a return (defective item, customer-keeps-it goodwill) and can receive a return without refunding (store credit, exchange). | | **Cancelled / voided orders** | Excluded. `status = 'Cancelled'` and `status = 'Declined'` are different states; cancellation is for orders that never shipped, decline is for failed authorisation. Neither contributes to refund count. | | **Currency** | **Multi-currency without FX.** Each `currency_code` is counted in its native bucket; the headline number is a count and therefore currency-agnostic, but if the merchant clicks through to view value, the figure splits per-currency. Stores using B2B Edition with quote-currencies different from the storefront currency see refunds bucketed in the *quote* currency, not the channel currency. | | **Channels / sources** | All `channel_id` values aggregate, web (`channel_id = 1`), POS, Channel Manager (Amazon, Facebook Shop, eBay), B2B portal. Marketplace refunds are particularly worth segmenting: Amazon-side refunds (initiated by Amazon for A-to-Z claims) appear here once Channel Manager syncs them back, with a typical 24-72h lag. | | **`Incomplete` orders** | Excluded. An Incomplete order can never become Refunded directly; it would have to pass Awaiting Payment first. | | **Partial refunds** | Excluded from this count, surfaced separately. A merchant who issues many partial refunds (typical for damaged-in-transit one-of-three-items scenarios) will find this card understates refund activity; pair with [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) which captures partial-refund dollar impact. | | **Time window** | `30D vsP` (rolling 30 days versus prior 30 days). | | **Alert trigger** | None on the count itself; a sudden spike in count usually signals either a SKU-level quality failure or a fraud-chargeback wave. The corresponding alert lives on [BC Alert Refund Rate Spike](/nerve-centre/kpi-cards/bigcommerce/refund-rate-spike-alert). | | **Roles** | owner, operations | ## Calculation ``` COUNT(status=Refunded) WHERE date BETWEEN [period_start, period_end] ``` ## Worked example A US-based mid-market home-fragrance brand on BigCommerce Plus, running web (`channel_id = 1`), Amazon Channel Manager (`channel_id = 1019847`), and a small B2B Edition portal (`channel_id = 1020100`). Reporting window 14 Apr 26 to 13 May 26. | Bucket | Orders placed | Orders refunded (status = Refunded) | Refund count rate | | ---------------------- | ------------- | ----------------------------------- | ----------------- | | Web (DTC) | 4,820 | 96 | 1.99% | | Amazon Channel Manager | 1,610 | 134 | 8.32% | | B2B Edition portal | 88 | 1 | 1.14% | | **Total** | **6,518** | **231** | **3.55%** | What the merchant should immediately notice: 1. **Amazon refund count is 4x the web rate.** This is normal in absolute terms (Amazon's A-to-Z claim system makes refunds operationally easier for the buyer than DTC), but 8.32% is at the upper end of healthy. Anything north of 10% on Amazon channel triggers Account Health Reviews; the merchant should cross-reference [BC Top Refunded](/nerve-centre/kpi-cards/bigcommerce/top-refunding-customers) to find the SKUs driving Amazon-specific refunds. 2. **The B2B Edition single refund is the most expensive one.** B2B orders typically have 4-15x DTC AOV, so even one refund moves [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) materially without moving this count card. **Always pair this card with the value card on stores running B2B Edition**, otherwise a single £18,000 quote-cancellation refund hides inside an apparent "all clear" count. 3. **The web 1.99% is healthy.** Industry benchmarks for DTC home goods sit at 2-4%; below 2% generally means either great products or under-permissive return policy. 4. **231 refunded orders is the *operational* workload number.** Each refund typically takes a customer-service rep 4-8 minutes (longer for marketplace, shorter for self-serve). At a £25/h loaded cost this is roughly £160-£320 in CS labour for the period, before any restocking, shipping-back, or inspection time. Now compare to the *return* count from the warehouse for the same period: | Bucket | Refund count (this card) | Return count (warehouse RMA log) | Refund-without-return | | --------- | ------------------------ | -------------------------------- | --------------------- | | Web | 96 | 71 | 25 (26%) | | Amazon | 134 | 22 | 112 (84%) | | B2B | 1 | 0 | 1 (100%) | | **Total** | **231** | **93** | **138** | The 138 refunds *without* a corresponding return are the merchant's leakage: * Some are legitimate (damaged-in-transit goodwill, low-value items not worth shipping back, "keep it" customer-service decisions). * Some are unaccounted (the warehouse received the item but never logged the RMA, the customer kept the item without staff noticing). * Amazon's 84% refund-without-return is structurally normal: Amazon's A-to-Z system frequently refunds the customer without requiring the item back if the dispute hits before a return label is issued. **This is BigCommerce's distinct refund vs return concept in action**, and conflating them at the financial level overstates inventory recovery. Action playbook this card surfaces: 1. **Pull [BC Top Refunded](/nerve-centre/kpi-cards/bigcommerce/top-refunding-customers) to find the offending SKUs.** Refund counts cluster on a small number of products in most stores; finding the top three usually accounts for 30-50% of refund volume. 2. **Cross-reference [BC Return Status](/nerve-centre/kpi-cards/bigcommerce/return-status) for the same period** to find refund-without-return cases. The gap is the leakage. 3. **For Amazon-driven refunds, log into Seller Central and review the Voice of the Customer report.** It frequently flags the underlying complaint type (defective, wrong item, item not as described) which the BC dashboard does not. 4. **Watch the trend on [BC Refunds Over Time](/nerve-centre/kpi-cards/bigcommerce/refunds-over-time).** A flat refund count over 90 days is healthy; a step-change up usually points to either a single bad batch (carrier damage, supplier defect) or a fraud wave. ## Sibling cards merchants should reference together | Card | Why pair it with Refund Count | | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) | The dollar twin. Count is the operational view, value is the finance view. A flat count with rising value means refunds are getting more expensive (higher-value items returning); a rising count with flat value means more low-value goodwill refunds. | | [BC Refund Rate](/nerve-centre/kpi-cards/bigcommerce/refund-rate) | The denominator-aware version. Count alone is unanchored; rate (count / orders) tells you whether refund volume is structurally rising or just tracking sales growth. | | [BC Refunds Over Time](/nerve-centre/kpi-cards/bigcommerce/refunds-over-time) | The time series. Single-number cards can't distinguish "it was always like this" from "this is new"; the time series can. | | [BC Top Refunded](/nerve-centre/kpi-cards/bigcommerce/top-refunding-customers) | The product-level breakdown. Refund counts cluster on a tiny minority of SKUs; the top-3 typically explains 30-50% of refund volume. | | [BC Return Status](/nerve-centre/kpi-cards/bigcommerce/return-status) | The operational counterpart. This card is "money returned"; that one is "items received back". Reconciling them surfaces leakage. | | [BC Channel Refund Rate](/nerve-centre/kpi-cards/bigcommerce/refund-rate-by-channel) | The per-channel split. Marketplaces (Amazon especially) have structurally higher refund rates than DTC. | | [BC Refunded Products](/nerve-centre/kpi-cards/bigcommerce/most-refunded-products) | SKU-level refund attribution at the line-item rather than order-level granularity. Useful when a multi-item order is partially refunded. | | [BC Alert Refund Rate Spike](/nerve-centre/kpi-cards/bigcommerce/refund-rate-spike-alert) | The anomaly detector. Watches this card and the rate card for sudden moves. | | [Stripe Refund Value](/nerve-centre/kpi-cards/stripe/refund-value) (cross-connector) | When Stripe is the gateway, the dollars should reconcile within ±2% to BC's refund\_value. The count itself may differ because Stripe counts refund *transactions* while BC counts refund *orders*. | | [Cancellation Rate](/nerve-centre/kpi-cards/bigcommerce/cancellation-rate) | A neighbour metric. Cancellations and refunds together form the "revenue that didn't stick" universe; tracking both prevents one masking the other. | ## Reconciling against the vendor's own dashboard **Where to look in BigCommerce's own dashboard:** The closest native view is **BigCommerce Control Panel → Orders → View Orders**, then filter the **Order Status** column to *Refunded*. Set the date range to match the card period and the row count at the bottom of the table is the directly-comparable figure. For a charted view, navigate to [Analytics → Orders Report](https://login.bigcommerce.com/deep-links/manage/analytics/orders) (Plus and Enterprise tiers only). The *Orders by Status* breakdown breaks the count out by status; the Refunded column matches this card. The Standard tier does not include this report, so Standard merchants should rely on the Orders list filter. For marketplace-specific breakdowns: BigCommerce Control Panel → Channel Manager → (select channel) → Orders. Each channel has its own filterable order list, but the status-filter pattern is the same. **Why our number may legitimately differ from the vendor's:** | Reason | Direction | Why | | ------------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Time zone** | Boundary days off | BC Control Panel uses the store's configured time zone (Settings → Store Profile → Time Zone). Our card uses UTC. For 30-day windows the gap averages out; for "today" or "yesterday" comparisons the cutoff can shift the count by 0-12 orders. | | **Sync lag** | Ours lower for last 30 minutes | OpenSearch index materialisation runs every 15-30 minutes via the BC webhook fanout. Refunds processed within the last sync interval are not yet indexed. | | **Partial refunds** | Theirs may be higher | Some Control Panel views count `Partially Refunded` as a refund; our card does not. Cross-check by also filtering for *Partially Refunded* in the Control Panel. | | **Channel Manager lag** | Ours lower for marketplace | Amazon, eBay, Facebook Shop refunds initiated marketplace-side take 24-72 hours to flow into BC via Channel Manager sync. The marketplace's own dashboard shows the refund instantly; BC and our card lag accordingly. | | **Cancelled-then-refunded edge case** | Either | If a merchant cancels and then refunds an order, BC may show `status = Cancelled` until the refund posts, then flip to `Refunded`. During the brief window between events the order appears in neither bucket. | | **B2B Edition quote refunds** | Either | Quote-based orders on B2B Edition refunded via the quote module sometimes do not flip the order's status\_id immediately. Force-refresh the order in B2B Edition admin if the count looks off. | **Cross-connector reconciliation (when both connectors are connected for this merchant):** These connectors view the same orders/transactions through different lenses. Counts should agree within tracking-gap accuracy. Divergence is a data-quality signal worth investigating. | Card | Expected relationship | Notes | | --------------------------------------------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_refund_count`](/nerve-centre/kpi-cards/stripe/refund-count) | Within ±5% on web channel | Stripe counts refund *transactions* (one order can have multiple partial refunds = multiple transactions). BC counts refund *orders*. Gap of 5-15% normal on stores using lots of partial refunds. | | [`paypal.pp_refund_count`](/nerve-centre/kpi-cards/paypal/refund-count) | Should equal PayPal-paid refunds only | PayPal-only subset, useful for stores that split traffic between Stripe and PayPal at checkout. | ***
Documentation cross-reference (for agencies running multiple platforms) The refund-count metric exists with a definition-equivalent on other commerce platforms, but the *refund vs return* distinction is BigCommerce-specific in the way it surfaces. Shopify treats `displayFinancialStatus = REFUNDED` as the financial event and exposes returns via the separate Returns API; Adobe Commerce uses the Credit Memo entity, which is closer to BC's refund-financial concept than to return-physical. * [`shopify.refund_count`](/nerve-centre/kpi-cards/shopify/refunded-orders) * [`adobe_commerce.refund_count`](/nerve-centre/kpi-cards/adobe-commerce/refunded-orders)
## Known limitations / merchant FAQs **Why doesn't this card include partial refunds?** Because the operational decisions a merchant takes in response to refund count are different for full versus partial refunds. A full refund means the order failed for the customer (wrong product, defective, didn't arrive); a partial refund usually means a small adjustment (one item of three, missing accessory, shipping refund for delay). Mixing them dilutes both signals. If you need the combined view, use [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) which captures the dollar impact regardless of full versus partial. **My BC Control Panel shows 240 refunded orders but this card shows 231, where are the missing 9?** Almost always a time-zone gap or sync lag. BC uses your store time zone (Settings → Store Profile); we use UTC. For a 30-day window the boundary can shift by up to 24 hours of orders. Check the Control Panel on a 31-day or 32-day window centred on your card period and the figures usually reconcile to within 1-2 orders. **A customer was refunded but the order still shows `Awaiting Fulfillment`, why?** This is a BigCommerce data-entry quirk. If the merchant issued the refund via the gateway directly (Stripe Dashboard, PayPal Resolution Centre) without using the BC refund flow, BC's `status` field never updates. The financial event happened, but BC doesn't know. **Always issue refunds through the BC Order Refund flow**, not gateway-side, otherwise this card will under-count. **How does this differ from the Returns Centre count?** The Returns Centre tracks RMAs (Return Merchandise Authorisation) which are *requests* to return goods. This card tracks completed financial refunds. A merchant can have 50 RMAs open and 20 completed refunds; only the 20 are on this card. **Returns and refunds are not the same lifecycle** on BigCommerce; refund is the financial outcome, return is the physical-goods outcome. **Does this include chargebacks?** Yes if the merchant fully refunded the disputed order before the chargeback resolved (treating it as a pre-emptive refund); no if the chargeback was lost and posted directly via the gateway without a BC-side refund flow. For a clean chargeback view, use [`stripe.stripe_dispute_count`](/nerve-centre/stripe/stripe_dispute_count) or the equivalent gateway card. **My subscription product shows up in this count but it shouldn't, the customer cancelled, they didn't refund.** BC's BigCommerce Subscriptions module historically used `status = Refunded` for subscription cancellations that issued a pro-rated refund of the unused period. If you see subscription orders here, that's the cause. Filter them out by tag or product type if the count noise is meaningful. **Why is my Amazon channel refund count 4x higher than web?** Structurally normal. Amazon's A-to-Z claim system makes refunds operationally easier for the buyer than DTC, and Amazon often refunds without requiring the item back. Industry benchmark for Amazon-channel refund rate sits at 4-9% (versus 1-3% on DTC). Above 10% you should worry about Account Health Reviews; below 4% your listing accuracy is well above average. **Can I export this list to my finance team?** Yes via Ask Viq: "export refunded orders for last 30 days as CSV". The export includes order\_id, customer\_id, refunded\_amount, refund\_date, channel\_id, payment\_method, currency\_code, and reason\_code. The reason code is the merchant-entered free-text refund reason from the BC refund flow; it is not standardised. **The number jumped from 60 to 230 last week, what happened?** Three usual causes, in order of likelihood: (1) a fraud wave (one fraudulent gift-card-resale operation can refund hundreds of orders in a day), (2) a SKU-level quality failure (a bad batch with manufacturing defect), or (3) a Channel Manager sync catch-up (marketplace-side refunds backlog flushing through). Pull [BC Top Refunded](/nerve-centre/kpi-cards/bigcommerce/top-refunding-customers) and look at refund concentration by SKU; if it's one or two SKUs, it's a quality issue; if it's evenly distributed across many SKUs, it's a fraud or sync event. **Does this respect the customer-group filter?** No. The card aggregates across all customer groups; B2B and DTC refunds are summed. Use [BC Guest vs Registered](/nerve-centre/kpi-cards/bigcommerce/guest-vs-registered-orders) and the customer-segment cards if you need the split. B2B Edition refunds are typically much larger in dollars but rarer in count, so the count card understates B2B impact. *** ### Tracked live in Vortex IQ Nerve Centre *Refunded Orders* is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.