One GTIN Across Multiple Variants: Detecting Dangerous Duplicates

A repeated GTIN is only dangerous if the rows claim to represent different trade items. The same variant can appear multiple times for different warehouses, suppliers, or dates: these are then offers to group under a shared identity. On the other hand, the same code assigned to two contradictory sizes, colors, presentations, or brands must block the merge. First validate the check digit, compare normalized attributes, keep the provenance, then place conflicts into a human review backed by an official source. Never automatically pick the most complete or most frequent row.

Legitimate repetition or identity collision

GS1 states that a GTIN can only be assigned to a single product. The organization also notes that trade item variations such as model, color, size, scent, weight, or presentation may require different references. The word "duplicate" therefore needs qualifying.

A legitimate repetition looks like this: same GTIN, same brand, same model, same size, and same content, but different supplier SKU, price, stock, or warehouse. The offers can be compared without overwriting their provenance. A collision looks more like the same GTIN for "blue, size S" and "red, size L," or for a single unit and a pack of three. It touches identity itself.

Preparing attributes before grouping

Grouping on the raw string creates errors if one format has zero-padding and the other doesn't. Keep the raw value, then create a normalized representation only according to documented rules. GS1 notes, for example, that its XML messages use a fourteen-digit GTIN with left-padding, while other exchanges accept a variable length. Normalization must be reversible.

Run each value through GTIN check-digit validation. Exclude invalid formats from automatic grouping, but keep them in the report. Then normalize the attributes without erasing their meaning: case, spacing, and accents can be harmonized for comparison, while size, color, quantity, and unit must remain explicit.

Create two layers:

1. product_identity for brand, model, and family; 2. variant_identity for size, color, scent, weight, content, or another sold dimension.

A product-level match does not justify a variant-level merge. This separation is essential when a catalog offers a generic title and places the size in another column.

An explainable detection algorithm

Detection can follow a deterministic procedure:

1. Preserve row, file, source, and timestamp. 2. Classify the code as absent, invalid, or check-digit-valid. 3. Group valid codes by normalized representation. 4. Compare brand, MPN, model, size, color, presentation, and content. 5. Flag multiple_offers if all identity attributes match. 6. Flag variant_conflict as soon as a structuring attribute diverges. 7. Flag insufficient if attributes are missing on both sides. 8. Require authorized proof before any resolution.

Don't calculate an average score that offsets a contradictory size with a very similar title. Some fields are blocking. An internal rule can declare that a divergence in brand, size, or content requires review regardless of overall similarity. This rule must be visible and versioned.

Resolving without majority voting

If five stores repeat the same erroneous code and a brand source gives a different variant, frequency does not make the five copies correct. Marketplace data can share a common origin. Favor primary proof: GS1 documentation where access rights allow, an official brand listing, readable packaging, or an authorized feed from the rights holder.

Log the decision with resolved_by, resolved_at, the proof URL or document, the applied rule, and the affected rows. Do not erase the faulty value from the raw source. The correction belongs to a matching layer, which allows it to be revised if the supplier fixes their feed.

Once identity is confirmed, offers can move on to the method for comparing suppliers on the same EAN. Price, stock, and SKU remain specific to each offer; only the product reference is shared.

When the GTIN is missing

Do not fabricate a GTIN to clear the review queue. Temporarily use an internal key based on source and SKU, then look for other proof. Matching by image and name can propose a candidate, but it must stay probabilistic and never replace official identification.

Images can show old packaging, assortments, or a generic variant. Titles can omit the size. Use them as complementary signals and require a larger safety margin before linking offers.

Duplicate review checklist

• ☐ Both raw and normalized values are kept.
• ☐ The check digit is validated before grouping.
• ☐ Product and variant are modeled separately.
• ☐ Multiple offers are not overwritten.
• ☐ Size, color, weight, and presentation are blocking on divergence.
• ☐ A missing attribute is distinct from a match.
• ☐ The majority of occurrences is not treated as proof.
• ☐ The official resolution source is logged.
• ☐ Corrections remain reversible.
• ☐ Matches without a GTIN keep a probabilistic status.

What ArbitragePro+ can automate / what the seller must verify

The proposed file-revue-correspondances specification could group valid GTINs, compare blocking attributes, and create a conflict queue with all source rows. It should keep the history of every resolution.

The seller must review authorized proof, confirm the variant and packaging, resolve conflicts, and own the final decision before linking offers or publishing a listing.

Review matches in context

Open ArbitragePro+ search to review the available products, identifiers, and matches.

Official sources

• GS1, «Global Trade Item Number (GTIN)», https://www.gs1.org/standards/id-keys/gtin — accessed 2026-08-17.
• GS1 Support, «How do GS1 GTINs and barcodes work?», https://support.gs1.org/support/solutions/articles/43000734095-how-do-gs1-gtins-and-barcodes-work- — accessed 2026-08-17.
• GS1 Support, «GS1 barcode commonly used for trade item identification», https://support.gs1.org/support/solutions/articles/43000734137-what-is-the-gs1-barcode-commonly-used-for-trade-item-identification- — accessed 2026-08-17.
• GS1 Support, «Required format of GTIN in GS1 EDI standards», https://support.gs1.org/support/solutions/articles/43000734355-what-is-the-required-format-of-gtin-in-gs1-edi-standards- — accessed 2026-08-17.