Customer Says the Invoice Was Not Received

Treat "we never received it" as a delivery question before a payment question: pull your send evidence, work out which of five failures happened, then re-deliver on the route their process reads rather than sending the same PDF to the same address. Monk runs invoice to cash as one system, covering invoice delivery, AP portal submission, cash application and collections, so the delivery state of an invoice lives on the invoice record instead of in somebody's sent folder. The customer is usually telling the truth as they see it. Someone searched their system, found nothing, and said so. Your invoice still exists somewhere, and the useful work is finding out precisely where it stopped.

The cost of getting this wrong is a second cycle. A resend that repeats the original mistake buys you another two or three weeks of ageing, another awkward call, and a customer who now believes your billing is unreliable. The diagnostic below takes about fifteen minutes per invoice and removes the argument permanently on that account.

What are the five reasons behind "we never received it"?

Five failures cover almost all of it, and they are ranked below by how often they turn up at enterprise buyers.

The first one dominates at large customers, because 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice. An emailed PDF at a buyer of that size is often a non-event on their side: no rejection, no acknowledgement, no record. Both parties are describing the same reality accurately and neither has said anything useful yet.

The last one is the expensive case and the hardest to see. The invoice reached their system, was rejected on a validation rule or parked in a draft state, and no notice reached you. From your ledger it looks identical to a customer who is behind on payments, which is covered in why AP portals reject your invoices.

How do you tell a dead mailbox from a filter from a wrong entity?

Read your own transport evidence first, because each of the five failures leaves a different fingerprint before you have to ask the customer anything.

A hard bounce, typically a 550 response naming the recipient as unknown, means the mailbox no longer exists and every reminder since that date went nowhere. Silence with no bounce at all means their server accepted the message, which rules out a dead address and points at filtering, misrouting or an unread shared inbox. An out-of-office followed by permanent silence usually means a departure that was never tidied up. Check whether other mail to the same domain is producing replies, since a domain-wide reputation problem looks like one dead contact until you compare accounts.

Then ask the customer two precise questions rather than one vague one. Ask them to search quarantine and the accounts payable mailbox for the invoice number rather than for your company name, because filtered mail usually keeps the subject line and staff usually search the sender. Ask which legal entity raised the purchase order, since multi-entity buyers route invoices by entity code through a shared service centre and an invoice addressed to the trading group is unprocessable at the subsidiary.

Finally, search the portal yourself before accepting that nothing arrived. Look by invoice number, by PO number, by amount and by date range, and check the draft or saved state as well as submitted. An invoice half-created and never submitted has no status and generates no notification, and the diagnostic steps for that are in how to tell if an invoice is stuck in an AP portal.

Why is "I sent it" not proof of delivery?

Because it is a statement about your outbox, and the only evidence that settles a payment-terms argument is a reference number generated inside the customer's system.

There is a clear hierarchy here and it is worth knowing where each of your accounts sits on it. A PDF in your sent folder proves you composed something. An SMTP transaction log showing the timestamp, recipient, message ID and the receiving server's acceptance response proves the message reached their mail infrastructure, which is a useful fact and still not proof that AP holds the invoice. An automated acknowledgement carrying a ticket or reference number is better, because it proves their intake process ingested the document.

Strongest of all is a portal submission receipt with an invoice ID and a visible status history, or a functional acknowledgement from an e-invoicing network. Both are generated by the buyer, both carry a reference you can quote in every subsequent message, and both convert the conversation from "did you send it" into "invoice 4471 has been at pending approval since the ninth." Read receipts and tracking pixels are not evidence, are stripped by most corporate mail systems, and should not appear in the discussion.

Keep five things on the invoice record for every send: the timestamp, the recipient address or portal, a copy of the document exactly as it went, the acknowledgement artefact, and the buyer's own reference number once you have it. Store them against the invoice rather than in a personal mailbox, because the colleague covering that account next month needs the same answer in one message.

What should change on the resend?

Everything except the invoice number and the invoice date, because resending an identical document down an identical route reproduces the original failure exactly.

Change the route first. If the account requires a portal or a network, submit there and stop emailing. If email is correct, send to the shared AP alias with the individual copied rather than the other way round, so a departure never breaks delivery again. Change the packaging next. Many intake systems parse the subject line and filename, and some reject anything that is not a single PDF under a size limit. Ask AP what their intake expects, then follow it precisely: a filename carrying the invoice and PO number is a small courtesy that keeps an automated indexer from misfiling you.

Change the content of the covering message too. Put the buyer's vendor number, the purchase order number, the legal entity and the invoice total in the body where a human or an intake bot can read them without opening an attachment. Strip out statement lines, dunning language and thread history, since a long chasing email to a busy AP clerk gets deferred and sometimes gets classified as correspondence rather than as an invoice.

What must not change is the invoice number and the document date. Issuing a fresh number creates a second open item on the customer's ledger, gives their duplicate-detection rule grounds to reject both, and makes your own cash application harder when a payment eventually lands. Where the original was rejected rather than lost, fix the named rejection reason before resubmitting, or you will collect a second rejection and a duplicate flag together.

Should you reset the payment clock, and how do you ask?

That depends on whether you can prove the invoice reached their system, and it is a negotiation rather than a rule.

Most contracts start payment terms from receipt of a valid invoice, which means a genuine non-delivery restarts the clock and a provable delivery does not. Your position follows directly from the evidence you hold. With a portal receipt or an acknowledgement reference, ask them to honour the original due date and quote the reference in the request. With nothing but a sent folder and a route that turned out to be wrong, accept the reset gracefully and spend the goodwill on getting a firm payment run date in writing instead.

There is a middle position worth using more often. Rather than arguing over thirty days, ask for the invoice to be included in the next scheduled payment run instead of the one after it. That is a small ask for an AP manager, it usually saves two to three weeks, and it does not require anyone to admit fault. If the clerk cannot commit, the AP manager can, and asking the clerk who has authority to approve an exception is a normal question rather than an escalation.

Do the arithmetic before you decide how hard to push. A thirty-day reset on a large balance carries a real financing cost for the rest of the year, and on a small one it costs more in relationship capital than it recovers. Whichever way it lands, get the agreed date in writing, note it on the invoice record, and diary a check two days before it.

How do you make sure this customer never says it again?

Fix three things on the account record, and none of them are about writing better reminder emails.

First, establish a verified AP contact of record. During onboarding, and then annually, get the customer to confirm in writing the exact intake route for supplier invoices: portal name, network identifier, or shared alias, plus the legal entity, the vendor number and any required references. Store it on the account rather than in a contract PDF nobody opens. Where the customer runs a portal, keep a register of the portal, the login owner, the submission rules and the deadlines.

Second, make delivery confirmation a required step rather than a nicety. An invoice is not sent until an artefact exists proving something on the buyer's side received it. Build a simple exception report of invoices with no delivery artefact after two business days, and work that list before any of them are due, since a rejection found on day two is fixable and the same rejection found on day thirty-five is an ageing problem.

Third, protect the channel itself. Authenticate your sending domain so filters stop treating invoices as suspicious, and keep transactional invoice delivery separate from bulk collections sending so a reputation issue in one does not silence the other. That is covered in email deliverability for collections. Submitting three or four days ahead of the due date gives every one of these failures room to be caught while the invoice is still current.

How does Monk handle this?

Monk keeps delivery state on the invoice, so an invoice that never reached the buyer's system looks different from one that did and has not been paid.

Invoices go out on the route each customer requires, portal submissions are filed and the response is brought back onto the record, and the current state of every invoice is visible without logging into four systems. Because 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice, that submission step is where most of this problem lives, and around 39% of cash flow slowdown is caused by edge cases of this kind.

Julia, Monk's AI agent for Intelligent Collections, ingests the context of the conversation and earns a 24% higher response rate than standard dunning, with 90% of collections resolved with zero human intervention. AI cash application matches 80% of receipts automatically, rising to 95% with suggested matching rules. Across $2B+ in receivables under management customers see a 40% average reduction in DSO and save 26 hours a month on receivables work. Monk is SOC 2 Type II compliant, integrates with QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, and onboarding takes less than one week. Monk files invoices into 600-plus AP portals, roughly 87% of them autonomously, with Coupa and Ariba the two our customers use most.

Where should you start?

Pick your twenty largest open invoices and ask one question of each: what artefact proves the buyer's system holds this document?

For every invoice, write down the route it went out on, the acknowledgement or receipt you hold, and the buyer's own reference number. Anything with no artefact is an invoice you cannot prove was delivered, and those are the ones that generate this conversation. You will typically find they cluster on two or three accounts where the intake route was never confirmed.

Then confirm the intake route in writing with each of those customers this week, before the next billing run rather than after the next dispute. To see delivery evidence, portal submission and collections follow-up sitting on the same invoice record, book a demo.

Frequently Asked Questions

What should I say when a customer claims they never received an invoice?

Reply with facts and one question. State the date, the recipient address or portal, and the invoice number you sent, then ask which route their AP process requires for supplier invoices. That single exchange usually identifies the failure, and it avoids an argument about whether your billing team did their job. Avoid promising a resend until you know the route.

Is an email send record proof that the invoice was delivered?

It proves the message reached their mail infrastructure if the receiving server accepted it, which is useful and limited. It does not prove a person read it or that accounts payable logged it. For enterprise buyers the record that settles a terms argument is a portal submission receipt or an acknowledgement carrying their own reference number.

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 their ledger, gives their duplicate-detection rule grounds to reject both, and makes cash application harder when payment arrives. Change the route, the recipient and the packaging instead.

Does the payment clock restart when I resend?

Usually yes, since most contracts run terms from receipt of a valid invoice. Where you hold a portal receipt or an acknowledgement reference, ask them to honour the original due date and quote it. Where you cannot prove delivery, ask instead for inclusion in the next scheduled payment run, which is an easier concession for an AP manager to grant.

Why do emailed invoices disappear at large companies?

Large buyers route supplier invoices through a portal, a network or a shared intake address administered by a service centre, so mail sent to an individual sits outside the process entirely. Mail filtering, attachment rules and departed contacts remove another share. None of these produce a bounce, which is why the invoice looks sent on your side and absent on theirs.

How soon should I confirm an invoice was received?

Within two business days of sending, rather than waiting for the due date. A rejection or a misroute found on day two is a same-week fix. The same failure found on day thirty-five means you spend the first fortnight of collections proving the invoice exists before anyone discusses paying it.

Can invoice delivery be tracked automatically?

Yes, and the useful version tracks the buyer's state rather than yours. Record the route, the submission receipt, the portal status and the buyer's reference on the invoice itself, then report on invoices holding no delivery artefact. That turns a recurring dispute into a short exception list somebody works each morning.