> ## 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. # Return Status, BigCommerce > Return Status 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 > The breakdown of Return Merchandise Authorisations (RMAs) by current status (Pending, Authorised, Received, Refunded, Rejected) over the period. This is the **physical-goods view** of return activity, distinct from [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) which is the financial view. On BigCommerce, *return is the goods coming back* and *refund is the money going out*; they share a customer event but different lifecycle states. This card lives in operations, [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) lives in finance. | | | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | `COUNT(returns) GROUP BY return_status` for RMAs created in the period. The Returns API exposes the status field with the BC-defined enum: `Pending`, `Authorised`, `Received`, `Refunded`, `Rejected`. | | **VAT / tax treatment** | n/a, this is a count card showing volume-by-state. | | **Shipping** | n/a for the count; whether return shipping is paid by merchant or customer is configured per RMA on the Returns API. | | **Discounts** | n/a. | | **Refunds** | RMAs that have completed the refund step show `status = Refunded` here. The dollar value lives on [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value). | | **Cancelled / voided orders** | n/a, returns are tied to delivered orders. | | **Currency** | n/a, count metric. | | **Channels / sources** | All channels with active Returns API coverage. **Important caveat**: BigCommerce's native Returns module covers web orders only. Marketplace returns (Amazon, eBay) are managed by the marketplace and do *not* flow into this card. Stores doing significant marketplace volume should treat this card as the **DTC-returns** view. | | **Returns vs refunds gotcha** | A merchant can refund without a return (defective item, customer-keeps-it goodwill) and can receive a return without refunding (store credit, exchange). This card never sees the refund-without-return cases; pair with [BC Refund Count](/nerve-centre/kpi-cards/bigcommerce/refunded-orders) to see them. | | **Time window** | `30D` (rolling 30 days; settings allow 7D, 30D, 90D). | | **Alert trigger** | None; threshold cards live separately on refund-rate spike alerts. | | **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, 30-day window 14 Apr 26 to 13 May 26. Returns module is enabled on web; Amazon returns are excluded. | RMA status | Count | % of total | Action priority | | ------------------------------------------ | ------- | ---------- | ------------------------ | | Pending (customer requested, not yet auth) | 23 | 18% | Authorise within 24h SLA | | Authorised (label sent, awaiting parcel) | 41 | 33% | Wait for carrier | | Received (warehouse logged it back in) | 38 | 30% | Inspect and refund | | Refunded (financial event complete) | 16 | 13% | Done | | Rejected (out of policy) | 7 | 6% | Communicate to customer | | **Total** | **125** | **100%** | | What's interesting: 1. **23 Pending RMAs are the operational debt.** Each pending RMA is a customer waiting for authorisation; SLA on most brands is 24-48h, so 23 outstanding requests means 23 customers in some state of not-knowing. **Authorise these first**; un-actioned RMAs convert to chargebacks at roughly 5% rate after 7 days. 2. **Authorised count exceeds Received count.** Normal pattern: 41 in transit, 38 already arrived. The 3-RMA gap is reasonable carrier-transit volume. If the gap grows to 50+ Authorised vs 20 Received, the carrier has a backlog or labels are being printed but not used. 3. **Received but not yet Refunded (38 - 16 = 22 RMAs)** are the warehouse-floor delay. The goods came back; the refund hasn't fired yet. Each day in this state is a customer-service email; **target same-day inspect-and-refund** for fastest customer satisfaction. 4. **7 Rejected is normal** (5-10% rejection rate is healthy; below 2% suggests the policy is too generous, above 12% suggests poor customer-side communication of policy). The seven rejected customers will likely complain via email or social; have a CS template ready. 5. **Total RMA count of 125 vs refund-count card at 96.** The 29-RMA gap is the *refund-without-return* universe (immediate refunds for damaged-in-transit, "keep it" goodwill, gift-card refunds). On Amazon-heavy stores this gap can exceed 80% of total refund count; this is the Amazon A-to-Z claim system in action. The action playbook this card surfaces: 1. **Triage Pending first.** Every Pending RMA is a CS ticket waiting to escalate; 24h authorisation SLA is the standard. 2. **Reduce the Received-to-Refunded latency.** The 22 RMAs sitting Received-but-not-Refunded are the highest-leverage CS improvement; same-day refund after warehouse receipt drops customer-satisfaction complaints by 30-50%. 3. **Inspect Authorised volume against carrier transit time.** If Authorised-minus-Received grows above 1.5x typical transit time, the carrier has a problem. 4. **Audit Rejected reasons quarterly.** If the same reason keeps appearing (policy-period exceeded, item-condition issue), tighten product-page communication to reduce future rejections. 5. **Pair with [BC Refund Count](/nerve-centre/kpi-cards/bigcommerce/refunded-orders)** to see the refund-without-return gap. Investigate cases where the gap is larger than 30% on web; they signal goodwill-refund creep. ## Sibling cards merchants should reference together | Card | Why pair it with Return Status | | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | [BC Refund Count](/nerve-centre/kpi-cards/bigcommerce/refunded-orders) | The financial twin. Returns minus refund-without-return scenarios = RMA count. The two should reconcile to within 20% on web-only stores. | | [BC Refund Value](/nerve-centre/kpi-cards/bigcommerce/refund-value) | The dollars completing the RMA lifecycle. Returns at the Refunded status drive this card. | | [BC Top Refunded](/nerve-centre/kpi-cards/bigcommerce/top-refunding-customers) | SKU-level attribution. Most returns cluster on a small SKU set; size-fit issues on apparel, defect rates on electronics. | | [BC Refunds Over Time](/nerve-centre/kpi-cards/bigcommerce/refunds-over-time) | Time series. Returns lag refunds by 5-10 days (goods take time to come back); reading the two charts side by side reveals the lag. | | [Fulfillment Rate](/nerve-centre/kpi-cards/bigcommerce/fulfillment-rate) | Forward correlate. Stores with fulfilment issues (wrong-item, damaged-in-transit) have higher return rates. | | [BC Channel Refund Rate](/nerve-centre/kpi-cards/bigcommerce/refund-rate-by-channel) | Channel split. Marketplaces don't flow into this card; the rate-card shows their separate numbers. | | [Cancellation Rate](/nerve-centre/kpi-cards/bigcommerce/cancellation-rate) | Different lifecycle: cancellations don't generate RMAs. Track both for the full "didn't stick" picture. | | [BC Refunded Products](/nerve-centre/kpi-cards/bigcommerce/most-refunded-products) | Line-item attribution for returns where a multi-item order had only some items returned. | | [BC Alert Refund Rate Spike](/nerve-centre/kpi-cards/bigcommerce/refund-rate-spike-alert) | Anomaly detector. RMA volume spikes precede refund spikes by \~5 days. | | [BC Top Customers](/nerve-centre/kpi-cards/bigcommerce/top-customers) | Best customers also return more (more orders = more returns); don't penalise high-return high-revenue customers operationally. | ## Reconciling against the vendor's own dashboard **Where to look in BigCommerce's own dashboard:** The native view is **BC Control Panel → Orders → Returns**. Filter by status to see the same buckets. The total count footer should match this card directly. For per-RMA detail, click into any RMA to see the full lifecycle log (created → authorised → received → refunded), with timestamps for each transition. This is where SLA analysis happens. For Standard tier (no Returns module), there is no native Returns Centre; merchants typically track returns in a third-party tool (Loop Returns, Happy Returns, Aftership Returns Centre). In that case, this card will be empty or near-empty; reconcile to the third-party tool directly. **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. RMAs created within a few hours of the boundary may bucket differently. | | **Sync lag** | Ours lower for last 30 minutes | Returns API webhook fanout is every 15-30 minutes. | | **Status granularity** | Possibly different | BC sometimes adds intermediate statuses (`Inspecting`, `Awaiting Stock Adjustment`) that we collapse into the closest five-bucket category. | | **Third-party Returns tools** | Ours blank | If the merchant uses Loop / Happy Returns instead of BC Returns, this card has no data; reconcile to the third-party tool. | | **Marketplace returns** | Ours blank | Amazon / eBay returns don't flow into BC's Returns API; they live on the marketplace. | | **B2B Edition returns** | Either | B2B Edition has its own returns workflow with different status names; depending on configuration, this card may or may not include them. | **Cross-connector reconciliation (when both connectors are connected for this merchant):** | Card | Expected relationship | Notes | | --------------------------------------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_refund_count`](/nerve-centre/kpi-cards/stripe/refund-count) | Stripe count >= RMAs at `Refunded` status | Stripe sees every refund event, including refunds that bypass the BC Returns flow. The gap is refund-without-return cases. | ***
Documentation cross-reference (for agencies running multiple platforms) The return-status concept exists differently across platforms. Shopify's Returns API has a similar status enum but BC uses different state names. Adobe Commerce's RMA module is the closest equivalent. * [`shopify.return_status`](/nerve-centre/kpi-cards/shopify/return-status) * [`adobe_commerce.return_status`](/nerve-centre/kpi-cards/adobe-commerce/return-status)
## Known limitations / merchant FAQs **Why is my Pending count growing every week?** You're under SLA on RMA authorisation. Pending RMAs that aren't authorised within 24-48h become customer complaints; the cohort grows because new requests arrive faster than CS clears them. Either increase CS capacity for RMA processing, automate auto-authorisation for in-policy requests, or tighten the policy filter so fewer RMAs become Pending in the first place. **My Received count is much lower than Authorised, what does that mean?** Customers received the return label but didn't ship the parcel. This is a structural pattern: 10-25% of authorised RMAs never come back (customer changes their mind, can't be bothered, loses the label). It's not a problem unless the un-shipped rate exceeds 30%. **Treat un-returned-after-Authorised as a goodwill-savings signal**; you authorised a return that didn't cost you anything. **Why is the Rejected count high on Mondays?** RMAs submitted over the weekend are processed Monday morning, including the rejected ones. Day-of-week pattern is normal CS workflow. **Why don't my Amazon returns appear here?** Amazon Channel Manager doesn't sync Amazon-side returns into BC's Returns API; those returns are managed entirely on Amazon Seller Central. **This card is web-only on most stores.** For the Amazon view, log into Seller Central → Reports → Return Reports. **My RMA shows Received but the warehouse never got it, why?** Most likely the Receive step was triggered prematurely (CS clicked "received" without warehouse confirmation, or the carrier scan-event triggered an automatic receive that the warehouse hasn't processed). Audit a sample monthly to keep the data clean; this is the most common Returns-module data-integrity issue on BC. **Can I see the value of pending vs received returns?** Yes via Ask Viq: "show value of returns by status for last 30 days". Pending value is your forward refund-liability; received value is the imminent refund-liability. **How does this differ from Loop Returns / Aftership Returns Centre dashboards?** Different tools, same idea. Third-party Returns tools typically have richer status models (`In Transit`, `Inspected`, `Approved for Refund`, `Approved for Exchange`, etc.). If you use a third-party tool, that's your authoritative source; this card has no data. **My Refunded count is lower than my refund\_count card, why?** Two reasons. First, the refund\_count card includes refunds-without-returns. Second, partial refunds may close an RMA without flipping it to `Refunded` status (BC's RMA module sometimes leaves the RMA Open if only part of the items came back). The cleanest reconciliation is RMA count at any post-Authorised status (Received + Refunded + Rejected) \<= Refund count, with the gap being refund-without-return. **Should I auto-authorise RMAs?** For in-policy requests within 30 days of delivery, yes; auto-authorisation cuts the Pending queue near to zero and improves customer satisfaction. For out-of-policy or high-value items, keep manual review. Configure in BC Returns settings. **What's a healthy rejection rate?** 5-10% across most categories. Below 2% means policy is overly generous (you're refunding goods you shouldn't); above 12% means policy isn't communicated clearly enough on the product page. Audit rejected RMA reasons quarterly to tighten communication. **My B2B Edition returns are showing weird statuses, why?** B2B Edition has its own returns workflow with custom statuses ("Awaiting PO Approval", "Inspection Pending"). Depending on Returns configuration, BC sometimes maps these to native statuses inconsistently; some configurations show B2B returns under `Pending` indefinitely. Check Returns module settings. **Can I export the RMA list?** Yes via Ask Viq: "export RMAs from last 30 days as CSV". Includes RMA ID, order ID, customer ID, status, created date, items, reason, value. *** ### Tracked live in Vortex IQ Nerve Centre *Return Status* 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.