Ask a controller why the returns reserve moved 40 basis points last quarter, and the honest answer is usually a shrug.
Not because the accounting is hard. The entries fit on one page.
The shrug happens because the reserve was built on one blended return rate for the whole business. A blended number cannot explain itself. It moved, something underneath it moved, and nobody can say which part.
Finance teams respond to this by refining the model. More documentation, a tighter methodology memo, a look-back test.
The model is almost never the problem. The input is.
- Under ASC 606 and IFRS 15, expected returns split into a refund liability and a separate right of return asset, both shown gross.
- The accounting is simple. The estimate behind it is not, and it lives in returns operations rather than the ledger.
- A single company-wide return rate is the most common reason a reserve drifts, because it cannot be traced back to what changed.
- Claimlane keeps the case, the reason code, the resolution and the credit note on one record, so the rate finance reserves against can be segmented and defended.
What the standard actually asks for
A sale with a right of return splits into three pieces the moment control transfers.
Revenue goes in only for what the business expects to keep. The rest becomes a refund liability. And the cost of the goods expected back moves out of inventory into a right of return asset, measured at former carrying value less the cost of getting them back.
The two balances are shown separately, not netted. That is the part older systems get wrong, and it exists so anyone reading the accounts can see the inventory exposure sitting behind the refund exposure.
Public filers disclose both and show the movement across the period. A revenue recognition note filed with the SEC lays out the roll-forward shape: opening balance, additions, releases, and the adjustment for actual against reserved returns.
The worked example, once
Round numbers, illustrative. A brand sells 100,000 on credit in the quarter, and those goods cost 40,000.
Expected return rate is 12 percent.
| Account | Debit | Credit |
|---|---|---|
| Accounts receivable | 100,000 | |
| Revenue | 88,000 | |
| Refund liability | 12,000 | |
| Cost of goods sold | 35,200 | |
| Right of return asset | 4,800 | |
| Inventory | 40,000 |
When goods come back, the refund settles against the liability and the asset clears into inventory. Revenue is untouched, which is the entire point of reserving in the first place.
At window close, whatever was over-reserved releases to revenue and the leftover asset writes off to cost of sales. Re-measurement happens at every reporting date, and the true-up runs through the current period. Prior periods stay shut.
That is the whole mechanic. Every competing article on this keyword stops here, which is roughly where the interesting part starts.
Where the 12 percent is supposed to come from
Historical return percentages applied to current period sales. That is the standard method and it is what filers describe in their revenue policies.
The trouble is what "historical" means in practice. For most mid-market brands it means a quarterly export from the helpdesk, cut by nobody, averaged across every channel and category the business sells into.
The spreadsheet is not the problem. The export feeding it is three months old and one column wide.
Returns and warranty claims were managed manually, making it difficult to ensure consistency or visibility across teams.
Simone Andersen, Customer Service Director, CoolshopWhy one blended rate fails
An 8 percent company-wide rate can hide a category returning at 3 percent and another returning at 20. The blend is arithmetically correct and analytically useless.
It fails in a specific way. When the reserve misses, finance knows the number was wrong but cannot attribute the miss.
Was it a channel, a market, a supplier batch, a promotion, a single SKU with a sizing problem? The blend erased all of it before the number reached the ledger.
Segmentation is what makes a reserve explainable. Rate by category, by channel, by market, by customer cohort.
B2B orders do not behave like direct-to-consumer orders. Marketplace does not behave like owned storefront. Hardware does not behave like footwear.
Seasonality compounds it. Extended windows over peak trading push returns into the following quarter, so a reserve built on an annual average understates Q4 and overstates Q1 every single year, predictably, and still surprises people.
Reason codes are the missing variable
Two returns can be identical in the accounts and mean completely different things about what happens next.
A product returned because it did not fit is part of a stable pattern. A product returned because it arrived faulty is a signal, and it clusters by batch and by supplier.
One is forecastable from history. The other says the history is about to stop applying.
A free-text box collecting "didn't like it" and "broken" cannot separate them. Structured codes captured at intake can.
Resolution type carries the same weight. A returnless refund clears the liability with no asset coming back at all.
An exchange for the same item at the same price is arguably not a return in the accounting sense. A model treating every return as a full refund with recovered stock overstates the asset on both.
Not the same as a warranty reserve
These get conflated, and running both off one assumption produces a wrong answer twice.
| Dimension | Returns reserve | Warranty reserve |
|---|---|---|
| Trigger | Customer right to return for a refund | Product fails to meet agreed specification |
| Income statement | Reduces revenue | Accrues cost, usually in cost of sales |
| Main driver | Return rate and refund value | Failure rate and cost per repair |
| Typical horizon | 14 to 90 days | 1 to 5 years |
The second calculation runs on failure rate and cost per claim rather than return rate, and it sits under a different standard. The mechanics are covered separately in warranty reserve accounting.
What auditors actually test
The account draws attention because it is estimate-heavy and management controls the estimate. It is one of the easier places on the balance sheet to flatter earnings quietly, and it gets tested accordingly.
Look-back testing comes first. Reserved against actual, period by period. Consistent large true-ups signal a broken input no matter how good the methodology memo reads.
Then the asset valuation. If historical data shows a fifth of returned goods arrive damaged, claiming full carrying value will not survive a second question.
Then segmentation. Five channels running five different return policies against one blended rate is a finding waiting to be written up.
Nobody sets out to build a reserve on a guess. It happens because the data that would have made it defensible was never captured at intake.
What the returns record has to produce
The reserve gets easier to defend when the operational record and the financial record are the same record.
That means the case carries what was returned, why, how it was resolved, and what financial action followed. Reconstructing that afterwards from a helpdesk, a payment provider and an ERP is where the month-end reconciliation habit comes from, and that person becomes an accounting control by accident.
Konges Sløjd cut handling time per claim from 15 minutes to 5 by generating credit notes in Business Central straight from the resolved claim. Davidsen went from five agents handling claims to one or two. Those are FTE numbers, but they land in the same place: the record finance reserves against gets written once, at source, by the person closing the case.
Where Claimlane sits
Loop, Narvar and AfterShip are built around the consumer-facing return journey, and they are good at it. ReverseLogix goes further into reverse logistics execution.
Claimlane sits where warranty, repair, replacement and returns share one case record and one set of business rules. That matters for this problem specifically, because a reserve needs resolution values and reason codes attached to cases, not a returns portal bolted next to a separate claims process.
The integration story is the finance story. Claimlane connects to Business Central, NetSuite, SAP, Dynamics, Shopify, Zendesk and Gorgias among others, so the credit note fires from the case rather than being keyed in later.
Reporting then cuts return rate by product, supplier and reason without an export, which is the segmented view the reserve needs.
Claimlane holds a 4.8/5 rating on G2 from aftersales and customer service teams.
Frequently asked questions
Getting the number right
The accounting for a returns reserve takes an afternoon to learn. The estimate takes an operating model.
Structured intake, consistent reason codes, resolution values recorded per case, credit notes fired from the case itself. Put those in place and the reserve stops being a quarterly argument, because every movement in it points at something specific.
The controller gets to answer the question. That is the whole return on the work.
Build the return and warranty portal customers actually use, and give finance a rate it can defend. Book a demo.
