Most Polish SMEs selling B2B on deferred payment terms have no idea how much they are actually lending. Their ERP has a "credit limit" field, but nobody fills it in, nobody enforces it, and nobody gets an alert when a customer crosses the line. As long as everyone pays, it doesn't hurt. It hurts once every few years — and when it does, it hurts a lot.
Payment terms of 14, 30 or 45 days are the B2B norm, not a privilege. It means you are permanently financing your customers out of your own pocket. With 60 active buyers each owing you an average of PLN 20,000, you are lending the market PLN 1.2 million interest-free. As long as the portfolio is healthy, that's a normal cost of doing business. The problem is: that portfolio is not static, and nobody is reviewing it in real time.
At one of our clients — an 18-person building-materials distributor in central Poland with roughly PLN 24 million annual revenue, running on Comarch Optima — the classic story played out. A large installation customer had been paying slightly late for six months, but was paying. The sales team saw no reason to worry. When the customer filed for bankruptcy, the exposure was PLN 180,000 — a month and a half of the whole branch's gross margin. Nobody was monitoring it, because the "limit" field in the customer record was set to 0 (which, as the system was configured during migration, meant "no limit") and the ERP had never raised a flag.
What a credit limit should actually count
First trap: most sales people think of a credit limit as "the maximum invoice amount". It isn't. A credit limit is the maximum total exposure to a single customer at any given moment — open invoices plus confirmed orders not yet invoiced.
If a customer has a PLN 50,000 limit, PLN 30,000 in unpaid invoices and is placing a PLN 25,000 order right now, they are over the limit — even if no single invoice ever exceeds PLN 25,000. An ERP that doesn't add this up protects you against nothing.
- Unpaid invoices (overdue and current — both count as exposure).
- Confirmed orders not yet invoiced.
- Warehouse releases without an issued invoice (common in logistics).
- Advance invoices not yet settled against a final invoice.
In Comarch Optima, enova365 and Subiekt all those components can be summed either natively or with a lightweight script/alert — provided someone deliberately configures it. Out of the box it rarely works the way you'd want.
How to set limits that aren't pulled from thin air
Second trap: limits set "by feel" by a sales rep who wants to lock in commission. If every customer gets a PLN 100,000 limit, there effectively is no limit. If limits are random, the collections team doesn't know when to escalate.
A simple, working scheme for an SME (let's be honest — proper credit scoring is for banks, not an 18-person distributor):
- New customer: limit = industry average monthly turnover × 0.5, capped at PLN 10,000, until three invoices are paid on time.
- Returning customer (over 6 months of history): limit = average monthly turnover over the last 6 months × 1.5.
- Customer with a history of >14-day delays: limit = average monthly turnover × 0.8, reviewed quarterly.
- Strategic customer with collateral (insurance, letter of credit, promissory note): limit = collateral amount × 0.9.
Plus two mandatory columns kept on the customer record: date of last review and source of the data (credit bureau, intelligence service, your own judgement). If the date is more than a year old, treat the limit as if it didn't exist.
What the system should do when a customer breaks the limit
Third trap — and the worst: the system knows a customer is over the limit, but nobody sees it. In most Optima or Dynamics rollouts, the credit limit shows up as a little red icon in the customer card that no one clicks on, because the order came in by email, the rep punches it into the ERP and hits save. End of story.
What should happen when a customer is over the limit needs to be defined explicitly, otherwise everyone improvises:
- Soft block on order entry — the system won't let the document be saved without approval by a specific role (CFO, head of sales, owner).
- Hard stop on warehouse release — the warehouse won't ship the goods while exposure is over the limit, even if the order is already in the system.
- Automatic email to the sales rep when the customer enters the warning zone (e.g. 80% of the limit), with a link to the customer card.
- Daily report on the sales director's desk — list of customers over and near their limit, with amounts. Not weekly. Daily.
In the example above — after that same PLN 180,000 incident — we rolled out exactly those four things at the client. Fourteen months later another buyer filed for restructuring. Exposure at the moment sales were frozen: PLN 45,000 instead of a potential PLN 220,000, because the system blocked the third order in a row and the head of sales didn't sign off an override. Five minutes a day to review the list — that's what it costs operationally.
What next
Credit limits in your ERP are not a six-month project. One week to clean up the customer master, two days to configure alerts, and one conversation with the sales team about the fact that "no" is also a valid answer. It's strange how few companies actually do it — until you hear the owner say: "but how am I supposed to tell a customer we've worked with for ten years that they're not getting the goods?". The answer: "tell them exactly what the system said — not you."
If you don't know where to start, do this over a weekend: top 10 customers by revenue, and for each one add up unpaid invoices plus unbilled orders in Excel. Compare to the "limit" in the customer card. Chances are at least one of them is already in deeper than they should be. That's your starting point.
A credit limit the system doesn't enforce isn't a limit. It's just a number in a field, next to the address and tax ID.