Moving Amazon wholesale off spreadsheets: what breaks
Migrate Amazon wholesale off spreadsheets in five passes: organizations, contacts, catalogs, purchase orders, cost history — with UPC columns repaired first.
Last reviewed 6 min readSupplyForge LLC
Migrating Amazon wholesale off spreadsheets works in five passes: organizations, contacts, supplier catalogs, open purchase orders, then cost history, with the identifier columns repaired first.
The order matters less than the repair. Most wholesale migrations fail quietly rather than loudly, and the usual cause is a UPC column that a spreadsheet application mangled months ago: nothing errors, no import is rejected, and the new system reports a no-match rate close enough to normal to be believed. The sections below cover the extraction order, the identifier damage, how to detect it in one formula, how to normalize supplier SKUs, and how to run both systems in parallel without doing it forever.
Extract in five passes, in this order
Extract in dependency order, because each pass supplies the keys the next one needs. Pass one is organizations: every supplier, distributor and brand, with its account status — prospect, contacted, applied, approved, active or rejected. Pass two is contacts, each attached to an organization from pass one, deduplicated on email or phone. Pass three is supplier catalog rows: the current price list per supplier, one row per SKU. Pass four is open purchase orders and inbound stock, which reference both a supplier and catalog rows. Pass five is cost history — what you actually paid, per SKU, per date — which feeds COGS and is the hardest thing to reconstruct later. Do not migrate dead data on any pass: a supplier contacted once in 2024 and a price list from two years ago are not worth cleaning.
The leading-zero problem breaks the UPC column
Excel strips leading zeros from any column it treats as a number, which silently invalidates UPC and GTIN values. Reproduce it in ten seconds: type 012345678905 into a blank cell and press enter. The cell now reads 12345678905 — eleven digits, and no longer a UPC-A. Opening a supplier CSV by double-clicking it applies the same General number format to the whole identifier column at once, and the damage becomes permanent the moment anyone saves the file. Long digit strings additionally display as scientific notation, so a copy-paste of what is on screen writes 1.23457E+11 into the new sheet. Neither behavior produces a warning. The fix is to never let the application guess: import through Data, From Text/CSV and set the identifier column type to Text before loading, or rename the file to .txt so the import wizard opens. Details of UPC, EAN, GTIN and MPN for Amazon matching explain which you need per supplier.
The identifier length audit
One formula tells you whether your identifier column survived. Run =SUMPRODUCT(--(LEN(TEXT(A2:A50000,"0"))=11)) across the UPC column: any material count of 11-digit values means leading zeros were lost, because a valid UPC-A is always 12 digits. Repeat with 12 and 13 for catalogs that carry EAN-13 or GTIN-14.
| Identifier | Correct length | What it looks like after the zero is lost |
|---|---|---|
| UPC-A | 12 digits | 11 digits; matches nothing, and the check digit no longer validates |
| EAN-13 | 13 digits | 12 digits; if the original started with a zero this is the equivalent UPC-A and still matches |
| GTIN-14 or ITF-14 | 14 digits | 13 digits; often mistaken for a valid EAN-13 |
| ISBN-13 | 13 digits | Unaffected, because ISBN-13 always begins 978 or 979 |
| ASIN | 10 characters | Usually unaffected, but book ASINs derived from ISBN-10 are all digits and can begin with zero |
The EAN-13 row is why the damage looks random rather than total. Some corrupted rows keep matching, so the no-match rate rises by a few points instead of collapsing, and a few points hides comfortably inside the 10 to 15 percent no-match rate a real wholesale catalog produces anyway from obscure SKUs, bundles and items genuinely not listed on Amazon. To verify a UPC-A rather than just count digits, apply the standard mod-10 check: multiply the digits in odd positions by three, add the digits in even positions, and the twelfth digit must take the total to the next multiple of ten.
Normalizing supplier SKUs before you import
A supplier SKU is unique within one supplier and nowhere else, so the natural key is the supplier plus the SKU, never the SKU alone. Two distributors will both sell you an item numbered 4032, and a migration that deduplicates on SKU across a merged sheet collapses them into one row with one price. Keep the SKU exactly as the supplier prints it, punctuation and all, because you will paste it back into their order form, and store a separate normalized copy — trimmed, case-folded, hyphens removed — for matching only. Split compound cells before the import: $4.19/ea, 12 min becomes a unit cost of 4.19, a case pack of 12 and an MOQ, in three numeric columns. Structuring supplier contact data so it stays clean applies the same rule to people and companies.
Run both systems for one buying cycle
Run the spreadsheet and the new system in parallel for exactly one buying cycle, and reconcile on three numbers rather than on everything. Number one is the catalog row count: rows in the source file against rows loaded, with the difference explained, not estimated. Number two is the no-match rate after matching, which should sit around 10 to 15 percent; materially higher means go back to the identifier audit. Number three is landed cost per unit on one purchase order you actually received, computed both ways — the number that catches a freight allocation or a fee assumption differing between the two systems, and how to calculate landed cost for Amazon wholesale sets out the components. When those three agree, stop maintaining the spreadsheet the same week.
What spreadsheets keep doing better
Spreadsheets keep winning at one-off math, and no migration removes that need. A quick model of a bulk-buy break, a what-if on freight, a supplier's oddly formatted quote pasted in to check a number — all of it is faster in a sheet, needs no permissions setup, and every VA already knows how. Forge Command ships a spreadsheet module and Google Sheets export for that reason. The cost of the move is real too: Forge Command needs your own Amazon SP-API credentials, plus Keepa credentials for Keepa data, before its catalog engine returns anything, and Keepa lookups spend your own paid tokens. Forge Command's pricing is not publicly listed. A seller with two suppliers and 300 SKUs may genuinely be better off in a sheet, as CRM versus spreadsheet for supplier management sets out.
Frequently asked questions
How long does a wholesale spreadsheet migration take
Measure it in buying cycles rather than days. The five extraction passes are usually a few days of work for a seller with 10 to 20 suppliers, and the parallel run should cover one ordering-and-receiving cycle so landed cost reconciles on a purchase order that arrived.
Why did my rows stop matching after moving off spreadsheets
Almost always a corrupted identifier column. Excel strips leading zeros from UPC and GTIN values and displays long digit strings in scientific notation, and neither produces an error. Audit the digit lengths before blaming the matcher, then re-export the identifier column as text.
Should I import my whole price list history
No. Import the current price list per supplier plus the cost you actually paid per SKU. Historical price lists are worth archiving as files, not as rows, because stale costs compete with current ones inside reports.
Can I keep using Google Sheets after migrating
Yes, and most sellers do. Forge Command includes a built-in spreadsheet module and Google Sheets export, so ad-hoc analysis continues in a sheet while the system of record holds suppliers, catalogs, purchase orders and cost history.