How it usually goes wrong
An order comes in from a long-standing customer. Sales enters it, the warehouse picks it, it goes out on the van. A week later someone in accounts notices the customer was already well past their limit with invoices sixty days overdue, and had been 'on stop' in a note in the accounting system that nobody in sales ever sees.
Now you have more money at risk with a customer who was already struggling to pay, and an awkward internal conversation about who should have caught it.
Why the stop never reaches the order
Credit control and order taking happen in different systems and different rooms. The ledger in Xero, QuickBooks or Sage knows who owes what. The order is taken in an ecommerce platform, a separate order system, a CRM or an email inbox. Unless someone looks across, the two never meet.
Where there is a check, it is often a person in accounts sending a list of stopped accounts around, which is out of date the moment it is sent. Or the limit is set in the order system once and never updated when the customer's payment behaviour changes.
What it costs to ship blind
| Consequence | Why it matters |
|---|---|
| Larger exposure to failing customers | The customers most likely to stop paying are the ones who keep ordering |
| Friction between sales and accounts | Each side blames the other for a process gap |
| Late, clumsy holds | Orders get stopped at the loading bay, which upsets good customers too |
| Credit limits that mean nothing | If limits are not enforced, nobody treats them seriously |
What we build
- A credit position per customer, refreshed from your ledger through its API: balance, overdue amount, oldest overdue item, limit, and any on-stop flag.
- A check at the moment of order, wherever orders are taken: Shopify or WooCommerce for trade accounts, your order system, or the CRM. The new order's value is added to the balance and compared with the limit.
- Clear outcomes: pass, soft warning to the salesperson, or hold. Hold reasons are shown in plain words, such as 'overdue invoices over sixty days'.
- A release route: the credit controller or manager gets a notification with the full picture and can release, part-release or ask for payment first, in one step.
- Customer messaging where you want it: an automatic, polite note asking for payment of specific overdue invoices before the order can ship.
- A daily report of held orders, released orders and who released them, so decisions are visible.
Limits themselves can be reviewed by a person with suggestions based on each customer's payment history, but the system does not change a limit on its own.
Day to day afterwards
Sales sees the credit position at the moment it matters, so the conversation with the customer happens before the order is promised rather than after it is on the van. Accounts no longer has to police the warehouse. Good customers are not held by accident on the basis of an old list, because the check uses live figures.
It also changes how the sales team talks about money. When a salesperson can say 'I can see two invoices from March still open, can we get those sorted and I will release this order today', the conversation is factual and quick. Without the data, the same salesperson either ships and hopes, or has to go and ask accounts, which delays the customer anyway.
Over time, the log of holds and releases shows which customers regularly go over, which releases turned out well and which did not. That gives whoever sets credit limits real evidence to work from rather than impressions.
Recognise any of these?
- Orders have shipped to accounts that were marked on stop.
- Credit limits are set in one system and enforced nowhere.
- Accounts sends round a list of stopped customers by email.
- Holds happen at dispatch rather than at order.
- Sales does not know a customer's balance when taking an order.