A 25 euro return on a product with a 6% return rate is hiding in your margin

Short answer. A return costs processing, shipping both ways, and sometimes a write-down. With a processing cost of 25 euro and a return rate of 6%, every product carries a fixed cost component that you have to allocate to your margin. A returns module books the credit note, but it does not make the decision about what happens to the product and the costs. That is your process.

Returns are part of e-commerce. The average return rate sits between 20% and 30%, in women's fashion even above 40%, and on marketplaces it varies per platform (source: Thuiswinkel.org). The question is not whether you have returns. The question is whether you know what they cost you.

What does a return really cost?

Not just the shipping back. A return costs the processing, the shipping both ways, the inspection, and sometimes a write-down because the product no longer sells as new.

Do the math and it becomes concrete. If a return costs 25 euro to process and the return rate of a product is 6%, then every unit sold carries a slice of return cost. That belongs in your price and in your margin, not as a surprise at the end of the quarter.

Tracking return rate per product and per channel

An average return rate tells you little. The average hides the outliers.

What you want to know: which products come back most often, and for what reason. And which channel costs you the most in returns. A product that sells perfectly well on your own shop can have a return rate on a marketplace that eats up the margin. If you cannot see that per channel, you steer on revenue while a channel is costing you money.

The decision a returns module does not make

A returns module knows one flow: request, approval, refund, back in stock. But the real question is a decision tree.

• Does this product go back into stock, to an outlet channel, or to the write-off?
• Who pays for the return, and can you push the costs back to the supplier or claim them under warranty?
• Is this a serial returner you want to treat differently?

Those are decisions, not status changes. The software books a credit note. Your process makes the decision, and it differs per business because your products, channels and supplier agreements are yours.

Charging back and allocating return costs

This is where it connects to your margin. A return caused by a product fault belongs with the supplier, not with you. But you can only charge that back if you link the return to the right supplier and the right purchase order.

That only works if your sourcing overview is accurate. That is why this ties in with tracking purchasing across multiple suppliers: without knowing what you bought from which supplier, you cannot push a return back to where it belongs.

The question is not only why you do it this way, but what goal you want to reach: control over your return costs, with less manual work. That is why I review your returns process thoroughly first. Some of the returns have simply grown over time and get solved by addressing the cause. The rest, the allocation and the decision tree, I build so they run automatically with every return, instead of you having to do them by hand each time.