The Linnworks CSV import is genuinely powerful: one file, one mapping, and thousands of prices change in a single run. That is also the problem. The same mechanism that updates 5,000 SKUs in thirty seconds will destroy 5,000 prices in thirty seconds, with no confirmation step and no undo. Having run — and occasionally fumbled — hundreds of these imports, here is what actually goes wrong and the workflow that prevents it.
Trap 1: the mapping screen trusts you completely
Every import starts by mapping your CSV columns to Linnworks fields, and this is where the worst accidents happen. Map your cost column to Retail Price and Linnworks will not blink — it will set your selling prices to your supplier costs across every row, silently. Map tier-price columns to the wrong extended property names and one tier's prices land in another tier's field. The import reports success either way, because as far as it is concerned, it succeeded.
The insidious part is saved mappings. Reusing last month's mapping is convenient right up until this month's file has its columns in a different order — then every saved assignment points at the wrong column. Check the mapping preview against actual values every single run, even with a saved mapping. Especially with a saved mapping.
Trap 2: silent overwrites
Linnworks imports are row-per-SKU write operations, not merges. Whatever value sits in a mapped column replaces whatever was there before — there is no "skip if blank" instinct looking out for you, no diff view, no confirmation showing what will change. Good data is overwritten as cheerfully as bad data. This is the single most important thing to internalise: an import is a bulk overwrite that happens to come from a file. Treat every run with the caution that description deserves.
Trap 3: the partial file
A subtler failure. You export your full catalogue, fix prices for one supplier's 400 SKUs, delete the other rows "to keep the file tidy", and import. Fine — those 400 update and the rest are untouched. But mix this habit with a colleague's habit of working on full-catalogue files and you eventually import an old full file over a newer partial update, reverting last week's changes without anyone noticing. Version control by filename ("prices-FINAL-v2-USE-THIS.csv") is where price accuracy goes to die. Decide as a team: files are either always full-catalogue or always scoped-and-dated, never a mixture.
Trap 4: encoding and format gotchas
- Excel eats your data before Linnworks sees it. Open a CSV in Excel and it may reformat what it finds — long numeric codes turn into scientific notation, leading zeros vanish, and regional settings can mangle decimal values. Save, and the damage is baked into the file.
- Currency symbols and thousands separators. A price column containing "£1,299.00" may not parse as the number you intend. Strip to plain decimals — 1299.00 — before importing.
- Character encoding. Files saved with the wrong encoding can corrupt accented characters and symbols. If your file contains anything beyond plain text, prefer UTF-8 and spot-check after export.
- Blank versus zero. A blank cell and 0.00 are not the same intention, but a mapped column does not know that. A stray zero in a price column is a free-product generator.
The safer round-trip workflow
- Export first, always. Pull the current values of every field you are about to touch. This is your backup — date-stamp it and do not touch it. Restoring from this file is your only undo.
- Edit a copy, never the backup, and never delete "irrelevant" columns you might need for verification later.
- Sanity-check the file: row count matches expectation; no blanks or zeros in price columns; spot-check five SKUs by hand against the source of the change.
- Verify the mapping preview against real values — does the column labelled Retail Price actually show retail-looking numbers?
- Trial with ten rows. Import a ten-SKU slice, open those items in Linnworks, confirm the right fields changed. Only then run the full file.
- Re-export and diff. After the full run, export again and compare against what you imported. Silent failures show up here and nowhere else.
Yes, it is slower than just hitting import. It is dramatically faster than reconstructing your price book from a stale backup and memory.
When to stop using CSV entirely
CSV is the right tool for occasional, structural changes — a supplier's annual price update, a one-off catalogue restructure. It is the wrong tool for routine pricing work. If you are running the round-trip weekly to maintain trade tiers, recalculating formula columns in Excel each time, the file is not your tool any more; it is your risk. A grid-based editor with inline editing and bulk maths removes the export-edit-import cycle for day-to-day changes — we compare the approaches honestly in bulk price updates: CSV vs grid — and formula-driven tiers remove most of the reason the file existed, as covered in cost-up and RRP-down price list formulas.
That is the design behind B2B Price Tiers, coming very soon: a spreadsheet-style grid with inline editing and bulk maths, formulas that recalculate tiers when costs change, CSV import/export kept for the jobs it is genuinely good at, and two-way sync writing every tier price to native Linnworks extended properties — so there is always a clean copy of your price book inside your own account. £29.99/month with a 14-day trial at launch. See b2b-prices.mcp-g.com and register your interest to get early access.