Sales forecasting basics using POS data

Sales forecasting with POS data starts with a simple idea: estimate what will sell next, based on what sold recently, adjusted for patterns you already know about, such as the season, the calendar and planned promotions. POS data, meaning scan records from point-of-sale registers, is a strong foundation because it records what shoppers actually bought.

A forecast is an estimate with assumptions attached. Treating it as a fact is the fastest way to lose trust in it.

What inputs does a forecast need?

History first. You need enough past data to see the patterns you want to project, usually at least a full year by store or store group, by item, by week. Less than a year and you can't see seasonality.

Then known changes. Distribution changes are the big one. If an item is about to gain 50 stores, a forecast based on past sales in current stores will miss the jump. Planned price changes, promotions and new items belong here too.

Finally, the calendar. Holidays that move, a 53-week year, or a month with an extra weekend can all shift results. A forecast should account for these explicitly instead of leaving them buried in the history.

Which simple methods should you try first?

Start with a naive baseline. The simplest version assumes next week looks like this week. A seasonal naive version assumes next month looks like the same month last year, adjusted for the recent trend. These sound crude, and they're surprisingly hard to beat in many categories.

A moving average is a small step up. It smooths recent weeks and projects that level forward. It's a reasonable choice for steady items without strong seasons.

For seasonal items, separate the seasonal pattern from the trend. Seasonal adjustment techniques estimate the usual shape of the year, so you can forecast the adjusted trend and add the season back. More complex models exist, but they should earn their place by beating these simple ones on your data.

How do you judge whether a forecast is any good?

Test it on the past. Pretend it's six months ago, build the forecast using only the data available then, and compare it with what actually happened. This is called backtesting, and it's the most honest check available.

Measure the error in plain terms. The average absolute difference between forecast and actual, in units, is easy to explain. Compare it against the naive baseline. If your sophisticated model doesn't beat "same as last year," it isn't ready.

Look at where it misses, too. A forecast that's accurate on average but consistently wrong for certain stores or certain months has a fixable problem.

Track errors after the forecast goes live as well. A running record of forecast versus actual, reviewed each month, shows whether accuracy is drifting and which assumptions keep failing.

What would you do with this on Monday?

Build the naive baseline for your top items first. It takes little time and gives you a benchmark. Then list the known changes coming in the next quarter, such as new distribution, price moves and promotions, and adjust the baseline for each one explicitly.

Present the result as a range, with the assumptions written down. "If the new stores come on in March as planned, we expect roughly this many units" is a statement people can plan around and check later. For category-level context, NRS Insights monthly reports show how categories have moved, and the July 2026 same-store sales report is the most recent example.