A customer says the invoice never arrived. How to walk the delivery chain link by link, what server acceptance proves, and why reissuing comes last.
Key takeaways
- The document and the message are two objects. A document that exists but was never sent, and one that was sent but never arrived, require opposite actions.
- Per RFC 5321, a server that returned a success reply at the end of the mail data has taken on responsibility to deliver the message or to properly report the failure. It may not silently discard it.
- A rejection code starting with 4 is temporary and a later attempt may succeed; one starting with 5 is permanent and will not change on a retry of the same message.
- The most common failure produces no bounce at all: the message is accepted, fails sender authentication, and is filtered into a junk folder where nobody looks.
- Resending the same file is not the same operation as issuing a new document, and your system has to distinguish them at the code level.
"I never got the invoice" is a report about the message, not about the document. Those are two separate objects with separate identifiers and separate lifecycles, and the first check is which one is actually missing. Issuing a second document before you know that turns a temporary delivery problem into a permanent accounting one.
Two objects, not one
A document produced by your invoicing system exists from the moment it is created, carries its own document number, and in Israel may also carry an allocation number obtained from the Tax Authority. The message that carried it is a different object entirely: it has its own Message-ID header, its own identifier at your outbound mail provider, and its own delivery outcome. Keeping the two apart is what lets you answer the right question.
| The question | Where you check | What follows from the answer |
|---|---|---|
| Was the document produced at all | The invoicing system | If not, there is nothing to resend. There is something to issue |
| Was an outbound message created | Your own send log | If not, the fault is yours and not the customer's |
| Was the message accepted by the customer's server | The mail provider log, keyed by Message-ID | If yes, resending changes nothing |
| Did it reach an inbox somebody watches | Only the customer can answer | This is where your measurement ends |
| Was the document paid | The collections system | Payment proves receipt better than any log |
That last row is worth more than the others combined. If the document was paid, it arrived, and the entire investigation is moot.
What does the receiving server's acceptance actually prove?
It proves a transfer of responsibility. RFC 5321 states it directly: once the server has issued a success response at the end of the mail data, a formal handoff of responsibility occurs, and the protocol requires the server to accept responsibility for either delivering the message or properly reporting the failure to do so. An acceptance is therefore not "it probably arrived" - it is a defined point in the chain.
What it does not prove: that the message landed in the right mailbox, that anybody saw it, or that the attachment survived the receiving organisation's security gateway. Past the point of acceptance, your measurement stops.
When a message is rejected, the enhanced status codes in RFC 3463 tell you precisely what happened:
| Code | Documented meaning | What to do |
|---|---|---|
X.1.1 | The mailbox specified in the address does not exist | Fix the address. Resending to it is pointless |
X.1.2 | The destination system does not exist or cannot accept mail | Check the domain. Usually a typo |
X.2.2 | The mailbox is full, past an administrative quota or capacity | Temporary. Ask the customer to clear space |
X.7.1 | The sender is not authorised to send to the destination, message refused | Per-host or per-recipient filtering. This is where sender authentication gets fixed |
The class of the code sets the action: per RFC 3463, a code beginning with 4 indicates a temporary condition where sending in the future may succeed, while one beginning with 5 indicates a permanent failure that is not likely to be resolved by resending the message in its current form.
The silent failure: accepted, then filtered
This is the scenario that eats the most time, because it generates no event to search for. The message is accepted successfully, fails sender authentication, and the policy your domain publishes instructs the receiving server to quarantine it. The customer saw nothing, you got no bounce, and your log shows a clean delivery.
- The actual sending address differs from the domain your authentication records cover. An invoicing platform that sends on your behalf is a common source of that gap.
- A message sent from a personal address carrying an attachment with a document number looks to a filtering gateway exactly like a classic impersonation attempt.
- The customer's invoice mailbox is often a group address routed into a ticketing system, where the invoice is closed as a handled enquiry without anyone opening the file.
- An attachment that is too large, or of a blocked type, is stripped at the corporate gateway, and the message arrives without the one thing it existed to carry.
The infrastructure side of this - which authentication records to check and in what order - is covered in operating SPF, DKIM and DMARC against mail filtering.
Why not simply issue the invoice again?
Because reissuing creates a second document with a second document number, and in Israel a second allocation number where the document requires one, for a single transaction. The customer holds two documents, bookkeeping sees two records, and the reconciliation against the payment that eventually arrives is broken. That is a technical description of the operational consequence and not tax or accounting advice; the correction path for a document already issued is set by your accountant and by Tax Authority rules.
The distinction your system has to be able to make is between three quite different operations:
- Resending the same file to the same address. No new document, only another delivery attempt.
- Resending the same file to a different address. Still the same document, with the new address recorded.
- Issuing a new document. An accounting action, not a delivery action.
A system where one button performs all three is exactly why this problem keeps recurring. How the quote, order and invoice stay tied to one identifier across the whole chain is set out in the quote to order to invoice flow under a single identifier, and the requirements around allocation numbers are detailed in the invoice allocation number from a developer's perspective.
What to record so the next investigation takes two minutes
- The document number, and beside it the allocation number where the document carries one.
- The recipient address exactly as it was sent, including any stray whitespace that got saved with it.
- The
Message-IDheader, which is the only search key that works both in your provider's log and on the customer's side. - The full response line from the receiving server, not just "sent" or "failed".
- The attachment filename and size, so a strip at a corporate gateway can be identified.
- The number of sends of that document and the reason recorded for each of them.
- Who performed the resend and when, so the sequence of events can be reconstructed.
The first four are the difference between a two-minute investigation and a week-long argument. They cost a handful of columns in a table, and they earn their keep every time a customer says something did not arrive.
Sources
Frequently asked questions
Our log shows a successful delivery and the customer insists nothing arrived. Who is right?
Both of you. A successful delivery means the receiving server took responsibility for the message, not that it reached the mailbox the customer is looking at. Quarantine filtering, routing into a group mailbox, or a stripped attachment all produce exactly that gap, and all of them happen after your measurement point.
Is it better to resend the same file or to issue a new document?
Resend the same file, almost always. The document already exists and is valid, and the problem is in delivery. Issuing a new document adds a second accounting record for one transaction, and unwinding that is a conversation with your accountant rather than a technical fix.
How do I know the attachment was not stripped in transit?
Store the attachment filename and size on the send record and compare them against what the customer reports seeing. If the message arrived without the attachment, it is almost always a security gateway on the receiving side. Sending a secure link to the document instead of an attachment removes this class of failure entirely.
Should we add a read receipt so we know the invoice was opened?
A read receipt depends on the recipient's consent and settings, so its absence proves nothing. A far more reliable indicator is payment status: a document that has been paid was certainly received. Tracking payment state against the document is covered in [payment to invoice reconciliation automation](/blog/payment-to-invoice-automation-israel).
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.