The indicators: DSO and aging
DSO (Days Sales Outstanding) says how many days, on average, it takes for sales to become cash. Aging splits open receivables by past-due bucket and shows where the risk sits. The first measures speed, the second the quality of the receivables.
Simple DSO = open receivables ÷ sales in the period × days in the period
Countback DSO = days needed, going back month by month, for sales to cover open receivables
Past-due share = past-due receivables ÷ open receivables
Aging buckets = not yet due · 1–30 · 31–60 · 61–90 · over 90 days
The countback method is less sensitive to months with very different sales. The guide to DSO calculation explains it with an example, and the guide to receivables aging describes the buckets.
What the dashboard shows
- DSO for the month against target and against the same month last year, with the trend over the last twelve months.
- Aging by bucket, in total and by business unit, area or sales rep.
- The customers that weigh most on the past-due amount, with the credit limit next to the open balance.
- Expected collections over the coming weeks, from the due dates of open items.
- Unpaid and disputed items, kept apart from the rest of the past-due amount.
The data you need from the database
| Data | Typical fields | What it is for |
|---|---|---|
| Open items | customer, document, document date, due date, outstanding amount | Aging and open receivables |
| Sales invoices | customer, date, net and gross amount | Sales in the period for DSO |
| Payments | customer, value date, amount, matched items | Actual collections and payments not yet matched |
| Customers | code, name, area, sales rep, payment terms | Grouping and comparing with agreed terms |
Credit limits and special conditions often sit in a separate spreadsheet: it is loaded as an Excel source and joined by customer code.
The steps in Muvia
In New source choose Oracle, give the server, the service and a read-only user, and select the tables for items, invoices, payments and customers. Muvia copies them on the schedule you choose, incrementally and over an encrypted TLS connection.
Schedule the copy before the working day starts, so the morning picture includes the payments booked the evening before.
A query calculates aging and DSO with the chosen definition, and becomes a dataset with stable fields.
The dashboard shows the picture; every Monday a PDF report goes out by email to treasury and management.
An alarm opens when DSO goes above target or a customer goes over their credit limit, and the register says who chased it and when.
The pitfalls of the customer ledger
- Unmatched payments: a transfer booked but not yet matched to items leaves the customer past due on paper. Show them separately rather than subtracting them by eye.
- Partial payments and instalments: aging must be calculated on the outstanding amount of each instalment, with its own due date, not on the document total.
- Bank collections subject to clearance: a collection presented to the bank is not yet final; if it bounces, the amount returns to past due.
- Unmatched credit notes: they must be taken off the customer's balance, or aging makes the customer look more exposed than they are.
- Deletions: items closed or deleted in the ERP must be recognised in the copy, for example by reading the item's status instead of counting only the rows present.
Frequently asked questions
No. The tables are copied on a schedule, incrementally and over TLS; the dashboard reads the copy. The ERP receives no queries during the day.
The simple method is easy to explain but is thrown off by months with unusual sales; countback follows reality better when sales are seasonal. What matters most is calculating it the same way every time, which is what a definition written once does.
Yes: if terms are in the customer master or in a file, the query also calculates the average delay against them, customer by customer.
The path is the same; the receivables use case starts from an ERP on SQL Server.