SKU design

How to design a SKU numbering system you will not have to replace in two years.

Most SKU schemes fail for the same three reasons: they encode something that changes, they run out of digits, and they use characters people misread. Fix those and a scheme lasts as long as the company.

Model SKUs in Nexodo Compare identifiers

Internal

A SKU is yours. No external body issues or validates it.

Stable

It must survive a price change, a rebrand and a supplier switch.

Readable

Warehouse staff read it aloud, so ambiguous characters cost money.

What to encode

Encode only what will never change about the item.

A SKU is a key. Every piece of meaning you push into it is a promise that the meaning will not change, and it is the broken promises that force renumbering. Cost, price, supplier, season, warehouse location and packaging promotion all change during a product's life and none of them belong in the code.

The attributes that are safe to encode are the ones that define the item's identity: the product family or category, the variant axes such as size and colour, and a sequence. Everything else belongs in an attribute on the record, where it can change without invalidating the key.

Encode	Do not encode	Why
Category or family	Supplier	Suppliers get replaced, categories rarely do
Variant axis such as size	Cost or price	Prices change constantly
Sequence number	Warehouse or bin	Stock moves between locations
Brand, if you are a distributor	Season or year	Carry-over stock outlives the year
Nothing else	Promotional packaging	Promotions end, the item continues

Shape

Fixed-length segments, generous sequence, no ambiguous characters.

Fixed-length segments are what let a system parse a SKU without a lookup table. Two or three characters for the category, two or three for a variant axis, and a numeric sequence long enough that you will not exhaust it. Sizing the sequence for ten times the catalog you have today costs one extra digit and prevents a migration.

Drop the characters people confuse: the letter O against zero, the letter I and the letter L against one, and the letter S against five. Restricting the alphabet to a subset removes an entire class of picking and receiving errors, and it costs nothing to decide at the start.

Fixed-length segments so a SKU can be parsed positionally
One separator style, applied consistently or not at all
Sequence sized for ten times the current catalog
Excluded characters: O, I, L and S against 0, 1 and 5

Variants

The parent and the variant need different codes, related by structure.

A product with size and colour variants needs a stable parent code plus a suffix for each variant combination. Building the variant SKU as the parent code plus fixed-length variant segments keeps the relationship visible to a human and derivable by a machine, and it lets a new colour be added without touching any existing code.

The trap is a purely sequential variant SKU with no relationship to its parent. It works until somebody has to reconcile a supplier file, a warehouse count and a webshop export by eye, at which point the missing structure costs hours every week.

Parent code plus fixed-length variant segments
New variant values append, they never renumber existing ones
One variant axis per segment, in a documented order
Never reuse a retired variant SKU for a different combination

Governance

A SKU scheme is only as good as the rule that stops people inventing one.

Schemes decay when someone needs a code before the process gives them one, so they make one up. Preventing that needs two things: a single place where codes are assigned, and an assignment that is fast enough that nobody routes around it.

In a PIM, that means the SKU is generated or validated where the product record is created, uniqueness is enforced at that moment, and the format is checked by a rule rather than by convention in a document nobody reads. Nexodo treats the SKU as a governed attribute with validation and history, so an out-of-format code is visible as a quality exception instead of surfacing months later in a channel error.

One assignment point, enforced by the system not by a policy
Format validated by a rule at record creation
Uniqueness checked before the record is saved
Retired SKUs kept, never reused for a different product

Frequently asked questions

Clear answers before you evaluate a PIM.

How long should a SKU be?

Long enough to be unique with the sequence sized for growth, short enough to be read aloud without error. Eight to twelve characters covers most catalogs. If yours is longer than sixteen, you are probably encoding attributes that belong on the record instead.

Should the SKU contain the GTIN?

No. They are different fields with different owners. A GTIN comes from GS1 and identifies the trade item globally. A SKU is internal. Keep both on the record and keep them separate.

We already have a broken scheme. Do we renumber?

Usually not the whole catalog. Freeze the old scheme, start the new one for new products, and keep the old codes valid. A full renumbering means touching every historical order, label and integration, and the cost almost never justifies the tidiness.

Do we need a check digit on a SKU?

Only if codes are keyed by hand at volume, such as in receiving. In that case a single check character catches most transpositions. If codes are always scanned, it is extra length with no benefit.

Continue your product data research

MPN reference

Test Nexodo with a supplier file your team already uses.

Tell us how your supplier files arrive and what your channels reject, and we will tell you whether this workflow fits.

Talk to us See what Nexodo does

A person replies, normally within one business day
Use a representative product sample
We will say plainly if Nexodo is the wrong fit

How to design a SKU numbering system you will not have to replace in two years.

Encode only what will never change about the item.

Fixed-length segments, generous sequence, no ambiguous characters.

The parent and the variant need different codes, related by structure.

A SKU scheme is only as good as the rule that stops people inventing one.

Clear answers before you evaluate a PIM.

Continue your product data research

Manufacturer part numbers: the field distributors get wrong most often.

Every product identifier your catalog carries, and what each one is actually unique across.

Find the catalog problems that block a confident purchase.

Turn many supplier catalogs into one trustworthy product catalog.

Test Nexodo with a supplier file your team already uses.