A refund belongs to the day it was issued, not to the day of the order it reverses. Book it backwards and last month's profit changes every time somebody returns something this month, so no month is ever final and no report you have already sent out stays true. Book it on the refund date and the past stays fixed while today carries the cost, which is noisier and correct. nouz books refunds on the refund date, with one deliberate exception: the product cost credited back is valued at the cost rule that was effective on the original order date, so the credit exactly reverses the original debit.
The two answers, and what each one costs you
This is a real choice and both answers are defensible on paper. Booking a refund back against the order it came from keeps the order whole: a report by order can tell you what that order finally earned. Booking it on the day the refund was issued keeps the day whole: what a day reports is what happened in it. You cannot have both, and almost nobody picks deliberately.
The cost of the first answer shows up the second time somebody reads a month. Returns arrive weeks after the sale, so a month is at its best on the day it closes and then decays for the next two months as its own returns come in. In an example store, returns ran at 4,81% of gross revenue over fourteen months, which is roughly one euro in twenty arriving late and landing on a month that has already been read, reported and acted on. The export you ran on the fifth disagrees with the system by the twentieth. Nobody did anything wrong, and the team quietly learns not to trust the report.
The cost of the second answer is real too, and worth conceding. A day with three large returns and modest sales can print a loss that has nothing to do with that day's trading. For a store with heavy returns a single day is a poor unit and a week is a better one. What you get in exchange is that yesterday's number is still yesterday's number tomorrow.
Shopify already takes the second answer on the revenue side, which is worth saying on a page like this one. From its sales reports documentation:
Returns display as a negative number on the date the return was processed.
What Shopify does not carry is any of the costs below the goods, which is the subject of what Shopify Analytics does not tell you. The dating question below is about those costs.
Why nouz books refunds on the refund date
Because a closed day has to stay closed. That is the whole reason. Every figure in the statement belongs to exactly one day, and once that recognition date is fixed for each of them, the entire P&L can be rebuilt from the raw orders and the cost rules at any time and come out the same to the cent. A number you can re-derive is the only kind anyone in a business will act on.
So on the refund date nouz recognises the refunded amount including refunded shipping, the refunded tax, the product cost credited back, and the cost of processing the return. On the order date it recognises the revenue, the product cost, the outbound logistics and the payment fees. Ad spend sits on the day it was spent, and fixed costs are spread across the days they cover. Cancelled and test orders are excluded from all of it.
The practical effect is that the daily profit email from 3 March, the P&L page today and an export somebody ran in May all agree about March, permanently. It also means today can look ugly for reasons that are two months old. We would rather explain that than explain why last month moved.
The one thing that does go back
One figure on a refund is deliberately valued by the past: the product cost credited back. It is priced at the cost rule that was effective on the original order date, not at today's cost. That single rule is what stops a supplier price change from inventing profit out of a return.
Work it through. You buy a unit in March under a cost rule of €18,00 effective from 1 Mar 2026. You sell it on 12 Apr 2026, so April carries €18,00 of product cost on the order date. Your supplier raises the price and you enter a new rule of €21,00 effective from 1 May 2026. The customer sends the unit back and you issue the refund on 9 Jun 2026.
- What nouz does: June is credited €18,00, because the rule effective on 12 Apr 2026 priced the sale. Debit and credit match, so the goods net to zero across the two months and June carries only the real cost of handling the return.
- Credit at today's cost instead and June gets €21,00 back against an April debit of €18,00. The store books €3,00 of margin nobody earned, on a unit that came back.
- Send the credit back to April instead and April's profit changes in June, which is the problem this whole post is about, wearing a different hat.
The error is not small and it is not conservative. Had the supplier price fallen to €15,00 rather than risen, the same treatment books a €3,00 phantom loss instead. It does not track your business, it tracks your supplier's price list. In an example store with 7.907 return events over fourteen months, a three euro error on each is €23.721,00 of profit that was never there.
This is also why a product cost needs a date at all. If the cost is one field holding one number, there is no April value left to credit at in June, and the best any report can do is reach for today's.
What never gets credited
A refund gives back the revenue and the goods. It does not give back the work.
- Outbound shipping, pick and pack and packaging. The parcel was picked, packed and carried. The carrier is not refunding you because the customer changed their mind, so the whole outbound charge stays on the order date.
- Packaging EPR fees, for the same reason and one more: the packaging was placed on the market and became waste there. It sits inside logistics, which is never credited.
- The payment fee. The provider kept its cut of the original charge. Providers vary, and if yours returns part of a fee it shows up in your payouts. nouz never credits it, because the charge was made.
Return processing is not a credit at all. It is a new cost, and it lands on the refund date: the return label, plus the handling charge for taking the parcel back in. In an example store that is €1,50 per returned shipment today and was €1,25 until 1 Apr 2026, which came to €47.507,15 over fourteen months, or €6,01 per return.
| Part | Over the window | Per return |
|---|---|---|
| Margin given back | €352.848,73 | €44,62 |
| Return processing | €47.507,15 | €6,01 |
| Stranded fulfilment | €43.342,64 | €5,48 |
| Stranded payment fees | €16.919,46 | €2,14 |
| Total | €460.617,98 | €58,25 |
The same arithmetic, run on your own return rate and your own margin, is in what a return really costs.
Chargebacks are not returns
A chargeback looks like a refund in your bank account and is nothing like one in your warehouse. The customer's bank pulled the payment back. No parcel is coming, nothing gets inspected, nothing goes back on a shelf, and you are usually charged a fee on top of losing the amount.
So it splits in two. The disputed amount goes to Returns, because the revenue is gone. The fee goes to Transaction costs, because that is what it is. No return processing cost applies, because there is no label and no shipment to handle, and nothing goes back into stock, because the goods are still with the customer.
Treating a chargeback as a return overstates your logistics costs and understates your fees, and it puts an event in your return rate that never came back, which bends the per-product return numbers you use to decide what to fix. Both halves belong to the day the dispute landed, for exactly the same reason everything else here does.