When the validated PDF is e-mailed, to whom, from what address — and the three things that must exist first — transcript

Presentation 2 of 4 in Make the e-invoice PDF your customer receives look like yours · about 9 minutes · for the whole-system operator — you run the books.

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for the person who has ticked Send Email To Buyer and wants to know what that actually set in motion. In about nine minutes you will know the moment the e-mail goes and the two ways your tenant might send it, who it is addressed to and why that surprises people, the three things that have to exist before a single message leaves, and the one e-mail in this family that plays by different rules.

Step 1 — Know the moment it goes, and which path your tenant takes

After this step you will stop watching for the e-mail at the wrong time. It does not go at Finalise and it does not go at submission. It goes when the validation poller, the job that asks LHDN what became of a submitted document, reads back the word Valid. At that moment one of two things happens, and which one is a fact about your tenant rather than your company. If a schedule row for the printable e-mail processor has ever existed on your tenant, even a deleted one, the poller writes a queue row and a draft e-mail thread, and the processor sends later, ten at a time. If no such row has ever existed, the poller sends the e-mail itself, inline, before it moves to the next document. On that inline path there is no queue and nothing to watch, and a consolidated e-invoice is attempted too, which the queue path deliberately skips.

Reference: My E-Invoice Admin Applet — When the e-mail goes, and to whom

Step 2 — Know who receives it, and why it is not the customer record

After this step you will look in the right place for a wrong address. The recipient is the buyer’s e-mail on the e-invoice header, the buyer block exactly as it was submitted to LHDN, and not the e-mail on the customer record. The two often agree, because the buyer block was filled from the customer, but they are separate fields and only the header one is read. A blank there means nothing is sent, and it is blank on a substantial minority of validated e-invoices across the estate. For a purchase-side document, a self-billed invoice for instance, the recipient is the supplier’s e-mail instead. And a configuration flag can redirect every e-mail for a company to the entity branch’s address, which is how a group that wants one mailbox per customer branch gets it. If a customer asks why their colleague received it, that flag is the first suspect.

Reference: My E-Invoice Admin Applet — When the e-mail goes, and to whom

Step 3 — Know the three things that must exist, and which one is on a screen

After this step you will understand why ticking the box can do nothing. Three things must exist before a message is sent. First, the company’s Send Email To Buyer switch on the E-Invoice tab. Second, an e-mail identity for the company, held as a subscription under a webhook topic whose code names the printable e-mail; it carries the subject, the body, the sender address and the attachment’s file name. Third, a sender inside that subscription, because the whole send sits behind a check that the sender is not blank. Only the first is on a screen. No applet writes the other two, and the platform does not create them for a new tenant or a new company; BigLedger sets them up. A company with the switch on and no subscription is not refused. The send simply returns nothing done, writes nothing, and the row sits in the queue looking untouched.

Reference: My E-Invoice Admin Applet — What has to exist before anything is sent

Step 4 — Know where the words and the sending address come from

After this step you will know what to ask for and whom to ask. The subject line, the body text, the address the e-mail comes from, the attachment’s file name pattern and its date format are all read from that subscription. Change the wording and it changes for every e-mail the company sends from then on; there is no per-document editing. The message travels one of two ways. If the company has an SMTP configuration under the same code, BigLedger sends through your mail server and the e-mail comes from you in every sense; across the estate that is rare. Otherwise it goes through Amazon’s mail service from the sender in the subscription, or from the platform’s default address if none was given. So when a customer’s spam filter is the problem, the question is which of those two your company is on, and only your BigLedger contact can say.

Reference: My E-Invoice Admin Applet — What has to exist before anything is sent

Step 5 — Do not confuse it with the cancellation e-mail

After this step you will not explain one e-mail with the rules of the other. When a cancellation request is processed, a separate notification goes out, and it obeys none of the above. It is addressed to the same buyer e-mail on the header, it opens with Dear User, it comes from a custom sender if one is configured and otherwise from a no-reply address at the platform, it goes through the platform’s mail service regardless of any SMTP setup, and it ignores the Send Email To Buyer switch and the subscription entirely. On a consolidated e-invoice the buyer e-mail is the literal word NA, so that notification is attempted at an address that is not one. Whether the buyer or the operator is meant to receive it is an open question for BigLedger, recorded and not answered here; what you can rely on is that switching the PDF e-mail off does not switch this one off.

Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

How the steps fit together

    flowchart TD
  s1["Step 1 — Know the moment it goes, and which path your tenant takes"]
  s2["Step 2 — Know who receives it, and why it is not the customer record"]
  s3["Step 3 — Know the three things that must exist, and which one is on a screen"]
  s4["Step 4 — Know where the words and the sending address come from"]
  s5["Step 5 — Do not confuse it with the cancellation e-mail"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

1. When is the validated PDF e-mailed? When the document is finalised
When the payload is submitted to LHDN
When the validation poller reads Valid — queued for the processor, or sent inline on a tenant that has never had the schedule row

2. A customer's e-mail on the customer record is correct, but they never receive e-invoices. Which field decides the recipient? The buyer e-mail on the e-invoice header, as submitted
The customer record's e-mail
The branch's e-mail

3. Send Email To Buyer is on. What else must exist before anything is sent? Nothing — the switch is sufficient
A webhook subscription for the company under the printable e-mail topic, with a sender in it — set up by BigLedger, not from a screen
A branch default printable format

4. Which statement about the cancellation notification is true? It is suppressed when Send Email To Buyer is off
It goes to the header's buyer e-mail addressed Dear User, ignoring the switch and the subscription
It uses the company's e-invoice format as an attachment

Answer key

When the validation poller reads Valid — queued for the processor, or sent inline on a tenant that has never had the schedule row — My E-Invoice Admin Applet — When the e-mail goes, and to whom
The buyer e-mail on the e-invoice header, as submitted — My E-Invoice Admin Applet — When the e-mail goes, and to whom
A webhook subscription for the company under the printable e-mail topic, with a sender in it — set up by BigLedger, not from a screen — My E-Invoice Admin Applet — What has to exist before anything is sent
It goes to the header's buyer e-mail addressed Dear User, ignoring the switch and the subscription — My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Next: Reading the Email Dashboard and the e-mail thread — what a row is evidence of, and the rows that never move · Back to the series · Play this as a presentation

Last updated on September 19, 2026

When the validated PDF is e-mailed, to whom, from what address — and the three things that must exist first Reading the Email Dashboard and the e-mail thread — what a row is evidence of, and the rows that never move