By Hiran de Silva
This video is a demonstration to demystify the phrase “Excel is not a database,” a common refrain in social media debates—most notably in the PDF shared by Mark Proctor titled Excel Is Not a Database.
To explore this issue, we’ll look at one of the most complex, frustrating, and routine tasks in finance: consolidation. Whether it’s budgeting, forecasting, or reporting, we’re often required to consolidate figures from hundreds of separate operating units—often across multiple levels of a hierarchy.
In this demonstration, we’ll stick to just one hierarchy, but the principle is the same for more.
🔧 The Scenario
Imagine we have 400 separate budget templates, each filled in by a different budget holder. These need to be consolidated across:
- 90 cities
- 50 countries
- 4 regions
- and ultimately the global total
We’re going to demonstrate all 145 levels of consolidation using just one Excel sheet.
This sheet serves as:
- The input template,
- The consolidated view, and
- The interactive drill-down tool.
There are no hidden sheets, no hidden columns, and no helper cells. What you see is what you get.
🧪 The Demonstration
Let’s walk through the flow.
- We begin with a filled-in budget for a company called Cool Bikes, located in Chennai, India, Asia.
- As the budget holder, once I’ve completed my figures, I simply click Put. That’s it. I’m done.
Now, let’s say I’m a regional manager for India:
- I select India in the dropdown,
- Click Get,
- And instantly I receive the consolidated budget for India.
Now let’s step up to the CEO’s perspective:
- I navigate to the top level: All,
- Click Get,
- And now I have the global consolidated view—again, no additional processing steps required.
But what if the CEO wants to drill down?
Say they want to understand a particular number, like sales:
- Select the Sales cell,
- Instantly see a regional breakdown of sales,
- Select Asia, then India, then Chennai,
- And finally we see Cool Bikes.
We can even cross-check figures. For instance, if we changed November sales for Cool Bikes, that new number is reflected throughout the drill-down and final consolidation.
🧠 High-Level Overview – How It Works
Let’s unpack what’s happening.
We’re using a simple Excel template with:
- 28 rows (accounts),
- 12 columns (months, Jan to Dec).
Each of the 400 budget templates uses this same structure—but with different values.
The only change we’ve made is the addition of a backend Access database, stored on a shared drive.
Inside the database, there is:
- A table that mirrors the Excel layout: 28 rows × 12 months,
- Plus metadata: account code, description, and operating unit code.
Initially, this table is empty. But when a budget holder (like the one for Cool Bikes) clicks Put, their sheet uploads those 28 rows to the database.
When all 400 budget holders have submitted, the table will contain:
- 400 × 28 = 11,200 rows of clean, structured data.
From that point, any user—finance analyst, regional manager, or CEO—can:
- Clear the sheet,
- Click Get,
- And instantly retrieve any view of the data, from the most granular unit to the full global roll-up.
All using the same Excel file, with zero VBA complexity on the front end, and no manual collation.
In the next explainer, we’ll take a deeper dive into how this architecture resolves the classic conflict between business and IT, and why the business user is often right in insisting that Excel can be a powerful front-end to an enterprise system—when it’s designed correctly.
Certainly. Here’s the continuation of your explainer, seamlessly integrated with the cleaned-up first part. It maintains the high-level walkthrough tone, preserving clarity while respecting the structure of a live demo narration.
🔄 Part 2: Why This Works – Excel + Relational Database
Let’s now continue the demonstration to show that leveraging a relational database alongside Excel is not just possible—it’s a breeze. This directly contradicts the skepticism you’ll often see from influencers on social media who claim, or assume, that such integration is complicated, unauthorized, or even “dangerous.”
Let’s go deeper.
🧩 How Does the Spreadsheet Know What to Retrieve?
Any user in the budgeting process—whether they’re in Chennai or Chicago—can retrieve their own template with a single click.
Behind the scenes, that template is retrieving 28 rows of data from a relational database—specifically, from an Access database file—based on the operating unit code (i.e. the shop).
So far, so simple.
But what about consolidation?
Here’s where the relational database earns its name.
We have another table in the same Access database: a group map. It defines the hierarchy:
- Region
- Country
- City
- Shop
This is the crucial bit: because both tables (the budgets and the group map) share a common field—operating unit—we can relate them. That’s what makes it a relational database.
We create a permanent join between the two tables. From that point on, Excel can request any filtered view of the data:
- By shop
- By city
- By country
- By region
- Or for the entire organization
The only change we make to the query is to adjust the filter.
Instead of Shop = Cool Bikes, we now say Country = India, or Region = Asia, or 1=1 (i.e. no filter at all—for full global).
All of this is still done inside a single Excel sheet, with no external links, no Power Query, and no helper files.
🔎 Drill-down: Just a Slight Variation
The drill-down functionality works in exactly the same way—with just a minor change to the query.
Let’s say we’re looking at sales for November in the top-level consolidation:
- We select the cell.
- The query retrieves records for Account = Sales, Month = November.
- But instead of aggregating them at the top level, it groups the data by the next level down:
- First by Region
- Then by Country
- Then City
- Finally by Shop
This gives us fully dynamic multi-level drill-down, in real time, on demand. No need for pivot tables, no nested IFs, and no copy-pasting from dozens of files.
And because the data lives in a relational structure, auditing becomes trivial—no need to chase through nested formulas, broken links, or inconsistently structured tabs.
💡 What We’ve Solved – And Unlocked
This tiny architectural shift has solved multiple problems in one go:
- ✅ Eliminated external links
- ✅ Removed consolidation bottlenecks
- ✅ Delivered dynamic drill-down capability
- ✅ Made the whole model auditable and transparent
- ✅ Enabled cross-functional collaboration—instantly
But perhaps more important, it has opened the door to much more powerful enterprise features.
Why?
Because the data is no longer trapped inside spreadsheets.
It’s been moved to a structured, shared, independent backend—while Excel still serves as the dynamic and familiar front-end interface.
🛠️ How Was This Built?
It’s deceptively simple.
- We created a standard Microsoft Access database file (.accdb).
- We placed it in a shared network folder.
- We created two tables: one for budgets, one for the hierarchy (group map).
- We established a join between them on the shared field (operating unit).
- Then we closed the file. We don’t ever need to open it again.
From that point on:
- All data entry and uploads happen from Excel.
- All reports and consolidations are generated in Excel.
- The database simply acts as a central hub—quietly doing its job in the background.
If you wanted to scale this up to the cloud, all you would do is point Excel to a cloud-based version of the same tables (e.g., SQL Server, SharePoint Lists, Azure).
🧭 What This Really Means
This isn’t just a technical trick. It’s a transformational shift in how Excel is used in the enterprise.
Instead of cobbled-together files passed around manually, we now have:
- A structured data model,
- A single source of truth, and
- A flexible Excel interface that fits any user’s needs—CEO to analyst.
And we did it all with Microsoft Office tools we already had.
No Power BI licenses, no costly FP&A cloud platform, no IT development team.
Just one shared file we never even open.
🧱 No IT Bottlenecks Required
It’s important to emphasize: IT involvement is not required.
Indeed, that’s the whole point of Microsoft Office: to empower business users to solve business problems without being blocked by technical bottlenecks.
This approach aligns exactly with that philosophy.
Contrast that with the scenario described by Mark Proctor in his PDF.
While it’s common to hear “Excel is not a database,” what we’ve shown is that Excel can work hand-in-glove with a database—and when it does, it becomes an enterprise-grade solution.
📈 Real-World Impact: Four Clients Tripled My Rate
Finally, here’s a real-world result.
In four separate consulting engagements, I introduced this exact architecture—Excel plus relational backend—and each time, the client tripled my rate to retain the capability in-house.
Why?
Because it outperformed the IT-managed solutions they’d been trying for years to get right.
And it did so using tools they already owned.
🧠 Coming Up Next
In the next part of this series, we’ll explore the philosophical and systemic question:
Why don’t more people know this?
Why has something so simple and powerful been so widely overlooked—especially when it solves so many pain points in collaborative enterprise Excel use?
We’ll unpack the cultural, educational, and commercial forces behind that. But for now:
Yes—Excel can be a database front-end.
And no—it’s not hard.
You just need the right architecture.
Let me know if you’d like this version formatted for slide narration, PDF, voiceover script, or a LinkedIn carousel.
Add comment