A wholesale distributor: credit decisions moved from Friday to live
A specialist wholesaler in the North West was tracking credit limits in a workbook updated every Friday. By Wednesday the figures were fiction, and the sales team was flying blind.
The reading
Two depots, 2,400 trade accounts, a credit controller in post for eleven years. The firm sold specialist fixings and fastenings into the construction trade; margins were thin, volumes high, and credit discipline the difference between a profitable year and a bad one.
The credit controller updated the master workbook every Friday evening. By Monday it was workable, by Wednesday it was out of date, by Friday it was a liability. The sales desk authorised orders against figures that were, on average, four days stale.
Two bad debts in the preceding year, totalling £47,000, had both been orders placed on a Thursday against a customer who had, in fact, exceeded their limit on the Monday.
The Friday fiction
The interesting observation was that the data to make correct credit decisions existed, in real time, in the accounts system. The ageing was there. The payment history was there. The current balance was there. The workbook existed because no one had ever connected the accounts system to the sales desk.
The credit controller spent most of Friday re-typing data from one system into another. She was aware of the absurdity; she had raised it, in writing, three times.
- 2,400 trade accounts, weekly manual credit refresh
- Average 4-day staleness on credit figures
- 2 bad debts in prior year traceable to stale data
- Sales desk making ~30 credit decisions per day
- Credit controller spending 7 hours per week on data entry
What we built
We wrote a small service that read the Sage ledger directly, computed each account's live exposure (balance plus open orders plus pending deliveries), and exposed a per-account credit status via an API the sales desk's order-entry screen now called at the point of quote.
The technical decision worth recording: we did not try to make the credit decision automatically. We presented the figures and let the sales desk decide. Experienced salespeople knew which customers were slow but good, and which were punctual but marginal. The system handled the arithmetic; the salesperson handled the judgement. This is the same pattern as the legal practice case, and we think it is close to a general principle.
The stack was unglamorous: a Python service on a managed VM, polling Sage every five minutes, with a simple REST endpoint consumed by the existing order-entry software.
The numbers at ninety days
| What | Before | After |
|---|---|---|
| Credit figure staleness | 4 days | <5 min |
| Credit controller data-entry hours | 7/week | 0.5/week |
| Orders accepted over limit | 11/month | 0/month |
| Order-to-quote decision time | 90 sec | 25 sec |
| Bad-debt provision | £47k/year | £6k/year run-rate |
Arithmetic for the system, judgement for the person
The pattern recurs because it is correct. Systems are good at arithmetic, consistency, and never forgetting. People are good at knowing that a particular builder has always paid in the end, and will again this time.
Asking a system to make the judgement is a category error. Asking a person to do the arithmetic, every Friday, for twenty-four hundred accounts, is a different category error. We try to make neither.