Inventory Planning for High-SKU Stores

A 1,200-SKU catalog does not produce 1,200 buying decisions a week. It produces about thirty. The hard part of planning a large catalog is not reviewing everything, it is building the filter that turns everything into the thirty items a person has to think about.

Most inventory advice is written for a catalog you can hold in your head. This is what the same job looks like when you cannot. Where the line between manual and automated review sits, and why it sits there, is covered in automatic versus manual reordering; this post starts from the far side of that line and deals with the operations problem it leaves behind.

What changes past a few hundred SKUs

Give each SKU ninety seconds. That is long enough to look at stock on hand, glance at the last few weeks of sales, and check whether there is already a purchase order in flight. It is not long enough to think properly about any of it. Then multiply.

That arithmetic is the whole problem. Review time scales with catalog size and the week does not, so somewhere in the low hundreds of SKUs a full pass stops fitting and quietly becomes a partial pass that nobody labels as one. The review still happens on the calendar. It just stops covering the catalog.

The second thing that changes is the shape of the mistake. In a small catalog you know the products, so an error is usually something you noticed and got wrong. In a large one, the error is something nobody looked at. A SKU can sit at zero for eleven days without a single person forming an opinion about it, because no step in the process ever brought it up. Silence stops being evidence that things are fine.

The third change is that the unit of work moves. Below a few dozen SKUs you plan product by product. With nine suppliers behind a catalog, the thing you actually send is a supplier order, and decisions about individual SKUs are constrained by the order they will travel in: minimum order values, case packs, whether it is worth opening an order with this vendor at all this week. Planning SKU by SKU and then discovering the supplier minimum wastes the review you just did.

Segment first, then review by exception

Two filters, applied in that order. The first decides which products deserve attention at all this week. The second decides which of those actually need a decision.

Segmentation is the durable filter. It changes slowly, usually once a quarter, and it splits the catalog by how much revenue a product carries and how predictable its demand is. The calculation behind both grades is covered in ABC-XYZ inventory analysis, and the order you work the resulting tiers in, including how often each tier gets looked at, belongs to prioritizing products for reordering. Both are prerequisites here rather than this post's subject.

Exception rules are the weekly filter, and they are the piece most stores never write down. An exception rule is a condition that, when true, puts a SKU in front of a human. Everything else stays out of the way. A workable starting set:

Run those over an example store: 1,200 SKUs, nine suppliers, one location. Of the 1,200, 180 sit in the weekly tier. The rules flag 23 of them below reorder point, 5 with a purchase order past its promised date, and 7 whose forecast moved beyond the threshold. Four SKUs trip two rules at once, so the queue for the week is 31 products, not 1,200.

The weekly buying routine

Once the filters exist, the routine is short enough to protect. Thirty-one decisions at roughly two minutes each is about an hour, and an hour is a thing that survives a busy week.

Run the filters, do not browse. The temptation with a large catalog is to scroll through it looking for something wrong. Scrolling finds whatever is visually striking, which is not the same as whatever is urgent, and it takes far longer.

Group by supplier before deciding any quantity. Six SKUs from one vendor is one order and one shipping cost; the same six spread across three vendors is a different decision entirely. Grouping first also surfaces the near-misses worth pulling forward: a SKU two weeks from its reorder point is worth adding to an order that is going out anyway.

Decide quantities only for what is in the queue. Everything outside it has already been reviewed by rule.

Send, and record the promised date. Without a promised date stored somewhere, the late-purchase-order rule has nothing to compare against and the second exception rule stops firing.

Write down what you deliberately skipped, and why. This is the step everyone drops. Without it, a SKU you consciously decided not to reorder reappears in the queue every single week, and the queue slowly trains you to ignore it.

The tiers below the weekly one get the same routine on a longer clock: a monthly pass over the middle of the catalog and a quarterly sweep of the tail, which for most stores is less about reordering and more about deciding what should still exist.

What has to be automated

The test is simple: anything that has to happen whether or not a person remembers is a candidate for automation. Anything that requires a reason from outside the sales data is not. Four things fail the memory test in every large catalog.

Sales velocity, recalculated per SKU. Velocity is the input under almost every other number, and it drifts constantly. Recomputing it by hand across a large catalog is not difficult, just impossible to sustain.

Reorder points, recalculated as velocity and lead time move. A reorder point is only correct for as long as the two numbers behind it are. When a supplier slips from twelve days to nineteen, the number on the sheet does not object, it just becomes wrong. How that recalculation works in practice is covered in automated reorder recommendations.

The exception scan itself. The scan is worth more running daily than weekly, because it costs nothing to run and its whole value is catching a crossing on the day it happens rather than up to six days later.

Purchase order status. Someone has to notice that an order is past its promised date while there is still time to chase it. That is a scheduled comparison, not a judgment.

Automating those four means something other than a file has to hold your supplier records, lead times and reorder parameters, and run on a clock. StockCue does that job, and the plan limits matter here more than in most posts: the Free tier covers 50 SKUs, which is not a high-SKU store by any definition, so a catalog of this size means Growth for up to 2,000 SKUs or Scale for unlimited. Forecasting with seasonal adjustment runs on every plan including Free, while purchase orders, receiving and stock counts start at Starter, so a store that wants the buying workflow as well as the numbers is looking at a paid tier from the outset.

What should stay manual

Exception rules are good at noticing and bad at knowing why. Everything below is a decision whose reason lives outside your sales history, which is exactly where an automated rule has nothing to work with.

Anything with a known one-off behind it. A promotion next month, a supplier changing their minimum order quantity, a wholesale account that placed one large order and will not repeat it. The history says one thing and you know another.

New products. A SKU with no sales history cannot be planned by rule, only estimated and then watched closely for its first few weeks.

The approval itself. A recommendation built on a wrong lead time is confidently wrong rather than visibly wrong, and no amount of automation flags its own bad inputs. Someone has to look at the number and decide it is plausible before it becomes an order.

Whether a product should still be in the catalog. No exception rule will ever fire "stop carrying this". Discontinuation is a commercial decision about margin, storage and range, and it is the single highest-value manual pass a high-SKU store can run, because every SKU removed is one less thing the whole system has to carry.

Moving off the spreadsheet

"Manage 1,000 SKUs without spreadsheets" is a common way to phrase this problem, and it slightly misdiagnoses it. Row count is not what breaks. A spreadsheet holds 1,200 rows without complaining, sorts them faster than any app, and will happily calculate a reorder point for every one of them.

What a spreadsheet cannot do is act while it is closed. Every recalculation in it is a person remembering to do a recalculation. Nothing in the file runs on Tuesday if nobody opens it on Tuesday, nothing in it raises a hand, and the numbers in it stay exactly as fresh as the last time someone had a free afternoon. At 40 SKUs that gap is a few minutes of work. At 1,200 it is the difference between a filter that runs and a filter that exists in principle.

The clean version of the move is usually not a deletion. Most stores that shift the recalculation into a tool keep the file for what it was always better at: supplier quirks, case-pack rules, the note about the vendor who closes for three weeks in August. Splitting it that way costs nothing and keeps the context that no software has a field for.

Whether that trade is worth making, what it costs to switch, and the store profile for which the honest answer is to stay exactly where you are, is a decision worth its own analysis: spreadsheet versus inventory planning software works through it, including the cases where the spreadsheet wins outright.

Frequently Asked Questions

How do you manage inventory for 1,000+ SKUs?

By filtering rather than reviewing. Segment the catalog so a small tier gets frequent attention and the rest runs on longer cycles, then apply exception rules (below reorder point, purchase order past its promised date, forecast moved materially) so only the products that need a decision reach you. The ongoing work in a large catalog is maintaining that filter, not looking at every product.

How often should a high-SKU store review reorder points?

A reorder point should be recalculated whenever the inputs behind it move, which for a fast seller can mean weekly and for a steady slow seller can mean quarterly. The interval matters less than whether the recalculation happens without someone remembering to do it, because a reorder point set months ago goes stale silently rather than visibly. Tiering the catalog by revenue contribution and demand variability is the usual way to keep that manageable.

What should be automated first in a large catalog?

The recalculation of sales velocity and reorder points, because that is the piece that has to happen on a schedule whether or not anyone opens a file. The exception scan comes next: something has to compare current stock against current reorder points every day rather than on review day. Purchase order status is the third, since a late delivery is only useful information while there is still time to chase it.

Can you run 1,000 SKUs on a spreadsheet?

Yes, and plenty of stores do. A spreadsheet handles a thousand rows without difficulty; what it cannot do is recalculate anything while it is closed, or tell you that something changed since you last looked. Whether that trade is worth paying for depends on how much review time you actually have and what a missed reorder costs you.