The Credit Limit Is Checked After the Truck Has Left
· 7 min read · Written by Faceela Research & Editorial Team
Reviewed by Ahmed Hassan Algammal — Founder and Enterprise Systems Consultant
Every trading system sold in this country has a credit limit field on the customer master. Every one of them can put a number in it. Almost none of them, as configured in a real business, has a credit control.
The field is not the control. The rule is not the control either. What decides whether a credit limit does anything at all is where in the chain it fires — and there are only three candidate positions, of which one works, one works expensively, and one is a notification pretending to be a gate.
A limit, a term and an ageing are three different questions
They are used interchangeably in conversation, which is how a customer ends up passing all three and still costing money.
| What it measures | What it can refuse | Who reads it | |
|---|---|---|---|
| Limit | Total exposure carried at once — size | A new order, if it is wired to one | Nobody, until it blocks something |
| Term | Days each invoice may run — time | Nothing on its own | The customer, selectively |
| Ageing | What has already happened | Nothing. It is a report | Finance, monthly, with no lever attached |
The limit is a rule about size, the term is a rule about time, and the ageing is not a rule at all — it is the record of the consequences of the other two, and it is the only one of the three most businesses actually look at.
Now consider the customer who is the reason this article exists. He is inside his limit, because his limit was set generously three years ago and nobody has revisited it. And he is ninety days beyond term on half his balance. Every check in the system passes. The ageing report shows him in the worst column, in red, every month, and the ageing report is not connected to anything that can refuse an order.
A limit that is not tested against ageing is a size check on a company that has a timing problem, and it will pass forever.
Three places to put the gate
Now the position, because the same rule produces three different outcomes depending on which link of the chain it sits on.
The chain from an order being typed to the money arriving has eight or nine steps, and a credit check is technically possible at most of them. In practice it gets configured at one of three: when the order is entered, when the delivery is released, or when the invoice is raised. All three look identical in a demonstration — a message appears, the user cannot continue, the vendor moves on to the next screen.
What separates them is not visible in a demonstration at all. It is how much of the transaction has already left the building by the time the message appears.
Order to cash, with the gate moved
The same check, in three places, doing three different jobs
Enquiry, quotation, negotiation
Sales order entered
Candidate gate · At order entry
Already given away here: Nothing. The stock is unallocated, no promise has been made to a driver, and the salesperson is still in the conversation where a term can be changed or a cheque asked for.
What it is: A control. It is the only point at which refusing costs the business a phone call rather than a movement.
Stock allocated and reserved
Picked and packed
Delivery released
Candidate gate · At delivery release
Already given away here: The allocation, the picking labour, and the slot on the truck. The goods are recoverable but only by putting them back — and the customer has already been told a date.
What it is: A control, and an expensive one. It works, and every stop here is a cost the business pays for not having asked earlier.
Goods on the vehicle
Signed delivery note
Invoice raised
Candidate gate · At invoicing
Already given away here: Everything. The goods are with the customer, the delivery note is signed, and the exposure exists whether the invoice is raised or not.
What it is: Not a control. It is a notification, and it reports a decision that was taken by somebody else, days earlier, without a check.
Due date, then the ageing report
Most systems are configured with the third one
Because it is the easiest to build and the one that argues with nobody. It also fires after the only three moments at which the answer could have changed anything. Moving the same rule to the first gate is a configuration change, not a new module — what it costs is the argument with the sales team, which is why it is usually not made.
The reason the third one is so common is not laziness. It is that invoicing is where finance already stands, and finance is who cares about credit — so the check gets built where the concerned party can see it, rather than where the decision is made. A control has to sit with the decision, and the decision is made at order entry by someone whose bonus depends on the answer being yes.
That last clause is the whole reason this cannot be solved culturally.
Post-dated cheques are a credit instrument, not a payment
Anyone who trades in the UAE knows the shape of this. A post-dated cheque is handed over at delivery, it is dated sixty or ninety days ahead, and everybody treats the transaction as closed.
It is not closed. Until it clears, the cheque is a promise with a date on it, and it is a different kind of promise from an open invoice — held in a drawer or lodged with the bank, discountable, presentable early by arrangement, and capable of bouncing.
Which means it belongs on the exposure calculation, and in most systems it is not. The invoice is marked as paid or partly settled, the customer's outstanding balance drops, his available credit rises, and he orders again — against headroom created by a piece of paper that has not yet been honoured.
A system that holds the cheque as an instrument with a date, presented separately from the receivable, gets three things a system that does not cannot produce: a maturity ladder of what will actually clear and when, an exposure figure that does not count uncleared paper as money, and a bounce history per customer, which is the single most predictive credit fact a trading business owns.
The override, and why it has to exist
Any system that can refuse a sale will, sooner or later, refuse a sale that should have been made. The customer is good, the payment is on its way, the owner knows the family, and the goods have to move today.
Design for that, because the alternative is not discipline — the alternative is a workaround. Somebody creates a second customer account. Somebody raises it as a cash sale and fixes it later. Somebody changes the limit, ships, and changes it back. Every one of those defeats the control permanently while leaving it in place decoratively, which is worse than not having it, because the reports still say it is working.
An override has to have three properties, and the third one is the one that is normally missing.
It has to be restricted to a named role — not a permission that migrated to five people because one of them was on leave. It has to be reasoned, requiring a selection or a sentence, because an override with no reason cannot be reviewed. And it has to be counted, in a report that shows overrides per month, per customer and per person who granted them, sent to somebody who is not the person granting them.
Once that report exists, the number of overrides falls without anybody being told to reduce it. This is the same effect naming demurrage against the shipment has, and for the same reason: the behaviour changes when the figure acquires an owner.
What to make a vendor show you
On a live system, with a real customer record, not on slides.
- Set a limit and refuse a sales order at entry — a refusal, not a warning.
- Show the exposure calculation behind that refusal, itemised: open invoices, undelivered orders, delivered-not-invoiced, and uncleared cheques.
- Block a customer who is inside his limit and beyond term, on the ageing rather than on the balance.
- Record a post-dated cheque so that it does not restore available credit until it clears.
- Override the block as an authorised user, capture the reason, and show it on a report.
- Produce that override report for a past month, by customer and by approver.
- Show a customer's bounce history and days-sales-outstanding trend on the same screen the salesperson sees before he takes the order.
Item 2 is the one that separates a real control from a field. A limit checked against invoice balance alone ignores everything already committed and not yet billed, which on a trading company with sixty-day terms is routinely the larger half of the exposure. If the vendor cannot itemise the number the block was calculated from, the block is arithmetic nobody can audit.
The short version
A credit limit is not a control. It is a number, and what makes it a control is the position of the check that reads it.
At order entry, refusing costs a phone call. At delivery release, refusing costs a re-stock and a broken promise. At invoicing, refusing costs nothing because there is nothing left to refuse — the goods are gone and the exposure exists whatever the screen says.
The customer who does the damage is not the one who breaks his limit. He is the one who stays inside it and pays late forever, and no size check will ever see him.
The suite that holds the limit, the ageing, the cheque register and the override log on one customer record is Logix. Turning the refusal itself into something that survives a busy Thursday is process automation, the same discipline described in ERP access control and segregation of duties. And what the leak is costing before you fix it is what the cost of chaos calculator is for.