By Hiran de Silva — Former CFO, Consultant to CFOs, Author of Triple Your Pay with Excel and The Miracle of Excel
The question that changes the debate
There is a familiar argument that regularly appears in discussions about Excel, particularly on LinkedIn.
Someone describes a business problem. Someone else proposes an Excel solution. And then comes the seemingly authoritative response:
“This isn’t a job for Excel. You need a purpose-built system.”
End of discussion?
Not quite.
Because whenever I hear that response, I have a question.
What, exactly, do you mean by a purpose-built system?
And, more importantly:
What is the difference between your purpose-built system and the enterprise-grade Excel solution that I am proposing?
These are not rhetorical questions. I genuinely want to understand what the other person believes the difference to be.
I have been involved in this kind of debate many times. A recent LinkedIn discussion with Phil brought the issue back into focus. Another memorable example was Paul Barnhurst’s response to my REG Call Handler demonstration in March 2024.
Within minutes of the demonstration appearing, Paul responded that this was not a job for Excel. It needed a purpose-built system.
That is precisely where I would want the conversation to begin.
Not with competing declarations about which technology is better. Not with opinions about whether Excel is good or bad. And certainly not with the assumption that putting the words purpose-built in front of system settles anything.
I want to narrow the argument to the actual point of difference.
And then examine it.
Because something rather interesting happens when we do.
1. The invisible dividing line in people’s minds
I suspect there is a deeply ingrained perception behind these arguments.
On one side are people who create spreadsheets.
On the other are people who develop enterprise software.
And there appears to be an assumption that the second group possesses knowledge, skills and capabilities that the first group does not.
There is also an assumption about scale.
Spreadsheets are associated with relatively small, personal or departmental tasks. Enterprise systems are associated with large-scale operations, collaboration, governance, security and control.
Therefore, when a business problem grows beyond a certain scale, the reasoning goes, it must also grow beyond Excel.
I understand why people think this way.
After all, the Excel practices that most people encounter reinforce precisely that perception.
They see spreadsheets being emailed between colleagues. They see version-control problems. They see disconnected processes. They see manual consolidation, fragile formulas and endless reconciliation.
They see the familiar problems of what I call Excel Hell.
And they conclude that Excel itself is responsible.
But there is an important distinction that seems to be missing.
The limitations of a particular way of using Excel are not necessarily limitations of Excel’s capabilities.
And the knowledge and capabilities of a particular group of spreadsheet users should not be confused with the boundaries of the technology they are using.
This distinction is fundamental.
Because Excel can participate in an enterprise client-server architecture.
It has been capable of doing so for decades.
And that changes the entire debate.
2. The first revelation: both solutions can use the same architecture
Let us imagine that we have two proposed solutions to the same business problem.
One is described as a purpose-built enterprise system.
The other is an enterprise-grade Excel solution.
Now let us examine their architecture.
Purpose-built application
Browser / AppClient interface
Business logic / APIs
SQL ServerCentral data
Enterprise Excel
ExcelClient interface
Business logic / APIs
SQL ServerCentral data
Illustrative comparison: the enterprise architecture can be equivalent, while the client technology differs.
First, the server.
Both solutions can use exactly the same relational database technology.
SQL Server, for example.
The same tables. The same relationships. The same stored procedures. The same transactional integrity. The same permissions, governance and audit requirements.
There is no inherent architectural difference.
Second, the business logic.
The processes, rules, calculations and workflows are determined by what the business needs to accomplish.
They are not determined by whether the person operating the system is looking at a spreadsheet or a browser.
A budget approval rule is a budget approval rule.
A reconciliation is a reconciliation.
A consolidated report is a consolidated report.
The logic can be designed independently of the client technology and implemented in the appropriate layer.
So far, therefore, the two proposed solutions can be architecturally equivalent.
Now we arrive at the client.
And here, finally, is where we have a genuine difference.
In the purpose-built solution, the client might be a web browser or a custom application.
In the enterprise Excel solution, the client is Excel.
We have narrowed the debate from a sweeping claim about enterprise capability to a specific question about the suitability of the client interface.
That is a much more useful discussion.
And it is the discussion I have been trying to have.
3. So which client interface is better?
Now we can make a meaningful comparison.
A browser-based application offers substantial advantages in certain circumstances.
It can be made accessible across different operating systems and devices. It can be centrally deployed and updated. It can provide a consistent interface to large numbers of users without requiring them to install a particular desktop application.
Modern browsers can also provide sophisticated, interactive user experiences.
But they do not automatically provide a better experience for every business task.
And this is where the nature of the work matters.
Consider accounting, finance, budgeting and management reporting.
These activities often involve substantial quantities of information that people need to examine simultaneously.
A finance manager might need to review twelve months of expenditure, compare actuals with budgets, inspect variances, change assumptions, consider alternative scenarios and immediately observe the financial consequences.
This is not simply a matter of entering data into a form.
It is an interactive analytical activity.
And the spreadsheet paradigm is extraordinarily well suited to it.
Excel provides a rich, mature environment for displaying, manipulating, calculating, analysing and presenting substantial quantities of structured information.
The user can navigate freely around a large model. They can inspect relationships, explore alternatives and interact with the information in ways that would require deliberate development in a custom application.
Could a browser-based system reproduce those capabilities?
Certainly, many of them.
But at what development cost? With what flexibility? And how easily can the resulting interface be modified as the business changes?
Those are legitimate questions.
A custom desktop application may offer greater design freedom, and a mobile application might be ideal for a simple approval process.
If all the user needs to do is inspect a request and press Approve or Reject, a mobile app could be excellent.
But suppose the user needs to review an entire departmental budget, understand the implications of twenty proposed adjustments and make an informed financial decision.
Now the relative strengths of the different interfaces become much more interesting.
The answer is not that Excel must always win.
The answer is that the client technology should be chosen according to the work the user needs to perform.
And in many finance and accounting scenarios, Excel begins with a considerable advantage.
4. One small step for a spreadsheet. One giant leap for the enterprise.
Now let us approach the question from the Excel user’s perspective.
Consider a conventional annual budgeting process.
Every department has a spreadsheet.
The spreadsheets contain formulas, assumptions, historical information, forecasts and the familiar structures that departmental managers already understand.
These spreadsheets are emailed to finance.
Finance consolidates them.
Changes are requested.
Revised spreadsheets arrive.
Different versions circulate.
Someone asks which version is correct.
Someone else asks who changed a particular number.
The CFO wants to know how the current consolidated budget differs from the version presented last week.
And the finance team begins another round of investigation.
This is Excel Hell.
It is real. I have encountered it.
But what is the underlying architectural problem?
The data is distributed across numerous independent files.
The spreadsheets are being used not only to interact with information but also to hold the authoritative data.
And that is the problem we need to address.
Now consider a remarkably simple change.
We separate the data from the spreadsheets and store it centrally.
The departmental spreadsheets remain.
The formulas remain.
The familiar layouts remain.
The users continue working with the interfaces they already know.
But instead of emailing their completed spreadsheets to finance, they press a button.
PUT.
Their data is submitted to a central relational database.
When they need current information, they press another button.
GET.
The spreadsheet retrieves the appropriate information from that same central source.
Of course, a production implementation must also provide validation, transaction handling, permissions, concurrency controls and audit logging.
But those are established database engineering practices.
We are not inventing a new technology.
We are applying an established architecture.
And look at what has changed.
The authoritative data no longer needs to travel around the organisation in emailed spreadsheet attachments.
Finance can retrieve current submissions directly.
The consolidation can be performed centrally.
Changes can be logged.
Users can work with controlled versions of the information.
Multiple participants can contribute to the same enterprise process without maintaining independent, competing records.
The transformation is enormous.
Yet, from the perspective of the spreadsheet user, the visible change can be remarkably small.
The familiar spreadsheet remains.
It has simply acquired enterprise capabilities through a relational database.
That is why I describe this as:
One small step for a spreadsheet. One giant leap for the enterprise.
5. The Digital Librarian
I have a name for the central capability that makes this possible.
The Digital Librarian.
Think about what a librarian does.
A librarian does not write every book, nor does the librarian dictate how every reader must read.
The librarian maintains an organised collection, ensures that information can be located and provides controlled access to it.
Our Digital Librarian performs an analogous role for enterprise data.
It maintains the central records.
It provides controlled methods for submitting information and retrieving it.
It enables different users and applications to work with the same authoritative data.
And, crucially, it does not require every user to adopt the same client technology.
An Excel workbook on Windows might use the service.
An Excel workbook on a Mac might use it.
A browser application could use it.
A mobile app could use it.
A Google Sheets solution could also participate, using an appropriate connection mechanism.
The clients may differ.
The authoritative data remains central.
This is the essential principle.
A relational database extending the capabilities of Excel, while also enabling other applications to participate in the same enterprise process.
It is not a choice between Excel and enterprise architecture.
It is Excel participating in enterprise architecture.
And once a CFO understands this, the implications extend far beyond the original problem.
The same principle can be applied to budgeting, forecasting, expense claims, management reporting, account reconciliation, operational reporting and many other collaborative processes.
The possibilities become apparent.
Because the architectural problem was never necessarily the spreadsheet.
It was the way the spreadsheets were being used.
6. Now let us reverse the challenge
Having demonstrated what can be achieved by extending Excel with a relational database, I want to turn the question around.
To the advocates of purpose-built systems, I ask:
Please show me how your proposed alternative improves upon this solution.
Not in general terms.
Not by repeating that Excel is unsuitable for enterprise work.
Not by showing a polished dashboard accompanied by a list of product features.
Show me how your solution performs the actual business task.
Take my annual budgeting model.
We have departmental managers working with their familiar budget spreadsheets.
They submit their data centrally.
Finance can retrieve and consolidate the information.
Management can examine proposed adjustments.
And the effects of those adjustments can be reflected in the consolidated budget during the review process.
Now show me how your purpose-built system accomplishes the same thing.
Can it reproduce the functionality?
Can it provide the same degree of user interaction?
Can it respond immediately to changing assumptions?
Can it support the existing budgeting process without requiring a wholesale redesign of the way managers work?
How much does it cost?
How long does it take to implement?
And when the business changes its requirements next month, who can make the necessary modifications?
These are not unreasonable demands.
They are precisely the questions that should be asked when comparing alternative solutions.
And they are the questions that a CFO ought to be asking.
7. A budgeting meeting that exposes the difference
Let me give you a practical example.
Imagine a budget review meeting.
The CFO and departmental managers are examining the proposed annual budget.
A manager suggests reducing expenditure in one area and increasing it in another.
The adjustment is entered.
The consolidated position is refreshed.
The financial implications are immediately visible.
Another manager raises a concern.
A further adjustment is proposed.
Again, the implications can be examined during the meeting.
The discussion proceeds.
Decisions are made.
The meeting moves to the next item.
This is not science fiction.
It is the kind of capability that can be engineered using Excel and a relational database.
Now consider the alternative.
Suppose the proposed purpose-built system cannot accommodate the same interaction within the meeting.
Suppose the users must submit changes through a separate process, wait for a consolidation cycle and return later to examine the results.
What happens?
Do we adjourn the meeting?
Come back in three days?
Then discuss the next adjustment?
And return three days later?
There are twenty items on the agenda!
At that rate, a meeting that could have been completed in thirty minutes might stretch across weeks.
I am not suggesting that every purpose-built planning system behaves like this. Some are designed specifically for real-time collaborative planning.
That is exactly why the demonstration matters.
Show me what your system actually does in this scenario.
If it performs better, demonstrate that.
If it performs equally well, demonstrate that.
And if it performs less well, acknowledge that too.
But please do not tell me that the solution is superior simply because it is called purpose-built software.
That is a description.
It is not evidence.
8. Marketing claims meet the demonstration
This brings us to a wider problem in the software industry.
Consider the marketing of Excel replacement products.
Workday Adaptive Planning has promoted its Nine Circles of Excel Hell.
The messaging draws attention to familiar spreadsheet problems, including consolidation and the difficulties of managing complex planning processes.
But those problems need to be examined carefully.
Are they inherent limitations of Excel?
Or are they consequences of a particular spreadsheet architecture?
Because if a central relational database eliminates the relevant problems while preserving the advantages of the spreadsheet interface, the comparison changes substantially.
The argument is no longer between a chaotic collection of emailed workbooks and a centrally managed enterprise system.
It becomes a comparison between two centrally managed enterprise solutions.
One uses Excel as its principal client.
The other uses a different client technology.
That is a very different contest.
Similarly, I have encountered claims that Excel cannot perform bottom-up budgeting.
But what does that claim mean?
Does it mean that an individual, disconnected workbook is unsuitable for coordinating a large enterprise budgeting process?
That may be a perfectly reasonable observation.
Or does it mean that an enterprise-grade Excel solution, supported by a relational database, cannot perform bottom-up budgeting?
Because that is a much stronger claim.
And it is contradicted by a working example that performs precisely that function.
A demonstration has a rather inconvenient habit of exposing the weaknesses in sweeping generalisations.
Once an audience has watched something being done, telling them that it cannot be done becomes rather difficult.
9. My challenge to Planful
At a GenCFO Academy panel discussion in November 2023, I heard Justin Merritt of Planful discuss the difficulties organisations experience when using spreadsheets for consolidation and account reconciliation.
His argument was that better tools exist for these activities.
Fair enough.
Let us examine that proposition.
First, I would want to establish precisely what problem is being addressed.
Are we discussing the difficulties of consolidating dozens of independently maintained spreadsheets?
Or are we discussing a centrally managed process in which Excel users submit information to a relational database and retrieve consolidated results?
Because those are not the same thing.
If the criticism concerns the first arrangement, we may well agree.
I would not recommend a sprawling collection of disconnected spreadsheets as the architecture for an enterprise budgeting system either.
But if the criticism is intended to apply to the second arrangement, I would ask Justin to demonstrate the superiority of the alternative.
Take the budgeting meeting I have just described.
Show me how Planful handles it.
Show me how managers review, amend and consolidate their budgets in real time.
Show me the user experience.
Show me how the system accommodates changing business requirements.
Show me the implementation and ongoing costs.
And then let us compare those outcomes with the enterprise Excel model.
I am not asking for a marketing presentation.
I am asking for a comparison of working solutions to the same business problem.
That is a fair challenge.
And it is a challenge I would extend to Anaplan, Workday Adaptive Planning, custom-built applications and anyone else who claims that their alternative is superior.
10. What does purpose-built actually mean?
There is another interesting dimension to this debate.
The expression purpose-built sounds reassuring.
It suggests that a solution has been designed specifically to meet the requirements of the business.
But consider this.
When I design an enterprise Excel solution for a particular organisation, I start with the business problem.
I examine the processes.
I examine the users.
I examine the information they need, the decisions they make, the relationships between departments and the controls required by management.
I design the data architecture.
I determine the business logic.
I design the user interactions.
And I build a solution specifically to accomplish those objectives.
What is that, if not purpose-built?
The fact that Excel provides the client interface does not make the solution any less purpose-built.
Indeed, a custom enterprise Excel solution may be more closely aligned with the particular requirements of a business than a commercial software package designed to serve thousands of different organisations.
A commercial product may offer valuable functionality, mature controls, integration capabilities, support and economies of scale.
Those advantages deserve consideration.
But they do not arise simply from the fact that the product is not Excel.
Nor does a custom Excel solution become inferior merely because it uses a familiar spreadsheet interface.
The label tells us very little about the actual suitability of either solution.
We need to examine what has been built.
And why.
11. The real test is not the technology. It is the outcome.
I would like to see these debates conducted differently.
Instead of beginning with a preferred technology, begin with the business requirement.
Define the problem.
Define the desired outcome.
Identify the participants, the information flows, the controls, the required responsiveness and the expected scale.
Then examine alternative architectures and client technologies.
If the task requires hundreds of users to make simple approvals on mobile devices, a browser or mobile application may be the obvious choice.
If the task requires complex, interactive financial modelling involving large quantities of tabular information, Excel may offer substantial advantages.
If the organisation requires a combination of both, there is no architectural reason why both cannot participate in the same system.
That is one of the benefits of separating the data from the client.
It gives us choices.
And it allows those choices to be made according to the actual requirements of the business.
This is also why I believe the discussion needs to move beyond the familiar argument about whether Excel is a database.
That is not the proposition.
The proposition is that a relational database can extend Excel’s capabilities, enabling Excel to participate in enterprise-scale processes while retaining its strengths as a user interface.
It is a well-established architectural principle.
And it deserves to be understood before anyone declares that Excel must be replaced.
12. The gauntlet remains on the table
My approach to these discussions is deliberate.
I do not want to spend hours exchanging general opinions about Excel.
I want to find the precise point at which two people disagree.
If someone says that enterprise work requires a client-server architecture, I agree.
If they say that enterprise data requires central governance, I agree.
If they say that large-scale collaborative processes require security, auditability, transaction integrity and controlled access, I agree.
We have no disagreement about those requirements.
Now, if they say that those requirements mean we must abandon Excel, I ask:
Why?
Which particular requirement cannot be met by an enterprise-grade Excel solution?
Which capability is missing?
Which business process cannot be supported?
And how does the proposed alternative perform that process better?
This is where the debate becomes interesting.
Because we have moved away from labels, perceptions and assumptions.
We are now examining actual capabilities.
I am perfectly willing to accept that another technology may be better suited to a particular task.
But I want to see the evidence.
And I expect the same standard to be applied to Excel.
A comparison between a badly designed spreadsheet process and a professionally engineered enterprise application proves very little about the relative capabilities of the technologies.
It tells us a great deal about the difference between bad design and good design.
So let us compare professionally engineered solutions on both sides.
Let us give Excel the same architectural foundations, the same database capabilities and the same engineering discipline as the proposed alternative.
Then let us examine the remaining differences.
And let us do so in the context of a real business problem, with real users and real requirements.
That is the challenge.
Not Excel versus enterprise architecture.
Not spreadsheets versus databases.
Not amateur spreadsheet creators versus professional software developers.
But two solutions, designed to meet the same business requirements, subjected to the same practical tests.
And if the only material difference is the technology used for the client interface, let us evaluate that difference on its merits.
Because there is a final question that I would put to anyone promoting a purpose-built system as inherently superior to Excel.
If the database is the same, the business logic is the same, the enterprise controls are the same, and the required outcomes are the same, what exactly makes your choice of client technology superior to mine?
Show me.
That is where the real debate begins.
Hiran de Silva is a former CFO, consultant to CFOs, and author of Triple Your Pay with Excel and The Miracle of Excel. His work focuses on extending Excel’s capabilities through relational database architecture to create enterprise-grade business solutions.
Add comment