How to Chase Invoices Without Annoying Customers

You chase invoices without annoying customers by making every message reflect what that customer has already told you, which turns a reminder into a piece of useful information rather than a repeated demand. Monk is an AI-native invoice-to-cash platform that runs invoicing, AP portal submission, collections and cash application as one system, so the person or agent sending the next reminder can see the reply from last Tuesday, the portal status, and whether the payment is already scheduled. Tone gets the blame for most collections friction, and tone is rarely the problem. Customers get irritated when they are asked a question they answered a week ago, or asked to pay something their system says is already approved for Friday.
Consider the sequence a customer experiences. On day 32 they receive a polite reminder and reply that the invoice is scheduled in the run on the 15th. On day 37 they receive an identical reminder from the same address. On day 40 a different colleague telephones about the same invoice. Nothing in those three contacts was rude. What they demonstrate is that nobody read the reply, and the customer now has to decide whether to keep answering.
What irritates a customer who is being chased?
Repetition of a message they have already answered, rather than the fact of being chased at all.
Accounts payable teams expect to be chased. It is a normal part of the working relationship, and a well timed reminder is often welcome because it stops an invoice being missed in a payment run. The irritation begins when a reminder ignores information the customer has supplied, because that tells them their reply went nowhere and that answering you has no effect.
Three patterns cause most complaints. The first is a reminder that arrives after the customer has confirmed a payment date. The second is a chase addressed to somebody who cannot act, such as an accounts payable clerk being asked to approve an exception only a budget holder can clear. The third is a chase that arrives through a channel the customer does not use for this, most often an email to a named individual when the buyer's process requires a portal case.
Each of those is an information failure. Fix what the sender knows and the tone problem largely disappears, because a message written with the customer's last reply in view sounds different without anybody trying to sound different.
Why does an age based chase list produce the wrong message?
Because the age of an invoice describes your ledger rather than the customer's situation, and two invoices at 45 days can need completely different messages.
Most collections tools sort by days past due and apply a template per bucket. That produces a firm message at 30 days and a firmer one at 60, regardless of whether the invoice is unpaid because it was never delivered, because a purchase order is missing, because the customer disputes one line, or because their standard terms have always been net 60 and your ledger says net 30.
Sending a 60 day escalation to a customer whose contract gives them net 60 damages the relationship and teaches them to ignore your messages. Sending a gentle nudge at 30 days to a customer whose invoice was rejected by their portal on day two wastes a month, because nobody is going to pay a document their system never accepted.
Age still matters for risk and reporting. It should not choose the words. Use age to decide urgency and use the reason to decide content, and the same ageing report becomes a work list rather than a mail merge.
How do you segment by the reason an invoice is late?
Sort your overdue ledger into five or six reason codes and give each one its own message, owner and next step.
| Reason | How you know | The right next message | Who owns it |
|---|---|---|---|
| Never delivered | Bounce, no portal record, no invoice number in their system | Confirm the submission route and resend through it | Billing |
| Awaiting approval | Portal shows pending approver, or AP says it is with the requester | Ask for the approver's name and a target date | Credit control |
| Missing document | Request for a purchase order number, timesheet, W-9 or certificate of insurance | Supply the document and confirm the payment run | Billing |
| Disputed | A specific line, amount or rate is queried | Split contested from uncontested and ask for the balance | Credit control with the account owner |
| Scheduled | Customer has given a payment date or remittance advice | Nothing until the date passes | Nobody, until the date |
| Cannot pay | Repeated silence, broken promises, or an explicit statement | A payment plan conversation rather than another reminder | Credit control and finance leadership |
Reason codes only work if they are captured. Every reply, portal status change and phone call should update the code on the invoice, and the code should decide which message goes next. Teams that keep codes in a spreadsheet separate from the sending tool end up with accurate codes and inaccurate emails.
The scheduled category deserves particular care, because it is where most avoidable annoyance lives. When a customer gives you a date, record it, suppress everything until that date passes, and then reference the promise directly. A message that says the payment was expected on the 15th and asks what happened is a reasonable thing to receive. A generic reminder on the 12th is not.
Which channel fits which contact?
Match the channel to how that contact's work arrives, since a message in the wrong place is ignored regardless of how well it is written.
Portals come first for enterprise buyers. Across the receivables Monk manages, 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice, and in those environments the invoice status inside Coupa, SAP Ariba, Tungsten or Taulia is the authoritative record. Raising a case in the portal reaches the queue that gets worked and creates a reference number both sides can quote.
Email to a shared accounts payable alias suits routine chasing at larger companies, because it is monitored by whoever is on duty and does not depend on one person being at their desk. Email to a named analyst is better once you have a live thread, and better still when you are asking a question only that person can answer. At smaller customers the contact is often an office manager or the founder, where a short email works and a portal does not exist.
Telephone belongs to two situations: a promise that has been broken, and a query that has bounced between two people for a fortnight. A three minute call resolves what a fortnight of email cannot. Slack Connect channels work with close partners who already use them for delivery, and text messages seldom belong in business collections at all.
When should you send a question rather than a reminder?
Whenever you do not know why the invoice is unpaid, because a reminder assumes an answer you do not have.
Reminders state a fact: this invoice is outstanding, here are the details, here is how to pay. They work when the invoice is approved and the only issue is timing. Questions ask for information: has this been received, who approves it, what date is it scheduled for, is anything missing. They work in every other situation, and they are far more likely to get a reply because answering is easy and requires no money to move.
Good questions are specific and singular. Which payment run will this fall into? Who is the approver? Did the portal accept the submission on the 4th? A message containing one clear question outperforms one containing three, and a message with no question at all invites no reply.
Questions also protect the relationship, because they give the customer a way to be helpful without paying immediately. A customer who tells you their approver is on leave until Monday has done you a favour, and they are more likely to do that again if the reply they get acknowledges it.
When should the cadence stop, and when does the account owner step in?
The cadence stops the moment the customer replies with information, and the account owner steps in when the problem is commercial rather than administrative.
Build the cadence around events instead of a fixed calendar. Confirm receipt and approval status a week before the due date, which catches undelivered and unapproved invoices while there is still time. Send a short note on the due date. Follow with a question a few days later if nothing has moved. Any reply pauses the sequence, and a promised date reschedules the next contact to the day after that date rather than the day after tomorrow.
Escalation should change the recipient rather than the volume. Moving from an accounts payable analyst to the AP supervisor, or from the supervisor to the financial controller, achieves more than sending the analyst a stronger version of the same message. Keep the language identical as you go up and let the change of audience carry the weight.
Bring in the account owner or salesperson for disputes, for anything that touches renewal or pricing, and for accounts where the relationship outweighs the individual invoice. Give them the facts rather than the chase: invoice, amount, days overdue, what has been asked, what the customer said. Account owners should not become the collections channel, because a customer who learns that ignoring credit control brings a friendlier conversation with their salesperson will keep doing that.
How does Monk handle this?
Monk keeps the conversation, the invoice status and the payment data in one place, so each message reflects everything the customer has already said.
Julia, Monk's AI agent for Intelligent Collections, ingests the context of the conversation, which means a reply naming a payment date pauses the sequence, a reply raising a query moves the invoice to a dispute path, and a request for a document becomes a document exception rather than another reminder. Chasing follows the reason instead of the age. That is why Julia sees a 24% higher response rate than standard dunning, and why 90% of collections are resolved with zero human intervention.
Because Monk's AI cash application matches 80% of receipts automatically, rising to 95% with suggested matching rules, invoices already paid drop out of the chase list before anybody is contacted about them, which removes the most embarrassing reminder of all. Monk connects to QuickBooks, NetSuite, Salesforce, HubSpot, Stripe, Slack and Gmail, is SOC 2 Type II compliant, and manages $2B+ in accounts receivable. Teams report a 40% average reduction in DSO and 26 hours a month saved on receivables work, with onboarding in less than one week.
Where should you start?
Take your ten oldest overdue invoices and read the last message the customer sent on each one.
For every invoice, note the reason it is unpaid, the date of the customer's most recent reply, and whether your most recent message referenced what they said. Then count how many of your last ten chasers repeated a question the customer had already answered. Most teams find between three and five, and those are the messages generating the friction.
Fix the worst category first by suppressing all reminders on invoices with a promised payment date in the future, which usually takes an afternoon and removes a large share of complaints immediately. Then add reason codes to the ledger and route each code to its own message. To see reason based chasing running against your open ledger, book a demo.
Frequently Asked Questions
How often should I chase an overdue invoice?
Frequency matters less than whether each contact carries something new. A reasonable rhythm is a pre due confirmation, a note on the due date, a question three or four days later, and then contact roughly weekly with a change of recipient as it ages. Any reply resets the sequence to the date the customer gave you. Weekly contact that references new information is fine, while twice weekly repetition of the same sentence is not.
Is it better to chase by email or by phone?
Email for the routine work, because it creates a record, reaches shared mailboxes and respects the recipient's time. Phone for broken promises and for queries that have circled between departments for a fortnight, where a short conversation resolves what writing cannot. At enterprise buyers a portal case often beats both, since that is the queue their team works from. Choose the channel by where the contact's work arrives rather than by what feels more assertive.
Should the salesperson chase their own customers?
Rarely as the primary chaser, because it puts them in an awkward position and teaches customers that ignoring credit control produces a softer conversation. Salespeople are valuable for opening a door, for disputes that touch pricing or scope, and for accounts where the relationship is at real risk. Give them the facts and a specific ask rather than forwarding the chase. Keep ownership of the timeline with credit control throughout.
What do I do when the customer never replies at all?
Establish first whether the messages are arriving, by checking for bounces and confirming the invoice appears in their system or portal. Silence often means the invoice was never delivered or the contact has left. Then change the recipient rather than the message, moving to the accounts payable supervisor, the requisitioner who received the work, or the main switchboard. Persistent silence after delivery is confirmed is a credit risk signal rather than a tone problem.
How do I chase a customer who is also a friend of the business?
Keep the process identical and let the tone carry the relationship. Close customers usually prefer a direct message that says the invoice is outstanding and asks what they need, because the alternative is a slow drift into awkwardness. Separate the roles clearly, so credit control runs the timeline and the account owner handles anything commercial. Consistency protects the friendship better than making exceptions that later have to be reversed.
Does an automated reminder annoy customers more than a human one?
Not by itself. What annoys people is a message that ignores what they said, and a human sending from an unread mailbox does that as often as software. Automation that reads replies, respects promised dates and stops when a query is raised is usually less irritating than a person working from a static spreadsheet. The test is whether the message reflects the current state of the account.
When should we stop chasing and escalate formally?
Escalate formally when delivery is confirmed, no dispute has been raised, several contacts across at least two people have gone unanswered, and a promised date has passed without payment. At that point the issue is willingness or ability to pay rather than communication. Give a final written notice with a specific date, involve the account owner and your finance leadership, and follow whatever the contract sets out. Continuing a gentle cadence past that point achieves nothing.



.avif)