Email and report distribution setup in Business Central: store reports that send themselves

Configuration · 9 min read

Every store has the same wish list: statements out to customers without anyone remembering, the weekly sales report in the manager's inbox on Monday, nobody exporting PDFs by hand. Business Central can do a good part of that — but only if the setup is done in the right order, and only if nobody confuses two different features that sit next to each other: scheduling a report and emailing a report. They are not the same thing, and most failed setups fail exactly there.

First, the honest bit: Schedule does not mean email

When a report is scheduled, Business Central creates a job queue entry and runs the report at the chosen time. If the output is saved to a file, the finished report lands in the Report Inbox on the Role Centre, ready to view or download. Nothing in that standard flow sends an email. Store and finance staff discover this the hard way: the report ran all month, faithfully, into an inbox inside Business Central that nobody opened.

Community threads on exactly this point are blunt. A user who scheduled an Account Schedule found the output only in the Report Inbox, and the accepted answers state that there is no standard feature to email a financial report directly, even through the job queue. The same answers point out the asymmetry: some documents — customer statements, purchase orders, reminders, sales invoices — do support email, because their own functionality provides it. So the working model is:

• Scheduling = the job queue runs the report; output waits in the Report Inbox.
• Emailed distribution = available where the document or report itself offers an email output, or where extra tooling is added.
• Manual email = Send to / email actions on the document, any time, no schedule.

Everything below builds the setup in the order that makes those three routes work: email account first, scenarios second, schedules third.

Step 1: Set up the email account

Email accounts in Business Central are added through connector extensions, and the standard extensions connect to Microsoft Exchange Online. Three connectors are available by default, and the choice matters for a store:

The numbered setup, the same regardless of connector:

1. Open Email Accounts. Use search, open the Email Accounts page, and add a new account, choosing the connector that matches the table above.
2. Complete the connector fields. For the Microsoft 365 connector, point at the shared mailbox created in the Microsoft 365 admin center. For Current User, the account is the sign-in account — there is nothing extra to type, but the user must have a mailbox.
3. For SMTP, plan on OAuth 2.0. Exchange Online is deprecating Basic authentication for SMTP, and Microsoft recommends OAuth 2.0. The current SMTP connector guidance (2025 release wave 2, version 27.2 and later) sets the account up from Assisted Setup → Set up SMTP Account, with example values Server smtp.office365.com, Server Port 587, Authentication Type OAuth 2.0. Prerequisites include a Microsoft 365 tenant with Exchange Online and Global Administrator or Exchange Administrator permissions. Note that certificate-based authentication is not supported for this flow.
4. Send a test email from the account before doing anything else, and keep the account that works as the default sender.

What success looks like: the test email arrives in an external inbox (not just an internal one), the From address is the address the store intends customers to see, and the account shows as the default for users who have no scenario-specific account.

Step 2: Assign email scenarios so the right account sends

One account is enough to send mail; scenarios are what make the right account send each kind of mail. A scenario is a predefined business situation, and an email account can be assigned to the scenarios it should handle — for example, sales documents send from one account and purchase documents from another. One workable store pattern: set the Current User account as the default so personal follow-ups come from a person, then assign a shared-mailbox account to the sales scenarios so quotes and invoices arrive from the store address even when a part-timer sends them. The Notification scenario is the one that dictates workflow notification emails, so approval requests follow whichever account owns that scenario — worth deciding deliberately rather than discovering later.

One operational tip from the field guides: if a user suddenly gets errors sending through the Current User account, have that user open the Email Accounts page and send a test email — that can force the OAuth token to refresh and clear the error.

Step 3: Schedule a report (and know where it lands)

With email working, scheduling is safe to set up — with the Report Inbox expectation set correctly:

1. Open the report and set the filters and options on the request page exactly as the finished report should use them. The options entered here are the options applied every time the scheduled job runs.
2. Choose Send to → Schedule. Pick the output type (PDF, Word, Excel, or XML), the start date and time, and whether the report prints or saves to a file.
3. Set recurrence with the Next Run Date Formula for repeating reports — for example, D4 runs the report every Thursday. A one-off schedule is removed from the job queue after it runs; a recurring entry rolls to its next interval.
4. Verify on the Job Queue Entries page. The schedule lives there now. Later changes — timing, output, the report's own options via the Report Request Page action — are made on the job queue entry, not by scheduling the report again.
5. Collect output from the Report Inbox on the Role Centre. That is the delivery point. If the store's routine expects a human to pick reports up, name the owner and the day, in writing, next to the schedule.

What success looks like: after the first scheduled run, the job queue entry shows a successful last run, the output file is sitting in the Report Inbox with the expected filters applied, and the person who owns pickup knows it is there.

The route that really emails: scheduled customer statements

Customer statements are the exception that proves the rule — this document carries its own scheduled email, and for most stores it is the highest-value automation in this whole setup:

1. Set a Document Layout on each customer that should receive statements. The layout determines both the email address used and the statement layout sent.
2. Open the Customer card and choose Scheduled Statement. Set the parameters: Start Date, End Date, and whether to include all customers with a balance, plus any customer filter.
3. In Output Options, set Report Output to Email. Confirm, and Business Central creates a job queue entry that sends the statements by email when it runs.
4. Mind the layout limitation: this scheduled statement method works only for reports using a Word layout. A statement report on an RDLC layout will not send this way, which is a layout decision to settle before promising anyone automatic statements.

What success looks like: after the job queue entry runs, statements have been delivered to the layout addresses — spot-check one customer with a balance and confirm receipt before relying on the run for month-end.

Decision framework: which route for which report

Troubleshooting: the three failures stores actually hit

• "The report ran but nobody got it." It was scheduled, not emailed. Check the Report Inbox — the output is almost certainly waiting there. Fix the routine (pickup owner) or move the report to a route that genuinely emails.
• "Statements did not send." Check in order: a Document Layout with an email address on the customer, Report Output set to Email on the scheduled statement, the job queue entry's status — and whether the statement layout is a Word layout, since RDLC layouts do not work with this method.
• "Sending suddenly errors for one user." If the account is Current User, send a test email from the Email Accounts page to force an OAuth token refresh before changing any setup.

Note: menu names and the SMTP OAuth flow reflect Business Central online as documented in October 2026 sources, including the version 27.2 SMTP guidance; tenants on older versions or on-premises installs may show different fields. Verify against the tenant in front of you before changing a live email account.

FAQ

Can the job queue email any report as a PDF? No — standard scheduling delivers file output to the Report Inbox. Emailed delivery exists where the document itself provides it (customer statements are the store-relevant case); anything else needs customization or Power Automate.

Which account should send store mail? A shared mailbox via the Microsoft 365 connector for anything customers should reply to as "the store"; Current User where the reply should reach the sender. Scenarios let both coexist.

Is SMTP still worth setting up? Only where Microsoft 365 connectors do not fit — and then with OAuth 2.0, since Basic authentication for SMTP is being deprecated by Exchange Online.