An unpaid invoice can turn into a surprisingly personal task. The payment date passes, and a straightforward question starts collecting feelings. Is it too soon to ask? Will the client think you are pushy? What if they are unhappy with the work?
Those questions do not tell you why the payment is late. Before writing a story about the client's motives, check what you actually know. Was the invoice sent to the right person? Is the due date clear? Has the client raised a dispute? Has anyone checked whether the payment already arrived?
Start there. A reminder should respond to the state of the invoice, not to an assumption about the person who owes it.
Imagine an invoice due on Friday. On Monday, the owner sees it is unpaid but decides to leave it another day. A busy week follows. By the next Friday, the reminder feels harder to send, even though the amount and the due date have not changed. That is an example of a process depending on somebody's willingness to do an awkward job.
A simple rule removes one decision: choose when the first reminder should go out, and write it before you need it. Keep it factual. Name the invoice, the amount, and the due date. Attach the invoice or give the client a working way to find it. Ask them to flag any problem with the details.
For example: "Checking on invoice 104, due last Friday. I've attached it again. Could you confirm the payment date, or let me know if anything needs correcting?" Adapt the details to the actual invoice. This is a starting point for the message, not a claim that the same wording will get every client to pay.
The next step matters too. Decide who checks for a reply and what happens if no reply arrives. A reminder sent from an unattended inbox creates another loose end. If the client disputes the charge, asks for a different recipient, or promises a payment date, someone needs to own that answer.
Do not turn the reminder schedule into a machine that ignores new information. Check the payment status before each send. Pause the sequence when a dispute needs attention. Record the promised date rather than sending a message tomorrow that behaves as if today's conversation never happened.
You can test this without buying another tool. Pick one unpaid invoice and follow its path. Where is the current status recorded? Who can change it? Who is responsible for the next action? If two people would give different answers, agree on one record before adding automation.
Then test the exceptions: a payment arriving just before the reminder, a reply asking for a correction, and a client saying the invoice went to the wrong person. The useful question is whether the next action still makes sense in each case. Sending on time is only part of the job. Sending the right message to the right person is the rest.
What part of invoice follow up gets stuck in your business: sending the reminder, finding the payment, or handling the reply? Tell us in the comments. For examples of OCTYN's work, visit octyn.co/casestudies.
Top comments (8)
The "record the promised date" point is the one I see skipped most. When a client says "we'll pay on the 20th," I write that date next to the invoice and set the next check for the 21st, so the follow-up becomes "you mentioned the 20th, can you confirm it went out?" instead of restarting the generic reminder sequence. It also helps to ask who actually approves payment the first time an invoice slips, because half the delays I've had were just the invoice sitting with someone who couldn't release it.
The approver question is the one that changes the whole thread. Once you know who can actually release the payment, every reminder after that goes to a person who can act instead of a person who can only apologize. And it pairs well with your date habit: "you mentioned the 20th" gives the approver something simple to confirm, which is a much easier reply to send than an excuse.
Agreed, and a quick way to find the approver is to ask it early and neutrally: "Is there anyone besides you who needs to sign off before this gets paid?" If you can, ask that before the first invoice even goes out, so it never feels like an escalation later. Then once the approver confirms a date, I'd note it next to the invoice and only follow up the day after it passes.
That early framing is the whole trick. Asked before the first invoice, it is process; asked after the third reminder, it is pressure. And the day-after follow-up works because it quotes their date back instead of introducing yours, so the conversation stays about their commitment, not your patience.
Exactly, and quoting their own date back also gives them an easy yes. "You mentioned the 20th, can you confirm it's on track?" takes ten seconds to answer, where a generic reminder invites an excuse. I also put the invoice number and amount in the same line so whoever forwards it to accounting doesn't have to dig.
The invoice number and amount in the same line is doing quiet work: it removes the one reply that costs you a day, which is "which invoice is this?" The forwarded message is the real audience. The person you wrote to often is not the person who pays, so the line has to survive being forwarded to someone with no context and no patience.
Agreed, and that's why I keep the subject line self-contained too: invoice number, amount, and original due date, so the forward still makes sense when it lands in an AP inbox. I also keep the body to two sentences and put the ask first, because the person who finally opens it is usually clearing a queue, not reading a story. If it's ever bounced back with "who is this?", I treat that as a sign my line was too dependent on prior context and tighten it.
The bounce test is the right bar. A line that survives being read by a stranger with no thread context is exactly what an AP inbox needs, because that stranger is who ends up reading it. The two-sentence body does the same job as the self-contained subject: anything longer gives a queue-clearer a reason to defer it to a pile that never gets cleared.