An overdue invoice does not become actionable merely because it appears in an ageing report. The team needs to know why it is open, who owns the next step and what state will change the plan.
A controlled collection workflow uses reminders as one tool. It does not replace investigation, dispute handling, payment matching or customer context with a fixed message sequence.
Classify the open balance
Separate not received, awaiting approval, promised, partially paid, disputed, payment sent and unmatched states.
The ageing bucket describes time, not the operating reason.
Assign one accountable owner
Name the person responsible for the next action even when several teams contribute evidence.
Escalation should change authority or support, not make ownership ambiguous.
Record the next action and date
State whether the team will resend, provide evidence, contact the buyer, check payment, resolve a dispute or escalate.
A note without a due date is not a plan.
Use stop conditions
Pause automated reminders when a dispute, promised payment or internal investigation makes the standard message inappropriate.
Restart only from a recorded state change rather than elapsed time alone.
Close with payment evidence
Match the receipt and allocation before marking the invoice paid.
Retain any deduction, credit or residual balance with its own reason and next action.
Assign ownership around the next decision
One person should be accountable for moving the invoice from its current state, even when sales, delivery, finance or accounting supplies evidence. Ownership follows the next decision, not organisational prestige. Record the owner, action, date and escalation boundary against the invoice.
Avoid shared mailboxes as the only owner. They can support intake, but a case needs a named accountable person or role assignment. When ownership changes, retain the hand-off time, reason and accepted next action so the customer and internal teams do not restart the investigation.
Start collections from verified context
Confirm the issued version, delivery outcome, due date, open balance, payment allocation, dispute state and customer contact before acting. A reminder is inappropriate when the invoice failed delivery or an authorised credit is pending. A generic overdue state should not override better evidence.
Use the customer's latest commitment without treating it as cash. Record covered invoices, amount, currency and date. Pause only the relevant action until the checkpoint, then verify supported receipt and allocation before closing the case.
Design a controlled action sequence
Define permitted reminders, internal reviews, customer contacts and escalations under approved business rules. Each step needs an entry condition, owner, communication purpose and stop condition. The sequence should adapt to delivery, dispute and promise states rather than send every customer the same message on age alone.
Keep legal escalation, credit decisions and customer relationship exceptions with their authorised owners. The operating workflow exposes those decisions and preserves their reasons; it does not invent policy or allow an informal note to suspend action indefinitely.
Work an approved-but-scheduled case
Assume the buyer confirms the invoice is approved but scheduled for its next payment run. Record the buyer, invoice, supported amount and expected date. Pause repetitive reminders through that checkpoint and assign the person who will verify receipt. Keep the open balance and invoice history unchanged.
If payment appears, allocate it using receipt evidence and close the action. If it does not, follow the defined missed-commitment path. Do not reset the case to a generic first reminder or delete the earlier promise; its history informs the next authorised decision.
Measure ownership quality
Review unowned cases, overdue actions, repeated transfers, stale promises, unresolved delivery failures and time waiting by reason. Use the organisation's own controlled population. A low message count is not success if balances remain blocked, and a high contact count can indicate poor context rather than effective collection.
Use patterns to improve invoice delivery, customer data, evidence and escalation design. Keep metric definitions stable and avoid unsupported public claims. The useful question is whether the right owner made the next supported decision at the right time.
Collection-case closure note
Record the invoice, current balance, decisive evidence, customer state, actions taken, receipt or authorised resolution, final owner and closure date. Confirm that payment allocation, dispute and customer statement views agree where applicable. Link authoritative records instead of duplicating them.
Reopen visibly if a payment reverses or new evidence changes the balance. Preserve the earlier closure and subsequent event so later reviewers understand why each action was reasonable at the time.
Decision summary
Start from the exact issued invoice, customer evidence and current balance.
Keep one accountable owner, one next action and one testable date.
Preserve delivery, dispute, promise, receipt and allocation as distinct states.
Use stable identifiers across customer, billing and accounting hand-offs.
Close only when another authorised person can reproduce the outcome.
Coordinate contributors without losing accountability
Create a compact case view showing the current owner, contributors, decisive evidence, customer commitment and next checkpoint. Sales can clarify the relationship, delivery can confirm acceptance and accounting can confirm receipts, but one person remains accountable for the case movement. Contributors should update the shared record instead of creating parallel customer promises that finance cannot see.
When an authorised escalation changes ownership, the receiving owner accepts the outstanding action and date. Keep the prior owner and transfer reason in history. Review cases that bounce repeatedly between teams because they often reveal unclear policy, missing evidence ownership or a customer-data problem rather than a difficult customer.
Handle disputes, concessions and escalation boundaries
When the customer disputes scope or requests a concession, route the evidence and decision to the authorised owner while the collection owner retains the case timeline. Do not promise a credit or suspend the entire account unless policy and authority support it. Record the disputed amount separately from the undisputed position and define which communications remain appropriate.
Escalation should name the decision needed, evidence available and customer consequence. A senior recipient should not have to reconstruct the case from forwarded messages. When a decision returns, the collection owner updates the balance, communication and next action so the case does not remain suspended after the escalation is complete.
Before closing or escalating, confirm that the customer's latest communication, delivery state, dispute scope, promise and supported balance are current. Record which contributor supplied the decisive evidence and which owner accepted the resulting action. This final check prevents an internally complete workflow from acting on customer context that changed during the case.
Put the control into practice
Review the ten oldest open invoices. If any lacks a reason, owner, action or date, fix that operating record before changing the reminder copy.
Run the review on a real case
An overdue invoice has been received and approved by the buyer, but payment is scheduled for the next run. Record that reason, the promised date and the person who will verify receipt. Pause repetitive reminders only until the agreed checkpoint.
Review open invoices by reason and next-action status as well as age. Each case needs one accountable owner even when sales, delivery or accounting contributes evidence.
Case-review checklist
Open-balance reason is current
One next owner is named
Action and date are explicit
Stop condition controls reminders
Payment evidence closes the case
Collection policy, legal escalation and customer communication must follow approved business rules. The workflow makes those decisions visible rather than prescribing them.
Evidence
Sources and scope
- GOV.UK: invoices and required information
Supports examples of core invoice information in UK guidance. Requirements vary by jurisdiction, tax status and transaction type.
Continue in context
