Late Payment Follow-Up Workflow

Late payment is not just a collections problem. In a small UK service or trading business, an overdue invoice can expose gaps between the quotation, delivery record, customer contact, accounting ledger and the person responsible for resolving a dispute. Sending the same reminder repeatedly will not repair those gaps. An effective late-payment follow-up workflow begins with reliable invoice facts, separates administrative reminders from disputed or sensitive accounts, and escalates only when the right evidence is available. This guide describes a controlled process that staff can maintain without turning a customer relationship into a sequence of threatening emails.

1. Establish one trustworthy invoice and payment record

Before building a reminder, decide which accounting system owns the invoice number, customer, currency, amount, due date, credit notes, allocation and balance. The workflow should read that record rather than maintain its own competing version of money owed. Record the last successful synchronisation and what happens if the connection fails. An email generator must never guess an outstanding balance from an old CRM note.

Test partial settlements. A customer may have paid most of an invoice, while the bank feed or allocation is awaiting review. A full-balance demand generated from yesterday's data is likely to cause frustration. Keep unmatched receipts in an exception queue and avoid contacting the customer until finance has resolved uncertainty. Likewise, a credit note may have been agreed but not yet posted. Distinguish issued, due, overdue, disputed, partially paid and settled states explicitly.

Map payment terms from the accepted contract or invoice, rather than relying on a universal assumption. GOV.UK's guidance on late commercial payments explains the framework where no payment date is agreed and other relevant conditions. The workflow should use the actual governing agreement and current facts, not treat every invoice older than 30 days as automatically collectible.

2. Define triggers and quiet periods around business reality

Choose a modest set of operational events: invoice issued, due date approaching, due date passed, payment received, dispute raised, customer response and escalation approved. A trigger should require the invoice to be eligible at the time of sending, not merely at the moment a task was queued. Recheck the ledger immediately before a message or collection action. This matters when a payment or credit is posted between scheduling and delivery.

Make timing configurable. A standard reminder may suit straightforward commercial invoices, while an account with negotiated instalments or a complex acceptance process needs a different route. Avoid repeated alerts on bank holidays or outside the customer's established communication arrangements without considering context. Do not invent an aggressive follow-up timetable simply to create a sense of urgency.

Include a duplicate-prevention key using invoice identity, reminder stage and relevant period. If the integration retries after a timeout, the customer should not receive the same overdue notice twice. Retain a delivery record where possible, but do not mistake an email delivery event for proof that the customer read or accepted its contents.

3. Separate payment queries and genuine disputes from ordinary collection

Not every unpaid balance represents unwillingness to pay. The customer might be waiting for a corrected purchase-order number, proof of delivery, an authorised sign-off or resolution of a service complaint. Provide an easy route for such explanations to reach a named owner. Once a dispute is recorded, pause ordinary reminder automation for the affected amount or invoice according to the business's policy.

Ask the account manager and finance team to reconcile the underlying evidence. Preserve the original quote, agreed scope, delivery confirmation, adjustments and correspondence. Do not ask AI to decide whether a contract was breached or a debt is legally enforceable. A model may summarise the issues for a reviewer, but the organisation remains responsible for the commercial and legal judgement.

For mixed cases, make the split clear. A customer may dispute one line while acknowledging another. Finance should decide whether and how undisputed sums can be pursued, with consideration of the agreement and circumstances. A workflow that knows only one status for the entire customer account may be too crude.

4. Write reminders that are factual, courteous and actionable

Build messages from confirmed data: customer identity, invoice reference, original amount, outstanding balance, contractual due date, approved payment instructions and the appropriate contact for queries. Avoid inserting bank details from free-text notes or from an unverified inbound email. If payment instructions have changed, use the company's established verification controls before sending them.

The first message can simply establish that the balance appears outstanding and ask whether payment has already been arranged or an issue needs resolving. Later steps may be firmer, but should remain accurate and proportionate. Never invent a previous agreement, pretend that a legal process has started, or imply that a human has reviewed a case when it has only been classified automatically.

Provide a direct reply route. Customers should be able to submit a remittance reference or explain a dispute without navigating a long automated menu. Route each reply to an accountable colleague and stop the generic sequence while the response is being assessed. A respectful, useful reminder is better for cash collection than a series of disconnected templates.

5. Control escalation, interest and recovery costs

Statutory interest and recovery charges are legal and contractual questions, not default automation features. GOV.UK describes statutory interest for qualifying business-to-business late payments as eight percentage points above the Bank of England base rate, subject to contractual and other conditions. Its debt recovery cost guidance describes fixed amounts that depend on the debt band. Those rules do not authorise a workflow to add fees blindly to every customer reminder.

Before calculating or sending any charge, check the customer type, agreement, current rate, eligibility, balance and whether a charge has already been applied. A finance or appropriately authorised decision maker should approve consequential action and preserve the calculation evidence. Do not publish a fixed example rate as though it were today's live Bank Rate. Different jurisdictions, contract arrangements or public-sector relationships can require different treatment.

Escalation should expose the evidence and desired decision: continue discussions, agree a payment plan, resolve a dispute or pursue an approved recovery route. Record the actual person who authorises a next step. A system that merely sends harsher emails after a timer expires is not meaningful governance.

6. Build a human-owned exception and recovery queue

Define exception types before deployment: customer not matched, balance uncertain, returned email, payment promise, disputed delivery, duplicate invoice and finance-system outage. Assign each to a suitable owner and show the due action in the system already used by the team. An exception should not simply cause another notification to the same unmonitored inbox.

A payment promise deserves a record of who made it, which invoice it relates to and when a follow-up is appropriate. Do not overwrite the original due date to represent an informal promise: staff may need both facts. Where a repayment arrangement is agreed, follow the approved policy and allow a person to review any missed instalment before restarting collection messages.

Keep logs narrow but useful: what triggered, the ledger state used, the message stage, the outcome and the person responsible for changes. Restrict access to commercial and personal information. If the integration goes offline, preserve unsent actions and revalidate balances before replaying them; never send a week's worth of stale reminders automatically on reconnection.

7. Test the full process with difficult invoice examples

Create a controlled trial containing a fully paid invoice, one with a partial allocation, an open credit note, a disputed service, an agreed future payment date and an invoice genuinely overdue under the relevant terms. Define what should happen in each case before running the automation. For a fully paid invoice, the correct output is no reminder. For a dispute, it is a review task. For an ordinary overdue balance, it may be a clear first reminder.

Check integration failures and race conditions. Schedule a message, then post a payment before sending. Retry the same event. Change the account contact. Observe whether the workflow stops, avoids duplication, preserves the original invoice reference and reports the exception. Test the wording against the organisation's tone and policy with both sales and finance colleagues.

Measure staff effort as well as message output. Count incorrect reminders prevented, disputed cases routed correctly, time spent reconstructing balances and genuine payment resolutions. Avoid inventing a recovery rate or treating every paid invoice as proof that a reminder caused the payment. Use the baseline to judge whether the workflow is worth maintaining.

8. Keep the commercial relationship and accounting truth aligned

Start with a simple scheduled review if the organisation handles only a handful of invoices. Add workflow automation when repeated delays, missing ownership or manual rekeying justify it. A larger operation may need specialised accounts-receivable tools, but selection still depends on ledger connectivity, approvals, dispute handling and export. The most expensive platform will not compensate for unclear terms or inconsistent invoice data.

Make the final design legible to staff: finance owns balances, the account team owns relationship context, a reviewer handles disputes and authorised management owns serious escalation. Every message should be explainable from an actual invoice state. The operational goal is fewer preventable misunderstandings and a more dependable cash-collection process, not simply a larger volume of automated demands.