Business Central Excel Reports Slow? 5 Fixes (2026)

By Thomas Werkhoven, CEO of Exsion365, registered accountant, previously group controller and CFO.

The report that refreshes in 10 seconds on a Friday afternoon takes 40 or 50 seconds on Monday morning, sometimes minutes. Nothing changed in the workbook. If that is your week, this article explains why and what to do about it, in the order we would try it.

The short answer

Business Central online runs your company on a shared tenant with one primary database. On Monday morning that database is answering 15 or 20 controllers refreshing weekend reports, plus every job queue entry, integration and update Microsoft or your partner scheduled for the same window. The Excel add-in is one more client waiting in that queue; a faster laptop does not shorten it.

Five things help, roughly in order of effort: route report reads to Business Central's read-only replica (a connection setting), schedule the heavy reports before anyone arrives, split slow-changing master data from transaction data so a refresh pulls less, check what else your tenant runs on Monday, and finally look at the design of the report itself.

One thing this article is not about. If what you are seeing is an error message rather than a slow refresh, an automation error on refresh, a ribbon that has vanished overnight, or a date cell that breaks when a colleague opens the file in English Excel, those have different causes and quicker fixes. We went through them in three Business Central Excel add-in errors that are not the add-in.

What a slow Monday actually looks like

Last week Nicky Oudt, Senior Reporting Consultant at Exsion365, sat down with the application team of a food producer that runs Business Central online across the Netherlands and Poland. They have over 100 Exsion Reporting licences and a library of roughly 280 reports that a virtual machine refreshes every night from about one o'clock. On paper the Monday problem should not exist: the reports are ready before anyone logs in.

In practice, 15 to 20 people arrive on Monday and press refresh anyway, because the weekend closed on Sunday and they want Monday's numbers. Screen build-up in Business Central itself slows down, and a report reload that takes 10 seconds on a Friday afternoon takes 40 to 50 seconds.

Their Polish IT manager had done his homework and asked a precise question: does the add-in support read scale-out, the read-only replica Business Central offers for reporting? The answer is yes, and it is the first fix below. But the more useful thing that came out of the session was a way of thinking about the problem, so start there.

Where the time goes in Business Central online

Every Business Central online tenant is a database on Microsoft's Azure SQL infrastructure, and everything you do talks to it: the web client, the job queue, API integrations, and any Excel add-in that reads live data. When a report is slow at one time of day and fast at another, the report is not the variable. The load on the tenant is.

On a Monday morning that load has several sources at once. Controllers refreshing. Job queue entries scheduled for the start of the week, such as a posting batch, an inventory adjustment, or a synchronisation with a warehouse or webshop. A scanning or document capture integration making API calls per document. Occasionally a Microsoft update that ran over the weekend and is still warming caches, or a partner extension doing its own housekeeping.

The customer in our session had heard from their implementation partner, years earlier, that API calls were limited to five in a queue; nobody had ever tested it. That is not the exact rule, but the instinct was right.

The operational limits nobody reads

Microsoft publishes the limits for Business Central online in a single page, Operational Limits for Business Central Online. It covers the maximum number of concurrent OData and API requests per tenant, the per-request timeout, the number of job queue entries that can run at the same time, and the limits on report and background sessions.

Two things follow from that page. First, an Excel refresh that pulls a large table is an OData or API request like any other, so it competes with your integrations for the same slots. Second, when the slots are full, the request waits; it does not fail. That waiting is your 50 seconds.

Fix 1: send reports to the read-only replica

Business Central online keeps a read-only copy of your database for exactly this purpose. Microsoft calls the feature read scale-out, and it is controlled by a property called Data Access Intent: a request marked ReadOnly is served from the replica instead of the primary database, so it does not compete with postings, job queues and everyone else writing to the tenant. Microsoft documents it in Using Read Scale-Out for Better Performance. The replica lags the primary by a moment, which for a Monday morning report is irrelevant.

In Exsion Reporting the setting lives in the connection screen. Open the connection from the Exsion ribbon and look for Transaction type. It defaults to Browse; switch it to Snapshot and the connection reads from the replica. The Exsion help text for the connection screen links through to Microsoft's explanation of the available data access options, so you can read what each choice does before changing it.

One practical note: the setting is stored per user, not centrally, so on a managed estate it goes into the onboarding instructions and the first-line checklist rather than into an Intune package.

How to test it without bothering 20 colleagues

Do not roll this out to everyone on a Monday and hope. Nicky's suggestion was simpler: two people sit next to each other with the same slow report. One changes the connection setting to read-only, the other leaves it as it is. Both press refresh at the same moment, on a busy morning.

If the read-only side comes back in 12 seconds and the other in 45, you have your answer and a number to put in the change request. If both are slow, the bottleneck is somewhere else and you have saved yourself a hundred desk visits.

Fix 2: schedule the heavy reports before anyone arrives

The customer already did this, and it is still the highest-value fix for most teams. Any report that is run every Monday by the same people with the same filters does not need a human to press refresh. Schedule it. The customer runs about 280 reports from a virtual machine starting around 01:00, and the batch is done in roughly an hour.

ExsionTime, Exsion's scheduling add-on, packages exactly that job. You upload a report to Business Central and set up its tasks and schedule there, and a Windows service on your own server or PC then refreshes it and saves the result as Excel, PDF or CSV, or emails it. One report can have several tasks, each with its own filters and recipients, so the same statement can go to four branch managers with four different filters. Output can also go to a folder, OneDrive or FTP rather than by email, and every run's status and errors are logged in Business Central and on the server. The setup is documented in the ExsionTime help.

Two honest notes. The service needs an always-on machine with Excel and the add-in installed, and a server is a better home for that than somebody's workstation. And the Business Central connection has to be renewed from time to time, at an interval your own security policy sets, which is worth planning for if a month-end depends on these runs.

The other caveat comes from the customer's own experience and has nothing to do with software: people keep pressing refresh for a fortnight anyway. Give it two weeks and tell them the reports are already current.

Fix 3: split static data from transactions

Here is a design habit that reduces every refresh, scheduled or manual. Most reports pull two kinds of data: master data that changes slowly (items, customers, dimensions, G/L accounts, item attributes) and transaction data that changes constantly (G/L Entry, Item Ledger Entry, Sales Invoice Line). A typical report refreshes both every time, even though the item list looked exactly the same yesterday.

The customer's application manager had already thought of the fix: a second button. One button does a full reload, the other refreshes only the transaction queries and leaves the master data as it was. In Exsion the mechanism is small: in the header of each download definition, the asterisk after Connection marks that download for refresh. Leave the asterisk off the master data downloads in a second definition and a refresh of that definition touches only the ledgers.

Refresh master data once a day, at night, and let the Monday morning refresh pull only what changed. On a report with 35 item attributes joined to a sales analysis, that is most of the rows gone from the request.

Fix 4: check what else runs on Monday

If the two-person test in Fix 1 shows that both refreshes are slow, look at the tenant rather than the add-in. Three places to check.

Job Queue Entries. Open the Job Queue Entries page in Business Central and filter on Monday morning. Anything with a large batch (an inventory adjustment, a periodic posting, a data synchronisation) that starts at 08:00 will contend with your controllers. Moving it to 06:00 costs nothing. Microsoft explains the page in Use Job Queues to Schedule Tasks.

Integrations. Document scanning, EDI, a webshop connector: each of them makes API calls, and a Monday backlog of weekend documents can saturate the request slots from the operational limits page above. Ask the vendor when their batch runs and how many requests it makes.

Updates and partner work. Microsoft's monthly updates and your partner's deployments both have a window. If the slow Monday is one Monday rather than every Monday, check the update history in the Business Central admin centre before you change anything.

When our customers report slowness, this is usually where it turns out to be: an update passing through, a partner job, or simply everyone in the tenant at once. We rarely hear that the add-in itself is the limiting factor on a Business Central online tenant, and when we do, the report design is the reason.

Fix 5: look at the report itself

Which brings us to the last fix. A report that pulls one balance per cell, or one lookup per row, sends one request per cell or row to Business Central. On a quiet Friday that is a few extra seconds. On a busy Monday each of those requests waits its turn, and the seconds become minutes.

The rule is the same one we described for Jet users in Jet Reports slow? Why Excel freezes on big reports: pull sets, not cells. One query on G/L Entry filtered to the period returns everything the report needs in a single request, and Excel does the arithmetic in a pivot or SUMIFS.

Two related habits help. Joins that Business Central can do in one request (item to item attribute, invoice header to invoice line) should be done in the query rather than with a column of XLOOKUPs against a second download; we cover the trade-offs in a separate post on item attributes in Excel from Business Central. And two tables that belong under each other, such as posted sales invoices and posted credit memos, can be stacked in one output range rather than fetched and glued together; the customer in our session had tried that the week before and called it an eye-opener.

When to call your reporting vendor

Everything above you can do yourself. What you cannot do is see your own tenant from the outside, and that is what a short session with a consultant adds. In the case we described, Nicky could not log into the customer's Business Central (they had no spare licence, which is common and fine), so the diagnosis ran on a screen share: which reports, which settings, what the tenant does on a Monday. Thirty minutes, one setting to test, one scheduling change, and a design tip that removed a join from a report.

If you run Exsion Reporting and your Monday looks like this one, tell us when it happens and let us watch it happen. A ticket that says "slow on Monday" gets a checklist; a screen share at 08:30 on a Monday gets a diagnosis.

If you do not run Exsion yet, you can test the software free for 30 days. The AppSource listing installs directly on Business Central with no warehouse, no replica of your own to maintain and no VM, which we explain in live Business Central data in Excel without a warehouse. Permissions come from Business Central, so a controller who cannot see a company in BC cannot see it in Excel either. Pricing is on the pricing page.

Frequently asked questions

[[FAQ_START]]

Why are my Business Central Excel reports slow on Monday morning but fast on Friday? | Because the load on your Business Central online tenant is different, not the report. Controllers refreshing weekend reports compete with job queue entries, integrations and updates for the same database and the same request slots.

Does Business Central have a read-only replica for reporting? | Yes. Business Central online supports read scale-out: a request marked with Data Access Intent ReadOnly is served from a read-only replica instead of the primary. Exsion Reporting exposes this as a connection setting, Transaction type, which defaults to Browse and should be set to Snapshot.

How do I test whether the read-only setting helps without changing every user? | Two people open the same slow report on a busy morning. One switches the connection to read-only, the other does not, and both refresh at the same moment. If the read-only refresh is clearly faster, roll the setting out; if both are slow, the bottleneck is elsewhere.

Should I schedule Business Central Excel reports overnight? | Yes, for any report that the same people run with the same filters every week. Scheduling moves the load to a window when the tenant is idle. ExsionTime needs an always-on machine with Excel and the add-in installed.

What else slows down Business Central online on a Monday? | Job queue entries scheduled for the start of the week, integrations working through a weekend backlog of API calls, and Microsoft or partner updates that ran over the weekend. Check those before changing report settings.

Can the Excel add-in itself be the reason Business Central is slow? | Rarely on a Business Central online tenant, and when it is, the cause is report design: one request per cell or per row instead of one query per table. Pull sets rather than cells and do joins in the query.

[[FAQ_END]]