SKU vs UPC vs GTIN: which number to match items on

The short answer

A SKU and a GTIN answer different questions. The SKU says which item this is in your business. The GTIN says which trade item this is anywhere in the world, under the brand owner's GS1 company prefix. An integration needs both, for different joins.

Between your own systems, match on SKU: you control it, and it exists for items that have no barcode. With suppliers and marketplaces, match on GTIN, stored as 14 digits of text. A UPC, an EAN and a GTIN-14 for the same item then compare as the same string.

One GTIN family, four lengths

GS1 US defines four lengths. A GTIN-12 is always 12 digits and is the number in a UPC-A barcode; GS1 US calls it synonymous with UPC. A GTIN-13 is the EAN-13 used mainly outside North America. A GTIN-8 is for small items. A GTIN-14 is always 14 digits, never starts with a zero, and identifies a grouping such as a case; it is not meant to be scanned at a register.

GS1 US's GTIN guideline says to store any GTIN as a 14-digit field, right-justified and zero-filled. The padding does not change the number:

The last digit of every GTIN is a check digit, and the integration recomputes it before trusting a code. A worked example for 61414110482, the first 11 digits of the UPC above. From the right, digits are weighted 3, 1, 3, 1 and so on:

digits from the right:  2  8  4  0  1  1  4  1  4  1  6
weight:                 3  1  3  1  3  1  3  1  3  1  3
weight 3 digits: 2+4+1+4+4+6 = 21, times 3 = 63
weight 1 digits: 8+0+1+1+1   = 11
total 74; next multiple of ten 80; 80 - 74 = 6
check digit 6: 614141104826

A code whose last digit does not match the computed one was mistyped, truncated or altered. It goes to a review list instead of matching the wrong item or nothing.

Why codes that look equal do not match

Most failed matches are two strings that a person reads as the same and a computer does not.

• A lost leading zero. Excel removes leading zeros when it opens a CSV, so UPC 012345678905 comes back as 12345678905, 11 digits. The full story is on supplier CSV and Excel files. An 11-digit value is restored to 12 digits only when the check digit then holds; for 012345678905 the computed check digit is 5, which matches.
• Padding. 614141104826 and 0614141104826 are one item. Compared as text, they differ.
• Whitespace. HX-2210 and HX-2210 with a trailing space, or with a non-breaking space pasted from a spreadsheet.
• Case and lookalikes. hx-2210 against HX-2210; the letter O against the digit 0. Shopify's own SKU guidance advises against formats where 0 and 1 can be confused with O and I, and against spaces and special characters.
• Separators. HX2210, HX-2210 and HX_2210 in three systems.

The rule that follows: GTINs are reduced to 14 digits of text with the check digit verified; SKUs are trimmed and compared in one case. The rule is applied the same way on both sides of every match, and the original value is kept for the log.

The each, the inner pack and the case

A GTIN identifies one packaging level. The single item, a pack of 6 and a case of 12 each have their own GTIN. A GTIN-14 for a case is built from an indicator digit, the first 12 digits of the contained item's GTIN-13 form, and a new check digit. From 0614141104826 with indicator 1, that gives 1061414110482 plus check digit 3: 10614141104823.

This is where stock goes wrong by a factor. A distributor's feed reports 40 on hand for 10614141104823. That is 40 cases. If the integration matches it to the store item by stripping the indicator digit, the store shows 40 units instead of 40 x 12 = 480. If it matches the case code to nothing, the item shows 0. The case code is matched to the case, and a unit conversion turns it into eaches; how that conversion is set up is on units of measure.

Where each system keeps them

Two details in that table matter for an integration. Shopify validates typed barcodes against their standard: a UPC is a 12-digit UPC-A or an 8-digit UPC-E, an EAN is 13 or 8 digits, a GTIN accepts 8, 12, 13 or 14 digits. A barcode without a type is stored as entered. An integration that writes 614141104826 as UPC gets a validation error if the value has lost its zero, which is better than storing it wrong.

NetSuite's upccode is a text field, so leading zeros survive as long as the value is sent as a string. A value sent as a JSON number instead of a string loses its leading zero: 012345678905 as a number is 12345678905.

When SKUs are not unique

Shopify does not require a SKU. Its help center says SKUs should be unique per variant, shows a warning on a duplicate, and lets the merchant ignore it, for example for bundles. On an order, LineItem.sku is an optional string: a custom item has none.

For an integration that matches on SKU, that leaves three cases, each with its own handling:

Writing to the first match is the failure to avoid. Stock for one item goes to two variants, or to the wrong one, and the error shows up as an oversell weeks later. The same holds for customers matched on email; that case is on duplicate customers and orders.

What this means for your integration

We set the match key per pair of systems before the first run: SKU between the store and the ERP, GTIN as 14-digit text against suppliers, and a cross-reference table where neither exists. Check digits, padding, whitespace and case codes are handled in that rule, and every record that matches twice or not at all lands on a review list with the reason.

The first runs are dry runs, so you see which items match and which do not before stock or prices are written. How product data moves as a whole is on product data integration. Send us a sample of your item file, and we tell you which key will hold for your catalog.