GTIN, EAN and UPC: Why Bad Barcodes Break Your Listings

Identifier problems do not announce themselves. A listing gets rejected and someone raises a ticket. A duplicate page appears with three reviews on it. A report shows a SKU selling in a city where you never shipped it. Each is treated as an isolated incident. They are usually the same incident, showing up in four places.

Product identifiers are the join key between your systems and every platform you sell on. When the key is wrong, everything downstream of it is wrong, including the numbers you use to make decisions.

What the identifiers actually are

GTIN is the umbrella term. Global Trade Item Number. It is the standard, not a competing code. EAN and UPC are formats of GTIN, distinguished mainly by length and regional origin.

UPC is the twelve digit format, historically North American. EAN is the thirteen digit format used widely elsewhere, including India. There is also a fourteen digit form used for cases and outer cartons, and an eight digit short form for very small packs. A thirteen digit EAN is simply a GTIN of thirteen digits. A twelve digit UPC padded with a leading zero becomes the same GTIN.

Two practical points follow. First, the last digit is a check digit calculated from the preceding digits, so a mistyped barcode is mathematically detectable. Any catalogue system worth using validates it on entry. Second, identifiers are issued against a company prefix licensed by the standards body, and in India that licensing is handled by the national GS1 organisation. Codes bought loose from a reseller may fail verification when a platform checks the prefix against the registered brand owner.

The rule that matters most is one identifier for one distinct sellable item. A different flavour is a different item. A different pack size is a different item. A promotional pack with a free sachet attached is a different item. A two hundred millilitre bottle and a four hundred millilitre bottle sharing one code is the single most common cause of catalogue chaos in Indian consumer brands.

How identifier problems break things

Platforms use the identifier to decide whether your product is new or already exists in their catalogue. That decision drives four outcomes.

Rejection. A code that fails check digit validation, or whose prefix does not resolve to your registered brand, gets blocked at listing creation. This is the least harmful outcome because it is visible immediately.

Unwanted merge. If your code already exists on the platform, your listing attaches to an existing page. Now you are sharing a page with someone else’s product, someone else’s images, and possibly someone else’s reviews. Detaching later is slow and evidence heavy.

Unwanted split. The opposite case. The same physical product enters twice under two codes, or under a code and an exemption. You now compete against yourself. Reviews and sales history split across two pages, ranking splits with them, and neither page performs as well as one healthy page would.

Buy box and ownership problems. When multiple sellers sit on a page created from your code, the page mechanics decide who wins the sale. If your own distributor listed the same code independently, you are bidding against your own channel. Brand protection tools cannot help until the identifier position is clean.

The quiet damage is in reporting. If one product exists under three identifiers, no report is trustworthy. Velocity looks lower than it is on each page. Stock cover calculations are wrong. Contribution per SKU is wrong. Teams then make planning decisions on numbers that were broken at the join key, which is the worst kind of wrong, because it looks precise.

Variants, parents and children

Variation structures are where identifier discipline is tested. The parent is a container. It is not a sellable item and should not carry a GTIN. Each child is a sellable item and carries its own unique identifier.

Three field failures recur. Grouping products that are not genuine variants of each other, which platforms flag and sometimes unpick. Reusing a child identifier when a pack is redesigned, so the sales history of the old pack contaminates the new one. And leaving an obsolete child attached to a live parent, which drags the whole family in search because a dead child with no stock still counts.

Attribute completeness sits alongside this. Platforms filter and rank on structured attributes, not on description text. Material, net quantity, unit of measure, country of origin, shelf life, colour, size, and category specific fields such as skin type or age range. A listing that is technically live but attribute poor will not appear in the filtered browse paths where a lot of demand actually sits.

A practical audit routine

Run this once as a cleanup, then quarterly as maintenance. Export from every channel plus your ERP item master into one sheet.

1. Validate every identifier for length and check digit. Anything failing is fixed before you look at anything else.
2. Count distinct identifiers per internal SKU, and distinct internal SKUs per identifier. Both should be one. Every exception is a work item with an owner.
3. Search each of your own codes on each platform. More than one live page for one code is a merge candidate to consolidate.
4. Search your brand name on each platform and compare the page count against your live SKU count. The difference is duplicates, hijacked pages or stale listings.
5. Check parent nodes for identifiers. A parent carrying a GTIN is a defect.
6. Score attribute completeness by category and rank the gaps by revenue, not by count. Fix the top sellers first.
7. Compare identifiers used on the physical pack, on the outer carton and in the system. Packaging artwork drift is a real and frequent source of mismatch.
8. Freeze the result as a master file with one owner and a change log.

The maintenance rule is short. No new listing goes live without a validated identifier recorded in the master. No pack change ships without a new identifier decision made before artwork is approved. Identifier assignment sits with one named person, not with whoever is uploading that week. That single control prevents most of the work above from ever being needed twice.