You sat through the Power BI implementation. The dashboards look good. Data refreshes overnight, and nobody emails a workbook called Sales_FINAL_v7 any more.

Then someone looks at the margin chart and asks something the dashboard was never built to answer. Which customers? Price or mix? Is it only Germany?

A few minutes later, somebody says it out loud: ‘Can we just export it to Excel?’

It is easy to file this under training, licensing or stubbornness. It is more useful to read it as information. A person who leaves a governed BI environment to answer a question is telling you exactly where that environment stopped being useful. So the real question is not why people still use Excel. It is why they feel the need to leave BI to answer the next question.

The short answer. People export because the report answered their first question and they now have a second one, and Excel is the fastest place to chase it alone. Some of that is healthy. The rest points to missing detail, missing definitions or missing trust in the numbers. Conversational analytics can help with that second group, but only on data and models that are ready for it.

Why do people still export Power BI data to Excel?

Because they have reached a question the report was not built to answer, and Excel is the quickest way to answer it themselves. The export is rarely the goal. It is the first step of an analysis. Microsoft says as much: when it announced better Excel export for tables and matrices in 2021, the stated business value was that many users want to continue their analysis in Excel as they explore data in Power BI.

In the 2025 AFP FP&A Benchmarking Survey of 362 finance practitioners, 96% use spreadsheets for planning and 93% for reporting daily or weekly, while 61% cite unreliable data and 60% inaccessible data as challenges. It covers spreadsheets in FP&A generally, not exports from Power BI, but where data is hard to trust or reach, people build their own route to it.

The dashboard answered the first question, not the second

A dashboard is a set of answers to questions somebody predicted. It does that job well: the same numbers, the same definitions, visible to everyone. The trouble starts when a number moves and the viewer asks why:

1. How is gross margin tracking against target? The dashboard was built for this.
2. Why did margin fall in Germany last month? Maybe there is a region slicer. Maybe.
3. Which customers caused it? That needs customer-level margin. Is it in the model?
4. Was it price, volume, discounting or product mix? That needs line-level price, discount, cost and product data, plus agreed logic for splitting the change.

Each question is narrower than the last and needs a different cut of the data. A well-designed report anticipates the second. By the fourth, nobody has built that page, and nobody could have: the fourth question only exists once the third answer is known.

The first question is monitoring. The other three are investigation. A decision follows. Three different jobs:

• Monitoring answers ‘what happened?’ This is what dashboards are built for.
• Investigation answers ‘why did it happen?’ It needs flexible questions, finer detail and room to change direction halfway.
• Decision answers ‘what should we do?’ It needs the explanation plus judgement, options and consequences.

Investigation is where many people reach for the export button, and Excel is where the decision often gets written up.

The problem isn’t Excel

Excel gives people a grid they can see and touch, the freedom to change shape without asking permission, and room for scenarios and half-formed ideas. Microsoft’s own training material calls it arguably the most common data analysis tool for information workers, and its documentation describes connecting Excel to Power BI semantic models so people can build PivotTables on governed data.

The Analyze in Excel checklist from Data Goblins, hosted by SQLBI, weighs three cases. For a finance analyst whose ad hoc regional pricing analyses were not repeatable, Analyze in Excel was the right solution. For an engineer who asked for a daily export of monitoring data, it was not, and the team built a Power BI report to replace the export-based workflow. The author’s warning is worth repeating: Analyze in Excel can occasionally be an over-used bandage for export requests, rather than addressing the root business problem.

So two different things hide behind ‘export to Excel’:

• Legitimate Excel use: modelling and scenarios, one-off exploration, outside data, judgement, formatting for a specific audience, working in a familiar tool on top of governed data.
• Excel as a workaround for an analytics gap: the same export every week, the same reshaping every time, rebuilding a number the model should provide, reconciling systems by hand, producing unofficial reports for other people.

Nothing in the first group is a problem to solve. Everything in the second is a question to ask.

When does exporting to Excel become a warning sign?

When the same export is repeated, reshaped the same way each time, or used to fix a number the model should already provide. One export tells you nothing. A pattern tells you what is missing. Four patterns worth watching:

• The same export, every week or month. A recurring view is missing from the report. Build it.
• The same reshaping straight after export. The model or the layout does not match how people think about the data.
• Exporting to reconcile or recalculate. Probably an integration or definition problem, or a measure that is missing or not trusted.
• The workbook becomes the version people quote. Now it is a report, with no owner, no refresh schedule and no review.

High export volume is a fair signal, not a verdict. Ten exports for ten different purposes is a healthy tool being used. Ten exports for the same purpose is a conversation you need to have, and it starts with the Super User’s question: what are you going to do with it?

What does the export workflow actually cost?

Mostly in stale versions, unreviewed logic and governance that stops at the file. Many exports follow the same loop, and each unanswered question restarts it.

• Versions and freshness. Once data leaves the model, it starts ageing. Is it current, and is everyone using the same version?
• Errors nobody reviews. Ray Panko’s review of field audits of real spreadsheets found errors in at least 86% of the spreadsheets audited in the most recent studies. Those audits predate 2008 and cover spreadsheets in general, not exports from BI.
• Governance that stops at the file. Microsoft documents controls on export: report designers choose which export options users get, admin settings override them, and Microsoft Defender for Cloud Apps can be used to set a policy that stops sensitive data being downloaded to unmanaged devices. Those controls decide where data goes, not what was calculated from it afterwards.

Why doesn’t ‘ask the analyst’ scale?

Because every new question needs a person with model access and the skills to answer it, and those people have limited time. The cost is not only the wait. It is what the analysts are not doing while they answer.

One data professional, writing on Substack, describes being asked, multiple times a day, ‘How do I export the data to Excel?’ His conclusion is that data teams should meet users where they are. We agree with half of that. Not every business user wants to build reports: the same practitioner describes users whose skills stop at drop-down filters, and says the vast majority sit somewhere in between.

None of this makes analysts surplus. They do what dashboards, Excel and AI all depend on: complex analysis, modelling, interpretation and building a data foundation worth trusting.

What if people could ask the data directly?

Conversational analytics lets a person ask a business question in everyday language and get an answer generated from governed data, with the option to ask a follow-up. It sits between ‘export it to Excel’ and ‘ask the BI team’.

This is the problem we are working on at Data Courage: making the next business question as easy to ask as the first one was to see on a dashboard.

Microsoft is building towards this too: Copilot in Power BI supports natural-language interaction with data, and Fabric data agents let organisations build question-and-answer experiences over lakehouses, warehouses, Power BI semantic models and other sources. Microsoft says agents generate read queries only and honour the user’s permissions, including row-level and column-level security. Parts of this are still in preview, so check the status of anything you plan around.

It is a better answer to one specific kind of question: the ad hoc follow-up that today triggers a ticket or an export. It is not a shortcut around foundations. A recent post on Microsoft’s Fabric Updates Blog puts the challenge plainly: the hard part is not enabling the conversation, it is making sure the answer is correct.

Four ways to chase one margin question

An illustrative scenario, not a customer case: the margin question again, from the CFO’s chair. Which customers drove the fall in Germany, and was it price, discounts, mix or cost?

• The predefined dashboard shows the decline but probably cannot split it into price, discount, mix and cost. The CFO gets confirmation, not explanation.
• Excel. A finance manager exports the sales lines, adds a price list and a cost file, and builds the price, volume and mix split in a PivotTable. It produces an answer, but the logic sits in a workbook only its author can see, and the next question restarts the loop.
• A request to the BI analyst. The analyst adds measures and a page for customer margin variance. The logic ends up in the model, reviewable and reusable, but it takes days, and the next question (is France the same?) joins the queue.
• Conversational analytics on a prepared model. The CFO asks which customers drove the decline, then for the change to be split by price, volume and mix. If the semantic model holds consistent definitions of margin, discount, cost and product category, with the right permissions, answers can arrive in the same session. If not, the assistant has to guess: Microsoft’s own wording is that without business context an answer is ‘only a plausible guess’.
  
  

  The four routes differ less in speed than in where the logic ends up: in a personal file, in a governed model after a wait, or in a governed model that can be queried in plain language.

See conversational analytics on your own data

Data Courage’s conversational analytics can work across multiple business data sources and lets people ask follow-up questions in plain language, so the next question does not start another export.

Does this mean dashboards, Excel and analysts are going away?

No. They do different jobs, and the conversational layer is built on the same models the others use. Microsoft describes the same semantic models as powering the dashboards the business uses daily and being kept up to date as a by-product of that use.

• Dashboards: recurring monitoring and shared numbers.
• Excel: flexible analysis and modelling, ideally connected to governed models rather than cut off from them.
• Conversational analytics: ad hoc questions and the follow-ups nobody predicted.
• Analysts and data teams: complex analysis, interpretation and the data foundation the other three depend on.

Before you add AI, fix the data underneath it

A conversational layer answers confidently from whatever it is given. Ambiguous definitions, untidy data and loose permissions do not disappear. They become wrong answers delivered faster.

• Data people can rely on and reach. In AFP’s survey, bad data ranked above people skills and tools as the main hindrance to technology success in FP&A. A chat interface does not change that.
• A semantic model that says what things mean. Microsoft’s tutorial on preparing models for Copilot says that without proper preparation, Copilot can generate less helpful and inaccurate results. Authors can add AI instructions, and Microsoft’s own example tells Copilot to use the model’s gross margin percentage measure rather than an average of transaction-level percentages. Microsoft is clear that the model interprets such instructions, with no guarantee they are followed.
• ERP data that can be modelled. Microsoft’s Business Central documentation says that for more advanced data science or business intelligence scenarios that need richer data engineering or data integration, Microsoft Fabric might be a good option. Getting ERP data into a form that can be modelled and governed is often the unglamorous work that decides whether a conversational layer is useful.

Get the foundation right first

Data Courage builds data platforms on Microsoft Fabric and Power BI models that bring ERP, CRM, finance and operational data together, so that dashboards and conversational analytics both have something reliable to stand on.

From exporting data to asking better questions

A practical sequence:

1. Follow ten recent exports to the end. Ask what each person did next and who received the result, out of curiosity rather than as an audit.
2. Sort them. Legitimate Excel use, or a workaround for a gap? The four patterns above help.
3. Fix the cheap gaps first. Add the detail page, drill-through or missing measure people keep exporting for.
4. Give Excel users a governed route. Connect Excel to the semantic model with Analyze in Excel or a connected PivotTable. Microsoft documents that row-level and object-level security apply to Analyze in Excel.
5. Write down the business terms people argue about, such as what counts as a ‘customer’. Put them in the model, then in the AI instructions.
6. Pilot conversational analytics on one domain. Use the real questions from step 1 as your test set, and check the answers against numbers you trust before anyone else sees them.

Where we fit. Data Courage works on both halves of this: the foundation underneath and the questions on top. Besides conversational analytics, we publish AI apps for Dynamics 365 Business Central, including AI Financial Intelligence, which lets finance users generate P&L and Balance Sheet reports and then ask follow-up questions in natural language inside Business Central, with support for dimensions, saved insights and export options. It is focused on finance and designed to complement standard reports, not replace them. As with any tool in this space, results depend on the quality of the data and the set-up underneath.

Using Business Central? Try AI Financial Intelligence

Generate P&L and Balance Sheet reports, then ask follow-up questions in natural language without leaving Business Central.

The export button is not going anywhere

Dashboards will keep answering the first question, and Excel will keep answering plenty of second ones. The aim is not to stop that. It is to know which second questions keep coming back.

The export button is not going anywhere, and it should not. The useful habit is to treat each export as a question: what was this person trying to find out, and why could they not find it where the data lives?

Talk to us about your exports

Bring one report your team keeps exporting to Excel, and we will give you a second opinion on what is missing underneath it.

Frequently asked questions

1. Why do users export Power BI data to Excel instead of using the report?

Usually because they have a follow-up question the report was not built to answer. They want to see the underlying rows, reshape the data, combine it with another file or add their own judgement. Repeated identical exports are a sign that something is missing from the model or the report.

2. Is exporting Power BI data to Excel bad practice?

Not by itself. One-off exploration, scenario modelling and working with outside data are good uses of Excel. It becomes a concern when the same export is repeated, when the workbook becomes the version people quote, or when exports recalculate numbers the model should provide. Microsoft provides admin and report-level export settings for organisations that need tighter control.

3. What is the difference between exporting to Excel and Analyze in Excel?

An export creates a file containing the data from a visual at that moment. Analyze in Excel creates a workbook connected to the Power BI semantic model, so a PivotTable can be refreshed and built on the model’s measures.

4. Will conversational analytics replace dashboards?

No. Dashboards remain the efficient way to monitor recurring metrics that many people need to see in the same form. Conversational analytics suits ad hoc and follow-up questions.

5. Can AI answer questions about Power BI data accurately?

It can when the model underneath is prepared, but not automatically. Microsoft says that without proper preparation Copilot can generate less helpful and inaccurate results, and that AI instructions are interpreted rather than guaranteed. Test with questions whose answers you already know before rolling anything out.

6. How can we reduce ad hoc report requests to the BI team?

Sort a month of requests into new logic, new cuts of existing data and questions about what a number means. Then fix the gaps that sorting reveals and, where the model is ready, pilot conversational analytics for follow-up questions.