How to Merge Inventory CSVs by SKU: Supplier Stock + Amazon, eBay, and Shopify Exports

10 min readPipeSheets Team

To merge inventory CSV files by SKU, first normalize the SKU column in every file (trim whitespace, fix the case, and restore leading zeros), then choose one file as the primary catalog and left join the update files onto it so every catalog row is preserved. The merge is only as accurate as the join key, so almost every failed inventory merge traces back to SKUs that look identical to a human but do not match byte-for-byte. This guide walks through cleaning the key, picking the right merge type, resolving conflicts when two files disagree, and verifying the result before you overwrite live stock.

If you sell across a supplier feed plus Amazon, eBay, and Shopify, you already know the pain: four exports, four column layouts, four slightly different versions of the same SKU. You paste them into one sheet, run a VLOOKUP, and half the rows come back as N/A. Nothing is actually missing. The keys just do not line up. Let's fix the key first, then merge.

Pick your primary file and your update files

Before touching formulas, decide which file is the source of truth for each column. A clean merge has exactly one primary file and one or more update files layered on top of it.

Assign a role to every file you are merging:

Primary (catalog): the master list of every SKU you own, with your canonical titles, categories, and cost. This file defines which rows survive the merge.
Update (stock): a supplier feed or warehouse export that carries current quantity on hand. You want its numbers, not its product names.
Update (marketplace): an Amazon, eBay, or Shopify export that carries live price or listing status per SKU.
Append candidates: rows for SKUs that exist in an update file but not in your catalog. Decide up front whether new SKUs should be added or ignored.

Naming these roles matters because it dictates conflict handling later. When your supplier feed says a SKU has 12 units and your Shopify export says 9, the answer depends on which file you trust for the quantity column, not on which number is bigger.

Why does the SKU join fail even when the SKUs look identical?

The join key is the SKU (or Custom Label, or seller-sku, depending on the platform). A join compares keys as exact strings. Three differences that are invisible on screen will silently break the match.

The three key killers, in order of how often they bite:

Leading and trailing whitespace: a supplier exports "SKU-100 " with a trailing space; your catalog has "SKU-100". Different strings, no match.
Case differences: "abc-100" versus "ABC-100". A string comparison treats these as two different products.
Leading zeros stripped by Excel: your SKU is 00123. Open the CSV in Excel and it reads 00123 as the number 123. Now one file has the text "00123" and the other has the number 123, and a lookup returns N/A because the key and the table values are different types.

The leading-zero problem is the sneakiest because it happens after you open a perfectly good CSV. Excel converts anything it reads as a number to the General format and discards the zeros, since 007 and 7 are mathematically identical. If your SKUs have leading zeros, keep the file out of Excel or force the SKU column to text before you do anything else.

Here is what the same product looks like across four exports, before any cleanup. Every row is meant to be the same SKU:

Source          SKU value as stored
--------------  -------------------
Catalog         00123
Supplier feed   00123           (trailing space)
Amazon          abc-00123
eBay            ABC-00123
Shopify (Excel) 123             (leading zeros lost)

Five spellings of one SKU. A raw merge would treat these as up to five different products. Cleaning the key means collapsing them back to a single canonical form before the join runs.

How to clean the SKU key before merging

Standardize the key in every file to the same rules, then merge. Do this on each file separately so you can spot problems per source.

Apply the same normalization to the SKU column in every file:

Trim leading and trailing whitespace (and collapse any double spaces).
Force a single case convention. Uppercase is the safest default for SKUs since most are alphanumeric codes.
Restore leading zeros if any were lost, padding to a fixed width so 123 becomes 00123 again.
Standardize the separator. If some files use ABC_100 and others ABC-100, pick one and find-and-replace the other.
Strip stray prefixes a channel adds, such as a marketplace tacking its own code onto your SKU.

This normalization step is exactly what PipeSheets is built for. Upload each export, run trim whitespace and a case transform on the SKU column, use find and replace (including regex) to unify separators, and preview the before and after with detected column types so you can confirm the SKU column is text and not a number. Because PipeSheets does not silently reformat cells the way Excel does, your leading zeros and long numeric SKUs survive the round trip. Clean each file, download it, and then merge with whatever tool you already use.

After cleanup, the five spellings above collapse to one:

Source          Raw SKU          Cleaned key
--------------  ---------------  -----------
Catalog         00123            00123
Supplier feed   "00123 "         00123
Amazon          abc-00123        00123
eBay            ABC-00123        00123
Shopify (Excel) 123              00123

Pro tip: also normalize the SKU in your primary catalog, not just the update files. It is tempting to treat the catalog as already clean, but a single trailing space in the master list will orphan every match against it.

Check for duplicate SKUs inside each file first

A join assumes the key is unique within each file. If your supplier feed lists the same SKU on two rows (say, two warehouse locations), a naive merge can multiply your catalog rows or pick an arbitrary one of the two. Shopify makes this especially easy to trip over: its inventory export writes a separate row per location, so the same SKU legitimately appears multiple times with different Available quantities.

Before merging, resolve duplicates inside each source:

Count rows per SKU in each file and flag any SKU that appears more than once.
Decide the rule: sum quantities across duplicate rows, keep the highest, or keep the most recent row.
For multi-location exports, aggregate to one total-quantity row per SKU before the join, or the location rows will fan out your results.
Only then merge, so each key maps to exactly one row on each side.

Left join vs update-only vs append: pick the right merge

The word merge hides three genuinely different operations. Choosing the wrong one is how people accidentally delete SKUs or zero out stock.

Left join (keep all catalog rows)

Start from the primary catalog and pull matching columns from the update file. Every catalog row survives; SKUs with no match in the update file simply get blank update columns. This is the default for building a combined view without losing products. In a spreadsheet this is a VLOOKUP or XLOOKUP from the catalog against the update file.

Update-only (touch only matching rows)

Overwrite specific columns (like quantity) on catalog rows that have a match, and leave non-matching rows untouched. Use this when a supplier sends a partial stock file covering only the SKUs that changed. The danger to avoid: do not let a partial update file blank out or zero the quantity for SKUs it never mentioned.

Append (add new rows)

Stack rows from the update file that have no match in the catalog, adding brand-new SKUs to the master list. Append is a union, not a lookup, so column headers must line up first. This is where header normalization pays off: a supplier's Item Number and your SKU need the same header before you can append.

Most real inventory refreshes are a left join plus a controlled append: keep every catalog row, refresh quantities from the supplier, and add genuinely new SKUs while flagging them for review rather than trusting them blindly.

A worked example: two 4-row files merged by SKU

Here is your primary catalog. It carries your titles and prices:

catalog.csv
sku,title,price,qty
00123,Blue Widget,19.99,5
00124,Red Widget,24.99,0
00125,Green Widget,14.99,8
00130,Purple Widget,29.99,3

And here is a supplier stock file. Note the messy keys: a trailing space, mixed case, and a SKU (00131) that is not in your catalog:

supplier.csv
supplier_sku,on_hand
00123 ,12
ABC-00124,0
00125,8
00131,40

After normalizing both key columns to uppercase, trimmed, zero-padded text, a left join on the catalog produces this. Watch the four outcomes:

merged.csv (left join on catalog)
sku,title,price,catalog_qty,supplier_on_hand,status
00123,Blue Widget,19.99,5,12,MATCH (conflict: 5 vs 12)
00124,Red Widget,24.99,0,0,MATCH
00125,Green Widget,14.99,8,8,MATCH
00130,Purple Widget,29.99,3,,UNMATCHED (no supplier row)

Append candidate (in supplier, not catalog):
00131 -> 40 units, no catalog record. Review before adding.

Four things happened, and you need to see all four: 00123 matched but the two files disagree on quantity (5 versus 12), 00124 and 00125 matched cleanly, 00130 is unmatched because the supplier did not send it, and 00131 is a brand-new SKU the supplier has but you do not. A merge that only shows you the tidy matched rows is hiding the rows that actually need a decision.

How to handle conflicts when two files disagree

When both files carry a value for the same column (00123 above), you need an explicit rule, not a coin flip. Decide before the merge, and apply it consistently.

Common conflict-resolution rules for inventory:

Source priority: the supplier feed always wins for on-hand quantity; your catalog always wins for title and cost. This is the cleanest rule for stock data.
Newest wins: if each file has a timestamp, keep the value from the more recently exported file. Useful when two systems both push stock updates.
Highest or lowest: for safety-conscious sellers, take the lower quantity to avoid overselling. Never guess this rule, decide it deliberately.
Flag and review: for price conflicts especially, write both values side by side and hold the row for a human rather than auto-picking.

Whatever you choose, keep both original columns in the output during testing (catalog_qty and supplier_on_hand as separate columns) so you can audit the decision. Collapse to a single final column only once you trust the rule.

Verify row counts before you trust the merge

The last step separates a real merge from a hopeful one. Reconcile the counts. If they do not add up, your key is still dirty or you have hidden duplicates.

Post-merge verification checklist:

Matched count: how many catalog SKUs found a row in the update file. A surprisingly low number almost always means unnormalized keys.
Unmatched-in-catalog: catalog SKUs with no update row. Expected for partial feeds; a red flag if the feed was supposed to be complete.
Unmatched-in-update (append candidates): update SKUs missing from the catalog. Review each before adding, since some are just typo variants of existing SKUs.
Conflicting count: rows where both files had a value and they differed. Confirm your conflict rule fired on every one.
Total row count: output rows should equal catalog rows for a pure left join. More rows means a duplicate SKU fanned out; fewer means you dropped rows.
Spot-check leading zeros in the final file: open it and confirm 00123 is still 00123 and did not become 123.

This is where the platform-specific column names matter, because you have to map them to your key before any of this works. Shopify inventory exports key on SKU (with Handle and Location columns, and a separate row per location). Amazon inventory loader files use the seller-sku column as the identifier alongside quantity and price. eBay's bulk file calls the SKU the Custom Label and requires the Action column to sit first, with everything else in any order. Rename each of these to a single common header (sku) before you merge, and the join has a fair chance.

The short version

A good inventory merge is 80 percent key hygiene and 20 percent the actual join. Normalize the SKU in every file to the same trimmed, cased, zero-padded text form; dedupe within each file; pick left join, update-only, or append deliberately; set an explicit conflict rule; and reconcile matched, unmatched, and conflicting counts at the end. Do the cleaning first with a tool like PipeSheets that will not mangle your SKUs, and the merge itself becomes the easy part. Skip the cleaning, and no merge tool on earth will save you from a key that does not match itself.