Blocking an over-limit customer in Sage 100

A bad debt is not decided on the day it becomes a bad debt. It is decided months earlier, at the moment someone accepts an order from a customer who is already over-extended.

Sage 100 can hold a credit limit. That is not the question. The question is what that limit actually covers on your installation, and what happens when it is crossed.

What native control does — and the caveat that matters

Behaviour depends on your version, your modules and your configuration. What follows describes what we most often see at client sites, not a universal rule. The first task is always to verify against the real installation.

In the general case, the customer record carries a credit limit, and entering a sales document triggers a check against it. That check can be configured as a warning or as a block.

It is a reasonable foundation. The difficulties come from three blind spots.

Blind spot 1: what the exposure figure actually counts

This is the most important and the most often overlooked.

Depending on configuration, the calculated exposure may include or exclude:

• orders entered but not delivered,
• delivery notes not yet invoiced,
• invoices not yet due,
• bills discounted but not matured,
• payments entered but not allocated.

A customer can therefore sit “within limit” while, in fact, two months of orders in preparation do not yet count. The check passes; real exposure is double the figure on screen.

The test to run today, on your own installation: take your largest customer, add up by hand everything they owe and everything committed to them, then compare with the exposure shown on the record. The gap is instructive.

Blind spot 2: a block that can be worked around

A block is only worth something if it cannot be bypassed.

Three routes around it turn up almost everywhere:

1. Override rights, granted broadly over time. An authorisation given one Friday evening to release an urgent delivery stays open for three years.
2. The limit adjusted on request. Changing the limit on the customer record is an unremarkable gesture, often untraced, and it empties the control of meaning.
3. Entry outside the circuit. If your sales force enters orders in a mobile app or a portal, and the credit check only exists inside Sage, going through the other tool is enough.

The third is the one we see most since order entry moved out of head office. A block that exists in only one tool is not a block: it is a convention.

Blind spot 3: nobody is told at the right moment

The breach is noticed at month end, on an aged balance, by the finance team. By then the goods have shipped.

The useful signal is the one that arrives at the moment of the breach, with the person who can still act: the account manager, the credit controller, management depending on the amount.

Five questions to settle before configuring anything

Configuration is not a technical subject. It is a management decision, and it is taken before the screen is opened.

1. What counts towards exposure? Orders, undelivered goods, unmatured bills: each inclusion is decided explicitly.
2. Warning or block? A warning everyone clicks through is worse than nothing: it creates the illusion of control.
3. Who can lift a block, and for how long? A release should be named, justified, traced and preferably temporary.
4. What happens to orders already in flight when a customer is blocked? Letting them ship empties the decision of effect.
5. Who is alerted, above what amount? An alert sent to everyone is read by no one.

Until those five answers are written down, no configuration will hold: it will be worked around within a month by the people who have to keep the business running.

Making the rule impossible to bypass

That is the principle behind OptiRisque: the block is applied inside the Sage database itself, not in an application layer sitting above it.

The difference is practical, not theoretical. A block owned by a third-party application disappears the moment someone enters the order directly in Sage. A block owned by the database holds at every entry point, whatever the tool.

Around that principle, the module consolidates the view a credit controller needs — authorised exposure, actual exposure, upcoming due dates, recorded delays, payment history — on one screen instead of three. And it raises the alert at the breach, not at period close.

What to check this week

• On your ten largest customers, does the displayed exposure match real exposure?
• How many users hold the right to override a block?
• Does changing a customer’s credit limit leave a usable trace?
• Do your entry points outside Sage apply the same rule?
• Of the breaches in the last six months, how many raised an alert at the time they happened?

The first two take a morning and give an honest picture. The last three determine the size of the project.

Going further

The OptiRisque module page covers the solvency record, the blocking mechanism and the alerts.

On the architecture that lets a third-party application write to Sage without breaking its business rules, see Connecting a business application to Sage 100c.