This is a workflow I’ve seen become much more complicated than the actual CSV import suggests.
The part I’d focus on is everything that happens before the Shopify update: validating SKUs, matching variants, detecting price/stock changes, handling missing or malformed values, and making sure a supplier’s file format change doesn’t accidentally overwrite the wrong products.
That would also make it much safer to automate than simply importing the CSV directly.
If you’re exploring this from a product-development perspective, I’d be interested in hearing what approaches/tools you’ve already tested and where they fell short. There may be some useful ways to simplify the workflow without making it another expensive all-in-one app.
For stock, I keep it native: Products → Inventory → Export, edit the new quantity, then import and check Shopify’s On hand (current)/(new) safety check before confirming. I’d avoid sorting that CSV in Excel.
The step that breaks most often is not the import itself, it is that the supplier file is keyed on SKU and Shopify’s product CSV is keyed on Handle. Nothing warns you about the mismatch. If the handle column is blank or slightly wrong, the row does not update the product you meant, it creates a new one, and you find out when the store has two of everything. So the first thing the workflow needs is a SKU to handle map built from a fresh export, not from last month’s copy.
Second one that quietly costs money. Opening the supplier file in Excel just to look at it is enough to damage it. Leading zeros vanish from SKUs and 13 digit barcodes become 5.01234E+12. It looks fine on screen. Import that and the barcode field is wrong across hundreds of variants with no error anywhere. Whatever reads the file should read the raw CSV, and if a person needs to eyeball it, do that on a copy.
Third, do not push the whole file. Diff the supplier file against a current export and push only the rows where price or quantity actually moved. A 4000 row supplier update is usually 60 real changes. That makes the import fast, and it also makes a bad file obvious, because if the diff says 4000 rows changed then the supplier changed their format, not their prices.
On timing, for a 3000 SKU catalogue the import is a few minutes. The hour goes on reconciliation before it. That is the part a tool would actually be buying back.
Are your suppliers sending one file each in their own format, or have you managed to get them onto a common template?
I’ve dealt with supplier spreadsheets like this, and the file itself is usually the easy part. The annoying bit is cleaning everything up first — inconsistent SKUs, different column names, missing prices, stock values formatted differently, or products that no longer exist in the store.
Once the file is cleaned up, the import can be pretty quick, but checking the data before pushing it live is what tends to eat up the time. For a larger catalog, even a small formatting issue can turn into a lot of manual work.
I’d definitely be interested in a tool that handles the mapping and validation reliably without being priced like an enterprise solution. That seems to be the gap with a lot of the options I’ve come across.
lumine’s SKU-to-handle point is the one that costs people real money, so two things to build around it rather than after it. First, take a stored copy of the products you are about to touch before every import, not once a month - the import that creates duplicates or zeroes a price is unremarkable until you need the state from ten minutes earlier. Second, run the import on one product first, compare the result field by field with the copy, and only then run the file.
For the developer question: the missing piece in most of these tools is not validation, it is the way back. I build StoreVault, which captures products as they change and, when an import goes wrong, previews the exact writes a restore would make before making them - so the fix is targeted, not a second import on top of the first. Plans are tiered by catalogue size and history depth, never by order volume, which is the right shape for a store that imports supplier files weekly but does not grow its catalogue every week. Whatever you build, give the user that preview.
Yeah same story as the others. The CSV import is the easy 5 minutes. The messy hour is everything before it.
Last update for us: supplier drops an .xlsx mid-week, columns renamed again, stock as "in stock / low / out" instead of numbers, and about 40 SKUs that do not exist in Shopify anymore. Open that in Excel once and leading-zero SKUs / barcodes are cooked, so we never touch the original — copy only, or read the raw file.
Workflow that actually works:
1. Fresh Shopify export (handles + variant SKUs) the same day, not last month’s file
2. Map supplier SKU → Shopify handle/variant ID before anything else — blank/wrong handle = duplicate products, no warning
3. Diff price + qty only. Full file push is how you overwrite good data with garbage when they change the format
4. Import one test SKU, eyeball it, then the rest
5. Keep a pre-import snapshot. When it goes sideways you want undo, not another import on top
For a few thousand SKUs, import itself is minutes. Cleanup + matching is where the time goes. Matrixify / native inventory import are fine once the file is clean — the gap is still cheap, reliable mapping + validation + rollback, not another $500/mo “PIM.”
Here’s the safest way to handle a supplier price or stock update:
Export your current store data as a backup.
Match supplier rows to existing variants using SKU or UPC.
Keep only the fields you want to update, such as price and inventory, so other product data isn’t overwritten.
Standardize the values, remove duplicates, and convert the file to your platform’s required format.
Test 5–10 products first, verify the results, then import the full file.
A clean file may take 20–30 minutes, while mismatched SKUs or complex variants can take several hours. For complex one-time imports, LitExtension’s CSV Files Migration Service can handle the data mapping, customization, and transfer for you.
As soon as the columns are standardized I found supplier CSV updates are generally plain sailing. The largest problems usually come from duplicated or non-matching SKUs, formatting, variants missing or stock that needs to be validated prior to import. For these recurring updates, I would start by creating a consistent template, mapping the supplier fields to the Shopify fields, validating the data and then only importing the changed records. The first clean up can take a couple of hours but subsequent updates can be a lot faster. If exsting products are prohibitively complex and expensive, there’s definitely a gap for a more stripped-down flow that prioritizes robust validation and bulk updates.
Hey @amigo_alpha, most of the time goes into mapping the supplier’s SKU to Shopify’s handle, since both CSV pipes match on handle and supplier sheets are keyed on SKU. Prices go through the product CSV, where a column you include but leave blank wipes that field while a column you omit entirely is left alone, so I strip a partial sheet down to Handle plus the fields I’m actually changing. Stock is a separate file at Products > Inventory > Export/Import, matched on Handle, Location and the option values, with ‘On hand (current)’ validated against ‘On hand (new)’ so a stale sheet gets rejected. Last update took me about an hour, nearly all of it in the lookup. Watch including SKU without Option1 name and value too, that deletes the variant option.
Hi Lukas, the time-consuming part here is matching the supplier’s file to your store and deciding which changes are safe to make. That’s the step I’d use AI to help with.
I built Manager for Shopify, a desktop app that connects AI tools like ChatGPT and Claude to your Shopify store. You can ask it to help with product updates in plain English.
For your file, I’d start with this request: “Match these supplier SKUs to my existing products. Show the old and new prices. List any missing or duplicate SKUs, and leave stock unchanged wherever the supplier hasn’t provided an exact quantity. Don’t update anything yet.”
That gives you a list of proposed changes to check before asking it to apply the updates. If you share a small anonymized sample, I’d be happy to demonstrate the process and see how much of that cleanup we can remove.
@amigo_alpha — fourteen replies here are about mapping the columns, and @lumine’s SKU-versus-handle point is the one that costs the most. There is a whole second category nobody has mentioned, and it is worse because the file looks fine afterwards: Excel changes the values themselves, on open, before you have touched anything.
The supplier’s file was correct. Opening it broke it. Saving it made that permanent.
What it does, all silently:
Leading zeros vanish. SKU 00123 becomes 123. Every row still matches a real-looking SKU, just not yours.
Long barcodes become scientific notation. A 13-digit EAN like 5901234123457 displays as 5.90123E+12, and once saved, the last digits are gone for good.
Some SKUs become dates.1-2 or 3-10 are read as dates and stored as serial numbers. SEP-5 too.
Quantities gain commas. Excel formats 1200 as 1,200. Copy that cell and you copy the comma. Paste it into a quantity field and many tools read it as 1, because parseInt("1,200") is 1 rather than an error. I wrote that bug myself and it put a wrong stock level into a live store — separate thread on how to test for it in ten seconds.
None of these throw an error, and none are visible in a spot check of the first few rows, because the rows that break are the ones with leading zeros or long barcodes and they are scattered.
So if you are building this, two things belong before the mapping step:
Read the bytes, never a spreadsheet’s interpretation of them. Parse the uploaded file directly and treat every identifier column as text. If a human must look at the file first, they should open it through Data → From Text/CSV and set those columns to Text — not by double-clicking, which is what everyone does.
Then validate identifiers by shape, not just by existence. Flag a SKU that got shorter than the store’s, anything containing E+, and any identifier that parsed as a date. Those three catch almost all of it, and they catch it before the import rather than in next month’s stock count.
@gotinker is right to avoid sorting the CSV in Excel. I would go further: the safest version of this workflow never opens the supplier file in a spreadsheet at all.
Disclosure: I build an inventory app, which is how I came to own the comma bug above.
The part that stands out to me is that there are really two separate failure classes before the import even happens: source corruption and write-scope expansion.
A supplier file can be “correct” until a spreadsheet tool mutates identifiers, and an import can be “valid” while still touching more fields than the merchant intended.
I’d want to preserve the raw source, normalize identifiers deterministically, compute the exact before/after diff, and only then decide what is safe to apply.
Full disclosure: I’m building a tool for exactly this workflow called CostRift.
I focused on the step before the Shopify import rather than trying to replace Shopify’s importer.
You load the previous and new supplier CSV/XLSX, map the relevant columns, and it shows price increases/decreases, new and removed SKUs, and rows where the match is uncertain so they can be reviewed instead of guessed.
If selling prices are included, it also shows the margin impact and the selling price needed to preserve the previous margin.
The raw supplier files are processed locally in the browser, and the basic comparison can be used without creating an account.
One thing I’m still trying to learn from merchants is whether the bigger pain is matching/validating the supplier data, or what happens after that when the approved changes need to be pushed into Shopify.
supplier file simply disappears from the new file?
I wouldn’t automatically assume that means zero inventory. It could be discontinued, temporarily unavailable, or just missing from that particular export.
Seems like those “missing SKU” cases probably need to be flagged for review rather than automatically updating Shopify.
Has that been a problem for anyone dealing with these files regularly?
One safety rule I’d add here is to keep “not supplied” separate from “supplied as zero/blank.”
On recurring supplier updates, a missing stock or price value should usually mean “do not change the existing Shopify value,” not “overwrite it with zero or blank.”
I’d also keep duplicate SKU, unmatched SKU, and missing required value as separate exception buckets instead of trying to auto-fix them.
One thing I’m curious about from your actual supplier files: when suppliers change columns or variant labels, do the SKU/barcode identifiers usually stay stable, or do those change too?
That seems like the point that determines how safely the comparison can be automated.
Following up on the examples here: thinking of your most recent supplier CSV or Excel update, did an unexpected price, stock quantity, or missing SKU make it into the store? Which import or sync tool did you use, and did you catch it before or after it wrote to Shopify? If you used a preview or dry run, what did it miss? Roughly how long did it take to correct? No store details or files needed — I’m trying to understand what actually happened in the workflow.
Your distinction between the product and inventory CSVs is helpful. For stock-only changes, a fresh Inventory → All states export includes SKU, Handle, and Location, so supplier SKUs can be matched against that export before filling On hand (new), while keeping On hand (current) for Shopify’s safety check. For the update that took an hour, did the supplier file contain total on-hand counts for one location, or units received / multiple locations? That determines whether replacing the on-hand value is appropriate.