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 (1)
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.