Outstanding and overdue mean different things
Outstanding is the amount still unpaid after applied payments and credits. Overdue is the part of that outstanding amount whose due date has passed. An invoice due next week can therefore be outstanding without being overdue. Keep the two measures visible so the team does not chase an amount before its agreed date. Use the remaining balance rather than the gross invoice value when deciding what still needs attention.
Part payments reduce the balance only after they have been applied to the relevant invoice. Credits also reduce it, but they are not cash received. Paid and voided items should not sit in the active reminder queue. A dispute changes how an invoice is handled; it does not automatically erase what remains outstanding. These distinctions matter more than a coloured status label without an explanation.
Read an ageing report with a date and a basis
An aged-receivables report groups money owed by how long it has been overdue. Here the non-overlapping groups are Not overdue, 1–30, 31–60, 61–90 and 91+ days overdue. The basis is the invoice due date, not its issue date or the day it was imported. Show the as-of date beside the report. Changing that date can move an unpaid invoice between groups even if its balance is unchanged.
EX-101 is 15 days overdue and EX-102 is 30 days overdue on 3 October. Both therefore belong in 1–30, not in separate overlapping buckets. EX-104 is due on 10 October and belongs in Not overdue. EX-103 has no remaining balance, so it contributes nothing to outstanding ageing. Keep settled history available for explanation without counting it as an open amount.
Follow the four sample invoices
The example starts with £2,350 outstanding: £900 on EX-101, £650 on EX-102 and £800 on EX-104. Of that, £1,550 is overdue and £800 is not yet due. The disputed £650 on EX-102 is already included in the overdue amount. Flagging it as disputed must not add another £650 to the total. EX-103 is settled after a £200 credit and a £1,800 applied payment against its £2,000 gross value.
If the EX-101 customer says ‘paid’, the next action becomes verification and the balance stays £900. Only the separately labelled simulated event applying the remaining £900 settles that example invoice. The resulting outstanding total is £1,450, including £650 overdue and £800 not yet due. This change demonstrates the arithmetic; it does not record a real payment or connect to a bank.
Make stale information visible
A useful tracking table includes the customer, invoice reference, due date, remaining balance, current state, next action and last source update. A last-update timestamp tells you how recent the source record is; it is not proof that someone reviewed the case. Keep the source update separate from the latest internal note or reminder. If a connection fails or an import is old, flag that uncertainty and hold further messages until the position has been checked.
Manual changes need the same care. An owner can record that a customer promised to pay, but that note should not replace the accounting balance. When a payment appears without an invoice allocation, ask the person responsible for the ledger to resolve it. Procora's proposed follow-up view would organise attention around those records, not become a second accounting ledger with competing balances.
Prioritise the reason for attention
Age and value help set priorities, but neither tells the whole story. A small invoice with a missing purchase-order number may need a document correction. A larger invoice under genuine dispute needs an owner to investigate. A payment claim needs verification. A wrong contact needs correction before any further message. Add an action and responsible person so the table becomes a practical work list rather than a list of red numbers.
Customer grouping can reveal several invoices requiring one coordinated conversation. Keep the individual references and states visible, and never combine currencies into one unexplained total. Review paid, voided, duplicate and disputed records before building a contact list. To plan a future pilot, discuss where your balances come from, how often they change and who handles exceptions. The aged-receivables guide explains how to check the same figures independently.
Explore the example
| Invoice / customer | Due date | Remaining | State / age | Next action / owner | Last update |
|---|---|---|---|---|---|
| EX-101Example A | 18 Sept 2026 | £900 | Part-paid15 days overdue | Review balanceOwner A | 3 Oct 202609:00 UTC · sample snapshot |
| EX-102Example B | 3 Sept 2026 | £650 | Disputed · reminders paused30 days overdue | Resolve queryOwner B | 3 Oct 202609:00 UTC · sample snapshot |
| EX-103Example C | 25 Sept 2026 | £0 | Settled— | Close recordOwner A | 3 Oct 202609:00 UTC · sample snapshot |
| EX-104Example D | 10 Oct 2026 | £800 | Not yet due— | Check contactOwner B | 3 Oct 202609:00 UTC · sample snapshot |
Illustrative workflow · sample data · no messages or payments are processed.