AP Contact Email Bounced: How to Find a New Contact

When an accounts payable contact's email bounces, stop chasing payment and start proving delivery, because an invoice that never arrived is not late in any sense the customer would recognise. Monk is an AI-native invoice-to-cash platform that runs invoicing, AP portal submission, collections and cash application as one system, so a bounced delivery raises an exception on the invoice rather than leaving it to age quietly in a report. The order of work is fixed: confirm what happened to the message, find a verified replacement contact through the buyer's own documents, resend through the route their system accepts, and record the new contact so this does not recur.

The failure is easy to miss. An invoice goes out on the first of the month, the mailer daemon reply lands in a shared mailbox nobody reads, and the accounting system shows the invoice as sent. Thirty days later it appears on the overdue report, somebody sends a reminder to the same dead address, and the cycle repeats. The customer has no record of the invoice, no dispute, and no reason to pay.

How do you tell a bounce from silence?

Read the delivery outcome, because four different failures look identical on your overdue report and each needs a different response.

A hard bounce returns a delivery status notification with a permanent code, typically 550 5.1.1 for an unknown user or 550 5.4.1 for a rejected recipient. The mailbox is gone. A soft bounce, such as 452 for a full mailbox or 421 for a deferred delivery, means the address exists but the message did not land, and it often clears by itself within a day.

A silent failure is the dangerous one. The receiving server accepts the message and then a filter such as Mimecast, Proofpoint or Microsoft Defender quarantines it, or an inbox rule files it in a folder nobody opens, or the shared mailbox routes into a capture tool that rejects attachments it cannot read. You get no notification at all, and your system reports a successful send.

Autoresponders are the most useful of the four, because they usually name a replacement. Read them rather than letting a rule archive them. A message saying somebody has left and asking you to contact a named colleague answers your question in one step. Where none of the four is present and the invoice is unacknowledged after a few days, check the portal record: 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice, measured across the receivables Monk manages, and no portal record means no invoice.

Why does an undelivered invoice keep ageing invisibly?

Your ledger records the date you raised the invoice rather than the date the buyer received it, so the clock starts whether or not anybody read the document.

Ageing reports are built from invoice dates. Nothing in the standard accounting flow verifies delivery, and few teams reconcile bounce notifications against the ledger, so the invoice moves through the 30, 60 and 90 day buckets on schedule. Every reminder goes to the same dead address, each one bouncing into the same unread mailbox.

The cost compounds. Payment terms almost always run from receipt or from a valid submission, which means an invoice delivered on day 62 is not overdue at all. Where the contract sets a submission deadline, often thirty or sixty days from completion of the work, a long enough delay can put the invoice outside the window and give the buyer grounds to reject it.

Add a delivery check to the ageing review. Any invoice with no acknowledgement, no portal status and no bounce after five working days should be treated as undelivered until proven otherwise. That single rule catches most of these before they reach a second bucket.

What is the order of operations for finding a replacement contact?

Work outwards from the documents you already hold to the buyer's own published routes, and treat anything requiring a search engine as the final option.

Steps one to five cost nothing and take about ten minutes, because those documents are already in your files. Most teams skip to step nine, the least reliable route and the one most likely to produce an address that fails.

The telephone deserves more credit than it gets. Calling the main number and asking to be put through to accounts payable, or asking for the correct address for invoice submission, resolves most of these cases in a single call. Ask for two things while you have somebody: the shared alias and a named individual who monitors it.

Why is guessing an email address a bad idea?

Guessing produces confident failure, because a wrong address that quietly accepts your message is worse than one that bounces.

Many corporate domains run a catch all, so an invented address is accepted, no bounce is generated, and your system records a successful delivery. The invoice ages exactly as before, with the added problem that you now believe it was delivered. Guessing also lands invoices in the wrong hands. An invoice carries your bank details, your customer's name and the amount owed, the exact material used in payment redirection fraud, and sending it to an unverified recipient creates an exposure your finance policy prohibits.

There is a deliverability cost as well. Repeated sends to invalid addresses raise your bounce rate, and mailbox providers use that signal to decide whether your domain is trustworthy. A billing domain that accumulates hard bounces starts landing in junk folders for customers whose addresses are correct, which turns one dead contact into a general delivery problem.

Guessing at a former employee's successor carries its own risk, since their mailbox may auto forward to a colleague with no authority over payables, or to an external administrator. Verify instead. A thirty second telephone call gives you an address somebody has confirmed, and a portal case gives you a route that does not depend on any individual mailbox at all.

What should you send once you find the right person?

Send a short introduction, the invoice itself, and one question about the submission route, without any hint that the delay was their fault.

Open by explaining why you are writing to them, name the previous contact and the bounce, and state the invoice number, the purchase order number and the amount. Attach the invoice PDF and any supporting document the buyer normally requires, such as a timesheet or delivery note. Then ask the decisive question: is email the correct route for invoices, or should this be submitted through a portal, and if so, which one.

Ask them to confirm receipt and to tell you which payment run the invoice will fall into. That converts a resend into a dated commitment rather than another document sitting in a queue. Where the delay has been long, ask for the due date to be calculated from this delivery rather than the original invoice date, which is usually what the contract says anyway and is easier to agree in the first message than in a later argument.

Never change bank details in the same message as a new contact introduction. A supplier writing to a new person, from an unfamiliar address, presenting an invoice and payment instructions is the exact shape of an attempted fraud, and any competent accounts payable team will treat it that way. If your remittance details have changed, handle that separately through the buyer's verification process.

How do you stop it happening again?

Hold a verified accounts payable contact for every customer and route bounce notifications to somebody whose job it is to act on them.

Give each customer record four fields: the shared accounts payable alias, a named individual with their direct address and telephone number, the submission route with any portal identifier or supplier number, and the date the contact was last verified. Send to the alias and copy the named person, so departures never break delivery on their own. Collect all four during onboarding, alongside the purchase order requirements and remittance instructions, and confirm them again at contract renewal.

Make bounces visible. Route delivery status notifications to a monitored address rather than to the mailbox that sent the invoice, and raise a task on the invoice when a hard bounce arrives so the exception has an owner and a date. Send billing mail from a domain with correct SPF, DKIM and DMARC records, because alignment failures are a common cause of silent quarantine at large buyers.

Add one automatic check: any invoice with no acknowledgement, no portal status change and no bounce after five working days gets flagged for a delivery verification call. Most undelivered invoices are found by that rule rather than by a bounce, and finding them in week one costs a phone call.

How does Monk handle this?

Monk treats delivery as part of collections rather than as a separate email problem, so a bounce becomes a visible exception with an owner instead of a message nobody reads.

Monk records whether an invoice reached the buyer and whether the portal accepted it, and Intelligent Collections works from that record alongside the reply history. Julia, Monk's AI agent for Intelligent Collections, ingests the context of the conversation, so a mailbox failure or an autoresponder naming a replacement changes what happens next rather than being followed by another reminder to the same address. Julia sees a 24% higher response rate than standard dunning, and 90% of collections are resolved with zero human intervention.

Undelivered invoices are a clear example of the edge cases that cause 39% of cash flow slowdown, and they are one reason Monk keeps invoicing, portal submission, collections and cash application in one place. Monk's AI cash application matches 80% of receipts automatically, rising to 95% with suggested matching rules, and Monk connects to QuickBooks, NetSuite, Salesforce, HubSpot, Stripe, Slack and Gmail. Monk is SOC 2 Type II compliant and manages $2B+ in accounts receivable, with customers reporting a 40% average reduction in DSO and 26 hours a month saved.

Where should you start?

Search your sent folder and your mail server logs for delivery failures over the last ninety days and match them against open invoices.

Every hard bounce matching an unpaid invoice is an invoice that was never delivered, and you can usually resolve those in an afternoon of telephone calls. Next, list your open invoices with no acknowledgement, no portal status and no reply of any kind. Those are the silent failures, and there are almost always more of them than there are bounces.

Then complete the four contact fields for your twenty largest customers: alias, named individual, submission route and verification date. Any customer where you cannot fill all four is a delivery failure waiting to happen. To see delivery, portal status and collections tracked against the same invoice record, book a demo.

Frequently Asked Questions

How do I know whether my invoice email was delivered or quietly filtered?

Delivery to the server and delivery to a human are different things, and only the first produces a bounce. Check for a delivery status notification, then look for positive evidence of receipt: an acknowledgement, an invoice number in the buyer's system, or a status change in their portal. Where none exists after five working days, treat the invoice as undelivered and verify by telephone. Read receipts are unreliable and most corporate systems suppress them.

Is it acceptable to call a customer's switchboard to find their accounts payable team?

Yes, and it is one of the fastest routes available. Switchboards exist to direct callers, and asking for the correct address for invoice submission is a routine request that receptionists handle daily. Ask for both a shared alias and a named person, and confirm the spelling before you hang up. Note the date you verified it on the customer record so the next person does not repeat the call.

What if the customer has no accounts payable department?

Smaller businesses often route invoices to an office manager, a bookkeeper, an external accountant or the founder. Ask who handles supplier payments and whether they use an accounting platform such as QuickBooks that accepts invoices at a dedicated address. Confirm the route in writing once, since these arrangements change more often than at larger companies. Copying a second person is a reasonable precaution where one individual handles everything.

Should I resend the original invoice or issue a new one?

Resend the original wherever you can, because reissuing changes the invoice number and can restart approval workflows the buyer may already have started. Send the same PDF with a covering note explaining the delivery failure and the new contact. Reissue only where the contract sets a submission deadline the original has missed, or where the buyer's system will not accept a document of that age. In either case, agree the approach with them before changing anything.

Can I ask for payment terms to run from the resend date?

Usually yes, and most contracts already say so, since terms typically run from receipt of a valid invoice rather than from the date you raised it. Raise it in your first message to the new contact rather than after a disagreement about ageing. Quote the payment clause if you have it to hand. Buyers who have received nothing tend to accept this readily, because the alternative is a debate neither side benefits from.

How often should I re-verify accounts payable contacts?

At least once a year for every active customer, and at contract renewal, which is when entity names, portals and finance staff most often change. Verify the twenty accounts that make up most of your receivables every quarter. A verification is quick: confirm the alias, the named person and the submission route, then record the date. Treat any bounce or unacknowledged invoice as a prompt to verify immediately.

What should I do if the buyer's portal login is also broken?

Contact the portal's supplier support rather than the buyer first, since access issues are usually resolved by the platform's own team and they handle them constantly. Have your supplier identifier, the buyer's name and the invoice numbers ready. Tell your customer's procurement contact in parallel, because they can reinstate access from their side where an account has been deactivated. Keep a record of the ticket reference to explain any delay in submission.