How to create SKU codes you won't have to redo later

A SKU is the only product identifier you control completely. Barcodes come from GS1, ASINs come from Amazon, and both arrive with rules attached. The SKU is yours to design. That freedom is also the trap: nothing stops you from designing it badly, and nothing outside your business will ever force a correction. By the time the problems surface, the code is printed on shelf labels, embedded in two years of order history, and referenced by every integration you own.

We have migrated catalogs off SKU schemes that made perfect sense to the person who invented them and no sense at all to the fifteen people who inherited them. The pattern below is what survives that handover.

A SKU is not a barcode, and the difference matters

A barcode identifies a product to the outside world. Everyone who stocks the same item uses the same EAN or UPC, because it is issued centrally and refers to the manufactured product itself. A SKU identifies the item to you. Two shops selling identical stock will have different SKUs for it, and that is correct, not a mistake to reconcile.

This distinction decides where each one belongs. The barcode goes in a barcode field, and it is the value you send to marketplaces and Google Merchant Center. The SKU goes in the SKU field, and it is the value your warehouse, your picker, and your accounting system read. Cramming one into the other is the single most common catalog mistake we see, and it breaks quietly: listings get rejected weeks later, for reasons that do not mention SKUs at all.

What belongs in a SKU

Only attributes that can never change for the life of the item. That list is shorter than most people expect:

• A category or product-line marker, but only if your team already talks in those groupings
• The attributes that make this variant a different physical thing: size, colour, capacity, pack quantity
• A sequence number that carries no meaning at all

That is the whole list. The test for any other attribute is simple: could this change while the product on the shelf stays the same? If yes, it does not belong in the code.

What does not belong, and why

• Price. It will change, and the SKU cannot follow it.
• Supplier. You will switch suppliers for an identical item, and re-keying the catalog is not an option you will want.
• Season or year. Carry-over stock outlives the label, and you end up with last year's code on this year's shelf.
• Cost, margin, or anything commercially sensitive. SKUs appear on packing slips that customers read.
• Anything a marketing team owns. Product names get rewritten; codes should not.

The supplier case is the one that catches people. Encoding the supplier feels useful on day one because it answers a question you are asking a lot in the first month. It stops being useful the moment you dual-source, and then it is actively misleading, because the code now asserts something false about half your stock.

Clothing, and other catalogs where variants explode

Apparel is where SKU schemes usually break first, because one product becomes thirty items. A single shirt in six sizes and five colours is thirty distinct things to pick, count and ship, and each needs its own code.

The structure that holds up separates the style from the variant:

SHRT-0042-NVY-M
 │    │    │   └─ size
 │    │    └───── colour
 │    └────────── sequence, meaningless by design
 └─────────────── product line

The first two segments together identify the style. Everything after them identifies which of its variants this is. That split is worth the discipline: it lets you group a style in reports without string-matching on colour names, and it means adding a seventh size does not disturb anything that already exists.

Fix the segment lengths and pad them. NVY and RED are both three characters; so is BLK. When a colour arrives that will not abbreviate cleanly, assign it a code and write it down. Do not let the pattern bend to fit the word, because a scheme with exceptions is a scheme nobody can parse.

Why the meaningless number is the important part

Every SKU scheme drifts toward being descriptive, because descriptive feels helpful. The problem is that descriptions compete for space and eventually collide. Two different navy shirts both want SHRT-NVY-M. Now you are adding a disambiguator, and the disambiguator is a sequence number you could have had from the start.

A sequence number never runs out of meaning because it never had any. It guarantees uniqueness without anyone having to think, and it degrades gracefully: when the abbreviations stop making sense in five years, the number still identifies the item.

Collisions happen later than you think

A duplicate SKU rarely announces itself. The catalog import accepts it, the marketplace accepts it, and the two products quietly share a stock count. You find out when one of them oversells, or when a customer receives the other one.

Check for duplicates when you generate the codes, not when you upload them. By upload time the code may already be on a label. If you are generating in bulk, generate the whole set first, check it against itself and against everything already live, and only then commit any of it.

If you already have a scheme you regret

Do not renumber the catalog. The cost is not the database update, it is every printed label, every open purchase order, and every historical report that no longer reconciles.

Freeze the old scheme instead and start the new one alongside it, applied only to products added from here on. Keep the old codes valid forever. A catalog with two schemes and a clear cutover date is inconvenient. A catalog mid-renumber, where the same physical item has two codes depending on which system you ask, ships the wrong product.

What makes a good SKU code?

A good SKU is short enough to read aloud, fixed in length, and built only from attributes that cannot change: product line, the variant attributes that make it a different physical item, and a meaningless sequence number. It never contains price, supplier or season, and it is checked for duplicates before it is ever printed.