Ask most trade counters which of last month's counter sales have actually been paid and you get a shuffle of card receipts, a scan of the bank statement and an educated guess. The order data lives in Linnworks; the payment truth lives somewhere else entirely. Recording trade order payment status at the moment the sale happens — Unpaid, Paid or Pending, written back to Linnworks with the order — closes that gap for good.
The gap between "order placed" and "order paid"
Linnworks is excellent at tracking what was ordered, picked and shipped. What it doesn't know, unless you tell it, is whether the customer standing at your counter paid by card on the spot, promised a bank transfer, or put it on their account. In a pure e-commerce flow that hardly matters — the marketplace or the payment gateway settled it before the order arrived. Trade is different. A single morning at the counter might produce:
- A cash-and-carry customer who paid by card before leaving,
- An account customer taking goods against 30-day terms,
- A pro-forma customer who says the transfer "went this morning",
- A regular who paid half and will settle the balance on collection of the rest.
Four orders, four different payment realities, and in most setups all four look identical in Linnworks. Credit control then has to reconstruct the truth weeks later from memory, till rolls and the bank feed.
What capturing status at the point of sale actually changes
With Trade Order POS, the person taking the order marks it Unpaid, Paid or Pending as part of submitting it, and that status is written back to Linnworks with the order itself. Small change, large consequences.
Chasing becomes a filter, not an investigation
Credit control's weekly job stops being "work out which orders might be unpaid" and becomes "pull up the Unpaid and Pending orders and work the list". The person best placed to know the payment situation — whoever stood in front of the customer — recorded it while it was still fresh, rather than an accounts assistant guessing from a bank line that says "FASTER PAYMENT REF 7734".
Pending stops meaning "forgotten"
The Pending status earns its keep with pro-forma customers. "The transfer's gone this morning" is usually true and occasionally optimistic. Marked Pending, the order sits on a short, visible list that someone checks against the bank daily. Confirmed? Flip it to Paid — there's even a Resend option for sending the confirmation again once things are settled. Not arrived by day three? You're chasing a three-day-old promise, not discovering a six-week-old hole.
Month-end reconciliation gets shorter
At month-end, orders marked Paid should match takings; anything Unpaid belongs on the debtors list; Pending items get resolved one way or the other before the books close. That's a checklist, not an archaeology dig. The order metadata the POS captures — customer PO number, internal reference, who placed the order — means each query is answerable without interviewing the whole counter team.
Making the statuses mean something
The system only works if everyone uses the words the same way. A convention that works for most trade counters:
- Paid — money received and confirmed before the goods left. Card at counter, cash, or a transfer visible in the bank.
- Unpaid — deliberately not paid yet: account customers buying on agreed credit terms. Unpaid isn't a problem status, it's a fact.
- Pending — payment claimed or expected but not yet confirmed. This is the list to check daily, because it should always be short.
Write those three definitions down, stick them by the till, and audit the first fortnight. The failure mode to watch is Pending becoming a dumping ground for "not sure" — if a status hasn't resolved in a few days, someone asks why.
Pairing status with the paper trail
Payment status tells you where the money stands; the auto-email option gives the customer a branded PDF confirmation of exactly what they ordered and at what price the moment the order is placed. When a payment query does arise, both sides are looking at the same document. Add per-customer price memory — the POS recalls what each account last paid per SKU — and you also remove the pricing disputes that so often masquerade as payment delays. Fewer "we were expecting a different price" emails means fewer invoices stuck in query.
If you're taking orders over the phone as well as at the counter, the same status discipline applies — see taking phone orders into Linnworks without rekeying. And if unpaid balances on small trade accounts are a recurring headache, pairing payment status with sensible thresholds helps too: our piece on minimum order values for trade accounts covers that side.
The compounding effect
None of this is glamorous. But a trade counter doing thirty B2B orders a week generates over 1,500 orders a year, and if even two per cent have ambiguous payment states, that's thirty orders a year someone has to investigate — or quietly write off. Recording the status in the moment costs the counter staff one tap. Not recording it costs credit control hours every month and costs the business real money at year-end.
Trade Order POS records payment status on every order and writes it back to Linnworks, from £28.79/month with a 14-day free trial via the Linnworks Application Store. Start at trade-pos.mcp-g.com.