Reading bounce codes on invoice and statement e-mails

How a SaaS business reads the bounce code when an e-mailed invoice or statement comes back undelivered, and how to fix the cause and resend.

By Achekam · 11 October 2026 · 4 min read · For Software (SaaS) businesses in South Africa, Nigeria, Kenya

A customer's account is sixty days overdue. When the finance team finally phones, the customer's accounts payable clerk says, quite reasonably, that they never received an invoice. A search of the shared billing mailbox turns up the answer: every invoice for the last two months bounced, and the bounce messages sat unread among newsletters and out-of-office replies.

E-mail is how many SaaS businesses deliver invoices, statements and reminders, and it fails more quietly than a returned letter. The failure message is there, but only if someone reads it, and it is written in a code that looks like gibberish. This article explains how to read that code, what the common ones mean, and a routine for fixing the customer's billing contact.

What a bounce message is

Microsoft explains that when an e-mail cannot be delivered, Microsoft 365 typically sends the sender a delivery status notification, also called a bounce message. Most commonly this is a nondelivery report, which gives an error code, the reason, suggested fixes and technical details for administrators.

Other mail systems word their bounces differently, but they often carry the same kind of code. The important point is where the bounce goes: back to the sender. Whoever looks after the address your invoices are sent from is the person who will see it.

Permanent and temporary: the first digit

Microsoft explains that the enhanced status codes in a bounce message are defined in RFC 3463. A code starting with 5, written 5.x.x, means a permanent error. A code starting with 4, written 4.x.x, means a temporary error.

That first digit tells you what to do next:

Resending a 5.x.x failure unchanged achieves nothing except another bounce.

The usual culprits on billing e-mails

Microsoft's guide covers many codes. A handful come up again and again on billing e-mails.

5.1.1, bad destination mailbox address. Microsoft says this typically means the sender typed the recipient's address incorrectly, or the address no longer exists, so the sender should check the address and send again. On billing e-mails, the classic cause is a customer's accounts clerk who has left, taking their mailbox with them.

5.7.12 and 5.7.134, external mail rejected. Microsoft explains that these mean the recipient's address is set up to reject messages from outside its organisation, and only an e-mail administrator at the recipient's organisation can change that. Some companies set up an internal-only mailbox for accounts payable and forget that suppliers need to reach it.

5.7.1, delivery not authorised. Microsoft says this often occurs when a sender writes to a distribution group that only accepts messages from its members or other authorised senders, and the sender must ask for permission to send to it. A shared "finance@" group address is a typical example.

4.4.7, message expired. Microsoft says this means the sending server could not deliver the message before it expired, and usually points to a problem on the receiving server, so the recipient's address and the receiving server's configuration should be checked.

Microsoft's article on nondelivery reports and SMTP errors explains what each code means and how to fix the usual causes.

What Achekam tells you about a send

Achekam reports on its side of the send. An issued invoice can be downloaded as a PDF on the business's letterhead and e-mailed from the invoice, with or without a pay link, and a failed send is reported as not sent. The server produces a customer statement of account as a PDF that can be e-mailed, and the screen says whether it was sent. Credit control, which is on for new workspaces, e-mails overdue reminders and a monthly statement once a day to customers with a balance, and records whether each e-mail went out; it needs working e-mail settings.

There are therefore two different failures to watch for:

1. The send failed. Achekam shows the invoice, statement or reminder as not sent. Check the business's e-mail settings and the customer's address on file, then send again.
2. The message left, but bounced later. Achekam's record is about whether the e-mail went out; a bounce that arrives afterwards comes back to the sending mailbox, so only someone reading that mailbox will know.

Both need a person to act. When a dispute about whether an invoice was received does arise, see invoice delivery evidence.

A routine for billing bounces

1. Watch the sending mailbox. Set a rule that moves anything that looks like a bounce into a folder someone checks daily.
2. Read the code. Note whether it is permanent or temporary, and which of the culprits above it matches.
3. Fix the cause at the source. For 5.1.1, ask the customer for a current billing contact. For 5.7.12, 5.7.134 or 5.7.1, ask the customer's IT administrator to allow your address, or to give you a different one. For 4.4.7, check the address and wait before retrying.
4. Update the customer's record, so the next invoice goes to the right place.
5. Resend the invoice or statement, and note the date.
6. Look for others. One bounce may mean every e-mail to that customer is failing, including reminders.

For customers abroad, whose mail systems you know less about, the same routine applies; see billing overseas customers.

Search the billing mailbox today for bounce messages from the last three months, list each customer they relate to, and update their billing contacts before the next invoice run.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.