The Excel vs. Power BI comparison has been making the rounds again—this time through a post by Danny Martens on LinkedIn. His tagline is punchy—“Get your tailored Power BI dashboard in five days” His post follows a predictable pattern in these kinds of comparisons:
“Stick with Excel when it’s a one-off. Use Power BI when reports are reused monthly, multiple teams need the same numbers, or when you spend hours preparing data. Excel is fast and familiar, but if it slows you down, it might be time to level up.”
So far, so typical.
What Martens is presenting isn’t a malicious lie—it’s just a flawed, incomplete picture, and it’s one that keeps getting recycled. Thankfully, in this case, Mark Proctor stepped in with a valid response: “You’re not comparing like with like.” And he’s right. But there’s more to this story.
The “Like for Like” Fallacy
Proctor’s point is that Martens is comparing Power BI today with the way Excel used to be used—Excel 97-style. Martens is implicitly treating Excel as if it’s still just a local tool for personal analysis: no automation, no architecture, no integration.
That’s not how Excel is used in serious business environments by professionals anymore. Or ever!
But let’s take the argument one level deeper: If you’re going to compare Power BI—which is fundamentally a client-server architecture—then the fair comparison is with Excel used in a client-server (or hub-and-spoke) architecture also.
And here’s the surprise for many: Excel supports this architecture natively. It has, for decades.
Why the Debate Won’t Die
The reason these posts keep appearing is, quite frankly, because most people—including many Excel professionals—don’t know this architectural capability exists in Excel. And because they don’t know, they default to treating Excel as a single-user, standalone tool. But that’s a bit like comparing a bicycle to a car and forgetting Excel can be driven too.
I demonstrated this through an Annual Budgeting model I posted recently. It showcases collaborative, enterprise-wide budgeting, version control, cell-level commentary, cascading drilldowns, and audit trails. Everything is driven by a central data store—an Access database or SQL backend on the Cloud—and the Excel workbooks act as thin clients, uploading and retrieving data via ADO (Microsoft ActiveX Data Objects).
You want Power BI to do that? All of that, as demonstrated in the video? Good luck.
Has anyone built a true budgeting workflow in Power BI? Not just a dashboard, but an interactive, multi-user, process-integrated budgeting engine? Because that’s what we’ve done in Excel—without needing a developer army or a heavy implementation cycle.
The Real Issue: Participation vs. Presentation
Here’s the deeper point that’s often missed: Excel can participate in business process. Power BI just presents the process.
A business user can suggest a feature—say, “Can we put cell comments here for budget reviewers?”—and that feature can be implemented in Excel the same day. Want drilldowns to the lowest granularity? Sure. Want cascading selection logic for multiple dimensions? No problem. Want data writebacks? Already done.
In Power BI, the conversation goes: “We’d need to build a separate Power BI App for that.”
This is where Excel wins—especially in client-server mode. It becomes a live interface into the data, an operational tool, not just a visualization surface. An interactively collaborative platform.
The Real Comparison: Architecture vs Tool
Let’s be clear: this isn’t just a Power BI vs Excel debate. We’ve seen the same flawed comparisons from vendors like Anaplan, Workday Adaptive Planning, DataRails, and ERP systems. The pattern is always the same: they compare their tool’s architecture to a bad way of using Excel in the enterprise.
The real comparison should be:
Enterprise architecture with Power BI vs Excel spreadsheets in an enterprise architecture.
Not: Power BI vs stand-alone Excel as created by novices..
And if the playing field is enterprise architecture—Excel wins. Unless your use case is so limited that data only flows in one direction, Excel in a hub-and-spoke setup can match or beat Power BI every time—especially when process participation and rapid iteration matter.
A Bit of History: Excel’s Client-Server Capabilities
For anyone who thinks this architectural model is niche or experimental, let’s go back in time.
The client-server revolution began in the early 1990s. It changed how industry worked—leaner, fitter, more integrated—by separating data from applications. And Microsoft didn’t sit out. In 1993, a young Satya Nadella demoed Excel’s client-server capability in a now-legendary DevCast presentation, the precursor to Microsoft Ignite.
By Excel 97, this capability had matured. ADO (ActiveX Data Objects) became the built-in mechanism for connecting Excel to centralized data. It’s still there today—version 6.1 ships with every Windows machine and Office installation.
This is not a hack. This is the plumbing Microsoft gave us so that Excel could operate as part of a distributed, data-driven enterprise. And it works beautifully. Bill Gates’ book ‘Business @ The Speed of Thought’ largely revolved around this idea of the Digital Nervous System. Connectivity and data flow.
So Why Don’t More People Know This?
Good question.
For influencers like Danny Martens (or I’ve seen a similar ‘Excel’s limitations post by Richard Nero), I don’t think it’s dishonesty. I think it’s simply ignorance—and perhaps too much exposure to the world of dashboarding rather than enterprise-grade spreadsheet-process engineering.
What’s troubling is not that individuals make this mistake. It’s that even when challenged, the broader LinkedIn community doesn’t push back. This shows how deep the misconception runs: even seasoned Excel users aren’t aware that Excel has an enterprise mode.
Final Thought: Why This Matters
When people compare Power BI to Excel and present Excel as the “inferior” option, they’re not revealing Excel’s limitations—they’re revealing their own limitations of knowledge.
This matters because it shapes perception. It shapes what businesses invest in. It shapes what users learn. And ultimately, it shapes careers.
So here’s the key insight for anyone evaluating these tools:
Don’t compare a proper architecture to a poor use of a tool.
Compare apples to apples. Or better yet—compare client-server to client-server.
If you do, Excel wins more often than not.
By Hiran de Silva
Enterprise Excel Consultant and Advocate for Evidence-Based Spreadsheet Engineering
ABSTRACT
This article critiques the common comparison between Power BI and Excel, arguing it’s often a flawed comparison of Power BI’s architecture to a basic use of Excel. The author contends that Excel possesses robust, often overlooked, client-server capabilities that allow it to function within an enterprise architecture, similar to Power BI. Excel can actively participate in business processes with features like data writeback and collaborative workflows, unlike Power BI which primarily focuses on data presentation. The piece emphasizes that comparing enterprise architecture with Power BI to enterprise architecture with Excel reveals Excel’s significant strengths, especially when process integration and rapid iteration are crucial. The author suggests the persistent debate stems from a lack of awareness regarding Excel’s advanced capabilities, revealing a limitation of knowledge rather than a limitation of the tool itself.
Add comment