Reminder troubleshooting

Invoice reminder email not received? Check the path before resending

If a customer says they have not received an invoice reminder, first check the recipient and the sending evidence. Do not assume the email reached their inbox, and do not immediately send another copy when the earlier outcome is unclear. Use an established contact route to confirm the right destination and what the customer needs before choosing the next action.

By PayerPing · Published

Check the address and the invoice context

Compare the reminder's actual recipient with the accounts contact confirmed by the customer. Look for an old employee address, a typing error or an invoice that should have gone through a portal. Check the invoice reference and date too, so both of you are discussing the same message. A customer may recognise the original invoice but not a follow-up sent to a different person.

Record what you find before changing anything. If the address is wrong, pause future reminders and confirm the correction through an existing contact route. Review any affected messages before resuming. Avoid sending invoice details to a new address merely because an unexpected email asks you to redirect them; establish the appropriate contact with the customer first.

Read the sending status carefully

Find the relevant message in your sending history. Scheduled means a message was planned; it does not establish submission. In PayerPing's status model, provider accepted means the email service accepted the submission, while delivery, bounce and uncertainty are separate outcomes. Read the service's explanation of its labels rather than treating every green indicator as proof that the customer saw the message.

For example, Postmark describes its delivery event as confirmation from the receiving mail server, and explicitly separates that from inbox placement. That provider definition does not establish which delivery evidence your selected reminder service actually receives. Check the evidence attached to the particular message.

If there is a recorded bounce or definite failure, follow the stated reason and support guidance. If the result is uncertain, investigate before duplicating the submission. Preserve the original history so you can explain what you checked. Even where delivery evidence exists, the customer's statement still needs a practical response; it does not tell you that they read or understood the request.

Confirm a useful contact route with the customer

Contact the customer through a route you already use, such as the agreed project contact or accounts telephone number. Ask them to confirm the address and whether they need another copy of the invoice. If they have an internal accounts process, ask which submission route it requires. Keep the question factual rather than suggesting they ignored an email.

You can ask the recipient to check whether the message is visible elsewhere in their mailbox and to consult their own email support where appropriate. Do not promise that a subject change, attachment change or repeated resend will ensure inbox placement. The useful outcome is a confirmed route and a clear decision about the invoice, not an unsupported explanation of the customer's email system.

A worked example: an outdated accounts contact

A fictional studio receives a call saying invoice ST-88 never reached accounts. The owner compares the saved recipient with the current contact and discovers that it belongs to someone who has left. They pause the sequence, confirm the current accounts address through their existing client contact and record who supplied it.

The owner checks the earlier sending outcome before choosing how to provide another copy. They correct the recipient, preview the next message and explain that it concerns the existing invoice rather than a new charge. The next review date follows the customer's confirmed processing step. Restarting the old sequence without those checks would have repeated the same mistake at the same address.

Prepare a useful private support request

If you cannot establish the sending outcome, make the support request specific enough to locate the attempt. Use the service's private support channel and minimum identifiers it requires. These are headings for your note, not a request to post customer details publicly.

Relevant invoice/reminder reference: [service reference]
Attempt time and timezone: [time shown in history]
Visible outcome: [exact status, not an inferred delivery]
Recipient check: [matches / correction confirmed / still checking]
Customer report: [which message they say is missing]
Action held: another reminder is paused while this is investigated
Question: was the submission accepted, and what action is permitted?

Keep raw provider payloads, full message content and unnecessary payer information out of the note. If a bounce or suppression is recorded, use its stated review process. Do not switch channels or create a replacement invoice to bypass it. Once the issue is resolved, agree one deliberate next contact with the customer rather than sending several copies to test what arrives.

Sources and further reading

All invoice reminder guides

Optional analytics

Allow Google Analytics and Vercel Analytics to measure visits and completed signups? You can use every feature without them and change your choice here at any time. Privacy details