Why aging reports alone won't fix collections

What an aging report actually tells you

An accounts receivable aging report lists open invoices in time buckets, usually current, 1 to 30 days, 31 to 60, 61 to 90, and 90 plus, subtotalled by customer.

That is a complete and accurate answer to a narrow question. The report is arithmetic on your ledger: if the books are right, the buckets are right, and no judgement is involved in producing it.

Which is also the limitation. Every fact on an aging report is a fact about the past, and nothing on it speaks to cause. Two invoices sitting in the same 61 to 90 bucket for the same amount can require completely different work, and the report presents them as identical rows.

The Intuit QuickBooks 2025 Late Payments Report, based on 2,487 U.S. small businesses, found 56% are owed money on unpaid invoices, averaging $17,500, and 47% carry invoices more than 30 days overdue. Nearly all of them can produce an aging report in under a minute. The report is not the scarce thing.

Why is my invoice late? Five answers that need five actions

An invoice is unpaid for one of a small number of reasons, and each has a different owner, a different next step, and a different resolution time.

The aging report collapses all of them into "days outstanding". Separating them is most of the value in a collections process.

A dispute

The customer read the invoice and disagrees with it. Wrong quantity, wrong rate, work they say was not delivered, a credit they believe was promised.

This is not a collections problem. Chasing it with reminders is worse than doing nothing, because each reminder confirms nobody on your side read the objection. Route it to whoever can resolve the commercial question, usually the account or project owner, with a decision deadline, then either issue a credit note or hold the line in writing. Tag disputed invoices and pull them out of the reminder sequence until closed.

An approval bottleneck at the customer

The invoice is accepted, uncontested, and stuck: sitting with a cost centre manager who has not coded it, waiting on a second signature, or held because it exceeded a threshold.

This one is solvable with information, not pressure. Find out where in their process it sits and who is holding it, which usually takes one call to accounts payable, and often the answer is that their workflow needs something you can supply in five minutes. For repeat customers, map the approval path once and reference it on every future invoice. Anyone who has built the other side of this will recognise it from their own payables process.

A missing PO number or reference

The customer's system rejected or parked the invoice because a required field is absent or wrong. No human decided anything.

This is the cheapest category to fix and the most expensive to leave alone, because the invoice can sit invisibly for a quarter while your reminders reach a mailbox nobody monitors. Reissue with the correct reference, and prevent it by capturing the PO requirement at order intake.

A wrong billing contact

The invoice went to someone who has left, to an inbox nobody owns, or to the operational contact rather than payables.

You find these by their signature: no response at all, ever, to anything. Not a complaint, not a promise, silence. Re-establish a live contact by any route available, including the relationship owner's phone, then correct the record so the next hundred invoices go to the right place.

Genuine inability to pay

The customer wants to pay and cannot. Their own receivables are late, their credit line is drawn, their season is wrong.

This is the only category where the honest answer might be a payment plan, and the only one where speed genuinely matters, because you are competing with their other creditors. The action is a documented instalment arrangement with dates and amounts, plus a decision about whether to keep supplying them. Atradius, in its 2025 North America B2B Payment Practices Barometer, reports around 6% of long-outstanding invoices ending as bad debts, and nearly all of it starts here. The same study found 44% of B2B credit sales overdue, which makes the categories above ordinary operating conditions.

Why aging buckets hide the invoice-level story

Bucket subtotals average away the only detail that determines what you do next.

A customer showing $80,000 in the 61 to 90 bucket might be one disputed invoice for $78,000 plus a handful of small ones, or forty routine invoices all quietly late. The first is a single commercial conversation. The second is systemic, either in that customer's payables process or in your billing accuracy. Same subtotal, opposite response.

Buckets also flatter you. An invoice rolling from 61 to 90 into 90 plus generates no signal in most workflows, because the totals still add up, and a large payment on a recent invoice can shrink a customer's exposure while the oldest item sits untouched.

The related habit worth breaking is working oldest first. Age correlates with difficulty, not recoverability. The 120-day invoice is often 120 days old precisely because it is disputed or the customer is insolvent, while the 40-day invoice for twice the amount is stuck behind a missing PO number and would clear this week. Sorting by age puts your least collectible work at the top every morning.

Why "days past invoice date" misleads when terms differ

Most aging reports age from the invoice date, not the due date, so the buckets measure elapsed time rather than lateness.

On net 30 terms, an invoice in the 1 to 30 bucket may not be due yet. On net 60, everything in the 31 to 60 bucket is still current. On net 90 project terms, an invoice can reach the 90 plus bucket while remaining within terms. Sell on mixed terms and a single aging report puts on-time and seriously delinquent invoices in the same column.

The fix is to age from the due date and to hold stated terms per customer as data rather than in a contract folder. Then the buckets mean days past due, the only version of lateness worth escalating on. It is the same distinction that makes raw DSO unreadable across a group, covered in understanding DSO.

What a working collections queue looks like instead

A collections queue is a list of invoices with a reason code, an owner, a next action, and a date. The aging report supplies only the first column.

Each past-due invoice carries four attributes. A reason code from the five categories above, assigned by a human on first contact. An owner, meaning a named person. A next action, specific enough that someone else could execute it. And a date by which it happens.

The queue is sorted by expected recovery rather than by age: amount, multiplied by likelihood of collection, weighted by how soon. A $60,000 invoice blocked on a reference number outranks a $9,000 invoice in genuine dispute, every time.

Two disciplines make it work. Every touch gets logged against the invoice, including the call that produced nothing, so the next person does not restart the conversation. And every promise to pay is recorded with an amount and a date, then checked on it.

None of that lives in an aging report. All of it builds on top of one.

The report is only as trustworthy as the books underneath it

An aging report inherits every error in the ledger it comes from, and in a group the most common error is unapplied cash.

Payments received but not matched leave those invoices showing as open. So do credit notes raised but not allocated, part payments applied to the wrong invoice, and receipts parked in suspense because nobody could identify the remitter. Each produces a row that looks like a collections problem and is a bookkeeping problem, and each burns credibility when someone chases a customer who paid three weeks ago.

If your books close on business day fifteen, the aging report is a fortnight stale the day you receive it. Current books are a precondition for collections work, not a separate initiative. Receivables sits on cruisr's roadmap rather than in the product: what cruisr delivers today is current books, a fast close, and group-level consolidation on top of QuickBooks Online or Xero, which is what makes an aging report trustworthy in the first place.

What this looks like across a group

Consider a group of nine entities where three of them, a services company, an equipment supplier, and a maintenance business, bill the same national customer.

Each produces a clean aging report. Entity A shows $40,000 at 45 days on net 30. Entity B shows $110,000 at 70 days on net 60. Entity C shows $25,000 at 100 days on net 30. Read separately, that is three moderate problems assigned to three bookkeepers, each sending a reminder sequence to a different contact at the same customer.

Read together it is a single $175,000 exposure to one counterparty, one item of which is 70 days past due, and it warrants one senior conversation rather than three automated emails. It may also have one root cause: the customer changed payables systems in the spring and none of the three entities updated the remittance reference.

The group view also changes the credit decision. Entity C is about to accept another order. On its own books the exposure looks tolerable; across the group it does not.

Getting to that view means adding receivables across separate company files with a consistent customer identity, the problem described in multi-entity consolidation challenges. Most groups do it in a spreadsheet, quarterly, which is too late.

Can QuickBooks or Xero do this?

Both produce a genuinely good single-entity aging report and both send automated reminders. Neither gives you a group-level receivables view.

Start with the hard boundary: neither adds receivables across separate company files. A group cannot see total exposure to a shared customer without exporting each entity and matching names by hand, which fails the first time one customer is spelled two ways. Inside one file the shortfall is narrower but real. There is nowhere to put a reason code or an owner, so the diagnosis above lives elsewhere, and no native concept of due-date aging on per-customer terms or of a promise to pay carrying a follow-up date.

What they do genuinely well is everything the ledger owns: aging summary and detail on demand, drill-through to the invoice, customer statements, and reminder sequences configurable by days overdue. For a single company with a few hundred open invoices, plenty of businesses need nothing more. Both are ledgers for one legal entity, and the group layer is yours to build or buy.

PYMNTS Intelligence found in 2024 that only 5% of mid-sized firms have fully automated their payables and receivables, so most are running the manual version of this.

Where to start

Take your current aging report and add two columns by hand: a reason code and an owner. It takes an afternoon, and you will learn more in it than the previous year of aging reports taught you.

Most groups find much of the open balance is not a collections problem at all: unapplied cash, missing references, wrong contacts. Fix those and the rest is short enough to work properly. To formalise it, building a collections process that scales covers cadence, escalation, and ownership.

If the blocker is that you cannot trust the underlying numbers across your entities, talk to us about the close diagnostic. It starts with your own QuickBooks or Xero files.