Trade credit limits in enova365 — the block saves less money than it should

The receivables post I published yesterday ended on a line I want to pick up, because that is where the money actually is. The useful moment in credit control comes before the next delivery leaves, not after the invoice goes past due.

This one is about that moment. Every enova365 installation with the Handel module already ships the mechanism. A credit limit on the kontrahent card, a control setting that can warn or block, and a separate check on overdue settlements. The mechanism isn't the problem.

The problem is that in most installations I open, all three parts are quietly wrong at once. The number hasn't been touched since migration, it counts less than the customer actually owes, and the check fires at the point in the process where stopping costs the most.

The limit is a number nobody has revised since migration

Start here. It costs an hour, and it decides whether anything else is worth doing.

Export your kontrahent list with three columns: the credit limit, the date that field last changed, and the customer's turnover over the last twelve months. Most installations will give you this from a list view. If the modification date isn't exposed, take it from the database or ask your partner for it once.

Then compute one ratio per customer, limit divided by average monthly turnover, and sort into three buckets.

Untouched since import. Same value for every customer, or a round number carried over from the previous system. On lists of a few hundred active kontrahenci, that's routinely 60-80% of them. These aren't credit decisions. They're migration artefacts.

Ratio below 1. The limit is smaller than what the customer buys in a normal month, so the block fires on ordinary business. Watch what happens next. The operators learn to override it, and after two months the override is reflex. A control that's always overridden is worse than no control, because it produces the paperwork of safety without the safety.

Ratio above 6. The limit is decorative. It will never fire, including on the customer who is about to stop paying you.

None of this needs software or a project. One export and a sort. And it usually reprices the entire conversation: twice now I've watched it end with a client deciding they didn't need an agent, they needed an afternoon with a spreadsheet and their sales director. Fine outcome, as far as I'm concerned.

A day count ages better than a złoty amount

enova365 gives you two independent levers here, and the second one is the better first build.

A value limit is a snapshot of a judgement. It rots, silently, and nothing in the system tells you it has rotted. A rule based on overdue days, with no new releases while anything sits more than N days past due, doesn't rot at all. Its input is the customer's behaviour this week rather than a decision from 2023.

It also matches how people actually think about risk. Nobody in a wholesale business loses sleep over a customer who owes a lot and pays on the dot. They lose sleep over the one who has started paying late.

One condition before you turn it on, and it isn't optional. Run the false-overdue check from the receivables post first. If a chunk of your overdue lines are payments that arrived and never matched to an invoice, which they usually are, for the reasons in the post on MT940 imports, then a days-overdue rule will stop shipments to customers who paid you on time. You get one shot at this. Block a good customer twice and the sales team will have the rule switched off by the end of the month. And they'll be right.

What the limit counts is not what you are owed

The credit check looks at settlements. Your exposure is bigger than settlements, and the difference isn't a rounding error.

Count all five:

1. Unpaid invoices, which is the only layer the check sees.
2. Goods released on a WZ and not yet invoiced.
3. Confirmed orders not yet shipped.
4. Deliveries in transit.
5. Complaint credits you have promised and not issued (this one reduces exposure, and leaving it out makes you block customers you shouldn't).

On a wholesale customer ordering weekly, layers 2-4 routinely add 30-50% on top of the settlement balance. That's the whole reason a customer passes every check on Monday and is genuinely over limit by Wednesday, having done nothing unusual.

The failure mode has a shape I've seen more than once. The block finally triggers at invoicing, on Friday, by which point three orders have already left the warehouse that week. The system did exactly what it was configured to do. It was just watching the last event in the chain.

The check fires at the most expensive moment

There are three places you can put a credit check, and they cost wildly different amounts.

At order acceptance. Cheapest by an order of magnitude. Nothing has been picked, nothing has been promised to a driver, and the conversation with the customer is a normal commercial one. We need the March invoice settled before this ships.

At document confirmation. This is where most installations put it, because it's where the mechanism naturally sits. The goods are picked, the customer is expecting delivery, and somebody now has to make a phone call they hadn't planned on.

At warehouse release. The most expensive place to discover anything. A loaded pallet coming back off a truck costs you the picking, the space, the driver's slot and the relationship.

So why is the earliest check the rarest one? Because in most wholesale businesses the order never reaches the ERP as an order. It arrives as an email in a salesperson's inbox, or a phone call, and it becomes a document hours later, by which time you're already at check point two. Credit control and order intake turn out to be the same project. That's one of the reasons a B2B ordering portal pays for itself in places nobody puts in the business case. An order placed through a portal can be checked against exposure before the customer has finished submitting it.

The insurer's limit is the number that decides whether a loss is recoverable

If your receivables are insured — KUKE, Allianz Trade, Coface — then there are two limits per customer, and the one that matters when things go wrong isn't yours.

In every installation I've looked at, the insured limit lives in the broker's portal or a spreadsheet on somebody's desktop. It isn't on the kontrahent card, it isn't in the credit check, and nothing compares your exposure against it. So you can sit comfortably inside your own limit and outside the covered amount at the same time. That's a loss you agreed to carry without ever agreeing to it.

The fix is small, and it's the first thing I'd build here. Put the insured limit in a dictionary custom field next to the internal one, keep it current, and alert on exposure above the insured figure. Do it as a proper field with a value list and a revision date, not free text. For the reasons in the post on custom fields, free text here turns into something nothing you build later can read.

There's a second and better reason to wire this up. When an insurer reduces a limit on one of your buyers, they're acting on payment data from other suppliers, data you have no other way of seeing. A limit cut is the earliest external warning signal a Polish wholesaler gets. It arrives by email, and in most companies it gets filed. Reading those emails into a field and raising a flag is perhaps a day of work.

What an agent may stop, and what it must hand to a person

The four permission levels from the post on who signs when the agent gets it wrong — read, propose, write, send — land here with an obvious boundary. It just isn't where people expect it.

Blocking a shipment is not a compliance action. It's a commercial decision wearing a compliance costume. Stopping a pallet to a fifteen-year customer over 300 zł of unmatched payment destroys more value than the risk it removes, and no rule you write will hold enough context to tell those two cases apart. That decision stays with a person.

What the agent does is assemble the case so the person can decide in thirty seconds instead of thirty minutes. Full exposure across all five layers, the split between genuinely overdue and merely unmatched, the payment pattern over twelve months, the insured limit, and whether this customer has been held before. Proposed hold, evidence attached, one click to release.

Then the half it can own outright, which is the half that actually saves money. Warn at 70% of the limit, three days before the next expected order. A warning at 70% is information somebody can act on commercially. A block at 100% is a fight in the loading bay. Only one of those is worth handing to software without a person in the loop.

One hard rule. No autonomous limit increases, ever. An agent that raises a limit because the customer keeps hitting it has drawn precisely the wrong conclusion from the data.

Measure the mechanism, not the customers

Two numbers tell you whether any of this is working.

The blocked-order rate, and, more importantly, how many of those blocks get reversed within 24 hours. Reversal above roughly half means your limits are wrong, not your customers. That's a measurement of your own configuration, and you can have it in week one.

The override log, with who and why. If your overrides aren't recorded with a reason and a name, you don't have credit control, you have a speed bump. When one person accounts for most of them, usually the owner, that isn't a data problem. It's a question about who is allowed to take risk, and it's better asked out loud than left to a config screen.

Neither of these is DSO. DSO will tell you something eventually, and by then you'll have spent a quarter.

---

If you want a second opinion on your own numbers, send me an anonymised kontrahent list with limits, last-changed dates and twelve-month turnover. I'll tell you what share of your limits are migration artefacts and whether there's a project here at all. Half an hour, no charge — write to me. How this fits together on the services side is described here: enova365 and AI integration.