An accounts receivable aging report sorts everything your customers owe you by how overdue it is, so you can see who to follow up and in what order. Before you send a reminder, reconcile the account — chasing a customer who has already paid, or one who raised a dispute nobody wrote down, damages the relationship and wastes the follow-up.
This guide shows how to track overdue invoices with an aging workflow built for a Hong Kong SME: choosing the aging basis, reconciling partial payments, disputes and credit notes, a worked example with a messy customer ledger, and a follow-up ladder where a person still sends every message. It is an operational guide, not accounting or debt-collection advice.
What an aging report actually is
An aging report is a dated snapshot of open customer balances, grouped into buckets by how long each amount has been outstanding. Microsoft's documentation on reviewing collections information describes exactly this: an aging snapshot is fixed to an "as of" date, and it needs refreshing as payments come in, so the date on the report matters as much as the numbers.
Two decisions make the report useful:
Pick your aging basis and state it. You can age each amount from its due date, its transaction/posting date, or its document date. The posting date can coincide with the invoice date, but they are not necessarily the same. Microsoft's customer aging report documentation shows these as configurable options and separates the "aging as of" date from the transaction cut-off. For collections, age from the due date — that tells you what is genuinely late. Whatever you choose, write it on the report along with the "as of" date.
Choose bucket widths. A common set is current (not yet due, including anything due today at 0 days past due) / 1–30 / 31–60 / 61–90 / over 90 days past due. The widths are a convention, not a rule; pick what matches your payment terms, and make sure the ranges do not overlap.
Reconcile before you chase
Four things routinely make an aging report lie:
- Unallocated receipts — money in the bank that has not been matched to an invoice yet.
- Partial payments — apply the cash to specific invoices; the unpaid remainder keeps its original due date and keeps ageing from there. An educational reference from Xero on accounts receivable aging notes that a usable aging view has to track open balances, partial payments and promised-payment dates together.
- Disputes and promises — under this example's review policy, a logged dispute pauses follow-up on the disputed amount (the balance and its aging do not change); an unlogged one is why you hear "I already told your colleague". A payment promise is a reason to hold, not a change to the due date. Record both.
- Credit notes — before a demand goes out, make sure each credit note is valid and applied to the right customer and invoice, so it is counted once. It reduces the balance of the invoice it is applied to; do not net credit notes against unrelated invoices.
Worked example: one customer, a messy ledger
Illustrative example — 示範例子（非真實客戶資料）. Aging as-of date and transaction/receipt cut-off: both 2026-09-07. Payment terms: 30 days from the invoice date. Aging basis: due date.
Customer Prosper Trading has:
- INV-1001 — issued 2026-06-30, due 2026-07-30, HK$18,000.00. A payment of HK$10,000.00 was received on 2026-08-05 and applied to it. Credit note CN-14 (2026-08-25, HK$900.00) was agreed and applied to this invoice for a pricing error.
- INV-1002 — issued 2026-07-15, due 2026-08-14, HK$6,500.00. The customer disputes HK$1,500.00 (claims a short delivery) and has promised to pay the undisputed HK$5,000.00 by 2026-09-15.
- INV-1003 — issued 2026-08-20, due 2026-09-19, HK$4,200.00.
- An unallocated receipt of HK$2,000.00 arrived on 2026-09-01 and has not been matched to an invoice.
Reconciled:
On a phone, scroll sideways to see the full table.
| Item | Original (HK$) | Applied (HK$) | Outstanding (HK$) | Due date | Days past due (2026-09-07) | Bucket | Follow-up status |
|---|---|---|---|---|---|---|---|
| INV-1001 | 18,000.00 | −10,000.00 payment, −900.00 credit note CN-14 | 7,100.00 | 2026-07-30 | 39 | 31–60 | Eligible — after the unallocated receipt is reconciled |
| INV-1002 | 6,500.00 | — | 6,500.00 (HK$1,500.00 disputed, HK$5,000.00 undisputed) | 2026-08-14 | 24 | 1–30 | Undisputed part: promised 2026-09-15, hold. Disputed part: follow-up paused |
| INV-1003 | 4,200.00 | — | 4,200.00 | 2026-09-19 | not yet due | Current | None |
| Unallocated receipt | — | — | (2,000.00) received 2026-09-01 | — | — | — | Allocate before any chase |
Working: INV-1001 is 18,000.00 − 10,000.00 − 900.00 = HK$7,100.00 outstanding; 2026-07-30 to 2026-09-07 is 39 days, so it is in the 31–60 bucket. INV-1002's outstanding balance stays at HK$6,500.00 — the HK$1,500.00 dispute pauses follow-up on that part, it does not reduce the balance or change the aging. Of that HK$6,500.00, HK$5,000.00 is undisputed with a promised date of 2026-09-15; the promise does not reset the due date or remove the amount. INV-1003 is not yet due. Adding the invoice outstandings: 7,100.00 + 6,500.00 + 4,200.00 = HK$17,800.00. The HK$2,000.00 receipt from 2026-09-01 is not yet allocated, so the net customer balance is 17,800.00 − 2,000.00 = HK$15,800.00 — which still includes the HK$1,500.00 in dispute and the HK$4,200.00 not yet due.
Who you follow up, and when:
- Reconcile the HK$2,000.00 receipt first. If it is confirmed against INV-1001, that invoice drops to 7,100.00 − 2,000.00 = HK$5,100.00. If it is confirmed against the undisputed part of INV-1002, INV-1002 becomes HK$4,500.00 (HK$1,500.00 still disputed, HK$3,000.00 undisputed) and INV-1001 stays at HK$7,100.00.
- Only after that allocation is confirmed, follow up the verified overdue amount on INV-1001.
- INV-1002: honour the promised date of 2026-09-15 for the undisputed part; keep the disputed HK$1,500.00 on a separate track.
- INV-1003: nothing — it is not due.
Do not send a demand for the whole HK$15,800.00: it includes an amount that is not due, an amount in dispute, and an amount under a payment promise.
A follow-up ladder — drafted, then a person sends
On a phone, scroll sideways to see the full table.
| Stage | Trigger | Tone and content |
|---|---|---|
| 1 — Reminder | 1–30 days past due | Assume it slipped. Restate invoice number, amount, due date and payment details; attach the invoice or statement. |
| 2 — Firm follow-up | 31–60 days past due | Reference the statement. Ask for a payment date or the reason for the hold. Name a person to reply to. |
| 3 — Final notice | 61 or more days past due | List only the verified overdue amounts eligible for this stage; keep disputed lines, not-yet-due invoices and agreed payment arrangements separate. Give a clear deadline. Offer a call. Escalation beyond this is a person's decision. |
This ladder is an example of an internal follow-up workflow, not a legal collections procedure; each stage acts only on verified overdue amounts.
Every message is drafted for review and sent by a person — including on WhatsApp. Do not automate sending on any channel: a wrong or badly timed message to a real customer is hard to take back.
Statement cut-off
Pick a day — for example the last working day of the month — and export a dated statement snapshot of each customer's open items as at that date. That snapshot is what you send and reconcile against; it is a point-in-time document, not a freeze on the ledger. Keep posting receipts as they arrive, and re-check the customer's position before any later reminder. Sending a statement first also surfaces disputes early.
For the issuing side of the same cycle, see how to write an invoice in Hong Kong, and for where a receivables workflow fits among other back-office jobs, our list of tasks worth automating. If late payments are a regular problem, tell us how your invoicing and follow-up work today and we will suggest where a drafted, human-sent workflow would help.
FAQ
Should aging run from the invoice date or the due date? For collections, the due date — it tells you what is actually late. Microsoft's customer aging documentation shows the basis is a choice you make; state which basis and "as of" date your report uses.
How is a partial payment shown in the aging report? Apply it to specific invoices. The unpaid remainder keeps its original due date and continues to age from there — it does not reset.
A customer disputes part of an invoice. Do we chase the rest? Log the dispute. Under this example's review policy, the dispute pauses follow-up on the disputed amount — it does not change the invoice balance or its aging. Follow up only the undisputed part, note that a dispute is open, and record any promised-payment date. A promise does not reset the due date.
Can the reminders be automated? A project could build the aging view and draft the right-stage message for each customer automatically. A person still reviews and sends every one, and decides on any escalation.