SKU Naming Conventions for Warehouses

A good SKU naming convention creates a unique, stable internal identifier for each stock-controlled item or variant. It should be short enough to use, structured enough to validate and independent of facts that will change. The SKU is not the product description, barcode, GTIN, supplier item number, bin location or sales-channel title, even when a legacy spreadsheet currently uses one value for all of them.

This guide focuses narrowly on identifier governance. Use the broader item-master data cleanup guide for descriptions, categories, suppliers and record ownership, and the barcode readiness checklist for scanning. The inventory systems service connects the policy to migration and operations.

1. Define the identity boundary

Decide when two sellable or usable things require different SKUs. Size, colour, material, voltage, pack quantity, formulation or condition may create a separate stock item when quantity, availability, cost or fulfilment must be controlled independently. A marketing title change normally should not. Document the variant dimensions that create identity and the fields that merely describe it.

2. Choose a code structure

Use a non-significant sequential code when long-term stability and simplicity matter most. Use a lightly structured code when a small number of controlled segments materially helps recognition, such as a product-family prefix plus sequence and variant suffix. Avoid encoding every attribute. The more meaning a code carries, the more likely a future category, brand or supplier change makes the code misleading.

• Use one approved character set and case convention.
• Set a minimum and maximum length supported by every connected system.
• Avoid spaces and punctuation that exports, URLs, labels or scanners may transform.
• Do not reuse a retired SKU for a different item.
• Do not make the code depend on supplier, cost, warehouse or current status.
• Generate and validate codes centrally rather than asking each team to improvise.

3. Keep units and packaging explicit

Microsoft describes a base unit of measure as the inventory unit and supports alternate purchase, production and sales units with defined quantities per base unit. Decide whether a case is an alternate unit of the same item or a separately stocked and sold trade item. If both each and case have independent barcodes, pricing or inventory, the system may need separate but related records. Never rely on a suffix such as ‘-12’ without a controlled conversion field.

4. Distinguish SKU from GTIN and barcode

GS1 identifies trade items with GTINs under its specifications. A GTIN is not a replacement for an internal warehouse SKU, and an internal SKU should not be presented as a GTIN unless it meets the applicable standard and allocation rules. Store the data carrier value, symbology, pack level and unit relationship explicitly. One item may have multiple scannable codes, but every accepted code should resolve to one intended transaction unit.

5. Handle variants consistently

6. Create a SKU policy and ownership

The policy should define who requests, approves, creates, changes, deactivates and merges an item. Require the identity boundary, base unit, variant attributes, description, category and reason before code creation. Prevent direct code edits after transactions exist. Use status changes and replacement links instead of renaming history to match a new product.

7. Migrate legacy SKUs safely

Export all active and historical codes with quantity, value, open orders, barcodes, supplier references, channel mappings and transaction usage. Group suspected duplicates, choose a surviving SKU and document whether quantities and open documents can be consolidated. Preserve legacy codes as searchable aliases. Microsoft import guidance includes item and unit templates, but the import file still needs explicit mappings and validation.

1. Never merge solely because descriptions look similar.
2. Check unit, pack, variant, tax, tracking and costing differences.
3. Update labels, ecommerce, POS, purchasing and accounting mappings together.
4. Test open purchase, sales, transfer, production and return documents.
5. Retain a cross-reference file with approval and effective date.
6. Count or reconcile affected items before and after the migration.

8. Validate the convention before rollout

Select fifty awkward items: similar names, long descriptions, multiple suppliers, variant families, packs, kits, serialised products, replacements and legacy duplicates. Generate codes, print labels, scan receipts and picks, search by description and alias, export and reimport, and test every connected channel. The convention passes when users can identify the item without decoding unstable business facts from the SKU.

Worked example

A distributor currently uses SUPPLIER-BRAND-SIZE-LOCATION as its code. A supplier change creates duplicates and a warehouse move makes the location segment wrong. The new policy assigns a stable internal sequence with a controlled family prefix. Brand, size, supplier, bin and GTIN move to separate fields. The old codes remain as aliases, and each alternate pack has an approved unit conversion or related SKU. Open orders are tested before the old codes are retired.

Ongoing quality checks

Report duplicate active descriptions with different SKUs, duplicate SKUs, missing base units, invalid characters, orphan barcodes, codes changed after transactions, items with quantity but inactive status, and new records created outside the approval path. The aim is not a clever-looking code; it is an item identity that stays reliable as suppliers, locations and channels change.

Sources checked

• GS1: General Specifications
• Microsoft Learn: Set up item units of measure
• Microsoft Learn: Import business data

This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.