Receivables in enova365: the report says 120 overdue, someone sends eight emails

Open the ageing report in enova365 on a Monday morning, in a distribution business with a few hundred customers, and it will show something like 120 overdue lines. Now ask the person who handles collections how many reminders actually went out last week.

Eight.

Everybody reads that gap as understaffing. It isn't. Those 112 lines that got no email were filtered, one at a time, by somebody who knows that three of them are disputed deliveries, two were paid last Thursday and haven't been matched yet, one customer has a handshake deal with the owner about 60-day terms that nobody wrote into the system, and one is a group company that has paid on the 25th of every month for nine years and always will.

None of that is in enova365. None of it is in any ERP. That filter is the asset, and it lives in one person's head.

Which is why "let's automate the reminders" is the wrong project. Sending is the easy half, and the dangerous half. The work worth paying for is writing the filter down.

What enova365 gives you, and five ways the number is still wrong

The settlements module holds the raw material, and holds it well. Every open item carries a contractor, a document, a due date, an original amount and a remaining amount. The ageing report buckets them. The payment forecast projects them forward. Nothing here needs replacing.

Trouble starts when somebody pulls that data out — into a spreadsheet, a dashboard, or an agent — and quietly gets one of these wrong.

Ageing by due date or by document date. The report takes a parameter for this, and the two produce visibly different pictures of the same portfolio. Which one you pick matters far less than everybody downstream picking the same one. I once sat through a monthly board pack where the whole trend line turned out to be parameter drift.

Remaining amount, not document amount. Partial payments are normal, and a settlement that has been half-paid still shows its original value in the wrong column. Pull the document total and you overstate exposure on exactly the customers who are trying hardest to pay you.

Not every settlement is a customer. Employee advances, tax authorities, one-off counterparties — they all live in the same table. A "receivables" query with no filter returns a number nobody can act on.

One customer is often several cards. Group companies with separate tax IDs, plus duplicate contractor cards created over the years by different people. Exposure per card is not exposure per decision maker — and the decision maker is who you would actually be calling.

Currency items move on their own. The złoty value of a foreign-currency receivable depends on when it was last revalued. Chase on a stale złoty figure and you get a conversation you cannot win.

Nothing exotic here. All five turn up routinely in the first data pull of a receivables project, and each one survives review because the output still looks like a perfectly plausible report.

Both ends of the ageing report are dirty

The fresh bucket is inflated by money you already have. If a fifth of your bank statement lines don't settle automatically — and in most installations they don't, for reasons I went through in the post on MT940 imports — then a slice of the 1-30 day bucket is cash that arrived and never found its invoice. Every one of those is a landmine. Chase it, and the reminder goes to a customer who paid you on time.

The far end is clogged with things that will never be collected and were never meant to be. Grosze differences from rounding. Unsettled advance payments. Duplicated documents from a migration in 2021. In a typical portfolio these are a large share of the count in the 90+ bucket and a negligible share of the value.

So never show ageing as one number. Show count and value side by side, because they answer different questions — and the gap between them is itself the diagnosis. A 90+ bucket with 60 lines and 4 000 złotych is a hygiene problem. The same bucket with 6 lines and 180 000 złotych is a business problem. Put both figures on the page and nobody has to guess which one they are looking at.

Writing the filter down

The suppression list has four categories, and each one has a different fix.

Already paid, not matched. Not a dunning problem at all. It gets fixed upstream, in reconciliation, and until it is fixed nothing automated should be allowed anywhere near a customer.

Disputed or under claim. This needs a state, and enova365 has nowhere obvious to put it, so people keep it in an inbox. The right home is a custom field on the settlement or the document — but a dictionary one, five values, a date and a person. Never free text. A free-text field here becomes the swamp I described in the post on custom fields: technically populated, practically unusable, and unreadable by anything you build on top of it later.

Terms agreed and never recorded. The handshake 60 days. The fix isn't a suppression rule, it's writing the terms into the contractor card where they belong. Half of what looks like collections chaos is unrecorded commercial agreements, and it disappears in the week somebody records them.

Structurally late, reliably good. The customer who always pays on the 25th. There is nothing to collect here. Either move the due date or set a per-customer tolerance in days and stop counting them as overdue at all.

Before any of that, run the measurement. Take last month's list of items overdue by more than 30 days and have the person who knows the customers mark each line: would you actually chase this one today? The share marked no is your false-overdue rate. In the 1-30 day bucket it usually lands between 15% and 35%. Past 90 days it falls under 10%, which is the honest argument for starting automation at the old end rather than the fresh one. An hour of somebody's time, and you know whether you have a project.

What an agent may send, and what it must not

The four permission levels I laid out in who signs when the agent gets it wrong — read, propose, write, send — apply here with unusual clarity, because in receivables the boundary between the third level and the fourth is also a legal boundary.

Safe for an agent to send on its own: the pre-due nudge, three days out. No legal weight, irritates nobody, and per message it recovers more cash than anything sent after the fact. Also safe: a neutral statement of open items. It states facts rather than making accusations, and it has a useful side effect — it surfaces disputes nobody ever bothered to report to you.

Not safe, and not a technical question either: the formal payment demand. It is a legal step, it becomes evidence, and it opens a sequence somebody has to be willing to finish. Same with interest notes and the statutory recovery fee — 40, 70 or 100 euro depending on the size of the debt. Interest accrues by law whether or not you send anything, so an agent calculating it for information is fine. Issuing the note is a commercial decision about a relationship, and waiving it is the normal outcome. No system should make that call for a human.

One more thing catches people out. The email address on the contractor card is usually a sales contact or a general inbox. Payables sit somewhere else entirely. Nobody notices the difference until an automated reminder about 300 złotych lands on the desk of the customer's managing director.

Start with the build that has no downside

Before any customer-facing work, there is a read-only receivables agent worth more than most dunning engines and carrying no risk at all.

Watch the 90-day line. Invoices crossing 90 days past their due date next month, listed with the VAT you can recover under bad-debt relief — and the mirror image on the payables side, where the correction is an obligation rather than an option, and missing it is a real exposure. Almost nobody watches this date. Pure money, sitting in a query.

Then watch the credit limit. enova365 keeps a limit per contractor, and the useful moment to say something is before the next delivery leaves, not after the invoice ages. Send the whole lot as a weekly digest to the person who owns the relationship, not into a shared queue where it becomes nobody's job.

No write access, no customer contact, real money. It is the first step I recommend on every one of these projects, and the reason never changes: it buys trust while the data underneath gets fixed. How the whole thing fits together on the services side, I describe here: enova365 and AI integration.

What to measure once it runs

The override rate. The share of proposed reminders a person cancels before sending. Above 30% in month one means the filter still isn't written down — keep everything on propose-only. Under 10%, and you can widen the band that goes out automatically.

Not days sales outstanding, at least not first. Too slow and too noisy to tell you anything in the first quarter. Measure the share of a month's invoiced value collected by the 10th of the following month — the same distribution question that decides whether the monthly close is a crunch or a routine.

The dead line count. How many items in the 90+ bucket are genuinely uncollectable. Write them off. A report people don't believe gets ignored, and that is the real cost of leaving them there.

None of this is about sending more emails. It is about the difference between 120 and 8 becoming something the business owns instead of something one person carries.

Want to know your own false-overdue rate? Write to me — send one anonymised ageing report and the list of reminders that actually went out last month. I will tell you where the ceiling is before anybody builds anything. Half an hour, no charge.