# Return reason codes: a taxonomy retailers can actually audit | WardrobeAudit

Source: https://wardrobeaudit.com/blog/2026-10-13-return-reason-code-taxonomy.html

October 13, 2026

A workable return reason taxonomy separates three things most retailers merge: what the customer said, what inspection found, and what the pattern suggests. Keep customer selected reasons short and honest, add a separate warehouse finding code, and let analytics derive risk flags. Audits fail when one code is asked to do all three jobs.

## Why current reason codes fail audits

Open any retailer's returns data and the largest code is usually something like changed mind or did not like, covering a third of all returns. That code contains genuine preference returns, sizing experiments, quality complaints the customer did not bother to explain, and a share of wardrobing that nobody identified. An audit built on it can measure volume and nothing else.

The root problem is a category error. The checkout form asks the customer for a story, the warehouse knows the physical truth, and the fraud question is about behavior over time. One dropdown cannot carry all three, so it ends up carrying none of them reliably.

## Layer one: the customer reason, kept short

The customer facing list should have six to eight options maximum, written in shopper language: wrong size, wrong fit, not as pictured, quality issue, changed mind, arrived late, damaged, other. Short lists get honest answers. Long lists get random clicks from customers who just want their label printed.

Two design rules matter. Never offer a code that accuses, because customers will route around it and poison the data. And always pair size and fit as separate codes: size is a catalog problem, fit is a product design problem, and merging them hides which team should fix what.

## Layer two and three: findings and flags

Warehouse inspection gets its own code set, recorded by staff, never shown to customers: resellable as new, worn or used signs, missing tags, damaged in transit, wrong item returned, empty or partial return. This layer is where wardrobing actually appears in data, because it records condition rather than stories.

The third layer is derived, not collected. Analytics combines customer history, timing, category, and inspection findings into flags: repeat worn returns, event timed returns, cross category patterns. Keeping flags derived rather than collected means they can be recomputed as models improve, and no frontline process has to accuse anyone to produce them.

## Running the audit on the new taxonomy

With three layers, the audit questions become answerable. Compare layer one and layer two: where customers say changed mind but inspection says worn, you have a measurement of your wardrobing exposure by category. Compare categories against each other and the taxonomy tells you where to tighten inspection, adjust windows, or fix sizing content.

Review the taxonomy quarterly. Codes that collect less than one percent are candidates for removal, and any new code needs an owner and a decision it will inform. A taxonomy is a measurement instrument. Like any instrument, it drifts, and the audit team's real job is keeping it calibrated.

## Frequently asked questions

### How many return reason codes should a retailer offer customers?

Six to eight. More than that and customers choose randomly to finish the form, which destroys the data. Keep the customer list short and shopper friendly, and put the detailed classification in the warehouse inspection layer instead.

### Why separate customer reasons from warehouse findings?

Because they measure different things and often disagree. The customer reports a story, inspection records physical condition. The gap between the two, by category, is one of the most useful audit signals a retailer has, and it only exists if the layers stay separate.

### Can reason codes detect wardrobing on their own?

No single code can. Wardrobing shows up in the combination of inspection findings, return timing, and customer history. That is why risk flags should be derived analytically from all three layers rather than collected as a form field.

### How often should a returns taxonomy be reviewed?

Quarterly is a good rhythm. Remove codes nobody selects, split codes that have grown to cover too much, and check that every code still has an owner and a decision attached to it. Taxonomies decay quietly without a review habit.