SKU (Stock Keeping Unit)

What is a SKU?

A SKU (stock keeping unit) is the unique internal code a company uses to identify every distinct item it sells or stores. It’s alphanumeric, each company defines it with its own criteria, and it serves one very specific purpose: so that when someone says “there are three left”, everyone knows exactly three of what.

The word “distinct” is doing all the work. A T-shirt isn’t a SKU: the blue T-shirt in size M is a SKU, and the same blue T-shirt in size L is another one. The SKU doesn’t identify the product, it identifies the specific variant that gets sold, counted and replenished.

A vocabulary note that saves confusion: inside a company, SKUs sometimes travel under other names —“item number”, “part number”, “style-color-size code”— depending on the system that generated them. They’re all the same thing, and in an assortment report “number of items” and “number of SKUs” measure exactly the same figure. If you want to place it in the context of the sector, here’s an overview of what retail is.

SKU, UPC, GTIN and vendor part number: what each one is

This is the most common confusion in inventory and the one that wastes the most time in an integration, a catalog setup or a count. Worth settling once and for all: the SKU is yours; the UPC belongs to everyone.

How many SKUs a product really has

There’s a practical consequence of the table above worth keeping in mind: two items can share a UPC and still need different SKUs, and vice versa. If you sell the same product bought from two suppliers, the UPC is identical but you may want to separate them to track cost; if you build a promotional three-pack, that’s a new SKU and also a new GTIN.

That second part isn’t an opinion. GS1 requires a different identifier for every size and color combination, and also when the declared net content changes or when a certification mark is added to or removed from the packaging. The criterion it applies is simple and works just as well for deciding your internal SKUs: if the customer or your trading partner needs to tell the item apart from the previous one, it’s a different item.

An example with round numbers. A T-shirt in 3 colors and 4 sizes isn’t one product in your inventory: it’s 12 SKUs. Add two more colors next season and you’re at 20. That’s why the SKU count grows much faster than the commercial catalog, and why an assortment that takes up one page in a brochure can be an inventory of several thousand lines.

How to build a SKU code that won’t cause you problems

There’s no standard to comply with: the SKU is yours and you can build it however you like. What there is, is plenty of ways to build it badly. The approach that works is a segmented code, of fixed length, where each block always means the same thing, ordered from the most general to the most specific. That way it reads at a glance and can be filtered and grouped in any spreadsheet.

An example for a short-sleeve blue T-shirt in size M from the spring-summer 2026 season: TEE-SS-BL-M-SS26.

Five rules that save you grief

• Fixed length and always the same separators. If one SKU has hyphens and another doesn’t, any data match between two systems will fail on exactly the items you least expect.
• Never start a SKU with a zero. Spreadsheets eat leading zeros when they open a CSV, and the code stops matching without anyone noticing.
• Avoid characters that get mixed up: O and 0, I and 1, S and 5. Whoever types a SKU by hand in a warehouse does it in a hurry and in the cold.
• No accents, no non-ASCII characters, no spaces and no odd symbols. They travel badly between systems, between languages and between marketplaces.
• A retired SKU is never reused. It’s the most expensive mistake on the list: the sales history of two different items gets mixed together forever, and there’s no way to separate it afterwards.

What the SKU lets you measure in your inventory

The SKU is retail’s minimum unit of analysis: below it, nothing can be measured. As soon as each variant has its own code, you get the indicators that really decide what gets bought, what gets replenished and what gets dropped.

• Turn rate. How many times that SKU sells and gets replenished in a period. It’s the figure that separates the item that works from the one that just takes up space.
• Days of cover. How many days your current stock lasts at the current sales rate. It’s what turns a number of units into a purchasing decision.
• On-shelf availability. What percentage of the time that SKU is genuinely within the customer’s reach, which is different from having it in the back room.
• Stockouts. When product was missing and for how long. Without SKUs you can’t even detect it, because there’s nothing to compare against.
• Sales per SKU and per facing. What turns space into a decision rather than a habit: it’s the basis for calculating share of shelf.

They all fit into the same store dashboard, which you’ve got developed in retail KPIs.

The problem the manuals leave out: the system says there’s stock and the shelf is empty

This is the part that articles about SKUs usually don’t cover, and the one that moves the most money. A SKU isn’t a code: it’s the promise that behind that code there’s a specific product in a specific place. And that promise is held up by the system record, not by the shelf.

The most instructive thing measured on this is the work of Nicole DeHoratius and Ananth Raman, published in Management Science in 2008. They reviewed nearly 370,000 inventory records across 37 stores of a single retailer, comparing what the system said with what was actually there. The result: 65% of the records were inaccurate.

It’s worth reading carefully, because it’s one retailer and not a sector average, and because “inaccurate” covers everything from a one-unit discrepancy to a serious error. But the order of magnitude matches what anyone who has run a physical count has seen. The study also adds two very actionable findings: inaccuracy drops where inventory audit practices exist and rises with the complexity of the store environment. In other words, it isn’t a software problem but an operational one, which is why it isn’t solved by retail digitalization alone.

The phenomenon has a name of its own: phantom inventory. The system thinks there are four units of a SKU left, so it doesn’t trigger the replenishment order; in the store there are none, because they were lost, stolen, returned incorrectly, or they’re in the back room behind something else. The SKU doesn’t sell, the algorithm reads that as no demand and cuts the next order. Nobody finds out, and the item disappears from the assortment in the quietest way possible.

How many SKUs should you have? What the evidence says about cutting assortment

The question always comes up, and the honest answer is that the evidence is split. But it’s split in a very useful way.

In favor of cutting: Peter Boatwright and Joseph Nunes, in Journal of Marketing (2001), studied a major assortment reduction at an online supermarket. Across 42 categories, where mostly low-selling SKUs were removed, sales rose 11% on average and grew in more than two thirds of the categories. The usual reading is the right one: too much assortment confuses, and pruning the long tail usually improves the category.

Against, and with data from the same retailer: Borle, Boatwright, Kadane, Nunes and Shmueli, in Marketing Science (2005), measured the effect at store level instead of category level. Total sales fell, and the greater damage didn’t come from people buying less per visit, but from them coming in fewer times. Infrequently purchased categories were the hardest hit.

The practical conclusion isn’t “cut” or “don’t cut”, but measure where: a SKU can be irrelevant within its category and, at the same time, be the reason a customer picks your store over the one across the street. That’s why an assortment decision shouldn’t be made with the turn-rate report alone in front of you, and even less so if it’s applied identically across the whole network without looking at how each store is managed.

What the SKU means for the store team

All SKU management rests, in the end, on what five or ten people do during their shift. These are the four routines that keep the data alive, and none of them is technological:

• Cycle counting instead of an annual inventory. Counting a few SKUs every week —the fastest moving and the highest value— catches the discrepancy while it can still be fixed. The December inventory only certifies the disaster.
• Replenish by scanning the code, not by reading the front label. Two variants of the same product look extremely alike. Scanning the SKU is what stops size M ending up in the L slot and the system silently drifting out of balance.
• Report shrinkage on the spot. A broken, expired or returned product that doesn’t get recorded is, precisely, an inventory record that has just become false.
• A channel to flag what doesn’t add up. When the store sees the system says four and the shelf has zero, someone has to be able to say so at that moment, without waiting for the next area manager visit.

At bottom it’s the same execution problem that shows up in the retail audit, in planogram execution, in visual merchandising and in store compliance. And it depends on three very specific things: that the standard is accessible at the moment of use —that’s what good SOPs are for—, that the task is assigned with a date and evidence, and that the store has somewhere to answer back. Digital task management is what turns those three things into routine rather than good intentions.

Conclusion: a SKU is worth whatever the number next to it is worth

Three things worth keeping. That the SKU is internal and the UPC is global, and confusing them breaks integrations and catalog setups. That every variant is a SKU, so inventory grows much faster than the commercial catalog. And that a well-built code —fixed length, meaningful segments, never reusing retired ones— saves you years of unreadable history.

But above all, that a SKU is only useful if the number next to it is true. With 65% of records measured as inaccurate in the field, the inventory bottleneck isn’t in the software: it’s in what happens in the store during the shift. isEazy Engage works precisely there: it brings together, in a single app, communication with the teams, bite-sized training people can take right at their workstation, and task assignment with evidence, so that what the system says you have is what the customer finds on the shelf.