Outliers in sales data: keep, cap, or flag?

A single store reports 900 bottles of water sold on a Tuesday when it normally sells about 60. What do you do with that number? Outliers in sales data should be investigated before anything else. Once you know the cause, you keep the figure, cap it, or flag it, and you record which choice you made.

An outlier is simply an observation far from the others. It isn't automatically wrong. Some outliers are data errors. Others are the most interesting thing in the dataset. The method below is about telling them apart.

What makes a data point an outlier?

There's no single threshold. A common starting point is to compare each store-day or store-week against that store's own recent history for the same item. A value several times the usual level, or a sudden zero in a steady seller, gets a closer look.

Comparing against the store's own history matters. A large store might sell 300 units of an item on an ordinary day, while a small one sells 30. A value of 300 is normal for the first and extraordinary for the second. Using a network-wide average as the benchmark would flag the wrong stores.

It also helps to check the neighbors. If one store spikes while similar stores nearby stay flat, the cause is likely local. If many stores spike together, it's probably a real event, such as a holiday or a regional promotion.

How do you tell a real spike from an error?

Look for a mechanism. Real spikes usually have one. A local event, a price cut, a storm warning, a case being sold to a single business customer. Errors tend to have a mechanical fingerprint instead.

A few fingerprints show up often in scan data:

1. A quantity that looks like a keying mistake, such as 100 instead of 10.
2. A day's sales appearing twice because a file was loaded twice.
3. Units that jump while dollars stay flat, suggesting a pricing or pack-size mismatch.
4. A negative value from a return or void landing on a different day from the original sale.

If the figure matches a fingerprint, it's probably an error and should be corrected or removed. If there's a plausible real-world cause, it's probably real and should be treated as such.

Keep, cap, or flag: which one when?

Keep the value when it's real and relevant to the question. If you're measuring how a category performed during a holiday week, the holiday spike is the point. Removing it would answer a different question.

Cap the value when it's real but would distort a summary. Suppose one store's bulk sale to a local business pushes an item's average far above what a typical store does. Capping that store-day at a sensible ceiling, such as the highest value seen in the prior few months, keeps the store in the data without letting one transaction set the trend.

Flag the value when you can't tell. Leave it in, mark it, and show results both with and without it. If the conclusion doesn't change, the outlier doesn't matter much. If it does, the reader needs to know.

Why document every choice?

Because outlier handling is one of the easiest places for analysis to go quietly wrong. Two analysts with the same data can reach different conclusions purely through what they removed. Nobody can check the work if the choices aren't written down.

A short log is enough: which values were changed, what rule was applied, and why. Over time, that log also shows patterns, such as a store whose feed repeatedly produces duplicates, which are worth fixing at the source.

Aggregated reporting from NRS Insights is built from store-level scan data, where these checks come first. You can read the most recent example in the July 2026 same-store sales report.