The aged debtors report shows who owes you money and how long it's been outstanding, bucketed into current, 30, 60, 90 and over 90 days. Every mainstream accounting system produces one, they're all accurate, and they're all in the same place: Xero calls it Aged Receivables, QuickBooks Online calls it A/R Ageing, Sage 50 and Sage 200 call it Aged Debtors, Business Central calls it Aged Accounts Receivable. The reason the standard one gets ignored isn't accuracy. It's that it's a snapshot as at today, with no trend, no owner, no note of who's been chased or what they promised, and no way to see whether the position is getting better or worse. A version people act on adds those four things, and none of them live in the ledger.
That's the short answer. The rest is the shape of the report that gets used, and where the extra columns come from.
Where is the aged debtors report in each system?
For completeness, and because a lot of the searches that land here are "aged debtors report Xero" or "aged debtors report Sage 50":
| System | Report name | What it shows well | What it doesn't hold |
|---|---|---|---|
| Xero | Aged Receivables Summary / Detail | Ageing by contact, adjustable buckets, drill to invoice | Trend over time, chase history, owner |
| QuickBooks Online | Accounts Receivable Ageing Summary / Detail | Ageing by customer, customisable columns | Trend, chase history, owner, promise-to-pay |
| Sage 50 Accounts | Aged Debtors Analysis (summary / detailed) | Ageing by account, retrospective as-at date | Chase history beyond the memo, owner |
| Sage 200 | Aged Debtors (summary / detailed), Debtors Ledger workspaces | Ageing by account, retrospective, by analysis code | Trend across months on one page, promise-to-pay |
| Business Central | Aged Accounts Receivable | Ageing by customer, by due date or posting date, period length adjustable | Chase history unless you use the collections features, owner |
Source: each vendor's product help, checked 21 September 2026. Names vary slightly by version and region; the report is always there.
Notice the right-hand column. Every system is missing the same things, and none of them are things a ledger is meant to hold. The ledger records the invoice and the payment. It doesn't record that Sarah rang them on Tuesday and they said the cheque's in the post.
Why does the standard aged debtors report get ignored?
I've watched this in enough finance teams to be confident about the pattern.
It's a list, not a picture. Two hundred rows sorted by customer name. The person reading it has to work out which rows matter. The report doesn't tell them.
It's today only. You can't see whether the over-90 column was £40,000 last month and £80,000 this month, or the other way round. The direction of travel is the most useful fact about debt and the standard report can't show it.
Nobody owns a row. Overdue debt is chased by people. If the report doesn't say who's chasing each account, it isn't a to-do list, it's a statement of fact, and statements of fact don't get actioned.
The context lives in someone's head or inbox. Promised payment dates, disputes, "don't chase, they're a friend of the MD". All real, all invisible on the report, all the reason the numbers don't move.
It's emailed as a PDF on a Monday and forgotten by Wednesday. Not a criticism of anyone. It's what happens to a static document that doesn't change until next Monday.
What does an aged debtors report people act on look like?
Same numbers, different shape. This is what I build, and it's one report, not a system:
The headline. Total overdue, the over-90 figure, and debtor days (see below), each with an arrow against last month-end. Three numbers, one line. Whether things are getting better or worse is answered before anyone scrolls.
The trend. Overdue by ageing bucket, by month-end, for the last twelve months. This needs month-end snapshots, which is the one structural thing the ledger doesn't give you. The model stores a copy of the ageing at each month-end and that's what the trend draws from. It's the single most useful addition and it's also the one that takes the longest to become useful, because you need a few months in the bank. Start storing it now.
The top ten. The ten accounts that make up most of the overdue, with the owner's name, the last contact date, and the promised payment date if there is one. The owner, contact and promise columns come from a small table the credit controller maintains (a SharePoint list, an Excel table, a Dataverse table, whatever they'll actually use), joined to the ledger by customer ID. That's the whole trick: the ledger does the numbers, a person does the context, and the report joins them.
Each person's own list. Row-level security so an account manager opens the report and sees only their customers. Nobody has to filter, and nobody can say they didn't know.
The exceptions. Accounts over their credit limit, invoices disputed, accounts with a promise date that's passed with no payment. Small tables, short.
That's the whole report. Three pages at most, one of which is the top ten. It's built once, refreshes itself, and is opened on a phone in the car park before a meeting.
How do you calculate debtor days?
Because it's the number that ends up on the board pack, and because the formula is often asked:
Debtor days = (trade debtors ÷ credit sales for the period) × number of days in the period.
The common version uses the last twelve months of sales and the debtor balance at period end, so debtor days = (debtors at period end ÷ sales for the last 12 months) × 365. Some people use the countback method, which is more accurate for seasonal businesses but harder to explain in a meeting. Whichever you use, use the same one every month, write the formula on the report, and don't switch without saying so. A debtor days figure that quietly changed method is worse than none.
Where does the data come from, and how hard is it?
The ledger side is easy: every system in the table above exposes its sales ledger, either through a connector, an API, or a direct database connection for the on-premise products. I've written up the routes for each in How to Connect Your Accounting Software to Power BI.
The context side (owner, last contact, promise date) is a table someone maintains. It has to be somewhere the credit controller will actually update, which usually means the tool they already have open. A list with five columns is enough.
The snapshot side is a scheduled copy of the ageing at each month end into a table the model reads. Power BI can't do this on its own (it reads current state), so something small has to store it: a dataflow that appends, a script, or the connector service if it supports history. It's a small job with a long payoff.
The whole thing is a single-source build when the ledger is the only system, which is what the First Report is for: one system, one report, the headline figure reconciled to the ledger to the penny, £1,950 fixed, ten working days. Details at the First Report. Aged debt is one of the more common first reports because the payoff is visible within a month.
Common questions
What is an aged debtors report?
A list of what customers owe you, with each invoice or balance bucketed by how far past its due date it is, typically current, 1 to 30 days, 31 to 60, 61 to 90 and over 90. Every accounting system produces one, under names like Aged Receivables (Xero), A/R Ageing (QuickBooks Online), Aged Debtors (Sage 50, Sage 200) and Aged Accounts Receivable (Business Central).
What's the difference between aged debtors summary and detail?
The summary shows one row per customer with the buckets across the columns. The detail lists every open invoice inside each customer. Credit control works from the detail; the board reads the summary.
How do I calculate debtor days?
The usual formula is trade debtors at period end divided by credit sales for the last twelve months, multiplied by 365. Pick one method, write it on the report, and keep it the same every month.
Why doesn't my aged debtors report show a trend?
Because the ledger holds the current state and the report shows it as at a date. To see a trend you need the ageing stored at each month end. Sage 50 and Sage 200 can run the report retrospectively for a past date, which helps, but a trend on one page needs the snapshots stored in a model.
Can Power BI show aged debtors from Xero, Sage or Business Central?
Yes. Business Central has a native Power BI connector and Microsoft's own Power BI apps include ageing. Sage 50 connects via ODBC, Sage 200 via its connector or SQL, Xero and QuickBooks Online via third-party connectors or the API. The routes are in How to Connect Your Accounting Software to Power BI.
Who should own the aged debtors report?
Whoever chases the money. The report only changes behaviour if each overdue account has a named person, and that name is on the report. Finance produces the numbers; the account owner or credit controller produces the action.
How much does it cost to build one?
Power BI Pro is £10.80 per user per month on Microsoft's UK page as of September 2026, for each person who opens it. The build, as a single-source First Report, is £1,950 fixed, reconciled to your ledger before it ships. If the snapshot history and the context table are already in place, it's at the simpler end of that.