How Do I Find the Returns That Are Actually Costing Me Margin?

Why your returns report doesn’t show the most expensive cases 

Because it sorts by percent and your problem shows up in euros.

A standard report ranks items by return rate. That always puts the small-volume outliers on top. The item that eats the most margin in absolute terms usually has a normal rate and never appears in the list.

On top of that, three cases disappear inside the overall rate:

1. Distorted monthly figures
2. Uncollected shipments
3. Returns with no reason

You only find any of the three if you go looking.

The scale of this is why it’s worth the effort. According to the EHI study "Shipping and Returns Management in E-Commerce 2024" processing costs are between €5 and €10 per return at 30% of surveyed retailers, and between €10 and €20 at another 26%.

And the Bamberg University research group on returns management estimates around 1.3 billion returned items per year in Germany, spread across roughly 530 million return shipments. Every item you prioritize wrong costs you multiple times over.

The following five analyses cover this. All example figures come from a demo dataset of 1,308 returns line items from 5,200 orders.

We walked through them in our AI Vibe Club where we built a skill for returns analysis.

Why is my return rate dropping in the current month when nothing has changed? 

Because the returns are still in transit.

A return arrives weeks after the order. If your report counts it in the month it lands, you’re comparing a closed month to one whose return window is still open. The most recent month always looks better.

In the demo dataset, 7.4% had come back in the most recent month. Extrapolated over the full return window, the real figure was 12.7%.

The test takes five minutes. Pull the same report for a month that’s a year old and compare it against what it showed at the time. If the numbers diverge, your report is counting by intake month.

What you need instead:

• Every return counts against the order month.
• Any month whose return window is still open is flagged as incomplete.
• Immature months carry an extrapolated final figure based on the timing pattern of closed months.
• Nobody presents an immature month as a trend.

Which items cost me the most when the rate looks normal? 

The ones that don’t appear at the top of your report.

In the demo dataset, five variants of one item had rates between 11.9% and 16.9%. Completely normal for fashion. Together they cost €10,622. Reducing that rate by one point on this item is worth more than fully fixing a niche item.

How to flip the view:

Rate by value is the fastest extra check: refunded revenue divided by shipped revenue. If it’s higher than the rate by unit, your returns are more expensive on average than what you’re selling. In the demo dataset it was 15.8% vs. 14.1%, so returns were about 11% more expensive.

A second pattern from the same logic: if return reasons for an item spread evenly across all sizes, you don’t have a variance problem, you have a pattern cut error. In the demo dataset, one hoodie had 114 returns with the reason "too small" against 6 for "too large". The size chart is off.

Packages that never reached the customer are coming back 

Because they sat in a parcel locker or store pickup point. And because your system doesn’t tell them apart.

The sequence: the package goes to the pickup location. The carrier reports it delivered, because to them it is. The pickup window expires, the shipment goes back, and it lands in your data as a normal return. Usually with no usable reason.

It looks like any other return and disappears into the overall rate. One large e-commerce brand lost €468,000 this way and only found it when they consolidated their data and searched systematically.

In the demo dataset, there were 94 such shipments: 1.81% of all orders, but 8.09% of all return events. €9,825 in revenue that never materialized. In the shipping stats, everything was green.

How to find them: you need to look at delivery status, return reason, and payment method together. Shipments without a return reason that come back shortly after the delivery confirmation are the usual suspects. With invoice payment, they cluster.

Make it a separate category.

As long as these cases run in your return rate, you’re optimizing the product when the problem sits in shipping and payment method.

Returns with no reason: what to do 

First, check whether the gap itself is a pattern.

In the demo dataset, 150 out of 1,308 return line items had no usable reason. That’s 11.5%. If those gaps spread evenly, it’s noise. If they cluster on specific items or return paths, there’s a case sitting there.

Behind this is a structural point. Return reasons are freely configurable in most systems. The reasons your customers select in the portal are often different from the internal ones. There’s no unified schema.

That’s why consolidating the columns is the first and most tedious step in any returns analysis. Skip it and you’re calculating on an unverified data foundation.

Is a low return rate always a good thing? 

No. And that’s the most important sentence in this article.

The relationship between return rate and profitability isn’t linear. Zero returns isn’t the optimum. Anyone who targets the rate ends up shortening return windows or dropping payment methods at some point, and loses more orders than they save in return costs.

The rate is an observation. The target metric is contribution margin after returns.

So calculate all the way through to gross margin instead of stopping at the percentage. In the demo dataset, the chain looked like this: €524,829 in shipped revenue, minus €92,854 in refunded revenue, minus COGS of the kept goods, minus return processing, minus written-off defective goods.

What’s left is €259,945 gross margin after returns.

In practice: before you sign off on a measure, calculate it against margin. An item with a 30% return rate and good margin can be more profitable than one with an 8% rate and thin margin.

The data foundation for returns analysis 

Returns line items: order ID, return date, item number, variant, customer number, channel, payment method, refund amount, return reason, return type (customer return or uncollected).

Sales line items: same keys plus order date, net revenue, and cost of goods.

One condition matters: the sales export has to cover the returns period plus the return window going forward. Otherwise you’re calculating returns against an incomplete sales base and all rates come out too high.

Missing a column isn’t a stop condition. Note which analysis it kills, run the rest. Without a batch column, for example, you can see a defect cluster but can’t assign it to a specific delivery.

How can I use AI for returns analysis? 

By writing it down once instead of explaining it again every quarter.

That was the case in the AI Vibe Club. Yves Schleich from Path to AI showed a returns analysis skill with Jörg Hipper, Head of Marketing at Xentral, and walked through how it came together.

You drop in the two exports and get the findings sorted by dollar value, with recommended actions.

A skill isn’t a technical thing. It’s a text file with the instructions, rules, and exceptions for a recurring task. Without it, you explain it fresh every month and get a slightly different result each time.

Three rules separate a useful analysis from a dangerous one:

• The script calculates, the model interprets. Every number in the report comes from a file produced by a calculation script. No model calculates rates itself. Side benefit: the order lines stay local.
• Every finding carries an evidence tier. Directly supported by the data, plausible interpretation, or only verifiable with an additional column.
• A dedicated section for what’s fine. Otherwise every number gets flagged as a problem and your team ends up working on noise.

Every measure that comes out of an analysis like this is a test to run. Set it up as an A/B test and define upfront what mustn’t break in the process.

How do I build a returns analysis skill like this myself? 

In eight steps (but only the last one actually produces the skill).

Most people take two shortcuts: recognize the workflow, type "build me a skill for this." Then they’re unhappy with the result.

1. Talk through the context instead of typing it. Speaking, you deliver several times the background.
2. Check whether the skill already exists.
3. Have the AI research what’s established on the topic: studies, field experiments, benchmark values.
4. Have the AI argue against your own hypothesis.
5. Cut the scope for version 1.
6. Build the first version. This still isn’t a skill, just the analysis logic.
7. Test with real exports, check numbers and format, iterate.
8. Now generate the skill, using Anthropic’s skill creator.

Step 4 changed the outcome in this session. The pushback hit the metric itself, and that turned into the guardrail that the rate isn’t the target.

It’s not finished after that. A skill behaves like software. New patterns come up in use, and those flow back in.

Returns analysis: how to start today 

With three questions against your own numbers. You don’t need new software.

1. Which month does a return count against in my report: the order month or the intake month?
2. What does my item list look like sorted by return cost in euros instead of rate?
3. How many of my returns are actually uncollected shipments?

If any of the three answers surprises you, you have your first case. And the proof that the rate alone isn’t telling you where your margin is going.