The RMA and Returns Process: How to Handle Returns Without Losing Money
Returns are not an edge case. If you sell physical products, somewhere between 5% and 30% of what goes out comes back, and every returned unit needs a decision. A clean RMA and returns process is what turns that flood into something you can track, cost, and recover value from, instead of a pile of boxes nobody wants to open.
RMA stands for Return Merchandise Authorization. It's the number you issue before a customer ships anything back. Below is what the process looks like end to end, a worked example with real numbers, and the two metrics that tell you whether yours is working.
RMA vs return: what the RMA actually does
A return is the event: a customer wants to send a product back. An RMA is the control you put in front of it.
Without an RMA, packages show up at your dock with no context. Receiving has no idea what's inside, whether it was approved, what condition to expect, or which order it ties to. With an RMA, every inbound return carries an authorization number that links it to the original order, the reason, and the resolution you already agreed to.
The RMA does three jobs:
- Screens out returns that fall outside your policy before shipping costs get spent.
- Gives receiving a heads-up so they can inspect and route the unit fast.
- Creates a paper trail for refunds, warranty claims, and your inventory count.
Skip it and you're reconstructing all of that after the fact, usually wrong.
The RMA and returns process, step by step
Here's the full flow. Seven steps, each with a clear owner.
- Request. Customer asks to return an item and gives a reason (defective, wrong item, changed mind, damaged in transit).
- Authorize. You check it against policy (in the return window? eligible category?) and issue an RMA number if it qualifies.
- Ship back. Customer sends the unit with the RMA number on or in the box, ideally on a label you generate.
- Receive. Your dock matches the inbound package to its RMA and confirms it arrived.
- Inspect. Someone checks condition against the stated reason. "Changed mind, unopened" and "defective, clearly used" get very different treatment.
- Disposition. Decide what happens to the unit: restock, refurbish, return to vendor, or scrap.
- Resolve. Close the loop with the customer: refund, replacement, store credit, or a denial with a reason.
The two steps people skimp on are 5 and 6. Inspection and disposition are where you either recover value or quietly destroy it.
A worked example
Say you run an electronics accessories shop. A customer returns a $60 wireless keyboard, reason "not compatible."
- Original sale: $60, your cost $28.
- Return shipping (you paid the label): $7.
- Inspection: unit is unopened, resalable as new.
Disposition: restock. You refund $60, put the unit back into sellable stock at its $28 cost, and eat the $7 return shipping. Net cost of this return: $7 plus a few minutes of labor. Not free, but cheap.
Now the same keyboard comes back "stopped working."
- Inspection: powers on intermittently, clearly used.
- Options: scrap it (lose the full $28 cost) or return to vendor under warranty.
- Vendor accepts it as a warranty defect and credits you $28.
Disposition: return to vendor. You recover the $28 instead of writing it off. The gap between a good process and a lazy one on this single unit is $28. Multiply that across a few hundred returns a month and disposition stops being a detail.
Restock, refurbish, return, scrap: the disposition call
Every received return lands in one of four buckets. Getting this routing right is most of the money.
| Disposition | When | Value recovered |
|---|---|---|
| Restock as new | Unopened, undamaged, in return window | Full resale value |
| Refurbish / open-box | Used but functional, cosmetic wear | Partial (sell at a discount) |
| Return to vendor | Defective under supplier warranty | Your unit cost, via credit |
| Scrap / recycle | Broken, unsafe, or unsellable | Zero (log it as a write-off) |
The rule: never auto-restock. A unit that goes back to "available" without inspection is how you ship a used, broken keyboard to the next customer and start the whole cycle over again.
The two numbers that tell you if it's working
Track these monthly.
Return rate tells you how much comes back.
Return rate = (units returned / units sold) x 100
Sell 4,000 units, take back 240, and your return rate is 6%. Watch it per product, not just overall. One SKU at 25% is a product problem (bad sizing, misleading photos, a defect), not a returns problem.
Recovery rate tells you how much value you claw back from returns.
Recovery rate = (value recovered from returns / original value of returns) x 100
If $10,000 of returned goods yields $7,500 back through restocking, refurb, and vendor credits, your recovery rate is 75%. That number is a direct measure of how good your inspection and disposition steps are. Sloppy disposition shows up here as a low percentage and real lost cash.
Where returns quietly break your inventory count
The failure mode is always the same: the physical unit and the number in your system disagree.
A return gets refunded but never received, so your count says you have one fewer unit than you do. Or it gets auto-restocked without inspection, so your "available" count includes a broken unit you can't actually sell. Do this a few hundred times and your on-hand numbers are fiction, which wrecks your reorder points and your reporting.
The fix is to treat every RMA as an inventory movement, not just a customer-service ticket. Receiving increments a "returns" or "quarantine" location, not sellable stock. Only a passed inspection moves the unit into available. Scrap decrements it as a write-off. Every step is logged.
Doing this in one system
This is where returns and inventory want to live together. Inventoros handles multi-location stock, so returns can flow into a quarantine location, get inspected, and only then move to sellable, with every movement logged. Because it's open source and self-hosted, you run it on your own server and own the whole trail. If you're wiring returns into a storefront or a helpdesk, the REST and GraphQL API and webhooks let an RMA update stock automatically, and the documentation covers install on cPanel, a VPS, or Docker.
FAQ
What is the difference between an RMA and a refund? An RMA authorizes the return of the physical goods. A refund is one possible resolution once the goods come back and pass inspection. You can issue an RMA and end with a replacement or store credit instead of a refund, and you shouldn't refund before you've received and inspected the unit.
How long should an RMA number stay valid? Tie it to your return window plus shipping time. A common setup is 14 to 30 days from issue for the customer to ship it back. After that the RMA expires and they have to request a new one, which keeps stale authorizations from floating around indefinitely.
Should returned items go straight back into sellable stock? No. Route them to a separate returns or quarantine location first, and only move them to sellable after inspection confirms condition. Auto-restocking without inspection is the fastest way to reship a defective unit and generate a second return.
How do I reduce my return rate? Look at reasons per product. If "not as described" or "wrong size" dominates, fix the listing (better photos, clearer specs, a size chart). If "defective" dominates on one SKU, it's a quality or supplier issue. You cut returns by fixing the top one or two reasons on your worst SKUs, not with a blanket policy change.