Automated reminders need a human exception owner

An invoice workflow can do everything it was configured to do and still fail to move a payment forward. The invoice goes out. The reminders arrive on schedule. The customer replies that the service period is wrong. Accounts receivable forwards the message to operations, and operations asks the account manager to check. Meanwhile, the next reminder goes out.

This is an illustrative scenario, but it captures a weakness worth looking for in any collection process: a record of activity without clear responsibility for resolution.

For finance leaders, the question is not simply whether reminders are automated. It is whether someone owns the work that a reminder cannot do.

Start before the invoice is overdue

In our remote finance and accounting recruiting business, we introduced reminders three days before the due date, on the due date itself, and three, seven and 15 days afterward. The advance reminder has been particularly useful. In our experience, delays beyond 10 days are now rare.

We also invoice recurring retainers during the month in which the service is provided, keeping Net 15 terms. That brings invoicing closer to the work instead of waiting until the service month has ended to start the payment clock.

These are observations from our business, not a controlled study or a benchmark for other companies. I would not attribute the outcome to reminder frequency alone. Invoice timing and the surrounding process matter too.

The lesson I take from this is that some collection work belongs before the due date. An advance reminder gives the customer an opportunity to flag a problem while there is still time to address it. But that opportunity is wasted if the reply enters an inbox with no clear next step.

Separate a payment reminder from a payment problem

A reminder answers one question: when is payment due? It cannot establish whether the invoice reflects the agreed service, resolve a pricing disagreement or supply a missing purchase order.

Those issues require different actions. Sending a stronger version of the same reminder does not resolve the underlying question.

The framework I propose is to distinguish routine follow-up from an exception as soon as a customer identifies a specific obstacle. This is a practical recommendation, not a claim that we have measured the effect of an exception log in our own business. This need not mean buying another system. It means making the obstacle visible and assigning responsibility for moving it forward.

The record should describe the actual problem. “Customer has not paid” is a status, not a diagnosis. “Customer disputes the billed service period; operations must verify the start date” tells the next person what needs to happen.

This distinction also prevents an overdue balance from becoming a catch-all category in which a missing document, an unresolved dispute and an unanswered reminder look identical.

Give each exception four fields

A useful starting point is a compact exception log linked to the invoice, with four required fields: reason, owner, next action and promised update date.

Reason. Record the customer’s stated obstacle, separating what is known from what still needs verification. “Customer says the PO number is missing” is more useful than assuming that the customer is delaying payment intentionally.

Owner. Name one person responsible for coordinating resolution. That person does not need authority to make every decision, but should know who does and remain accountable for the next update. A department name or shared mailbox is not enough.

Next action. State a concrete task. “Follow up” is vague. “Ask the account manager to confirm the agreed service start date against the contract” is actionable. Correcting an invoice or approving a commercial concession should still follow the company’s existing authorization process.

Promised update date. Specify when the customer or internal team will next hear from the owner. This is not necessarily a payment date. An owner may commit to providing a verified answer tomorrow without being able to promise when the customer will pay.

The log should be brief enough to maintain during normal work. Its purpose is to make the next decision easier, not to create a second reporting exercise.

Make the handoff explicit

Consider an invoice with a disputed service period. Receivables can identify the unpaid balance and contact the customer, but operations may hold the evidence needed to establish when delivery began.

Under this approach, receivables records the issue, names an owner and identifies the evidence required. Operations returns a finding. The appropriate person approves any correction, and the owner communicates the outcome to the customer. If the invoice is correct, the customer receives an explanation rather than another unexplained demand for payment.

Ownership should continue through the handoff. Forwarding an email should not, by itself, count as transferring responsibility. If ownership changes, the receiving person should explicitly accept it, along with the next action and update date.

The reminder schedule also needs to reflect the live situation. Where a genuine dispute is being investigated, the owner should decide whether routine reminders should continue, change or pause under the company’s policy. A pause should have a review date; it should not make the balance disappear from view.

Give treasury a usable explanation

For treasury, the value of this discipline is the context it adds to the expected receipt date. An aging report shows how long an invoice has been outstanding. It may not explain what has to happen before the customer can pay.

An unresolved billing question, a corrected invoice awaiting customer confirmation and a customer-confirmed payment date represent different stages. Treating them as equivalent can obscure the assumptions behind a cash forecast.

The exception record should support that distinction. An internal promise to resolve a query by Friday is not evidence that cash will arrive on Friday. Treasury should be able to see which dates reflect internal actions and which reflect an actual customer payment commitment.

A short review can focus on overdue update promises, cases with no next action and problems recurring across invoices. Repeated service-period disputes, for example, should prompt a review of how billing receives delivery information, not simply more collection messages.

Measure resolution, not message volume

Reminder counts are easy to report. They say little about whether the underlying obstacles are being removed. More useful checks include how long exceptions remain open, whether promised updates happen and how often the same billing issue returns.

Automation remains valuable: it makes routine follow-up consistent and reduces dependence on someone remembering to send an email. The human role is to handle the point at which routine follow-up stops being sufficient.

Before adding another reminder, ask what is preventing payment, who owns that problem and when they will report back. A well-timed message can surface an exception. A named person must carry it through to resolution.