Accounts receivable and credit limits in B2B: monitoring credit without manual work

Short answer. You monitor accounts receivable and credit limits in B2B by setting a limit per customer based on turnover and payment behaviour, and testing it automatically against open items plus orders in progress. When the limit is exceeded the system blocks the order, and reminders go out on their own.

In wholesale I sell on account. That is not a luxury but a condition for taking part: payment terms, a credit limit and a minimum order value are part of the deal. The problem is not that I sell on account. The problem is that monitoring it lives in a spreadsheet nobody keeps up to date, while a customer places a fourth order without having paid for the first three.

What you really want: a grip on your open items, not just less typing

The goal is not "saving time on reminders". The goal is that at any moment I know who owes how much, who is over their limit, and which order I had better not ship just yet. Figures that add up. A receivables position I can trust when I assess my cash position. And reminders that do not depend on whether someone happens to think of it on a Friday afternoon.

A credit limit is the foundation for this. According to Microsoft on Dynamics 365, the exposure per customer consists of open invoices plus orders in progress, tested against the limit. The moment that total touches the limit, something should happen. By hand it does not happen, or it happens too late.

How to set and monitor a credit limit per customer

The limit itself is no mystery. A workable rule of thumb is to take the expected monthly purchase volume as a basis, add a margin to it, and adjust it on payment behaviour: good payers up, structurally late ones down or paying in advance. Kredietverzekeringkosten.nl describes that same principle, plus the fact that with credit insurance you may set the limit yourself up to a certain amount, provided you use sound credit information.

Setting it is therefore a human job. Monitoring it is not. Monitoring means testing every order against the limit minus the outstanding balance, before it reaches the warehouse floor. That is exactly where it goes wrong by hand, because nobody looks that up for each order.

First review the process, then build

Before I build anything I look at how it runs now. Often there are steps in there that made sense once and are now just noise. A reminder cycle of 7, 14 and 30 days that in practice is never followed. Customers with a limit that has not been revised for three years while their purchase volume has doubled. A manual "owner's approval" on every order above an amount, when that approval could just as easily be a rule.

Sometimes a step turns out to be redundant. Sometimes it turns out that half the exceptions stem from one customer with non-standard arrangements. That is a deliberate step, not an excuse to do nothing. I want to know which process I am automating before I cast it in concrete, otherwise I automate the mess.

Why a standard package often falls just short

An ERP such as Microsoft Dynamics 365, AFAS, Exact or AccountView can handle credit limits, blocking rules and automatic reminders. For the happy path that is fine and you should use it too. You do not need to build credit logic from scratch if the package does it.

The moat is in the exceptions. A tiered customer with a different limit per product group. A subsidiary whose orders have to count towards the parent's limit. A limit that moves with the season or with outstanding credit notes. Orders that come in through a supplier portal or B2B webshop and only touch the limit after they have already been confirmed. That kind of logic rarely sits neatly in the standard, and that is where I build the integration or the intermediate layer that does do it: the limit is tested at the right moment, the block lands in the right place, and the reminder goes out with the right tone per customer segment.

Reminders that send themselves

Dynamics, AccountView and comparable packages can flag open items based on due date, minimum amount and days since the last reminder, and dun them in batch by email. That is the starting point. What I build around it is the decision logic your package does not know: do not dun when there is an open dispute, a different tone for an A-customer than for a one-off buyer, and a heads-up to the account manager before the third reminder goes out rather than after. The manual work disappears, the judgement stays where it belongs.