Direct answer

'Never got it' ends when the sending is on the record, not in your memory.

'Never got it' is three different claims wearing one coat. Here is how to separate sent from received from read, the proof stack to assemble for the invoice in dispute, the exact resend message that attaches the record instead of arguing, and the one-time setup that makes the dispute impossible on the next job.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 21, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on publication day.

Sent, received, and read are three different facts

Most invoice arguments collapse three separate events into one word, delivered, and then argue about all three at once. Separate them and the argument mostly dissolves. Sent means the invoice left your system, addressed to the client, at a recorded time. Received means it arrived in the client's system: their inbox, their accounts payable portal, their mail room software. Read means a person opened it and took it in. You can prove the first with your own records. You can usually evidence the second through the receiving system's records or the client's own reply. The third you can almost never prove, and you do not need to: an invoice is payable because the work was accepted and the bill was sent to the right place, not because someone's eyes crossed it. When a client says they never received your invoice, answer the provable layers, in order, and do not let the conversation drift into the unprovable one.

The sent-proof stack: what to gather for this invoice, now

Build the stack from what already exists before you write a single word to the client. First, the sent copy itself: the invoice exactly as sent, same number, same date, same amount, saved with the message that carried it. A retyped invoice is a new claim; the original file with its timestamp is evidence. Second, the sending record: the sent-folder entry, the invoicing tool's send log, or the portal's submission receipt, showing the address it went to and when. Check that address character by character against the address the client gave you, because a real share of these disputes are one wrong letter in an accounts payable address. Third, any thread around it: the delivery message for the work itself, the client's reply to anything sent the same day, any out-of-office or ticket number their system returned. Fourth, the work's own acceptance state, if you have one: an invoice attached to accepted work is much harder to wave away than an invoice floating on its own. Gather all four before you resend anything, because the resend message below is built out of them.

The strong move: one record for the work, the invoice, and the acceptance

The weak position is an invoice sent as a loose attachment into someone's inbox, where its whole existence depends on that inbox. The strong position is the invoice riding on the work's delivery record: the finished work, the steps that produced it, the client's acceptance decision, and the invoice for that work, all behind one checkable link. Then "we never received it" has a factual answer that is not your word against theirs: the record shows when the work was saved, what the client decided about it, and when, and the invoice sits on that same record. The two public records below show the shape. One is accepted, with the client's decision recorded on it. One is still pending, which is also a documented state, not a missing one.

Accepted: this stage is a settled fact, not a claim

Still open: delivered, checked, and waiting on the client

Notice what the accepted record settles for an invoice dispute: the client recorded a decision on this work, on a date, marked ok_to_release. A client who decided on the work cannot easily also claim the job's paperwork never reached them. And the pending record settles the opposite case just as usefully: if the invoice is unpaid because the decision is still open, the record says so plainly, and the conversation becomes about the decision, not about inboxes.

The resend message, word for word

Resend once, with the record attached, and without arguing. Arguing about whether they received the first copy invites a debate you cannot win and do not need. The message that works states the original send as a fact, attaches the proof, and asks for one small confirmation:

"Resending invoice [number] for [the work], first sent on [date] to [address]. The invoice is unchanged: same number, same amount, same due terms counted from the original send date. It is attached here, and it also sits on the delivery record for the work itself: [record link]. That record shows the work, the date it was saved, and your acceptance on [date]. Please reply to this message to confirm it is with you now, and tell me the payment date I should expect. If your system needs the invoice in a different format or through your portal, send me the route and I will file it there today, and keep this copy as the dated original."

Three details do the work in that message. The invoice is unchanged, so nobody can claim the resend quietly moved the amount or the date. The record link moves the proof out of the inbox entirely: even if this email also vanishes, the link is the invoice's home. And the ask is a reply confirming receipt, which converts this send into a received fact in the client's own words. If they reply about anything else in that thread, receipt is settled by their reply's existence. If they do not reply, send the same package through a second channel, a portal upload or a different named contact, and keep that send record too.

Set it up once so it never happens again

For the next job, make the invoice's sending a recorded event instead of an email you hope landed. Agree the billing address and the accounts contact by name before work starts, in the same message that agrees the price. Deliver the work on a record and put the invoice on that record at delivery, so the invoice's date is the delivery date and its existence never depends on one inbox. Ask for a receipt confirmation as a standing step, the same way you ask for acceptance of the work: a one-line reply is enough, and clients who pay normally do it without thinking. And keep your sent copies with their timestamps as a habit, filed per job, so the stack above takes ten minutes to assemble instead of an evening of digging. None of this accuses any client of anything. It treats "never got it" as what it usually is, an inbox problem, and removes the inbox from the chain.

What this page does not settle

An invoice can genuinely go astray: spam filters, staff changes, a closed mailbox, a portal that silently rejects a file. Nothing here assumes bad faith, and the first occurrence should be handled as a systems problem, exactly as the resend message above does. Contract terms, late-payment rules, and formal debt routes differ by place and by what you signed, and this page is general information, not legal advice. On the records themselves, be precise: a verifiable receipt proves the saved result was not changed since it was saved, and a delivery record proves the invoice was sent and saved at the time it shows. Neither proves that a person opened or read the invoice, and Zambo never holds your money or the client's.

Frequently asked questions

My client says they never received my invoice. How do I prove I sent it?

Start with what your sending system kept, not with your memory. The core proof is the sent copy itself, the invoice exactly as sent with the message that carried it, plus the sending record that shows the address it went to and the time: a sent-folder entry, an invoicing tool's send log, or a portal submission receipt. Check that address against the address the client gave you, because one wrong letter is a common honest cause. Then strengthen it with context: the thread the invoice travelled in, and the work's own delivery record if you have one, because an invoice attached to accepted work is far harder to wave away. What this stack proves is sent, and usually received by their system. It does not prove a person read it, and it does not need to: payment turns on the work being accepted and the bill being properly sent, not on anyone's reading habits.

Does an opened email or a read receipt prove they got the invoice?

No, and the absence of one proves nothing either. Read receipts can be declined by the reader or blocked by their mail system, and open tracking relies on image loading that many inboxes suppress, so a genuine invoice can show as unopened and a skimmed one can show as read. Treat opens and read receipts as hints, never as evidence, in either direction. The records that carry weight are the boring ones: the send log with its timestamp and address, the portal's submission confirmation, and best of all the client's own reply in the thread, which settles receipt in their own words. Build your case and your resend on those, and if a client leans on a missing read receipt, answer with the send record and the delivery record link instead of debating tracking pixels.

What exactly should I send when I resend the invoice?

Send a package, not just the file again. It has four parts: the original invoice unchanged, same number, same date, same amount, because an altered resend restarts arguments; a one-line note of the original send, the date, the method, and the address it went to; the delivery record link for the work, where the invoice also lives, so its existence no longer depends on any inbox; and a single clear ask, a reply confirming receipt plus the payment date to expect. The wording on this page is ready to copy. Send it once in the original thread so the history stays together. If there is no reply within your normal payment window, send the identical package through a second channel, such as their portal or a named accounts contact, and keep that send record too. Identical, dated, and boring beats indignant every time.

What if the invoice really did land in spam or go to the wrong address?

It happens, and the first time it happens with a client, treat it as the systems problem it probably is. Confirm the exact billing address and a named accounts contact, ask them to check spam and any portal the invoice should have gone through, and resend to the confirmed address with a request for a one-line receipt confirmation. Then fix the route permanently: note the confirmed address on the client's record, and from the next invoice on, deliver the invoice on the work's delivery record as well as by email, so a filter can delay a copy but cannot erase the invoice. Where the pattern repeats with the same client across several invoices, the problem is no longer spam, it is process on their side or delay as a tactic on yours to price in, and the answer is the same either way: dated records for every send, and payment terms that run from the recorded send date.

How do I make 'never received it' impossible on the next job?

Deliver the work and its invoice on one record, so the invoice's send date is the delivery date and it lives behind a link, not inside an inbox. When the job runs through Zambo, the handover record carries the work step by step, the client's decision sits on it, accepted and ok_to_release, or still pending and hold, and the invoice rides on that same record: one link answers what was delivered, when it was saved, what the client decided, and what is owed. For $0.99, run the next job that way and let the record be the invoice's home: https://zambo.dev/day-pass/ A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related