GMC Error "invalid_upc": Why Google Rejects Your Barcode and How to Fix It

You upload your product feed to Google Merchant Center and Diagnostics lights up:

Issue: Invalid GTIN [invalid_upc]
Attribute: GTIN [gtin]
Value reported: 012345678905

The error says your barcode is invalid. But the number is right there on the package. Your supplier swears it's correct. Amazon accepts it. Why is Google rejecting it?

invalid_upc (also surfaced as invalid_gtin depending on the Diagnostics view) is one of the most common GMC errors and one of the most misdiagnosed. The cause is almost never a typo. It's almost always one of four specific format issues that look fine to a human but fail Google's mathematical validation.

This post covers what Google actually checks, the four causes ranked by frequency, and the exact verification steps to confirm a fix.

What Google means by `invalid_upc`

GTIN (Global Trade Item Number) is the umbrella term for product barcodes maintained by GS1, the standards body that issues them. The five common formats:

GTIN-8 — 8 digits (small items, bottle caps)
GTIN-12 / UPC — 12 digits (most common in North America)
GTIN-13 / EAN — 13 digits (most common outside North America)
GTIN-14 / ITF-14 — 14 digits (case-level packaging)
ISBN-10 / ISBN-13 — books

Google's product data spec accepts all of these in the gtin field. When Google says invalid_upc, it has done two checks against the value you provided:

Length check. The string must be exactly 8, 12, 13, or 14 digits. No spaces, no dashes, no leading or trailing characters.
Check digit validation. The last digit of every GTIN is a check digit calculated from the previous digits using a fixed algorithm. If the math doesn't work, Google rejects the GTIN regardless of how official it looks.

The check digit math is publicly documented by GS1 and is the same for all GTIN lengths. It's how Google can detect typos and bad transcriptions without a database lookup. Google does not check that the GTIN is registered to a real product; it only checks that the digits are mathematically self-consistent.

Why Google flags it

Four root causes account for nearly every invalid_upc error in practice, ranked by how often each shows up.

Cause 1: A leading zero was stripped (most common, by a wide margin)

This is the single most frequent cause. UPCs that start with 0 get treated as numbers somewhere in your data pipeline and lose the leading zero.

Real example: a valid UPC is 012345678905. Stored in a spreadsheet column formatted as "Number," it becomes 12345678905, which is 11 digits, not 12. Google rejects it.

Where this happens:

Excel and Google Sheets automatically convert numeric-looking strings to numbers. A 12-digit UPC pasted into Excel becomes 1.23457E+10 in scientific notation and the underlying value silently loses precision.
CSV exports from Shopify, WooCommerce, or BigCommerce that go through any spreadsheet step.
JSON-to-feed converters that infer the type as integer instead of string.
Database columns typed as BIGINT instead of VARCHAR.

The fix: store and transmit GTINs as strings, never as numbers. In a CSV, format the cell as Text before pasting. In a database, use VARCHAR(14) not BIGINT. In a feed-generation script, wrap the value in quotes and pad with leading zeros if needed.

Cause 2: The check digit is wrong

The last digit of every GTIN is calculated from the previous digits. If even one digit is off, the check fails.

Here is the GTIN-12 (UPC) check digit algorithm in plain language for the value 01234567890X where X is the check digit:

Sum the digits in odd positions (1st, 3rd, 5th, 7th, 9th, 11th from the left): 0 + 2 + 4 + 6 + 8 + 0 = 20
Multiply that sum by 3: 20 * 3 = 60
Sum the digits in even positions (2nd, 4th, 6th, 8th, 10th): 1 + 3 + 5 + 7 + 9 = 25
Add the two sums: 60 + 25 = 85
The check digit is whatever you'd add to get to the next multiple of 10: 90 - 85 = 5

So 012345678905 is valid. 012345678906 is not.

Common ways check digits go wrong:

Transposed digits during manual entry: 012345678905 typed as 012354678905 fails the check.
Truncation at the wrong end. A vendor sends you a 13-digit EAN (5012345678900) and you assume it's a UPC and drop the last digit instead of the leading "5".
Wrong format conversion. Some systems convert UPC-E (compressed 8-digit) to UPC-A (12-digit) incorrectly.

The fix: validate every GTIN before it goes into the feed. The GS1 check digit calculator is the authoritative tool. For programmatic validation, the algorithm above is straightforward to implement in any language.

Cause 3: The GTIN belongs to a different product

Google does not check the GTIN against a product database, but Google does deduplicate across the global Merchant Center catalog. If your GTIN is shared by another product (because someone reused a deprecated GS1 prefix, or because of a counterfeit-flagged barcode pool), Google may reject your submission with invalid_upc instead of a more specific error.

Common scenario: a small brand buys "GS1 prefixes" from a reseller (like the cheap eBay sellers offering "100 UPCs for $10"). These prefixes are often in the deprecated GS1 US prefix range that was sold off in the 1990s. The barcodes scan, but they're not registered to your brand, and Google's deduplication catches them.

The fix: get GTINs through GS1 directly. If you sell store-exclusive or unbranded products and don't have GS1-issued GTINs, set identifier_exists to false in your feed and provide brand plus mpn instead. See Google's GTIN requirements for when identifier_exists: false is acceptable.

Cause 4: The value contains hidden characters or whitespace

Less common but maddening when it happens: the GTIN looks correct in your spreadsheet but has a trailing space, non-breaking space, or invisible Unicode character that breaks Google's parser.

This usually comes from:

Copy-pasting from a PDF supplier sheet (PDF text extraction adds non-breaking spaces).
Vendor systems that pad fixed-width text columns with spaces.
Excel export with autocorrect settings that insert special characters.

The fix: strip all whitespace and non-digit characters from GTINs before submission. In a script:

const cleanGtin = String(gtin).replace(/\D/g, '');
if (cleanGtin.length !== 8 && cleanGtin.length !== 12 &&
    cleanGtin.length !== 13 && cleanGtin.length !== 14) {
  throw new Error(`GTIN length invalid: ${cleanGtin.length}`);
}

Tools to verify the fix

1. Validate the check digit before submitting. Use the GS1 check digit calculator for one-off checks. For bulk validation, any spreadsheet with the GTIN-13 algorithm can flag bad rows in seconds.

2. Confirm the data type in your source system.

For Shopify:

Go to Products > pick a product > Variants
Check that Barcode field shows the leading zeros if applicable
If the field is blank but you know there's a barcode, the export step probably stripped it

For WooCommerce:

Variant GTINs typically live in _global_unique_id or a custom field via the WooCommerce Brands plugin or similar
Inspect the database directly: SELECT meta_key, meta_value FROM wp_postmeta WHERE post_id = X AND meta_key LIKE '%gtin%'

For BigCommerce:

The upc field on Product or Variant is the standard location
API responses return it as a string; check your feed-generation code for any unintentional parseInt() calls

3. Test a single product end-to-end. In Merchant Center, click into a product flagged with invalid_upc and look at the "Value reported" field. Compare that exact string to what's in your source system. If they differ — extra digit, missing zero, different length — the corruption is happening somewhere in your feed pipeline, not in the source.

4. Bulk-validate your feed before submission:

# Extract GTINs from a CSV feed and check length
xsv select gtin feed.csv | tail -n +2 | \
  awk '{
    gsub(/[^0-9]/, "")
    len = length($0)
    if (len != 8 && len != 12 && len != 13 && len != 14)
      print "INVALID LENGTH:", $0, "(" len " digits)"
  }'

A more thorough check that includes check-digit validation can be wired into any existing feed-validation script. The GTIN check-digit algorithm is one function and worth adding to your pre-submission gate.

What not to do

Don't strip the GTIN field on rejected products. Sending a product without a GTIN when one was expected gets you a different error (missing_required_attribute_gtin) and reduces your eligibility for branded-product placement.
Don't set identifier_exists: false on products that do have valid GTINs. Google uses GTINs to match your products to other merchants' submissions and grant ranking benefits. Setting it false is a downgrade for properly-branded products.
Don't try to "fix" check digits by changing the last digit. If the check digit is wrong, the rest of the digits are probably wrong too — usually a transposition. Get the canonical GTIN from the supplier or GS1, not by guessing.

How SnowPipe handles this

SnowPipe syncs Shopify, WooCommerce, and BigCommerce catalogs to Google Merchant Center via the Merchant API v1. Two specific design choices head off invalid_upc before the data ever reaches Google:

GTIN-aware string preservation. SnowPipe types the GTIN field as a string from extraction through transformation through write. Leading zeros never get stripped because the value is never coerced to a number, regardless of the source system's column type. For Shopify variants, the barcode field comes through verbatim; for BigCommerce upc, the API response is preserved without parsing.

Pre-flight check digit validation. Before any product reaches the Merchant API, SnowPipe runs the GS1 check digit algorithm on every GTIN. Products with invalid GTINs are surfaced in the SnowPipe UI with the exact failure mode (wrong length, failed check digit, contains non-digit characters) rather than waiting for Google to reject them. Catalog managers can fix the source data without burning a Merchant Center submission cycle.

You can see the GTIN validation status in the Products tab inside any GMC connection in SnowPipe, with deep links back to the Shopify or BigCommerce admin to fix the underlying value.

Summary

invalid_upc is almost never a real "invalid barcode." It's almost always a leading-zero strip from spreadsheet handling, a check-digit mismatch from a typo, or a hidden whitespace character from copy-paste. Store GTINs as strings everywhere in your pipeline, validate the check digit before submission, and use the GS1 calculator to confirm any value the supplier sends you. The fix is rarely "get a new barcode" — it's usually "stop your data pipeline from corrupting the existing one."

Tired of fighting GMC barcode rejections one product at a time?

Try SnowPipe free — connect your store and get pre-flight GTIN validation plus accurate Google/Facebook syncs in minutes. Or, book a 15-min demo and I'll walk you through your specific setup.