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 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 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. |
| 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 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% |
- 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.
- 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.
- 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.
- 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.
- 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.
- Triage Pending first. Every Pending RMA is a CS ticket waiting to escalate; 24h authorisation SLA is the standard.
- 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%.
- Inspect Authorised volume against carrier transit time. If Authorised-minus-Received grows above 1.5x typical transit time, the carrier has a problem.
- Audit Rejected reasons quarterly. If the same reason keeps appearing (policy-period exceeded, item-condition issue), tighten product-page communication to reduce future rejections.
- Pair with BC Refund Count 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 | 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 | The dollars completing the RMA lifecycle. Returns at the Refunded status drive this card. |
| BC Top Refunded | SKU-level attribution. Most returns cluster on a small SKU set; size-fit issues on apparel, defect rates on electronics. |
| BC 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 | Forward correlate. Stores with fulfilment issues (wrong-item, damaged-in-transit) have higher return rates. |
| BC Channel Refund Rate | Channel split. Marketplaces don’t flow into this card; the rate-card shows their separate numbers. |
| Cancellation Rate | Different lifecycle: cancellations don’t generate RMAs. Track both for the full “didn’t stick” picture. |
| BC Refunded Products | Line-item attribution for returns where a multi-item order had only some items returned. |
| BC Alert Refund Rate Spike | Anomaly detector. RMA volume spikes precede refund spikes by ~5 days. |
| BC 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. |
| Card | Expected relationship | Notes |
|---|---|---|
stripe.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. |
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.