← All posts
Linnworks ops · 10 July 2026 · 7 min read

Choosing a trade counter POS for Linnworks: a buyer's guide

If you run a trade counter alongside your online channels, you already know the awkward truth: Linnworks is brilliant at managing orders once they exist, but it was never designed for a customer standing in front of you with a trolley of stock and a van on the yellow lines outside. Most sellers bridge the gap with a generic retail EPOS, a spreadsheet, or a paper pad that gets rekeyed later. All three cost you money. Here is what to actually look for in a trade counter POS that talks to Linnworks properly.

Why generic retail EPOS fails at the trade counter

A retail EPOS is built around anonymous shoppers paying full price at a fixed till. Trade is the opposite on every axis. Your counter customers are repeat accounts, not strangers. They expect the price they paid last time, not the RRP on the shelf label. They buy in quantity, often ask for a discount on the order total, sometimes want a delivery charge added, and frequently quote a purchase order number that must appear on the invoice or their accounts department will bounce it.

Worse, a standalone EPOS keeps its own product database and its own stock figures. Every sale made at the counter has to be reconciled against Linnworks later, either by CSV export or by hand. That is how you end up selling the last two units of a SKU at the counter while the same units sell on eBay ten minutes later. If the POS does not read live stock from Linnworks and write orders back into Linnworks as native orders, it is not a trade counter POS for Linnworks. It is a second system to babysit.

The five capabilities that actually matter

1. Live stock, straight from Linnworks

The single most important test: when you search a SKU at the counter, is the availability figure the same one Linnworks holds right now? Not a nightly sync, not a cached copy from this morning. Live. Trade customers ask "how many have you got?" constantly, and the answer has to be true across every channel. Any POS that maintains a duplicate catalogue will drift, and drift means overselling.

2. Barcode scanner support without ceremony

At a busy counter, typing SKU codes is a bottleneck. A decent trade POS should treat a cheap USB HID barcode scanner as a first-class input: scan a barcode, the line appears in the cart, focus returns to the scan field, ready for the next item. No drivers, no pairing apps, no dedicated hardware terminal. If a tool demands proprietary scanners or a locked-down till PC, walk away — commodity scanners under thirty pounds do the job perfectly when the software is built for them. We cover the hardware side in detail in our guide to using a USB barcode scanner for trade orders.

3. Customer memory — accounts, addresses and last prices

Trade selling runs on relationships, and relationships run on memory. When a regular walks in, the POS should find them in seconds and pull their details from your existing Linnworks order history — no separate CRM to maintain. The gold standard is per-customer price memory: the system remembers what each customer paid for each SKU last time and offers it as the default. That one feature ends the "what did we charge Dave last month?" shout across the warehouse, and it is precisely what generic EPOS cannot do because it has no visibility of your Linnworks history.

4. VAT modes that match how trade buyers think

Retail shoppers think in VAT-inclusive prices; trade buyers think ex-VAT, because that is how their own margins work. A trade counter POS must handle both: display and enter prices either ex-VAT or inc-VAT, and keep the cart arithmetic honest in both modes. If you have ever watched someone at a counter reverse-engineer 20% VAT on a calculator while a queue forms, you know why this belongs on the checklist.

5. Native Linnworks order creation

The finished sale should land in Linnworks as a real order — correct source and sub-source, correct customer, correct line prices, payment status recorded — the moment you press the button. Not a CSV to import at 5pm. Native order creation means your pick lists, stock levels, reporting and accounting integrations all see counter sales instantly, exactly as they see web orders. The cost of doing this manually is bigger than most sellers realise; we broke it down in the hidden cost of rekeying B2B orders.

Nice-to-haves that quickly become essentials

Questions to ask any vendor

  1. Where does stock data come from, and how stale can it be?
  2. Does an order appear in Linnworks natively, with source, sub-source and payment status set?
  3. Can it remember what each customer paid last time?
  4. Does it work with any USB HID scanner, or only approved hardware?
  5. Can I switch between ex-VAT and inc-VAT views mid-order?
  6. Can I produce a quote without creating an order?

If a product clears all six, you have found a genuine trade counter POS for Linnworks rather than a retail till with a sync bolted on.

Where Trade Order POS fits

We built Trade Order POS because we needed exactly this list ourselves: live SKU search against real-time Linnworks stock, scan-to-add with a standard USB scanner, customer auto-fill from three years of processed Linnworks orders with per-customer price memory, ex/inc VAT cart modes, per-line overrides, order discounts, delivery charges, quotation PDFs, payment status at the point of sale, and native order creation with optional auto-processing and branded email confirmations. It runs standalone in a browser or embedded inside Linnworks itself, from £28.79 a month solo or £76.79 for a five-seat team, billed through the Linnworks Application Store.

Put it through the six questions above yourself — start a 14-day free trial of Trade Order POS and run your next counter sale through it.

Ready to try it?

Two clicks gets you a hosted Linnworks MCP connected to Claude. Cancel anytime.

See the Linnworks MCP →