Customer Says the Invoice Was Not Received: What to Do

When a customer says they never received the invoice, treat it as a delivery question before a payment question. Pull your send record, confirm which route their accounts payable process expects, and re-deliver on that route with the original invoice number intact. At Monk we see these resolve to one of four causes: the invoice went to a named individual who left or is on leave, the message was filtered before anyone opened it, the invoice needed to go through an AP portal instead of an inbox, or it arrived and was rejected without anyone telling you.
Why do customers say they never received an invoice?
The claim is usually accurate from where the customer sits. Someone in AP searched their system, found nothing, and told you so. The invoice still exists somewhere, and the useful work is finding out where it stopped.
Four causes cover most cases:
- The invoice went to a person rather than a process. The named contact left, changed roles, or is on leave, and their mailbox is not part of the AP intake path.
- The message was filtered. Missing SPF, DKIM or DMARC records, an aggressive subject line, or a large batch send can put a legitimate reminder into quarantine.
- The invoice belonged in a portal. The buyer requires supplier invoices through Coupa, Ariba or a similar system, and an emailed PDF is outside their intake process entirely.
- It arrived and was rejected. The portal or the AP system rejected it on a PO mismatch, a duplicate number or a missing field, and the rejection notice never reached anyone on your side.
The fourth one is the expensive case, because the invoice looks sent in your ledger while nothing is moving on theirs. We wrote about the mechanics of that in why AP portals reject your invoices.
What do you do when a customer says the invoice was not received?
The sequence below takes the claim from first reply to a confirmed delivery route, without creating duplicate invoices along the way.
- Pull the send record before you reply. Find the exact timestamp, recipient address, invoice number and attachment name for the original send, and check whether the message bounced or was accepted by the receiving server. An accepted message with no bounce tells you the invoice reached the customer's mail infrastructure, which changes the conversation from "did you send it" to "where did it land."
- Ask which route their AP process expects. Send one short question to the AP contact: should this invoice arrive by email to a shared alias, or be submitted through a portal such as Coupa or Ariba? Around 92% of enterprise invoices have to be submitted through a customer AP portal rather than paid from an emailed invoice, so an emailed PDF at a large buyer is frequently a non-event on their side.
- Search the portal before you accept that nothing arrived. If the customer runs a supplier portal, log in and search by invoice number, PO number and amount. An invoice can sit in submitted status for weeks without reaching an approver, and the portal is the only place that state is visible.
- Have the customer check spam, quarantine and their shared AP mailbox. Ask them to search their quarantine and the accounts payable alias for your invoice number rather than your sender name, because filtered mail often keeps the subject line intact. If the message is sitting in quarantine, ask them to allow your sending domain so the next twelve invoices do not repeat the same trip.
- Re-deliver on the confirmed route and keep the original invoice number. Send the same invoice number and the same dated document through whichever channel the customer named. Issuing a fresh invoice number creates a second open item in their system and gives their AP team a duplicate-invoice reason to reject both.
- Get written acknowledgment and an expected pay date. Ask for a one-line reply confirming the invoice is in their system, along with the internal reference number and the payment run it is scheduled for. That reference is what you quote in every follow-up, and it turns the next reminder into a status check on a known item.
- Fix the delivery route on the customer record. Update the billing contact, the AP alias and the submission channel on the account so the next invoice goes out correctly the first time. If the failure was a departed employee, add the shared AP alias as the primary recipient and keep the individual as a copy.
Which delivery route applies to this customer?
Before you re-send anything, decide which of these four routes the account uses. Each fails differently, and each has a different confirmation signal.
| Delivery route | How you confirm it landed | Common failure | First thing to check |
|---|---|---|---|
| Email to a named person | A reply from that person | The person left, is on leave, or never forwards to AP | Whether the address still resolves, and whether a shared AP alias exists |
| Email to a shared AP alias | An auto-acknowledgment with a ticket or reference number | Spam filtering, attachment size limits, or an intake rule that drops non-PDF files | Authentication on your sending domain and the quarantine on theirs |
| AP portal submission | A submission receipt and a status that advances past "submitted" | Validation rejection on PO number, line items or required fields | The invoice status inside the portal, searched by invoice and PO number |
| EDI or an e-invoicing network | A functional acknowledgment from the network | A mapping change on the buyer's side that silently fails the transaction | The acknowledgment log for that transaction set |
Most disputes about missing invoices are a mismatch between the route you used and the route the buyer's process reads. Confirming the route once per account removes the argument permanently.
What proof of delivery should you keep?
Keep enough evidence to answer the question in one message rather than a thread. For every invoice you want the send timestamp, the recipient address, the invoice number, the document itself as sent, and whatever receipt the channel produced.
For email that means the accepted-delivery record and any auto-acknowledgment. For a portal it means the submission confirmation and the status history, which is stronger evidence than anything email produces. Store all of it against the invoice rather than in a personal mailbox, because the colleague covering the account next month needs the same answer.
How do you stop this from recurring?
Treat the first occurrence as a data problem on the account. A customer who says the invoice never arrived will say it again next quarter unless the contact, the alias and the submission route are corrected on the record.
Three changes remove most repeats. Send to a shared AP alias with the individual copied, so a departure does not break delivery. Authenticate your sending domain so filters stop treating your reminders as suspicious, which we cover in email deliverability for collections. And for any buyer that runs a portal, submit through the portal and track the status there, because an invoice that stalls in a portal produces exactly this conversation. Our guide on how to tell if an invoice is stuck in an AP portal covers the diagnostic steps.
How we handle invoice delivery at Monk
We built Monk so that delivery state lives on the invoice rather than in someone's sent folder. Invoices go out on the route each customer requires, portal submissions are filed and tracked, and the current state of every invoice is visible without logging into four systems.
Monk files invoices into 600-plus AP portals, roughly 87% of them autonomously, with Coupa and Ariba the two our customers use most. Intelligent Collections then follows up on what remains open, ingesting the context of customer conversations and responding more effectively than standard dunning, which produces about 24% higher response than standard dunning across our base. More than $2B in receivables run on Monk today, and customers see a 40% average DSO reduction. Around 39% of cash-flow slowdowns come from predictable recurring exceptions like this one, which is why we treat delivery as something to instrument rather than chase.
Frequently asked questions
What should I say when a customer claims they never received an invoice?
Answer with facts and a question. Confirm the date, recipient address and invoice number you sent to, then ask which route their AP process expects for supplier invoices. That reply resolves the delivery question in one exchange instead of three.
Is an email send record proof that the invoice was delivered?
It is proof of send and, if the receiving server accepted the message, proof of delivery to their mail system. It is not proof anyone read it or that AP logged it. For enterprise buyers, the record that counts is the portal submission receipt.
Should I issue a new invoice number when I resend?
No. Resend the same invoice number and the same document date. A new number creates a second open item on the customer's side and gives their AP system grounds to flag both as duplicates.
How long should I wait before re-sending an unpaid invoice?
Confirm receipt within a few days of issue rather than waiting for the due date to pass. Waiting until an invoice is thirty days late means you spend the first two weeks of collections proving the invoice exists.
Why do invoices sent by email disappear at large companies?
Large buyers route supplier invoices through an AP portal or a shared intake address, and mail sent to an individual often falls outside that process. Authentication problems and content filters remove another share of messages before a person sees them.
Can invoice delivery be automated so this stops happening?
Yes. Monk files invoices into 600-plus AP portals, roughly 87% of them autonomously, and keeps the submission state on the invoice record so the AR team can see where each one stopped. Coupa and Ariba are the portals our customers use most.



.avif)