The invoice says sent, but the customer never received it

A sent label can mean that the application queued an email, that an email provider accepted the request, or that a recipient's mail server accepted the message. Those are different points in the delivery process. Ask the application owner which event creates the label. Keep the invoice's financial status separate from its communication status. A valid open invoice can exist even when its email never reached the intended accounts-payable contact.

Amazon SES provides a concrete example of this distinction: its send event means the request succeeded and delivery will be attempted, while its delivery event means the recipient's mail server accepted the email. Its event model also identifies bounces, delays and rendering failures. Other providers use their own definitions. Read the documentation for the service actually sending your invoices, then map its events to the labels shown in the billing application.

Start with the invoice identifier, intended recipient, attempted send time and message identifier. Confirm that the recipient belongs to the correct customer and is the approved billing contact. A delivery event for the wrong address does not resolve the complaint. Check whether the message was the original invoice, a reminder, a receipt or a corrected document. Several communications about the same invoice can otherwise be mistaken for evidence that the original reached the customer.

Ask the technical owner for the relevant delivery history rather than a full mailbox export. Identify whether the message remained queued, failed to render, was rejected, bounced or reached the recipient's server. Preserve the reason code and time where available. Avoid forwarding logs that contain reusable links, authentication material or unrelated customer details. A narrow event record is usually enough for finance to decide which operational follow-up is needed.

If the provider shows server acceptance, coordinate with the customer's authorized contact to check their mail routing or quarantine process. Provide the sender address, approximate time and subject without asking for the customer's credentials. Server acceptance does not prove that a particular employee read or approved the invoice. Keep the investigation factual and avoid using a tracking event as an accusation that the customer is denying something they necessarily saw.

For an invalid or obsolete billing address, verify the replacement through an established customer contact or agreed update process. A request from an unfamiliar address to redirect invoices can expose confidential information or divert future payment discussions. Update the appropriate master record and record the authorization. Check whether existing invoices and future reminders use that updated record or retain an earlier recipient, because application behavior can differ by document state.

For a temporary delivery issue, follow the sending service's supported retry behavior. Repeated manual sends can create several copies without fixing the underlying problem. For a template failure, reproduce and repair the missing data or rendering defect through the application owner. For a suppression or complaint status, investigate the reason and the service's rules before overriding anything. The finance team's goal is reliable transactional delivery through an approved route, not simply a larger count of send attempts.

An illustrative queue contains 40 invoice emails. The provider reports 34 accepted by recipient servers, three permanent failures caused by invalid recipient addresses, two still delayed and one rendering failure. The business cannot truthfully describe all 40 as delivered. Route the three address failures for contact verification, let the technical owner assess the delayed messages, and repair the template for the failed render. Keep the 34 accepted messages available for customer-specific follow-up if receipt is still disputed.

Before resending, confirm that the invoice remains the valid current document and that its balance reflects payments or credits already processed. A customer who paid after the first attempt should not receive an unqualified demand for the original amount. Use the application's supported resend or approved delivery route, preserving the invoice reference. Do not create a new invoice merely to trigger another email unless a legitimate correction process requires a replacement.

If a secure customer portal is an agreed alternative, confirm that the authorized contact can access the right invoice there. Avoid publishing a private payment link in a broadly visible channel. Record the route and outcome in the customer account so another collector does not repeat the investigation. Where the customer requires a specific procurement portal or electronic delivery process, resolve that requirement with the account owner instead of treating ordinary email as automatically sufficient.

Payment terms and collection decisions need their own review. A delivery failure may affect the commercial discussion, but the accounting team should not invent a revised due date or legal consequence without authority. Ask the responsible owner to evaluate the contract and circumstances. Record any agreed concession or extension separately from the technical delivery repair so the balance and collection schedule remain understandable.

Create an exception view that connects delivery failures to invoice identifiers, amounts and responsible contacts. Prioritize unresolved high-value or time-sensitive items without treating every temporary delay as a permanent failure. Reconcile the view to the sending service and define who clears each exception. A generic technical alert can be missed by finance unless it identifies the invoice whose collection process is affected.

Review recurring causes such as obsolete billing contacts, missing template fields or a broken notification connection. Verify the repaired process with a controlled test and the next affected real invoice. Keep evidence that the exception was resolved, not just that someone pressed resend. Reliable billing communication requires a traceable document, a verified recipient and a known delivery outcome, alongside the separate evidence of the customer's actual payment.