Every order in Linnworks lives in one of two worlds: open or processed. The split looks simple, but misunderstanding what "processing" actually does — and when it should happen — is behind a surprising number of stock discrepancies, mangled reports and awkward trade-counter workflows. Here is the lifecycle explained the way I wish someone had explained it to me.
The two states
Open orders are work to be done. An order lands in open orders — from a channel or entered manually — and sits there while you pick, pack and arrange despatch. Open orders are the operational to-do list: they are what your warehouse works from and what most despatch-focused screens and automations act on.
Processed orders are work that is finished. Processing an order is the act of declaring fulfilment complete — the goods are despatched, the order is done. It moves out of the open-orders view and into the processed archive, which is your permanent sales history.
The key mental model: processing is a one-way door. It is the moment an order stops being a task and becomes a record.
What processing actually does
Processing is not just a status flag. When an order is processed:
- It leaves the operational pipeline. It disappears from open orders and from anything driven by open orders — pick lists, despatch queues, open-order counts.
- Stock is finalised. The stock committed to that order is confirmed as gone, and your levels reflect a completed sale rather than a reservation.
- It becomes part of sales history. Processed orders are what feed sales reporting, and what tools that read your history — repeat-order lookups, customer indexes — treat as the record of what actually sold.
One quirk to plan around: a newly processed order exists immediately, but takes roughly 12 to 24 hours to show up in the processed-orders search index. If you process an order at 3pm and search for it at 5pm, it may not appear — it is not lost, just not indexed yet. We cover the symptoms and workarounds in the processed-order indexing delay explained.
Why the split matters for reporting
Open and processed orders answer different questions, and mixing them up ruins both answers.
- Open orders answer "what do we owe customers?" — outstanding fulfilment, backlog, orders at risk of going out late.
- Processed orders answer "what did we sell?" — revenue by day, by channel, by SKU. Your end-of-day sales figures come from here.
This is why stale orders parked in open orders are so corrosive. Every quote-as-dummy-order, every abandoned manual order, every counter sale someone forgot to process sits there inflating your apparent backlog while being invisible to sales reporting. The sale happened; the numbers say it did not.
Where should a counter sale live?
Here is the case that trips up trade sellers. A customer walks up to your trade counter, buys goods, pays, and carries them out the door. Where does that order belong?
Think it through with the lifecycle: an open order means "fulfilment still to do". But there is nothing to do — the goods left in the customer's hands thirty seconds after the sale. A counter sale entered as an open order is a lie to your own system. Until someone remembers to process it manually:
- the warehouse sees a pick task for goods that are already gone — worst case, someone picks and despatches a duplicate;
- stock shows as allocated rather than sold, so availability is wrong on every channel;
- the sale is missing from processed-order reporting, so today's revenue is understated.
The correct state for a counter sale is processed, immediately. The order should pass through open orders in a heartbeat — created and processed in the same action — because fulfilment was complete at the moment of sale. The same logic applies to any sale where the customer takes the goods with them. Manual order entry in Linnworks makes this awkward, because it was designed around ecommerce despatch, not a customer standing at a counter; we compared the options in choosing a trade counter POS for Linnworks.
Safe auto-processing
The fix is auto-processing: the order is created and moved straight to processed in one step at the point of sale. Done right, it is the single biggest workflow improvement available to a Linnworks trade counter — but "done right" carries conditions, because processing is that one-way door:
- Only auto-process when goods genuinely leave with the customer. If the counter order is actually for later delivery, it belongs in open orders like any other despatch job.
- Capture payment status with the order. Processed does not mean paid — trade customers often collect on account. Track Unpaid/Paid separately or credit control loses visibility; see payment status on trade orders.
- Make it deliberate, not accidental. Auto-processing should be a setting you choose for a specific order flow, not a blanket rule that swallows orders which still need picking.
This is how we built it in Trade Order POS: auto-process is an optional toggle, so a submitted counter sale goes open to processed instantly, stock is decremented as sold, a branded PDF confirmation can be emailed automatically, and payment status (Unpaid, Paid, Pending) is written back with the order. Counter sales land in your sales history in real time, and your open orders stay what they should be — a clean list of despatch work still to do.
The honest summary
Open means still to fulfil; processed means done and counted. Processing finalises stock and moves the order into permanent sales history, with a 12 to 24 hour lag before it is searchable. Keep open orders honest — nothing should live there that is not genuinely awaiting despatch — and counter sales, where the customer walks out with the goods, should be processed at the moment of sale, automatically if your tooling supports it safely.
Trade Order POS submits counter sales into Linnworks with optional auto-processing, automatic branded PDF confirmations and payment status written back to the order. Start your 14-day free trial at trade-pos.mcp-g.com.