BigCommerce CSV Import Errors: Invalid SKUs, Duplicates and Garbled Names

Last updated: August 2026 · By the CSVUndo team · 8 min read · Applies to product CSV imports in the BigCommerce control panel · Not affiliated with or endorsed by BigCommerce

Microsoft’s own documentation says Excel automatically removes leading zeros and converts large numbers to scientific notation, with a maximum precision of 15 significant digits — precisely the treatment that destroys a 12-digit UPC or a long numeric SKU in a product CSV.

What do the BigCommerce import errors actually mean?

The importer works row by row, and most of its complaints are about identifiers. Merchants report “Invalid product SKU” when the SKU column holds something the importer cannot accept — entire manufacturer-supplied files importing nothing under that message. The exact wording varies by store — BigCommerce runs two import experiences side by side (more on that below) — but the diagnosis is the same: the importer read the SKU cell and rejected what it found.

The duplicate family — “SKU is a duplicate”, “The product SKU is a duplicate” — fires when the value already exists on another product. The Catalog API reference documents the conflict as a product that “was in conflict with another product” through “duplicate unique values such as name or SKU”, and the validation failure as a product that “was not valid” from “missing required fields or invalid data”. Note the first phrase: product names must be unique too, so a duplicated name trips the same conflict as a duplicated SKU.

The quieter third pattern — rows skipped as duplicates when you meant to update them — is a matching problem, not a data problem, covered in its own section.

Why does BigCommerce call a SKU invalid after Excel touched the file?

Because what Excel displays is what it saves. In the default General format Excel renders any number of 12 or more digits in scientific notation, so a numeric SKU or UPC like 898765432109 displays as 8.98765E+11 — and saving the sheet back to CSV writes that display string into the file. A BigCommerce SKU is a user-defined alphanumeric code of up to 255 characters, so the platform never expects an exponent there: the value is simply no longer your SKU. Depending on the import path, it can be rejected outright, collide with another collapsed code from the same file, or import “successfully” and quietly poison every feed and integration that reads it.

The recovery is honest but bounded: expanding 8.98765E+11 restores 898765000000 — the digits Excel actually kept, with zeros for the rest. Excel stores at most 15 significant digits, so a longer code had its tail zeroed before the save; rows that still look wrong after expansion need a fresh export from your source system. The full mechanics are in the scientific notation guide and why Excel changes 16-digit numbers to zeros.

Why are UPCs and EANs a digit short?

A CSV cannot declare “this column is text”, so Excel types every cell by guesswork on open. A cell of pure digits becomes a number, and to a number parser the leading zero is meaningless: 042100005264 and 42100005264 are the same quantity, so Excel keeps the shorter one. A UPC-A is exactly 12 digits and an EAN-13 exactly 13, each ending in a check digit — a code that has lost its zero is not a barcode at all.

Here BigCommerce is more forgiving than you would want: the Catalog API accepts the upc field as free text up to 32 characters, with no documented length or check-digit validation, and the gtin and mpn fields are plain strings too. An 11-digit code therefore imports without a murmur, and the damage surfaces later, wherever the code is actually consumed — shopping feeds, channel integrations, a warehouse scanner. A silently damaged barcode is worse than an import error: nothing points at the row. The mechanics are the classic leading-zeros problem; only the place it detonates differs.

How do I repair the file before re-uploading?

Fix the raw file, not the spreadsheet view — cell formatting evaporates on the next save, but a repaired CSV stays repaired.

1. Drop the export onto the scientific notation fixer and confirm which columns hold identifier codes; every collapsed value in them is expanded back to plain digits, delimiter and layout preserved.
2. Then the leading-zeros fixer: tick the UPC or GTIN column, set the standard width — 12 for UPC-A, 13 for EAN-13 — and short digit-runs are left-padded back: 42100005264 becomes 042100005264 again. A BigCommerce SKU column is usually alphanumeric, and a column containing anything but digits is listed with its tick box greyed out, since left-padding A-1001 with zeros would not be a repair.
3. If product names show é or ’, finish with the broken characters fixer — details in the encoding section.

Two design rules protect your catalog. A value is only expanded when it matches the exact shape Excel’s General format writes, so 2E5 is never rewritten — that check runs automatically across the file. And nothing is padded unless you tick its column: a header naming a standard-width code (ZIP 5, UPC 12, EAN 13) is pre-ticked at that width, provided no value in it still starts with a zero — one that does proves Excel never stripped the column. Any other digit-only column is offered unticked with the width pre-filled from its longest value, so read it before you tick. Everything runs locally: the file never leaves your browser.

Why does BigCommerce report duplicates — even for products you deleted?

Three situations end in the same word. The first is genuine: SKUs and product names are unique across the catalog, and your row’s value already belongs to another product. The second is manufactured by Excel: two distinct long numeric SKUs that collapse into the same 8.98E+11 string now conflict with each other, so a clean export reports duplicates that never existed. The third is a matching problem: on the legacy import flow, rows are matched to existing products by the Product ID column — leave it blank and the importer tries to create each row, so anything whose name or SKU collides is reported as a duplicate instead of being updated. BigCommerce does not publicly document how the modern importer matches rows, so on either experience the safe workflow is the same: re-export the products you want to change, edit that file, and keep the ID and SKU columns intact.

And the ghost case: sellers report duplicate-SKU errors on codes whose products were deleted long ago — deleted products lingering in a backend cache that keeps their SKUs reserved until BigCommerce support purges it. A SKU you know is free that keeps bouncing is a support ticket, not a file fix.

Why do product names arrive as é or ’?

Mojibake means the bytes and the decoder disagreed somewhere. Excel’s plain CSV save writes the legacy Windows codepage (Windows-1252 on most machines) rather than UTF-8, and a file can also arrive with the damage already baked in from an earlier round-trip — Café stored literally as Café. BigCommerce does not publish an encoding requirement for import files, so take the question off the table before you upload: hand it clean UTF-8 whose special characters are already correct.

Diagnose first: the encoding checker reads the file’s actual bytes and reports what it really is — which regularly contradicts the save dialog. (CSVUndo tools read raw bytes and detect the encoding before decoding, so a Windows-1252 é survives the trip in.) If the characters are already mangled, the broken characters fixer reverses the common mojibake patterns, and the UTF-8 conversion guide covers producing a clean file. If garbled names are already live in the store, repair the file and re-import it with the ID and SKU columns intact so the clean rows update them.

CSV only: file type, templates, size and delimiter

The product importer takes CSV only: BigCommerce’s help documentation recommends exporting as CSV whenever you plan to re-import, because any other file type will not import, and sellers report .xlsx uploads rejected with an error saying only CSV is accepted. An Excel workbook must therefore pass through Save As → CSV UTF-8 (Comma delimited) — precisely the step that writes Excel’s damage into the file, so repair before you upload, not after.

Which columns the file needs depends on your store: the legacy flow has a field-matching step, P/D product types and Product ID matching, while the modern flow types each row as a Product, Variant or Image row, with variant options in a Type=X|Name=Y|Value=Z syntax sellers report rejections for when it strays. Do not build headers from a blog post, this one included — download the template from your own import page and keep its headers exactly as exported. As a floor, the Catalog API requires name, type, weight and price to create a product; the help documentation describes the minimum as a name and a price, with weight for physical products.

Limits and traps worth knowing: the help documentation puts the import file size limit at 20 MB — roughly 300,000 lines with every supported column — and BigCommerce caps variants per product at 600. Image columns must reference a URL that is already online, or a file on the store’s server; a CSV cannot carry image files from your computer. Since December 2023 the modern importer on Multi-Storefront stores writes custom fields as JSON — the old format broke on characters such as semicolons. And on delimiters BigCommerce documents nothing, but CSV conventionally means commas: if your Excel saves CSVs with semicolons, standardise the file with the delimiter converter, which respects quoted fields.

How do I stop Excel breaking the next export?

Never double-click a product CSV. Open a blank workbook and use Data → From Text/CSV, click Transform Data, set the SKU, UPC and GTIN columns to Text, then Close & Load — declared as text, 042100005264 survives every edit and save. On Microsoft 365 (Version 2309 or later) there is also a permanent switch: File → Options → Data → Automatic Data Conversion, then untick the options that remove leading zeros and convert long numbers to scientific notation — it protects your machine only, so the import habit still matters for colleagues. And keep an untouched copy of every export: the original is the only perfect backup. The full routine is in how to open a CSV in Excel without breaking it.

Frequently asked questions