How much revenue did you lose to stockouts?

The method

1. Each SKU's sales are laid out day by day from its first ever sale, so a product launched in month three isn't punished for months one and two.
2. Every weekday gets its own baseline rate. A product that only sells on Saturdays is not out of stock Sunday to Friday — a flat average says it is, and would report several times more loss than the product has ever earned. Thin weekdays are pulled toward the SKU's own average so a single quiet Tuesday can't distort it.
3. Days when the entire shop sold nothing are thrown away first. Those are closures, holidays, site outages or tracking gaps. Treating them as per-SKU stockouts is how one Thanksgiving weekend becomes five figures of imaginary loss spread across the whole catalogue.
4. A run of zero-sale days is flagged only if the units it should have contained — adding up each day's own weekday rate — passes a bar set once for the whole report, from its total size. Checking every gap independently would manufacture findings, because a few hundred SKU-months contain thousands of chances for a quiet stretch to look like an outage.
5. Runs shorter than 4 days are never flagged.
6. The bar is set once for the whole report, from its size, so adding SKUs or months raises it slightly for everything in the file. A finding that sits close to the bar can drop out when you upload a longer export, and the same SKU can be judged in one file and not in another. That is the correction working, not the tool changing its mind: more SKU-days means more chances for an ordinary quiet stretch to look like an outage, and the bar has to rise to keep the number of false alarms across the whole report where you set it. It rises logarithmically, so it moves slowly: quadrupling the size of your file raises the bar by ln 4 — about 1.4 expected units — whatever size the file was to begin with.
7. Every SKU is also given the shortest outage it could have produced a finding from. Invert the bar: a run has to reach the bar in expected units, and over a run spanning whole weeks that expectation is close to its length times the SKU's average daily rate — so the shortest detectable outage is the bar divided by that rate. (An average-rate approximation: a gap falling on a SKU's strong weekdays clears the bar a little sooner, one on its weak weekdays a little later.) Any SKU whose number exceeds 14 days is listed as a blind spot rather than as clean. Fourteen is not a statistical constant — it is the outage length this tool's floor was measured against, chosen because a fortnight out of stock is roughly where a merchant would want to have known.
8. A run that is still going when the file ends is never priced into the total. A product that is silent right now might be out of stock, or might be one you delisted, paused or put away for the season — the sales data is identical in every case, so any figure would be a guess dressed as a finding. Those SKUs get their own section instead, with the cost written as a condition. A product with no sales at all in the recent half of its history is treated as discontinued and gets no figure of any kind.
9. Lost revenue = lost units × that SKU's median unit price, and lost units can never exceed what the SKU actually sold. If the estimate wants to break that ceiling, the model doesn't fit and the SKU is moved out of the total.

What this does not know

• Slow sellers are excluded, not estimated. Measured: a SKU is judged at all from about 0.3 units a day, and a two-week outage only becomes findable at about 1 unit a day. Below that a fortnight of silence is ordinary and the data physically cannot tell it apart from an outage. Those are reported as "not assessed" rather than given an invented number — so this total is an undercount by design.
• "Nothing found" is not "nothing happened", and this page says which it means. Between those two rates sits a band where a SKU can be assessed, produce no finding, and still have been out of stock for two weeks without it registering. Reporting that as clean would be the same failure as an inflated total, aimed the other way — and the more expensive way, because it ends with a dead SKU that never gets reordered. Every assessed SKU therefore carries the shortest outage it could have shown, and the ones above 14 days get their own section instead of silence.
• It can't see your inventory log. It infers stockouts from the shape of your sales. A gap could equally be a paused ad campaign, a supplier delay, or a listing you unpublished.
• Promotions and seasonality aren't modelled beyond the weekday pattern. A product that sells only in December will look wrong here; that's why it gets moved to the "doesn't fit" table.
• Substitution isn't modelled. If a customer bought the blue one because the red one was gone, the red one's "lost" revenue was partly recovered.
• Refunds and cancellations usually stay in an orders export as positive line items, so they inflate the baseline slightly. Filter them out before exporting if you can. Where your export writes the return as a negative line instead, those lines are set aside and the count is printed with your result — the sale each one reverses still counts, because the demand was real even though the money came back.
• Mixed currencies aren't converted. If your export has more than one presentment currency, the money column here is meaningless — use the units column.
• It cannot tell a stockout from a decision. Everything still silent at the end of your file is listed under "Selling stopped recently" with its cost stated as a condition, and left out of the headline. Only you know which of those you meant to do — so the total on this page counts only outages you demonstrably recovered from, and is smaller than the truth if some of that silence was unintended.

Treat this as a shortlist to go investigate, not an audited figure, and never as the sole basis for a purchase order. Open your inventory history for the top three and confirm they were actually out before you act on any of it.

More on why it is calculated this way: most stockout-cost calculators overstate losses, and here is the arithmetic — the four failures behind the rules above, each with the measured numbers.