Here's how it goes. A buyer clicks "refund," the platform approves it, the money's gone — and your inventory count jumps right back up.
But where's the actual product? Still in the buyer's hands. Or on a truck somewhere. Or never coming back at all.
That gap — between the refund being issued and the returned unit actually becoming sellable again — is where sellers bleed money. Let me show you my scars.
The current state: your inventory numbers are lying
Most OMS setups work like this by default: refund approved → inventory auto-replenished to sellable.
Sounds reasonable, right? Money went out, the goods will come back eventually, so add the stock now to avoid stockouts.
The problem is the word "eventually." Return shipping takes 5–12 days. Warehouse receiving and QC adds another 1–3. During those two weeks, your "sellable" number is stuffed with units that haven't come home yet.
I call them ghost units. On the books, but not on the shelf.
Pitfall #1: overselling during the post-promo return wave
November 2024, the week after Black Friday. Our Shenzhen warehouse (self-fulfilled, OMS wired to our own WMS).
Over 300 refunds that week. The OMS did its default thing: refund approved, inventory replenished. Every time.
We had a hero SKU selling about 120 units a day. The system showed 200 sellable, so we kept the ads running full blast. Turns out the warehouse could only actually ship 40 — the other 160 were mostly "refunded, in transit."
We oversold 60+ orders. The platform auto-cancelled them, our cancellation rate shot past 4%, and we nearly triggered an account warning.
Lesson learned: return rates during promos run 2–3x normal, and ghost inventory scales right along with them. A rounding error in normal weeks becomes a full-blown incident in peak season.
Pitfall #2: refund-without-return makes inventory appear from thin air
This one's sneakier.
Quality complaints, lost parcels, wrong-item shipments — plenty of platform policies just issue the refund and tell the buyer to keep the item. The OMS replenishes inventory anyway.
Take a power bank selling around $70. A dozen "refund, no return" cases in a month, and the books magically gain a dozen units. Month-end counts never reconcile.
At our worst, we had 80+ ghost units sitting in a virtual "awaiting return" status. Count variances hit 300+ units a month. The warehouse guys were furious.
Do the math: five steps from refund to sellable
Break the chain down and the timing gap is obvious:
| Step | Action | Typical lag |
|---|---|---|
| 1 | Buyer requests refund | 0 |
| 2 | Refund approved (or auto-approved) | 0–2 days |
| 3 | Return shipment in transit | 5–12 days |
| 4 | Warehouse receiving + QC | 1–3 days |
| 5 | Restocked as sellable | — |
From step 2 to step 5, that's one to two weeks. The OMS default replenishes at step 2 — you're "spending" inventory two weeks before it exists.
Three replenishment strategies, compared:
| Strategy | Replenish when | Upside | Risk |
|---|---|---|---|
| Aggressive | On refund approval | Never stock out | Oversell, platform penalties |
| Conservative | Only after receiving + QC | Books always true | Hot SKUs may stock out |
| Hold (recommended) | Refund → frozen "awaiting return" state → sellable only after QC passes | Books match reality | One more inventory state to maintain |
The counterintuitive part: slower replenishment makes more money
Most sellers' first instinct: replenish fast, don't miss sales.
Wrong math. One oversold order costs you: platform cancellation strikes, bad reviews, refund fees, support time — way more than the margin on one unit. Meanwhile the "cost" of a few missed sales is just delayed revenue.
Overselling is a certain loss. A stockout is only a possible missed opportunity. When in doubt, keep the books conservative.
That's why I say the OMS default of "refund = replenish" isn't a software bug, but it is a trap. The default made the most aggressive choice for you.
What we do now
Early 2025, we rewired the logic. Five rules, nothing fancy:
First, decouple refunds from replenishment. A refund is a financial event; receiving is a warehouse event. Two separate state machines. Approving a refund no longer touches sellable stock.
Second, add an inventory state: "awaiting return." After refund approval, units go into this frozen bucket — not sellable. Only when the WMS receives and QC-passes them do they flip back to sellable.
Third, partial refunds never move inventory. Refunding just the shipping fee or a discount credit? The goods didn't move, so not a single unit changes. Hard-coded.
Fourth, auto-write-off after 15 days. Buyer said they'd return it but never shipped? Inventory can't hang forever. Fifteen days is our empirical number — tune it to your own return lead times.
Fifth, review the "awaiting return" aging report weekly. Anything over 10 days, customer service proactively follows up with the buyer.
The numbers
Three months after the change:
Oversell rate: 1.1% → 0.2%. Monthly count variance: 300+ units → under 40.
One side benefit: customer service stopped arguing with the warehouse every day about whether an order "actually has stock," response times got faster, and our negative review rate dropped half a point too.
Last Black Friday: 900+ refunds processed, zero oversells.
Pitfall reminders
A few more, so you don't learn them the hard way:
Platform refund webhooks lag and sometimes fire twice. Make your replenishment logic idempotent — the same refund pushed twice must never add stock twice.
Return orders and refund orders often don't match one-to-one: one order with multiple refunds, merged returns, exchanges. Replenish based on actual received SKUs, never reverse-engineer from refund amounts.
FBA-style platform fulfillment runs a completely different inventory logic. Don't force self-fulfillment rules onto it.
Lost parcels and refund-without-return cases: write the inventory off in one go. Don't let them squat in "awaiting return" pretending they'll come back.
This one I've tested myself. It works.
By Ah K, E-commerce Seller (5 yrs)
