Common Barcode Errors in Supplier Feeds and How to Fix Them

Why barcode errors matter more than you think

A single wrong digit in a GTIN does not just fail a validation check. It breaks EDI order matching, corrupts GS1 data pool syndication, causes POS lookup failures at the counter, and generates returns when the scanned product does not match the catalog listing. In electrical distribution, where a single order might reference 200 line items across 15 suppliers, barcode errors compound fast.

The worst part: most barcode errors are silent. Your import script does not reject the record because the field is populated. The value just happens to be wrong. You find out when a customer scans a product and gets "item not found," or when your GS1 data pool submission bounces three weeks later.

Error 1: Wrong check digit

The last digit of every GTIN is a check digit calculated using the GS1 modulo-10 algorithm. When a supplier types a barcode manually instead of scanning it, single-digit errors are common. The check digit catches most of these, but only if you actually validate it.

What it looks like in the feed:

How to fix it: Validate the check digit on every GTIN at import time. If the check digit fails, flag the record for correction. Do not attempt to "fix" the check digit by recalculating it, because the error might be in any position, not just the last digit. Send the record back to the supplier for confirmation.

Run your entire feed through the free GTIN validator before importing. It checks the modulo-10 calculation and flags every invalid check digit in seconds.

Error 2: Truncated codes from integer storage

This is the most insidious barcode error because it happens inside your own systems. When a database column stores GTINs as integers instead of strings, leading zeros are silently dropped.

What it looks like:

The supplier sends 0012345678905 (a valid 13-digit EAN). Your import script parses it as a number: 12345678905. Now it is 11 digits. It is not a valid GTIN in any format. Some systems will then try to "fix" this by padding it back to 13 digits, but they pad on the wrong side or pad to the wrong length.

How to fix it:

1. Store GTINs as strings. Always. In every system.
2. Preserve the exact length the supplier sent.
3. After import, validate that the length is 8, 12, 13, or 14 digits. Anything else indicates truncation.
4. If you find 11-digit values in your database, they are almost certainly truncated UPC-A codes. Add a leading zero and validate the check digit.

Error 3: Embedded spaces, hyphens, and formatting characters

Suppliers often format barcodes for human readability. They add spaces between digit groups, insert hyphens, or include non-breaking spaces copied from PDF catalogs.

What it looks like in the feed:

"GTIN": "401 033 036 912 5"
"GTIN": "4010330-369125"
"GTIN": "4010330369125\u00a0"

All three are the same barcode. None of them will pass validation without cleanup.

How to fix it: Strip all non-digit characters before validation. This means removing spaces, hyphens, tabs, non-breaking spaces (U+00A0), and any other Unicode whitespace. Then validate length and check digit on the clean numeric string.

A common mistake is stripping only regular spaces. Non-breaking spaces (copied from PDFs or Word documents) survive most basic cleanup routines. If you are still seeing validation failures after stripping spaces, check for Unicode whitespace characters.

Error 4: UPC-12 vs EAN-13 confusion

North American suppliers send 12-digit UPC-A codes. European systems expect 13-digit EAN-13 codes. When a supplier sends 012345678905 (12 digits) and your system requires 13 digits, someone adds a zero. The question is where.

The correct answer: Add a leading zero. 012345678905 becomes 0012345678905. The check digit remains valid.

The wrong answer (that happens constantly): Add a trailing zero. 012345678905 becomes 0123456789050. The check digit is now wrong, and you have created a barcode that does not exist on any product.

What it looks like when this goes wrong:

How to fix it: When converting UPC-A to EAN-13, always prepend a zero. Never append. After conversion, validate the check digit. If the check digit fails after adding a leading zero, the original UPC-A was already wrong.

Error 5: Duplicate GTINs across product variants

A supplier assigns the same GTIN to multiple product variants. This happens frequently with cable products (same GTIN for different cut lengths), luminaires (same GTIN for different color temperatures), and circuit breakers (same GTIN for different packaging quantities).

What it looks like:

How to fix it: Deduplicate GTINs after import. When the same GTIN maps to multiple SKUs, escalate to the supplier. Each distinct trade item should have its own GTIN. If the supplier insists the GTIN is correct (because they consider cut lengths as the same "product"), document the exception and use your internal SKU for differentiation.

Error 6: Expired or reassigned GTINs

GS1 allows GTINs to be reassigned to different products after a minimum 48-month quarantine period. A GTIN that was valid for a discontinued circuit breaker in 2020 might be assigned to a completely different product by 2025. If your catalog carries historical products, stale GTINs cause mismatches.

How to fix it: Periodically cross-reference your GTIN database against GS1's Global Registry Platform (GRP) or against fresh supplier feeds. Flag any GTIN where the product description in GRP does not match your catalog record.

Error 7: Invalid GS1 prefixes

Every GTIN starts with a GS1 company prefix assigned to the brand owner. Prefixes are allocated by country. A barcode starting with 400 through 440 is assigned to a German company. A barcode starting with 300 through 379 is French. When a supplier fabricates a barcode instead of obtaining one from GS1, the prefix is often invalid.

What it looks like: A GTIN whose first three digits do not correspond to any allocated GS1 prefix range. Prefixes 200-299 are reserved for internal use and should never appear in a supplier feed.

How to fix it: Validate that the GS1 prefix falls within an allocated range. This does not prove the GTIN is real (you would need GS1's registry for that), but it catches obvious fakes.

Building a barcode validation pipeline

The fix for all of these errors is the same: validate before import, not after.

1. Strip formatting. Remove all non-digit characters.
2. Check length. Accept only 8, 12, 13, or 14 digits.
3. Validate check digit. Use the GS1 modulo-10 algorithm.
4. Normalize. Pad to 14 digits with leading zeros for storage.
5. Deduplicate. Flag any GTIN that appears on more than one SKU.
6. Prefix check. Validate the GS1 prefix range.

Use the free GTIN validator to spot-check individual barcodes or validate batches before committing them to your product database.

The cost of skipping validation

Every invalid barcode that enters your system creates downstream work. EDI order rejections. POS lookup failures. Marketplace listing suppressions (Amazon, for instance, rejects products with invalid GTINs). GS1 data pool submission failures. Customer returns when the wrong product ships because the GTIN matched the wrong record.

Catching these errors at the feed import stage costs minutes. Catching them after they have propagated into production data costs days.