A SKU, or stock keeping unit, is the code you give to each item you sell. Customers rarely see it, but your team uses it every day: to pick orders, count stock, reorder from suppliers and find the right item when a buyer calls.
A good SKU system is short, readable and consistent. A bad one is a random mix of numbers that nobody can decode, and it causes picking errors that cost real money. This guide shows how to design one that will still make sense when your range is ten times bigger.
SKU, barcode and product: what is the difference?
- Product is what the buyer sees: "Classic Cotton T-Shirt".
- SKU is one specific sellable version of it: the Classic Cotton T-Shirt in blue, size M. Each SKU has its own stock count and can have its own price.
- Barcode (such as EAN or UPC) is a standard number used across retailers and scanners. It is often assigned by a manufacturer or registered with a standards body.
You create SKUs yourself, for your own business. They do not need to be registered anywhere, and they can carry meaning that helps your team.
The structure of a good SKU
Most practical SKU systems are built from a few short blocks, from general to specific:
CATEGORY - PRODUCT - VARIANT 1 - VARIANT 2
For example:
TS-CLS-BLU-M
- TS = T-shirts (category)
- CLS = Classic model (product)
- BLU = Blue (colour)
- M = Medium (size)
Anyone on your team can read that code and know what to pull off the shelf.
Seven rules for a SKU system that lasts
1. Keep it short. Aim for 8 to 12 characters. Long codes are hard to read and easy to mistype.
2. Start with the most general block. Category or brand first, then product, then variants. This makes SKUs sort nicely in lists and spreadsheets.
3. Use only letters, numbers and a hyphen. Avoid spaces, slashes and special characters, which break in some files and systems.
4. Avoid letters that look like numbers. O and 0, I and 1, and sometimes S and 5 get confused. Pick one convention and stick with it, or leave those letters out.
5. Never start with a zero. Spreadsheet programs often drop leading zeros, so 0123 becomes 123.
6. Keep codes fixed and use a list. Write down every block and its meaning in one shared document: BLU is always blue, never "BL" on one product and "BLUE" on another.
7. Never reuse a SKU. When a product is discontinued, retire its code. Reusing it mixes old orders, returns and reports with the new item.
Building your code list
Before you create the first SKU, make a small table for each block. An example for a clothing store:
| Block | Code | Meaning |
|---|---|---|
| Category | TS | T-shirts |
| Category | HD | Hoodies |
| Product | CLS | Classic |
| Product | OVR | Oversized |
| Colour | BLK | Black |
| Colour | WHT | White |
| Colour | BLU | Blue |
| Size | S, M, L, XL | Sizes |
From this table, every SKU writes itself: HD-OVR-BLK-L is the oversized hoodie in black, size L.
For a store that does not sell clothing, the blocks change but the idea stays the same. A tea shop might use type, origin and weight (GRN-JP-100 for a 100 g Japanese green tea). A hardware shop might use category, size and finish.
Variants: one product, many SKUs
The number of SKUs grows quickly with variants:
Number of SKUs = values of option 1 × values of option 2 × ...
A T-shirt in 4 sizes and 3 colours is 12 SKUs. Add a second fit and it becomes 24. Typing each one by hand is slow and invites mistakes, so it pays to define options once and let your system build the combinations.
Not every combination has to exist. If the oversized fit only comes in M and L, only create those SKUs.
When to give a version its own product page
Sometimes a colour or version is different enough to deserve a separate product page with its own photos and description, for example a limited edition print. In that case, keep the SKU structure the same, give it its own product code block, and link the pages together so buyers can switch between versions.
Common mistakes
- Using the supplier's code as your SKU. If you change supplier, your whole system changes. Store the supplier code separately.
- Random numbers. 100457 means nothing to the person picking an order.
- Putting the price in the SKU. Prices change; SKUs should not.
- Different people inventing codes on the fly. Agree on the code list first.
- One SKU for several variants. You lose the ability to see which size actually sells.
A quick checklist
- Choose the blocks for your SKU structure (category, product, variants).
- Write a code list for each block and share it with the team.
- Check the rules: short, no spaces, no leading zero, no confusing letters.
- Create SKUs for each existing variant, and only for variants that really exist.
- Label shelves or bins with the same SKUs.
- Decide who is allowed to add new codes.
How RedCart helps
In RedCart's Store module, you define options such as Size or Colour once at store level, with their values. On each product you tick the values it actually comes in, and when you save, the cabinet builds one SKU for each combination. Colour values are picked with a colour picker, so each one carries a real colour, and every SKU can carry its own price in each of your currencies.
Each SKU then has its own stock in each warehouse, tracked by the Warehouses module with a movement log. When a version deserves its own page, product families link separate products by a characteristic such as colour, with switches on the product page, while each card keeps its own URL.
Summary
A good SKU system is built from short, meaningful blocks in a fixed order, backed by a shared code list and a few simple rules. Set it up once and your picking, stock counts and reports all become easier.
If you would like to set up your catalog and SKUs with us, create a RedCart account.