Attributing Refunds to the Right Month

One order, two dates, two correct answers. Why the choice matters more than it sounds, which one suits which question, and the reporting failure that comes from never making it.

By Ed · Published August 20, 2026 · 7 min read

Twenty-five years starting companies, consulting, owning a multi-million-dollar P&L and leading business intelligence for large enterprises.

An order placed on 28 January, refunded on 14 February. Which month lost the revenue? Both answers are defensible, they produce different monthly series from identical data, and the majority of store reports never state which one they used.

The two bases

Order date. The refund reduces January. Each month carries the reversal of its own sales, so a monthly series never shows revenue that was later undone.
Refund date. The refund reduces February. The series follows cash out of the business, and January stops moving once it is closed.

Neither is wrong. They answer different questions, and the question determines which one is right for a given report.

Which question you are asking

Did this product, campaign or month actually work? Order date. A range with a 30% return rate should not look successful in the month it shipped, and under refund-date attribution it does, for exactly as long as the return window lasts. This is the basis for merchandising, marketing and margin analysis.

What happened to the money? Refund date. Cash left in February. An accountant reconciling a bank statement needs the movement in the month it moved, and needs last month to be the same number this week as it was last week.

The tension is real and does not resolve. Most stores need both, and the workable arrangement is one basis for the operating reports and the other for the accounts, with each labelled — rather than a single figure that quietly is one of them.

What order-date attribution costs you

Months change after they end. January revenue read in February is not January revenue read in April, because refunds kept arriving. If anyone downstream treats a monthly figure as final — a commission calculation, a board pack, a bonus accrual — this is a genuine problem and not a philosophical one.

Two mitigations, both partial. Report a fixed number of days after month end, so the return window has mostly closed. Or show both figures, the original and the refund-adjusted, side by side. The first is simpler and is what most stores end up doing.

What refund-date attribution costs you

Every high-return period is flattered at the time and punished later. A November campaign with poor product-market fit reports beautifully in November and drags January down, at which point the January team is asked to explain a number that has nothing to do with anything they did.

It also makes return rate by product genuinely hard: the refunds are in a different period from the sales they reverse, so a naive ratio of refunds to sales in one month compares two different populations.

From running the reporting that got argued about

I have never seen this decision made deliberately. It gets made by whoever wrote the first query, usually by joining on the date column that was already in the refund file, and then it is defended for years by people who were not there.

What settled it, at one business, was recomputing a single quarter both ways and putting the two series next to each other on one slide. The gap was eleven percent in the worst month. Nobody had believed it was material until they saw it, and the decision took about four minutes after that.

Doing it in Excel

Refund-date attribution is the easy one, because the date is already on the row:

Refund month  =EOMONTH([@[Refund date]],0)
Refunds       =SUMIFS(Refunds[Amount],Refunds[Refund month],$A2)

Order-date attribution needs the order date joined onto the refund first:

Order date    =IFERROR(SUMIFS(Orders[Order date],Orders[Order],[@Order]),"")
Order month   =IF([@[Order date]]="","unmatched",EOMONTH([@[Order date]],0))

The unmatched label is the important part. Refunds whose order is not in your file — outside the window, or with no order id — are real money, and a lookup that returns an error or a blank will drop them from the total without comment. Give them a bucket and let the amount be visible.

For a product-level breakdown, a partial refund against a multi-line order needs allocating across that order lines in proportion to line revenue, the same allocation described in the contribution margin piece. If the refund file names the specific line, use that instead — allocation is what you do when the information is missing, not an improvement on having it.

One basis, stated

Quiriz for e-commerce attributes refunds to the order date, so a month carries the reversal of its own sales and net sales, net revenue and contribution margin all move together. In Excel that is =QUIRIZ.ASK("net sales by month in 2025", "table"), and the basis is stated alongside the answer rather than left to be inferred.

The honest boundary: this means closed months can move. If your accounting needs an immutable monthly figure, the operating series here and the accounting series will differ during the return window, and they are supposed to. Two labels, two numbers, both correct — which is a much better position than one label and two numbers.

Recompute one high-return quarter both ways before you decide. The gap is either negligible, in which case the choice does not matter, or it is not, in which case you have just found something worth knowing.

Get a monthly series that means one thing

Upload your order and refund exports and ask for net sales by month, with the refund basis attached to the answer. Free to start.

Try Quiriz free →

Frequently asked questions

Should refunds be recorded in the month of the sale or the month of the refund?

Both are used. Recording against the order month means each month carries the reversal of its own sales, which is what you want for judging whether a product or campaign worked. Recording against the refund month matches cash movement and means a closed month never changes afterwards, which is what accounting generally wants. The mistake is not picking one; it is running both in different reports under the same label.

Does changing refund attribution change my total revenue?

Not over a long enough window — the same refunds are subtracted either way. It changes every monthly figure inside that window, and it changes the year total whenever refunds cross the year boundary. December sales refunded in January land in different years under the two bases, which is exactly when someone notices.

Why does my monthly revenue keep changing after month end?

This is the signature of order-date attribution. A refund issued in March reduces January, so January revenue is different in April than it was in February. That is correct behaviour for the basis, and it is unacceptable if a closed month is meant to stay closed. If your accounting requires immutable months, that alone settles the choice.

How do I handle a refund with no matching order?

Goodwill credits, refunds against orders outside your window, and refunds where the order id was not recorded all have to go somewhere. Dropping them makes the breakdown disagree with the total for no visible reason. Report them in their own bucket, so the amount that could not be matched is a number on screen rather than a silent gap.

Do partial refunds need different treatment?

The timing choice is the same, but the allocation is not. A partial refund against a multi-line order has to be spread across that order lines before any product-level figure works, in proportion to line revenue, unless the refund file identifies the specific line. Where it does identify the line, use that — an allocation is a fallback for missing information, never an improvement on having it.