Search the Linnworks docs for "price list" and you will come up short. Each stock item has exactly one retail sale price and one purchase price. If you sell to trade customers at different rates — bronze, silver, gold, distributor — the platform simply has no home for those numbers. Here is an honest map of the workarounds, from worst to best.
First, the distinction people miss: channel prices are not price lists
Linnworks does support channel-specific pricing: you can set a different price per listing on eBay, Amazon or your website. Sellers sometimes hear this and think the multiple-price-list problem is solved. It is not, because channel pricing answers a different question.
- Channel pricing answers "what does this SKU cost on this marketplace?" Every buyer on that channel sees the same number.
- A customer price list answers "what does this SKU cost for this buyer?" The same order channel — usually phone, email or a trade counter — needs different prices for different customers.
You cannot fake per-customer pricing with channels. You would need a channel per customer, which is absurd, and trade orders mostly are not coming through marketplaces anyway. If you are weighing per-customer prices against grouped tiers, we compare the two models properly in customer-specific pricing vs price tiers.
The spreadsheet workaround (and how it fails)
What most Linnworks wholesalers actually do: an Excel file with a column per tier, formulas hanging off the retail or cost price, emailed to whoever takes trade orders. It works on day one. It degrades from day two:
- Version drift. The warehouse copy, the sales copy and the "FINAL v3" copy disagree within a month. Nobody knows which is live.
- New SKUs never make it in. Products created in Linnworks do not appear in the spreadsheet until someone remembers. Trade customers get quoted retail, or worse, a guess.
- Cost changes do not propagate. Your supplier raises prices, Linnworks purchase prices get updated (maybe), and the spreadsheet's margins quietly rot.
- Formula damage. One sort operation on a filtered range and a hundred prices are silently wrong.
Every failure mode shares a root cause: the price list lives outside the system of record. We go deeper on this in tiered pricing in Linnworks without spreadsheets.
The better workaround: price lists in extended properties
Extended properties — Linnworks' flexible name/value fields on each stock item — can hold one property per tier: "Tier_Trade", "Tier_Distributor" and so on. This immediately fixes the biggest spreadsheet problem, because the prices now live on the stock item itself. They are visible in the Linnworks UI, editable by staff, exportable to CSV, and readable by any order tool or template via the API.
Maintained by hand, though, this approach still has sharp edges. There is no validation (typos become prices), no formulas (a cost change means recalculating every tier yourself), and bulk updates mean the CSV import round-trip, where one wrong column mapping silently overwrites good data. It is a sound storage layer with no maths on top.
It is still worth doing even manually, because it changes where mistakes happen. A wrong number in a spreadsheet is invisible until a customer queries an invoice; a wrong number in an extended property is on the item screen where anyone picking or quoting can see it. And because extended properties export cleanly, you can audit the whole price book in one pull rather than reconciling three copies of a file.
What a proper tier engine adds
The end state is to keep extended properties as the storage — because that keeps your data portable and inside your own account — and put a pricing engine in front of them. Concretely, that means:
- Named tiers, unlimited. Bronze, silver, gold, export, staff — whatever your trade structure needs, not a fixed three.
- Formula-driven prices. Each tier defined as cost-plus-margin or RRP-minus-discount, so a cost update recalculates every affected tier price instantly. See wholesale price list formulas: cost-up vs RRP-down.
- Attractive rounding. Formulas that land on .99, .95 or .49 endings instead of £13.4271.
- A grid, not a form. Spreadsheet-style editing with bulk maths across thousands of SKUs, plus CSV import/export for the cases where a file genuinely is easier.
- Customer-to-tier assignment and per-tier minimum order values, so the list is enforced at order time rather than being a reference document.
- Two-way Linnworks sync, writing every tier price back as native extended properties — so if you ever stop using the engine, your price lists stay in Linnworks.
That last point is the litmus test when evaluating any pricing app: ask where the prices live. If the answer is "in our database", your price list is hostage. If the answer is "in your Linnworks extended properties", you own it.
This is precisely the tool we are building. B2B Price Tiers is coming very soon: unlimited named tiers, a cost-up/RRP-down formula engine with attractive rounding, a bulk-editing grid, customer-to-tier assignment, minimum order values, and two-way sync to native Linnworks extended properties — £29.99/month with a 14-day trial when live. See b2b-prices.mcp-g.com for the full picture and register your interest now to hear the moment it launches.