A SKU, or stock keeping unit, is a merchant-defined code used to identify a product or product variant inside the business. A SKU helps staff and software answer a practical question: which exact item are we talking about?
SKUWhat is a SKU? How internal product identifiers work
For example, a store might use:
TEE-BLK-Mfor the medium, black variant of a T-shirt. A SKU is not the stock quantity, and it is not automatically the same as a barcode, UPC, or GTIN. Those fields can be related to the same variant but solve different identity problems.
A SKU identifies a variant, not a pile of stock
Suppose one T-shirt comes in 2 colors and 2 sizes. There are 4 sellable variants, so a clean catalog normally has 4 distinct SKUs. Now suppose TEE-BLK-M has 8 units in Warehouse A and 3 in Store B. You do not need to turn those into 2 different products just because stock is in 2 places. Shopify's current guidance is to use the same SKU for the same product variant across locations and track each location's inventory level separately.
One variant identity, many location quantities
That distinction applies to inventory systems more broadly:
SKU = what the item is inside your catalogLocation quantity = how many of that item are at a place
SKU vs barcode, UPC, and GTIN
A SKU is usually internal. The merchant chooses the format to make operations easier. A GTIN is a standardized global trade-item identifier. GS1 defines GTINs for identifying products or services that may be priced, ordered, or invoiced across supply chains. UPC and EAN are commonly encountered numbering/barcode forms within that broader product-identification world.
Shopify therefore exposes SKU and barcode as separate product fields. Its documentation describes the SKU as a code used within the business, while barcode/GTIN data supports scanning and product identification in external channels and marketplaces. A business can use both a SKU and a GTIN for the same variant. They do not need to be the same value.
| Option | Identifier | Who defines it | Main job | Example |
|---|---|---|---|---|
| SKU | SKU | Merchant/business | Internal variant identity and operations | TEE-BLK-M |
| GTIN | GTIN | GS1 system / brand owner allocation | Standardized trade-item identity across organizations | numeric GTIN |
| Barcode | Barcode | Encoded/scannable representation or field | Machine scanning and external identification | UPC/EAN/GTIN barcode |
| Inventory quantity | Inventory quantity | Inventory system | Current stock state | 8 units at Warehouse A |
What makes a useful SKU system?
The best SKU scheme is boring: stable, unique, readable enough for staff, and scalable enough that you do not have to redesign it every month. Useful practices include:
- One unique SKU per normal sellable variant. Duplicate SKUs make reporting and integrations ambiguous
- Use a consistent pattern. If
BLKmeans black, do not make it mean blue in another category - Keep codes reasonably short. Long narrative identifiers are slow to type, scan visually, and troubleshoot
- Avoid ambiguous characters.
0vsOand1vsIare easy to misread - Use separators deliberately. Hyphens or underscores can make attribute segments easier to parse
- Leave room for growth. A format that works for 30 variants should not collapse when the catalog reaches 3,000
Shopify similarly recommends short, consistent, unique codes and warns that duplicate SKUs can cause problems in inventory tracking and third-party integrations.
Worked example
A shirt sold in 3 sizes and 4 colors has 12 color/size combinations. If all 12 are independently sellable variants, a clean SKU system needs 12 unique variant codes.
- A simple pattern could be:
SHIRT-[COLOR]-[SIZE]Examples:SHIRT-BLK-SSHIRT-BLK-MSHIRT-BLK-LSHIRT-WHT-S...
Each variant can then have its own barcode/GTIN where needed, while inventory systems track quantities for that SKU by location. Shopify uses the same 3-size by 4-color example to explain why unique SKUs are needed per variant.
What passes and what does not
- It can be tempting to put every fact into a SKU:
TEE-BLK-M-SG-WH1-29.90-8UNITS- That creates brittle identity
- Price changes. Inventory moves. A warehouse closes. The SKU should not need to change just because operational state changed
- Encode stable attributes only when they genuinely help humans or systems identify the variant. Keep mutable facts such as price, stock quantity, and storage location in their own fields
- That gives you a useful design rule:
- A SKU should identify the item, not describe the item's current situation
Common mistakes
- Reusing one SKU for several ordinary variants and then wondering why reports cannot distinguish them
- Creating a new SKU for the same variant at every warehouse instead of tracking location quantity separately
- Treating SKU, UPC, barcode, and GTIN as synonyms
- Putting price or current stock quantity inside the SKU
- Using inconsistent abbreviations that staff cannot decode reliably
- Changing SKU formats without mapping old identifiers for integrations, orders, and reporting
Questions we get asked
Does every product need a SKU?
Not every platform technically requires one, but SKUs are very useful for inventory, fulfillment, reporting, and integrations. For a normal ecommerce catalog, assigning stable unique SKUs to sellable variants is a strong default.
Should every variant have a different SKU?
Usually yes. If color, size, pack, or another option creates a distinct sellable variant, give it a distinct SKU. Specialized bundle or ERP workflows can have exceptions, but duplicate variant SKUs should be intentional rather than accidental.
Is a SKU the same as a UPC or GTIN?
No. A SKU is an internal code chosen by the business. A GTIN is a standardized trade-item identifier designed to work across organizations and supply chains. A product can have both.
Should I create different SKUs for different locations?
Not for the same variant merely because stock is held in multiple locations. Keep the variant SKU stable and track the quantity separately by location.
Can I change a SKU later?
Technically, many systems let you. Operationally, treat SKU changes as migrations because integrations, reports, warehouse processes, historical exports, and staff references may depend on the old value.
OnVoard's take
A SKU is most valuable when it behaves like a stable internal key that humans can still recognize.
Give each normal sellable variant one clear SKU, keep that SKU consistent across locations, and let separate fields carry barcode identity, price, and inventory state. The simpler that model is, the fewer catalog and integration bugs you create later.
Every app on every plan. Connect your store and switch on the flows in an evening.