iqseller
← Back to blog

EAN and GTIN errors that block your listings and how to fix them

July 12, 2026

What is a unified catalog and why you need one to sell across channels What is ACoS More on Catalog

When a listing gets blocked over an ean gtin problem, it’s almost always one of four things: the code has a wrong check digit (it doesn’t validate), it comes from a prefix that isn’t yours and doesn’t match your brand (a resold code), it’s already used on another product in your own account (a duplicate), or it’s simply in a format the marketplace doesn’t accept for that category. Figuring out which of the four is the first thing you have to do, because each one is fixed differently and the error message Amazon or MercadoLibre hands you rarely says which is which.

The reason underneath is that GTIN (Global Trade Item Number) is the number that identifies your product in world commerce, and EAN-13 or UPC-A are just formats of that GTIN. Marketplaces no longer accept anything you type in: they query the global GS1 database to confirm the code exists, that the check digit adds up, and that the prefix belongs to your brand. If any link in that chain fails, the listing is rejected before it even goes live. It’s not a platform whim, it’s the verification working as designed.

This article walks through the EAN and GTIN errors that block listings most often, how to read the real message behind each rejection, and how to fix a duplicate or invalid code without ending up with three dashboards open and an impossible spreadsheet trying to guess which code belongs to which SKU on each channel.

iqseller panel about EAN and GTIN errors that block your listings and how to fix them
Illustrative view of the module in iqseller.

error 1: the check digit doesn’t add up

An EAN-13 has 13 digits and the last one isn’t random: it’s a control digit calculated from the other twelve with a fixed formula (a weighted sum of odd and even positions). When you type a code by hand and drop a number or swap two of them, that digit stops matching and the marketplace catches it instantly with an error like “invalid barcode” or “invalid GTIN.” It’s the silliest error and the most common, because it almost always starts as a typo when someone moves a code from a label into a spreadsheet.

The fix is simple but tedious by hand: check that the code has the right number of digits (13 for EAN-13, 12 for UPC-A) and that the check digit is correct. Free online validators exist, but the real pain for a multichannel seller isn’t validating one code, it’s validating hundreds without knowing which one is wrong until the listing breaks. A catalog that validates the check digit the moment you enter the GTIN warns you before the rejection, not after.

One detail that trips people up: sometimes the code is fine but you pasted it with an invisible trailing space, or with the leading apostrophe Excel adds to treat it as text. The marketplace reads that ghost character and rejects a code that is actually correct. Cleaning the format before publishing saves hours hunting for an error that isn’t in the number at all, only in how it got saved.

Glossary: what an EAN/GTIN is and what it’s for →

error 2: the code doesn’t match your brand (resold)

This one stings the most because you don’t see it coming. You bought “lifetime” codes for five dollars in a bazaar or reseller site, published without a problem for months on MercadoLibre, and suddenly Amazon rejects the listing with “the GTIN doesn’t match the brand” or “invalid code.” You didn’t do anything new: Amazon simply queried the GS1 database and found that the prefix of that code belongs to another company, in another country, not to your Brand Registry brand.

There’s no cosmetic fix here. The code is structurally wrong because its prefix was never yours. The only real way out is to replace it with a legitimate GTIN generated from your own GS1 México prefix. If you don’t have a prefix yet, the full route is in how to get legitimate EAN or GTIN codes for your products in Mexico; there’s no valid shortcut, and every attempt to “recover” a resold code ends in the same rejection.

The extra pain is that you discover the problem product by product. A reseller sold you twenty codes from the same sliced-up prefix, and those twenty will fail; but you find them one at a time, each time you try to publish or update. Having the catalog in a single place lets you flag every SKU dragging codes from a suspect prefix at once, instead of patching leaks one by one.

error 3: the same GTIN on two products (duplicate)

A GTIN identifies a unique product. If the same code shows up on two different SKUs in your account, the marketplace doesn’t know which is which and blocks the listing with a duplicate error, or worse, attaches your product to the wrong listing. This happens constantly with variants: you enter the same code for the small size and the large one because “it’s the same product,” when in reality each sellable variant needs its own GTIN.

It also happens the other way around, and that’s more treacherous: two physically different products end up with the same code because someone copied a row in the master spreadsheet without changing the GTIN. On a single channel you might catch it; with Amazon, MercadoLibre and Shopify at once, the duplicate can live hidden for weeks until one listing collides with another and neither updates correctly. Manual reconciliation across files is exactly where these duplicates slip in.

The fix is to assign a unique GTIN per sellable product and verify no code repeats across the whole catalog. Doing that by hand in a spreadsheet of hundreds of rows is precisely the invisible work that grinds down the multichannel seller. A unified catalog that stores each SKU with its GTIN once detects the duplicate the moment you enter it, not after it has already rejected the listing on two different channels.

Glossary: unified catalog across channels →

error 4: wrong format for the category

Not every category accepts the same type of code. Amazon may ask for an EAN-13 in electronics but accept only UPC-A in another category, or require a GTIN where you’re trying to put an ASIN. MercadoLibre has its own rules per category and sometimes lets you publish without a code, sometimes not. The error reads like “the identifier type isn’t valid for this category” and it confuses people because the code itself is legitimate; it’s simply not the format that category expects.

The fix comes from knowing what each category asks for before publishing, not after the rejection. If your product has a valid EAN-13 from GS1, you can almost always convert it or present it in the format the category accepts, because EAN and UPC are the same GTIN seen two ways. The problem isn’t the number, it’s knowing which of its formats applies in each place.

GTIN exemption fits in here too. If you sell a very small private label or handmade goods, you don’t always need a code: Amazon offers the GTIN exemption with your brand approved, and MercadoLibre allows publishing without a code in several categories. The expensive mistake is forcing a resold code “to get by” when you actually qualified for exemption. The simple rule: someone else’s brand that already exists → use its GTIN; your own new product → your own GTIN or a formal exemption, never a resold one.

how to know which error you have before it breaks

The marketplace error message almost never names the real cause. “Invalid GTIN” can be a wrong check digit, a resold code, or a wrong format, and each is fixed differently. Chasing the literal message makes you guess blindly: change the code, republish, wait for the rejection, try something else. That trial-and-error loop, multiplied across channels, is what turns a five-minute fix into a lost afternoon.

The way to break the loop is to check the code against all four causes in order, before retrying: first validate digits and check digit (is the number well formed?), then the prefix (is it yours or resold?), then uniqueness (is it used on another SKU?), and finally the format for the category. If you have the catalog in a board that already knows these four checks, the problem shows up flagged before you try to publish, not as a surprise rejection three days later.

That same unified panel is what lets you cross the catalog against what you can actually ship. Fixing a GTIN does little good if the product has no real available stock; publishing in real time something you can’t deliver just swaps one problem for another. When you see code, channel and availability in a single view, you stop reconciling by hand and start deciding with information you trust.

Glossary: what real available stock is →

the pattern behind all these errors

Notice that all four errors are born in the same place: the code lives loose, typed by hand, repeated across files and channels with no single source keeping it honest. The wrong digit is a spreadsheet typo; the resold one is a code nobody verified at setup; the duplicate is a copied row; the format is a rule you didn’t check. None of them is a hard technical problem. All of them are the consequence of managing identifiers in several places at once without those places talking to each other.

That’s why the durable fix isn’t repairing each rejection as it appears, but tying every GTIN to its product in one place all channels share. There the digit is validated on entry, the prefix is flagged if suspect, the duplicate is caught instantly, and the format is adjusted per channel. You get to start with ACoS and healthy prices because every listing points to a real, identifiable product, instead of chasing code errors listing by listing. Legitimate codes plus a real-time unified catalog turn those blocks into something you see at a glance and fix before they stop a sale.

See every metric in detail →

be among the first in the beta

Join the waitlist