When credit limits outlive the customer they were set for

A frequent failure in customer credit is the stale limit. A limit is approved on the facts available at onboarding, then left alone while the customer's payment behaviour changes. Exposure grows quietly until collections, not credit, discovers it. The fix is reviews triggered by events, with overrides that expire.

How it starts

The application stage usually gets the most care. Someone pulls a bureau report, checks trade references and sets a limit that fits the customer as they look that day. After that, the account moves into a review cycle that exists on paper and slips in practice. The credit team is busy approving new accounts, and new accounts have a salesperson pushing for an answer. Existing ones do not.

Overrides make it worse. A large order arrives, the customer is over limit, and a manager approves a temporary increase so the shipment can go. Nobody records an end date. The higher figure becomes the real limit, and the next reviewer sees it as the baseline.

A quieter cause sits in the ledger. Credit memos, pricing disputes and adjustments are often posted late. Until they are, the balance the credit system sees is wrong. Sometimes it shows a customer as further behind than they are, so the team learns to distrust the numbers and stops acting on them. Sometimes it hides a real problem behind an open dispute that nobody is chasing.

How it gets noticed

It rarely shows up inside credit first. The collections team notices that the same customers keep appearing on their call lists, yet orders for those customers keep getting released. When they ask why, the answer is that the account is within its limit. It is, because the limit was raised and never brought back down.

The aging report tells the same story to anyone who compares it with the credit file. Look for customers whose limit has not moved while their average days to pay has stretched. Look for accounts sitting on a hold that someone keeps lifting by hand. Look for a gap between the customers collections would suspend and the customers credit has actually suspended.

External reporting can expose it too. Where delinquent balances are reported to credit agencies, a customer reported as delinquent but still trading on open terms internally is a clear signal that the two sides of the function are working from different pictures.

What fixes it

Start with the policy. It needs to say what causes a review, not only how often one should happen. Useful triggers include a payment pattern that worsens, a bureau score that drops, an order that would take the account over limit, and a dispute left open too long. Calendar reviews can stay as a backstop. They should not be the main mechanism.

Next, give every override an expiry. A temporary increase should revert on its own unless someone renews it with a reason. The approver's name and the reason belong on the account record, where the next reviewer will see them.

Then clean up the inputs. Credit memos and adjustments need an owner and a clear route into the ledger, so the balance used for credit decisions is close to the truth. Disputed amounts should be tagged as disputed and tracked, not left to blur the picture.

Finally, connect suspension and reinstatement to the same rules. If an account is suspended for late payment, the policy should state what brings it back: payment of the overdue balance, a new limit, a guarantee. Without that, reinstatement becomes a favour granted to whoever calls loudest.

Where the fix tends to slip

Triggers that fire too often get ignored. If every small change in a score creates a review task, the queue fills and the team goes back to judgement by habit. Tune the triggers so that each one leads to a decision worth making.

Sales will also resist expiring overrides. Bring them into the design early, and give them a fast route to request a renewal. A slow process gets bypassed.

The credit and collection reports should be built for decisions, not for filing. A report that lists every account is read by nobody. One that shows accounts where behaviour and limit have drifted apart gets used.

Questions for the people who run it

What runs day to day often differs from the written procedure, so ask the team directly:

• When did you last lower a limit, and what prompted it?
• Who can release an order that is over limit, and how do they do it in the system?
• Do temporary increases ever come back down, and who makes that happen?
• Which accounts do you review only when someone complains?
• How long do credit memos and adjustments wait before they hit the ledger?
• When collections wants an account suspended, how does credit find out?
• What does it take to reinstate a suspended customer, and is it the same every time?
• Which reports do you actually open, and which ones do you skip?
• Where do you keep notes that the system has no field for?

The answers to the last question are often where the real policy lives.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.