In companies that issue a high volume of low-value invoices, the ageing report and the bank statement tell two different stories. The first says how much should come in by month end. The second, once the month is closed, records a part of it. Credit management usually starts from that gap rather than from a deliberate financial strategy: someone in the finance team notices that the collection forecast is consistently more generous than the cash that actually arrives, and that the variance always leans the same way.
The cause, however, is specific. A forecast built on the ageing report assumes the customer pays on the date printed on the invoice. In practice almost no receivables ledger behaves that way, and the deviation is not noise: every customer has a recurring delay, fairly stable over time, that the business knows from experience and has never turned into a calculation parameter.
An invoice due date is not a payment date
The figure needed already exists, in the transaction history. To find it, compare issue dates, due dates and bank movements over recent months. What comes out is the average delay of each customer. A treasury platform reads the ageing report from the ERP and the movements from the bank. It then calculates that delay and adds it to the contractual due date. As a result, an expected collection date rather than a contractual deadline.
The difference matters. For instance, if a customer runs thirty-seven days of average delay, an invoice falling due on 28 February does not belong in the February forecast: it lands in cash at the end of March, and the business has known this for months without ever writing it into a model. A forecast based on the ageing report is not miscalculated. Rather, it answers a different question: it says when the company is entitled to be paid, not when it will be paid.
Above all, the more complete platforms let both readings run side by side and compare them in a scenario, so the board sees the gap before the month closes rather than discovering it afterwards. That is the starting point of dependable credit management.
| How the collection is forecast | Data required | Question it answers |
|---|---|---|
| Contractual invoice due date | Ageing report from the ERP | When the company is entitled to be paid |
| Average delay per individual customer | Collection history reconciled against bank movements | When it will probably be paid, customer by customer |
| Indicator built in house | Formula defined by financial control | How cash behaves according to the internal model |
| Comparison scenario | Two forecasts held in parallel | What the optimism of the ageing report costs |
How do DSO monitoring and automated chasing work?
A treasury platform calculates the average collection time, updates the ageing report against each customer’s real delay and sends reminders following sequences defined in advance.
DSO, days sales outstanding, reads on three levels: company-wide, monthly and per customer. The aggregate figure serves the board, while the per-customer figure serves whoever works on collections, because it shows where the delay concentrates. The first measures, the second directs. On top of this sits a dynamic ageing. In other words, overdue is not classified at thirty days from the invoice date for everyone, but against the observed behaviour of each counterparty. The parameter can be overridden by hand where payment follows no pattern.
Automated reminders and credit management
The sequence is defined once and then works across the whole ledger.
On collections it is worth being explicit. In credit management a platform does not reduce DSO on its own. It turns collections into a process with a sequence of its own, instead of an activity that depends on who in the finance team remembers between one close and the next. That is therefore an organisational difference before a technical one, and it shows most in ledgers with many small positions, where volume makes manual chasing unworkable.
Can reminder timing and wording be tailored to each customer?
Yes: customers are grouped into clusters with distinct sequences, for example a reminder eight days before the due date and a second one eight days after.
By contrast, the strategic customer pays with a fifteen-day delay that everyone tolerates. The customer who only moves at the third chase cannot receive the same wording at the same hour. For this reason, treasury platforms with a dedicated collections module allow clusters, timing and content to be defined. The sequences then run automatically across the whole customer base. Segmentation comes before automation.
A case from the field
A consortium invoicing services to its own members worked through a large volume of modest documents. Reminders went out from the invoicing software: two or three preset emails, identical for everyone. The cash forecast was built on due dates and ran consistently ahead of the money actually credited, while nobody could keep track of the small positions one by one.
Ultimately, the shift came from recognising one thing. The delay was not a tolerance to accept: it was a figure for each individual member, already sitting in the collection history and never calculated. The treasury platform rebuilt that value and made it the indicator the forecast rests on. Members were sorted into differentiated reminder clusters. The comparison between the contractual forecast and the one based on observed delay became a scenario available at any time. Decisions on invoice financing stopped relying on the ageing report and started taking the real behaviour of the ledger into account.
Collections: when one transfer settles several invoices
Automatic matching between a bank movement and a document works well on linear cases: one credit, one invoice, the same amount. A real ledger produces plenty of others. A lump-sum transfer settling six invoices, a bank receipt aggregating several positions, a payment on account covering part of a document and leaving a balance open.
On these cases, however, automation steps aside and a human check is needed, allocating the amount across individual invoices or recording the partial collection. It is a practical limit raised regularly in client conversations, and worth seeing for what it is. A platform rarely closes one hundred per cent of matches on its own. Its value sits elsewhere: in surfacing exceptions as a visible, ordered work queue, instead of leaving them to settle in a spreadsheet only one person can read.
In credit management, in short, quality is measured by how exceptions are handled.
Credit management and invoice financing lines
Invoice financing facilities, the credit lines a bank grants against receivables and factoring arrangements, are the part most often left outside the systems. Many companies track usage on a manually updated spreadsheet, with the risk of drawing on a line already committed. The mistake surfaces at the bank counter.
In addition, a treasury platform can monitor facility usage, show the remaining headroom and simulate the interest tied to the advance, provided it receives data from the bank or from the accounting system. How readable those flows are varies between institutions and needs technical confirmation before it is promised: it is one of the first feasibility checks in a treasury project, not a detail to postpone until go-live. Anyone wanting to understand how granted and drawn facilities are recorded can start from the documentation of the Central Credit Register run by Banca d’Italia, which is the source banks use to read a company’s overall position.
Where feasibility is verified
In the treasury projects Aesir Srl runs, the preliminary check covers exactly these exchange points: what the bank exposes, what the ERP releases and in what format.
On the ERP side, meanwhile, the door stays open in both directions: Aesir is Gold Partner of NTS Informatica for Business Experience, and with other systems we use the connectors available or build them, without asking a company to change platform in order to start work on collections. The platforms we select process data in datacentres within the European Union, with certifications from the ISO/IEC 27001 family and requirements aligned with NIS2: the same standards applied to the Aesir infrastructure, which operates Tier IV datacentres in the EU with replication. Readers coming to this from the spreadsheet side will find the wider picture in the article on the five fatal mistakes of managing treasury in Excel, while the role of the system feeding the ageing report is covered in the piece on Business Experience and the future of ERP.
Credit management: what to ask a vendor
Seven questions worth asking when assessing a platform for credit management, whichever supplier is chosen:
- Is the average delay calculated per individual customer or only in aggregate, and can it drive the cash forecast?
- Can the indicator be overridden by hand for counterparties that follow no pattern?
- How many distinct reminder sequences can be defined, and can the wording be changed without the vendor?
- How are lump-sum transfers, bank receipts and partial collections handled, and where do unmatched exceptions go?
- Does data on financing facility usage come from the bank, from the ERP or from both, and how often is it refreshed?
- Is the ageing report read from the ERP in use through an existing connector, or one still to be built?
- Can the contractual forecast and the behaviour-based one be held in parallel and compared?
Finally, the first two questions separate a credit management platform from advanced reporting. The last two show how much integration work belongs in the budget.
Frequently asked questions
Does a credit management platform replace the ERP?
It works alongside the ERP, which remains the source of the ageing report and the documents. The platform adds the reading of bank movements, the calculation of indicators and the running of reminders, returning matches to the ERP where the connector allows it.
Do the accounts need to be tidy before starting?
It helps, and the project surfaces the issue early: duplicate customer records and never-matched payments come out in the first reconciliation. Even a partial clean-up of the ageing report before go-live reduces the manual work of the first weeks.
How much history is needed for a reliable average delay?
Enough reconciled collections to tell recurring behaviour from an isolated episode. In practice the figure becomes usable once it covers several invoicing cycles for the same customer, and it stabilises as the platform accumulates movements. From there on, collections work from a dependable base.
Do automated reminders risk annoying the best customers?
Segmentation exists precisely for this: the cluster of strategic customers can carry only the courteous reminder before the due date, leaving the more insistent sequences to the positions that warrant them. The company decides the tone, the platform applies it consistently.
Let’s talk
Credit management does not improve because a dashboard is added. Instead, it improves when the forecast stops measuring what the company is owed and starts measuring how its customers behave, and when collections become a sequence that starts on its own rather than a task someone has to remember. The useful first step is not choosing a product: it is checking whether the average delay per customer can already be derived from the data the company holds. In most cases it can, and yet nobody has extracted it. If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.