How to Handle Returns Without Losing Inventory Accuracy

Returns damage inventory accuracy for two reasons, and neither is sloppy counting. The first is that a returned unit often has nowhere to be while it waits, so it exists on your dock but not on any report. The second is that the refund and the restock get collapsed into one event, when they are two decisions with different owners and different information behind them. Give every returned unit a scannable resting place the moment it arrives, keep disposition a separate decision made after somebody opens the box, and the returns bench stops being the place your count goes to die.

Why do returns damage accuracy differently from picking errors?

Not because they are worse, but because they fail in a way your existing controls are not shaped to catch.

A mispick is hard to trace, but it is at least symmetrical. A picker takes the wrong unit from an adjacent bin and you get a compensating pair: one location short, one long, netting to zero on any summary report. That is genuinely annoying to find, and it is the sort of thing a cycle count program is built for. The variance has a shape, it sits in a location you already count, and the count schedule will eventually reach it.

A return has no such shape. It arrives unannounced, in unknown condition, against an order that closed three weeks ago, sometimes with no paperwork at all. Some share of what lands on any returns dock is blind: no packing slip, no order number, nothing to receive against until somebody works out what it is. And it lands in an area that in many warehouses is not a location in the system, which means the usual safety net, the cycle count, cannot catch it. You cannot count a place that does not exist.

The volume is what makes this structural rather than occasional. The National Retail Federation and Happy Returns projected total retail returns of 849.9 billion dollars for 2025, with an estimated 19.3 percent of online sales returned and 9 percent of all returns found to be fraudulent. That 19.3 percent is a share of sales value rather than of units, and returns skew toward higher-ticket categories, so the unit rate will differ. Either way it is not a rounding error, and it is moving through the flow that usually has the least process attached to it. The connection to the wider cost of getting this wrong is laid out in the real cost of inventory inaccuracy.

What state is a returned unit actually in?

It helps to separate the places a unit physically rests from the decisions made about it. The resting places are: in transit from the customer, on the dock awaiting disposition, in quarantine, in repack, staged for a vendor return, or back in sellable stock. The decisions, inspection and disposition, are keystrokes that move a unit between those places. Conflating the two is how returns areas end up with statuses instead of locations.

There is a second split worth naming, because it is the one that actually breaks. The return record and the physical unit travel separately. Shopify's return-management documentation models a return as a record with its own lifecycle, moving through requested, open, declined, closed and canceled, and that lifecycle is separate from any inventory movement. A return can be open for days while the box is still in a van. Nothing in the record's state tells you where the unit is.

Closing that gap is an integration problem before it is a floor problem, and it is worth being honest about that. Floor discipline alone will not tell the return record that a carton arrived. Something has to write the receiving scan back to the record, or the two halves keep their own versions of the truth.

Does a refund have to mean a restock?

No, and it is worth separating what actually constrains you from what does not.

Shopify's own guidance on managing returns describes the order plainly: "After you receive and inspect the returned items, you can issue a refund." Inspection before refund is the documented flow, not a stricter standard somebody invented.

On the legal side, the federal rule most often cited in this area is narrower than its reputation. The Federal Trade Commission's Mail, Internet, or Telephone Order Merchandise Rule sets a refund clock, seven working days from the date the buyer's right to a refund vests, or one billing cycle where the seller is the creditor. But it is triggered when a seller cannot ship within the promised time and the order is cancelled. It does not address merchandise a customer voluntarily returns after receipt, and it carries no provisions on inspecting returned goods or on restocking fees. That is a narrow finding, not a licence: your published policy, your card network agreements, your marketplace contracts and several state statutes on posted refund policies may each set a deadline you are bound by. Check what you have actually committed to rather than assuming either direction.

What none of those constrain is the inventory move. Real deadlines on a returned unit do exist, and they are worth knowing: vendor return windows that void a credit if you miss them, contractual processing times with a third-party logistics provider, and in regulated categories such as food or pharmaceuticals, rules that may prohibit restocking a returned unit at all. None of them say the unit must go back into sellable stock the moment the customer is refunded.

The tooling assumes the two are separate. Shopify's refund model treats restocking as an explicit choice rather than an automatic consequence: its restock type values include NO_RESTOCK, documented as "Refund line item was not restocked", alongside RETURN, which the documentation says to use "when restocking line items that were fulfilled", and CANCEL, "when restocking unfulfilled line items". Its return-management guide states that the return-processing operation "also supports dispositions, allowing you to decide whether a returned item will be restocked into inventory as part of the processing step".

Refund on whatever clock you are actually bound by. Restock on the inspection's. They look like one event mainly because a screen puts the buttons next to each other.

Where should returned stock physically live?

Put a location wherever a unit comes to rest, sellable or not. That is the rule, and it is deliberately not "wherever a unit can be promised to a customer", because most of these places are ones a unit explicitly cannot be promised from.

The set worth having:

• Received, awaiting disposition. Usually carton-level on arrival, becoming unit-level once the box is opened and the contents are known.
• Quarantine or hold. Damaged, missing parts, suspected fraud, awaiting a decision.
• Repack or refurbishment. Sellable after work, not before.
• Vendor-return staging. Units waiting on a return authorisation number, which is where phantom inventory breeds, because they sit for weeks.
• Scrap or destruction hold.

The inspection bench is the exception. It is a place a unit passes through, not one where it rests, and putting a scan on it adds two transactions per unit for very little accuracy. Teams skip those scans on a busy Monday, which manufactures the variance you were trying to prevent.

A status on an order record is not a location. A status tells you what a system believes; a location tells a person where to walk. When the two disagree, neither one is automatically right. Go and look at the unit, then correct both records to match what you found. That is the whole discipline, and it is the same one described in what inventory accuracy is and how to measure it.

How do you decide what goes back into sellable stock?

Disposition is a per-unit decision with a reason code, and the reason code is what makes it reviewable later. The practical set: back to sellable stock, repack and then sellable, route to a secondary channel, return to vendor, donate, scrap, or refuse the return and send it back.

Two things make it work. The inspector has to be allowed to say no, because if the only fast path through the screen is "restock", everything becomes sellable and the inspection is decorative. And the reason code has to be specific enough to act on. "Damaged" tells you nothing. "Damaged in outbound packaging" tells you to change the box.

On fraud, be precise about what receiving actually catches. Scanning the contents against what the return says should be there catches empty cartons and substituted items. It does not catch wardrobing, where the correct unit comes back worn, and that is a large part of the problem the 9 percent figure covers. Screening at the authorisation stage and inspection quality catch that one; a receiving scan will not.

One consequence that gets skipped: a unit refunded but not restocked is not free. It is on hand and not available to promise, it does not net against a reorder point, and if that state lasts, you are carrying stock you cannot sell while reordering as though you had none. Decide deliberately how long units are allowed to sit awaiting disposition, because that number is a working-capital decision as much as an accuracy one.

How do you count a returns area?

By age, not by location rotation. The population turns over in hours, the units are condition-unique, and a variance tolerance against a location whose contents are different every morning does not mean much. Work the oldest unresolved units first and review weekly.

A pile that keeps growing is a signal, but diagnose it before staffing it. It is at least as likely to be a vendor that has not issued return authorisations, disposition rules ambiguous enough that inspectors escalate everything, refurbishment parts on backorder, or returns arriving with no data to match them to an order. Cut the pile by reason code and age first. The scheduling and variance mechanics are the same ones covered in the complete guide to cycle counting.

What to fix first

1. Make the resting places real, scannable locations. Nothing else works until a unit has somewhere to be.
2. Receive on arrival, at carton level if that is all you can identify, and have that receipt write back to the return record. That write-back is the integration worth building.
3. Keep the refund decision and the disposition decision separate in the written process, and accept that they will usually be made by different people in different systems.
4. Add reason codes to disposition, then actually read them monthly, cut by age.
5. Decide how long a unit may sit awaiting disposition before it is escalated.

None of this makes returns cheaper on its own. It makes them visible, which is the prerequisite. A warehouse that knows it has four hundred unresolved units on a returns bench, and knows why, has a problem it can work. A warehouse that has quietly pushed those four hundred units into available stock has an accuracy problem it will not discover until a customer does.