An SKU, short for stock keeping unit, is an internal alphanumeric code that a merchant assigns to each distinct sellable item, so that every product variant can be counted, priced, ordered and shipped without ambiguity. In e-commerce product catalogs, the SKU is the primary key that links the storefront, inventory, orders and fulfillment for one specific version of a product.
A T-shirt in three sizes and two colors is one product but six SKUs, because each combination is stocked, picked and sold separately. The SKU is defined by the seller, which distinguishes it from global identifiers such as GTIN barcodes assigned through the GS1 system.
What an SKU identifies and why it matters
An SKU identifies the smallest unit that differs in any way that matters for stock or sale. If two items differ in size, color, capacity, packaging or bundle content, they need separate SKUs; if they are fully interchangeable for the buyer and the warehouse, they share one.
Because the SKU is shared by every system, it acts as a common language between departments. The storefront shows a product variant, the warehouse management system counts the SKU on a shelf, the order management system reserves it, and accounting reports margin per SKU. A wrong or duplicated SKU breaks this chain and causes overselling, mis-picks and incorrect reports.
How SKUs differ from product IDs, GTINs and serial numbers
Several identifiers appear in product data, and each one answers a different question. Confusing them is a frequent source of catalog errors and rejected product feeds.
| Identifier | Assigned by | Identifies | Typical use |
|---|---|---|---|
| SKU | The merchant | One sellable variant in that merchant’s catalog | Inventory, orders, internal reporting |
| GTIN (EAN, UPC) | Brand owner via GS1 | One trade item worldwide | Barcodes, marketplaces, shopping feeds |
| MPN | The manufacturer | One manufacturer part | Matching products across sellers |
| Product ID | The store platform | One database record | Internal links and API calls |
| Serial number | The manufacturer | One individual physical unit | Warranty, returns, theft tracking |
The same physical item can carry different SKUs at different retailers, but it has one GTIN. Marketplaces and shopping channels therefore usually require the GTIN in a product feed, while the SKU stays the merchant’s own reference.
Designing an SKU structure
A good SKU scheme is unique, stable, short and readable by people. Many merchants use structured codes built from segments, but the segments must stay meaningful as the catalog grows.
| Segment | Meaning | Example value |
|---|---|---|
| Category | Product family | TS (T-shirt) |
| Model | Base product | 0412 |
| Color | Variant attribute | BLK |
| Size | Variant attribute | M |
| Full SKU | Combined code | TS-0412-BLK-M |
The table below lists design rules that experienced catalog managers apply and the reasons behind them.
| Rule | Recommendation | Reason |
|---|---|---|
| Length | Roughly 8 to 12 characters | Easy to read, type and print on labels |
| Characters | Uppercase letters, digits and hyphens | Avoids encoding and spreadsheet issues |
| Ambiguous characters | Avoid O and 0, I and 1 | Prevents picking and typing errors |
| Leading zeros | Avoid or prefix with a letter | Spreadsheets often strip leading zeros |
| Supplier codes | Do not reuse as the SKU | Supplier changes would break history |
| Reuse | Never reassign a retired SKU | Old orders and reports would become ambiguous |
SKUs in variants, bundles and product feeds
In most store platforms, a parent product groups several product variants, and each variant carries its own SKU, price and stock level. The parent itself is usually not stocked and may have a reference code that is not a true SKU.
Bundles need a deliberate decision. A virtual bundle has its own SKU for sale and reporting but deducts stock from its component SKUs, while a pre-packed kit is assembled in advance and stocked as a physical SKU. Mixing the two models leads to stock counts that do not match the shelf.
In product feeds for marketplaces and shopping ads, the SKU usually serves as the item ID that connects performance data back to the catalog. Changing SKUs in a live feed resets that history, so SKU changes should be rare and planned.
Using SKU-level data for decisions
Because every sale, return and stock movement is recorded per SKU, the SKU is the natural level for inventory and merchandising analysis. Reorder points, safety stock and sell-through rates are calculated per SKU, not per parent product, since a sold-out size is a stockout even when other sizes remain.
SKU rationalization is the periodic review of slow-moving SKUs. Each additional SKU adds storage, photography, data maintenance and forecasting effort, so merchants often retire variants that sell rarely and tie up capital. The opposite risk is removing variants that complete the range, such as the smallest and largest sizes, which may sell slowly but prevent customers from leaving for a competitor.
Return data per SKU is equally useful. A high return rate on one size often points to a sizing chart problem rather than a product defect, and it can be fixed with better product attributes.
Common SKU mistakes
- One SKU for several variants: stock looks available although the requested size is sold out.
- Encoding volatile data such as price or supplier into the SKU, which forces changes later.
- Duplicate SKUs across channels for different items, which corrupts synchronization.
- Manual SKU creation without validation, which produces typos that break integrations.
- Treating the GTIN as the SKU when the merchant sells unbranded or self-made goods without GS1 codes.
Explained without jargon
An SKU is a name tag that a shop gives to every exact version of a product. A blue shirt in size small and the same shirt in size large get different tags, because the shop needs to know exactly how many of each it has.
Customers rarely notice SKUs, but the shop uses them everywhere: on shelves, in orders and in sales reports. One clear tag per version keeps everyone counting the same thing.
A typical use case
An online shoe retailer sells 300 models, each in up to 12 sizes and several colors, for a total of about 7,000 SKUs. Early on, the team created codes by hand and some sizes shared a code, so customers occasionally ordered sizes that were not in stock.
The retailer introduced a structured scheme in the form model-color-size, generated codes automatically from product attributes and blocked duplicates in the import process. Mis-picks in the warehouse fell noticeably, the marketplace feed stopped reporting identifier conflicts, and reports finally showed which sizes sold out first, which improved purchasing for the next season.