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.
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.
What’s interesting:
- 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
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:
Cross-connector reconciliation (when both connectors are connected for this merchant):
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.