Document Email (Invoices & Credit Memos)

Posted sales invoices and credit memos are emailed to the customer as a PDF by a recurring job queue, codeunit 51722 "Auto Email Job Queue". Routing is decided entirely by Business Central's standard Document Sending Profile on the customer -- TBC adds no customer-level email setting.

The job queue entry is created automatically (like the currency rate update) -- everything else below must be configured per company, and the flow does nothing until it is.

How the Flow Works

Stage	What happens
Posting	An event subscriber reads the customer's Document Sending Profile and stamps the posted document: Pending (E-Mail active), E-Invoice (Electronic Document active), or Not Applicable (neither). Posting itself can never fail because of this.
Job queue	Every run picks up documents with status Pending, hands them to BC's standard EmailRecords (report resolved from Report Selection), and writes Sent or Error with the error text. Each document is committed on its own, so one failure does not affect the rest.
BC mailing job	EmailRecords does not send inline: it enqueues a one-shot job queue entry for codeunit "Document-Mailing" (category MAILING) per document. That job renders the PDF, resolves the address and puts the message in the Email Outbox, which the email account then sends.
Follow-up	Status, sent time and error message are shown on the posted invoice / credit memo, with Resend Email and Skip Email actions.

The profile is re-read at send time. A customer moved to an e-invoicing channel after posting is dropped from the queue rather than sent a duplicate PDF -- the two channels never both send.

Status Sent means handed over, not delivered. TBC's status covers everything up to the mailing job. A failure after that -- rejected recipient, throttled account -- lands in the Email Outbox with an error message and BC's own retries, and does not set our status back to Error. Email Outbox is therefore part of the same monitoring picture.

Single send path: "Post and Send" and "Post and New" are hidden on the Sales Order page. Post and Send would send in the foreground outside the queue, and the queue would then send the same invoice again.

1. Master Switch on AIR Setup

AIR Setup → Document Sending → Auto Email Invoices Enabled

Off by default. While it is off, posted documents are left at Not Applicable and the job queue exits immediately. Turn it on last, when steps 2--4 are done and the job queue entry (step 5) is verified — otherwise the first posted invoices are stamped Pending and then fail in the queue.

Leave it off when an external distribution service (e.g. Golden EDI) owns outbound distribution for the whole company.

2. Email Account

Settings → Email Accounts -- at least one account, marked as default. The default account is the one BC uses for every email scenario that has no account of its own, and this flow assigns no scenario, so the default account is what sends the invoices. One account is not enough on its own: it still has to be marked.

The page renders accounts as tiles, where the Default column is not visible. Read it from the action instead: select the account and look at Set as default -- greyed out means this account already is the default, clickable means it is not. Choose Send Test Email on the account while you are there; if that arrives, later troubleshooting is about routing or Report Selection, not about email itself.

3. Report Selection

Report Selection - Sales -- the queue sends whatever report is selected here:

Usage	Report ID	Report name in the lookup
Invoice (S.Invoice)	51800	Sales Invoice
Credit Memo (S.Cr.Memo)	51800	Sales Invoice

Report 51800 renders credit memos as well -- same layout, different heading -- so it is used for both usages. If a usage is left on the BC standard report, the customer receives the standard invoice layout without any travel information.

If a usage has no report at all, the queue stops that run with one clear error naming the usage instead of failing document by document. The documents stay Pending and go out on their own once the selection is in place -- nothing has to be resent by hand. The two usages are independent: a missing credit memo selection never holds up invoices.

Report Selection - Sales also has an Email Body Layout column. Leave it empty for go-live: the customer then gets BC's default email text with the PDF attached.

4. Document Sending Profiles

Document Sending Profiles -- one profile per outbound channel, assigned per customer:

Profile code	E-Mail	Electronic Document	Used for
EMAIL	Yes (Use Default Settings)	No	Customers who get the PDF by email -- the only profile this queue acts on
E-INVOICE	No	Through Document Exchange Service	E-invoice customers. Stamped E-Invoice, never emailed from here
STANDARD	No	No	Nothing is sent automatically. Usually the default profile

note

TBC sends with EmailRecords(false), which always uses Yes (Use Default Settings) and a PDF attachment no matter what the profile says -- the profile's own E-Mail / E-Mail Attachment values are not read on this path. TBC reads the profile only to decide whether to queue the document at all (E-Mail ≠ No, Electronic Document = No). Set EMAIL to Yes (Use Default Settings) anyway, so a manual Print/Send → Send by Email behaves the same as the queue instead of opening a settings dialog.

The codes are examples. TBC never reads the profile code -- only the E-Mail and Electronic Document field values. Name them whatever the customer already uses.

Assign the profile per customer on the customer card (Document Sending Profile, Communication FastTab). Customers without one fall back to the profile marked Default, so pick a default that is safe for everyone who has not been classified yet -- normally STANDARD.

Create STANDARD first and tick Default there

Default cannot be cleared once set -- BC answers "There must be one default rule in the system". The only way to move it is to tick Default on another profile, which clears it everywhere else. A profile carrying Default cannot be deleted either.

Electronic Document is hidden on the page entirely when no Electronic Document Format is registered in the company. If the field is not there, the company has no e-invoicing format installed -- which also means no customer can be routed to the e-invoice channel.

5. Job Queue Entry (Auto-Created)

The app creates the recurring entry automatically -- per company, on app install and on upgrade (upgrade tag TBC-DocumentEmailJobQueue-20260903):

Setting	Value
Object to Run	Codeunit 51722 "Auto Email Job Queue"
Description	Send posted invoices and credit memos by email (Travel Business Connector)
Recurrence	Every 5 minutes, all seven days, 06:00-22:00
Max. Attempts / Rerun Delay	3 / 300 s

Seeding it is safe before the rest is configured: with the master switch off the run exits on its first statement.

You do not create this entry manually -- but you must verify it:

1. Open Job Queue Entries and find the entry for codeunit 51722.
2. Check Status = Ready. Task scheduling is not always available during install/upgrade, so if the entry was left On Hold, set it to Ready manually.
3. Check Earliest Start Date/Time. If the app was installed outside the 06:00-22:00 window -- an evening deploy, or a late setup session -- the first run is scheduled for the next day at 06:00, and nothing happens in the meantime. Clear the field (or set it to now) to start the cadence immediately; during setup and testing it is also reasonable to widen Starting/Ending Time temporarily.
4. In a company created after the app was installed, the entry appears on the next app upgrade -- create it manually (same settings as above) if it is needed before then.

Include the entry in whatever job queue monitoring the customer uses: a recurring entry that errors stops, and invoices then pile up in Pending.

The 06:00-22:00 window is deliberate: an invoice landing in a customer's inbox at 03:00 looks like a system talking to itself, and nobody is around to react to an error. Widen it only if the customer asks.

Which Address the Document Is Sent To

BC resolves the recipient in this order (first hit wins), all of it standard behaviour:

1. An address stored for that specific document from an earlier manual send (Email Parameter).
2. Document Layouts on the customer card (Related → Customer → Document Layouts) -- the Send To Email column on the row for that usage. Use this when invoices go to an accounts-payable address that differs from the customer's general email.
3. Sell-to E-Mail on the document itself (field 172). It is copied from the customer when the order is created, so it reflects the customer card at order creation time -- fixing a wrong address on the customer card does not change orders that already exist.
4. E-Mail on the customer card (bill-to customer).

Because of step 3, correcting an address on the customer card and choosing Resend Email on an already posted document keeps using the old address. Either correct the address in Document Layouts (step 2 outranks the document) or send that one document manually.

Switching a Customer Between Channels

The status is stamped on each document at posting and is never recalculated for documents that are already finished, so changing a customer's Document Sending Profile has no effect on what has already been sent:

Document state when the profile changes	What happens
Sent	Nothing. The queue only ever reads Pending.
E-Invoice / Not Applicable / Skipped	Nothing. Never picked up.
Error	Nothing automatic -- Error is only retried by a person choosing Resend Email, and Resend is refused if the customer is no longer on the email channel.
Pending	Re-checked at the next run. Still on email → sent. Moved to e-invoice → not emailed; the status becomes E-Invoice and the error message field explains that the channel changed after posting.

So neither direction can produce a duplicate on its own: this queue never sends anything but PDF email, and it only sends documents that were Pending and whose customer is still on the email channel. Equally, the e-invoicing engine triggers at posting -- it does not go back and pick up documents posted before the switch.

The one case that needs attention is the last row: a document posted minutes before the profile was switched to e-invoice is emailed by nobody. The e-invoice channel never saw it (it was posted before the switch) and this queue steps aside. It is not lost silently -- it carries the explanatory note on the posted document -- but somebody has to decide what to do with it: send it on the new channel, or set the profile back and use Resend Email.

Practical rule when onboarding a customer to e-invoicing: switch the profile when nothing is Pending for that customer. Filter Posted Sales Invoices on Invoice Email Status = Pending first; if the list is empty for that customer, the switch is clean.

Going the other way (e-invoice → email) has no such window: the old documents keep status E-Invoice and are simply never touched again. If one of them has to go out as a PDF after all, that is exactly what Resend Email is for -- it works once the profile says email, and it is always a deliberate manual act.

Verification

1. Post an invoice for a customer with the EMAIL profile → Invoice Email Status = Pending.
2. Wait for a queue run — drop No. of Minutes between Runs to 1 while verifying → Sent, with a sent time, and the PDF in the customer's inbox.
3. Post an invoice for a customer with E-INVOICE → E-Invoice, no email.
4. Post an invoice for a customer with STANDARD → Not Applicable, no email.
5. Remove the email address from a test customer and post → Error with a readable message; put the address back and choose Resend Email → Sent.
6. Post a credit memo for the EMAIL customer → the same flow on the posted credit memo.
7. Open a sales order and confirm that only Post is offered -- no Post and Send, no Post and New.

Fields Added to Posted Documents

The same three fields, with the same IDs, on Sales Invoice Header (tableextension 51415) and Sales Cr.Memo Header (51420):

Field ID	Name	Type
51380	Invoice Email Status	Enum "Document Email Status"
51381	Invoice Email Sent DateTime	DateTime
51382	Invoice Email Error Message	Text[250]

All three are non-editable and set by the app. See Enum Reference for the status values.