Why does Excel cause so much pain in Finance?
By Hiran de Silva
Most people think of a spreadsheet as a document.
And they think of Excel as a document editor.
That sounds innocuous enough.
But I believe that one simple mental model explains an extraordinary amount of what has gone wrong with spreadsheets in business over the last thirty years.
Think about the way spreadsheets are commonly used.
Someone creates a workbook.
Someone else needs some information from it.
So the workbook is emailed to them.
Or perhaps it is placed on SharePoint.
They make some changes.
Another person makes some other changes.
Someone needs to consolidate the results.
Someone needs to work out which version is the latest.
Someone needs to establish why two versions no longer agree.
Someone eventually asks for an audit trail.
And somebody, usually in Finance, has the unenviable task of working out:
Who changed what?
When?
Why?
Which file did it come from?
And which number is actually correct?
We have built an enormous amount of spreadsheet practice around the assumption that this is simply what spreadsheets are.
Documents.
Excel is therefore a document editor.
Email becomes the transport mechanism.
SharePoint becomes the document store.
Consolidation becomes a separate exercise.
Version control becomes largely a question of naming files.
Governance becomes increasingly difficult.
Audit becomes forensic archaeology.
And as the spreadsheet process becomes larger and more critical, we introduce workarounds.
Then workarounds for the workarounds.
Each one introduces another layer of complexity and risk.
Eventually the spreadsheet that began life as a perfectly sensible little document becomes a critical Finance process that is bursting at the seams.
And someone says:
“Excel can’t cope with this.”
But there is another possibility.
Perhaps Excel isn’t the problem.
Perhaps the problem is the way we have been taught to think about Excel.
That is why I have created Excel for the CFO.
And the extraordinary thing is that the pivotal change I am proposing isn’t new.
It happened in the technology industry more than thirty years ago.
To understand its significance, however, we need to go back a little further.
Welcome to the 1980s
The personal computer revolution had begun.
For the first time in human history, computers were beginning to appear on ordinary people’s desks.
Not everybody’s desk.
Far from it.
The typing pool might have been upgraded to word processing.
The bookkeeper might have an accounting package.
A department might have a computer.
And somewhere in the organisation there was usually a whiz kid who seemed to know what all these mysterious machines did.
But these computers were largely self-contained.
They weren’t all seamlessly connected to one another.
Information frequently moved physically.
You printed something.
You sent it to another department.
Somebody keyed it into another system.
If you were more sophisticated, perhaps you put the data onto a floppy disk.
Remember those?
Three-and-a-half-inch diskettes.
And there was another important difference.
Under DOS, applications didn’t operate together in the way we now take for granted.
You loaded the software you wanted to use.
You did your work.
Then you left it and loaded something else.
You didn’t casually have your spreadsheet, database, email, browser, Teams, PowerPoint and half a dozen other applications open simultaneously.
The software we used was commonly called a package.
Some people of my generation still use the word.
Apparently, in 2026, the only other person who still has a package is Linford Christie.
But I digress.
The important point is that these software packages were necessarily self-contained.
The Four Components of an Application
Think about almost any business application.
I would divide it conceptually into four components.
First, presentation.
Something displays the result.
Perhaps it is a report.
Perhaps it is a screen.
Perhaps, in the 1980s, it was intended eventually to emerge from a dot-matrix printer.
Second, logic.
The application does something.
A payroll system calculates payroll.
A stock system determines stock positions.
A spreadsheet contains formulas.
There are rules governing what happens to the information.
Third, the user interface.
The human being needs some mechanism for interacting with the application.
In those days it might have been a green-on-black screen, 80 characters wide by 25 rows deep.
No mouse.
Boxes to type things into.
Function keys.
Enter.
Escape.
Very exciting.
And then there is the fourth component.
The really important one for our story.
Data.
Every application ultimately manipulates data.
If it is payroll, there are employees, salaries, tax rates, hours worked, bank details, cumulative tax and so forth.
If it is stock control, there are products, quantities, locations, movements and reorder levels.
And in the standalone computing world, the data naturally lived with the application.
Why wouldn’t it?
There wasn’t anywhere else for it to go.
That was completely normal.
But technology was about to make a very important change.
The Great Separation
During the 1980s and early 1990s, a number of technological developments began coming together.
Networking was one.
Computers could communicate.
Windows was another.
Multiple applications could coexist in an environment in a way that had been impossible in the old standalone DOS world.
Relational database technology was developing rapidly.
And gradually a different architecture became practical and increasingly mainstream.
Client-server.
The idea that matters to our story is beautifully simple.
Remember our four components?
Presentation.
Logic.
User interface.
Data.
What happens if we separate the fourth one?
What happens if the application continues doing exactly what it did before…
…but its data doesn’t have to live inside it?
Instead, the data resides centrally.
The application becomes a client.
The centrally managed data resource sits at the server end.
And suddenly something extraordinary becomes possible.
Different applications can interact through shared data.
The Sales department does something that changes the data.
Manufacturing can respond.
Stock falls below a threshold.
Purchasing can respond.
Finance receives new information.
Its processes can respond.
The departments don’t have to communicate by repeatedly printing information, sending it elsewhere and asking somebody to type it into another application.
The applications can communicate through data.
That may sound completely unremarkable today.
That’s because it worked.
It became normal.
But at the time it represented an enormous conceptual change.
Management Changes Too
There was another important development taking place at roughly the same time.
Management thinking was changing.
In 1993, Michael Hammer and James Champy published the hugely influential Reengineering the Corporation.
Business Process Reengineering encouraged organisations to stop blindly automating inherited departmental procedures and instead reconsider processes across the enterprise.
Technology was not the origin of that management philosophy, and Hammer and Champy did not invent client-server computing.
But the developments complemented each other powerfully.
Management was asking:
Why do we do things this way?
Technology was increasingly answering:
You don’t have to.
People such as Tom Peters were also challenging organisations to abandon comfortable old assumptions.
The result was a period in which businesses were highly motivated to rethink how information flowed through their organisations.
Remember something else.
This was before today’s Internet.
Before cloud computing.
Before broadband.
Many people hadn’t even encountered the World Wide Web.
Those who had will remember the excitement of watching an image load in a browser.
Slowly.
From the top.
Line…
by line…
by line.
A photograph could take several minutes.
If it happened to be a Playboy centrefold, anticipation was apparently part of the user experience.
That was the technological world in which this transformation was occurring.
Which makes what happened next in our story even more interesting.
What Has Any of This Got to Do with Excel?
Everything.
Because a spreadsheet was also an application.
Take Lotus 1-2-3.
Or early Excel.
It had presentation.
The worksheet.
It had logic.
The formulas.
It had a user interface.
The grid, menus, keyboard and eventually the mouse.
And it had…
data.
All four components.
Together.
Exactly like the other standalone applications of its era.
And that leads to an obvious question.
If separating data from applications transformed enterprise computing…
why shouldn’t the same principle apply to spreadsheets?
Imagine three people.
Tim.
Ted.
Todd.
Each has a spreadsheet.
Under the document model, collaboration requires those spreadsheets to travel.
Tim sends his workbook to Ted.
Ted sends something to Todd.
Todd sends something back.
Someone creates another version.
Someone copies it.
Someone changes it.
Someone sends it to six people.
Congratulations.
We now have six more spreadsheets.
Eventually those copies begin their own independent lives.
Numbers diverge.
Someone consolidates them.
Someone discovers they don’t reconcile.
Another spreadsheet is created to reconcile the spreadsheets.
And somewhere in the building, a CFO develops a headache.
We call this collaboration.
But what we are really doing is using document movement as a substitute for data flow.
That distinction is fundamental.
Now Remove the Data from the Workbook
Imagine exactly the same Tim, Ted and Todd.
They still have Excel.
They still have spreadsheets.
They still see familiar worksheets.
They still have formulas.
They still have reporting layouts.
They still have user interfaces.
They can still exploit everything that makes Excel such an extraordinarily useful business tool.
But there is one difference.
The operational data isn’t imprisoned inside their individual workbooks.
It is centrally located.
Tim updates something.
He updates the shared data.
Ted retrieves something.
He retrieves the shared data.
Todd does something that changes the business position.
He updates the same shared data.
Now we have something very different.
One trusted source.
One version of the truth.
People are no longer reconciling copies that have gradually wandered away from one another.
The spreadsheet becomes part of a system.
And suddenly many of the supposedly inherent problems of Excel begin disappearing.
Version proliferation.
Manual consolidation.
Broken external links.
Email dependency.
Reconciliation between competing copies.
The difficulty of establishing who changed what.
Governance.
Access control.
Auditability.
Scale.
Reach.
Collaboration.
The difference is so dramatic that I sometimes illustrate the two architectures with paintings.
The traditional spreadsheet environment looks like Jackson Pollock.
Data and documents flying everywhere.
The centrally organised model looks more like Piet Mondrian.
Structured.
Ordered.
Everything in its place.
Same Excel.
Different architecture.
The Digital Librarian
I have my own name for the central data component.
I call it the Digital Librarian.
A librarian doesn’t write your books for you.
A librarian doesn’t tell you what conclusions to draw from them.
The library shelves don’t calculate anything.
They hold information in an organised structure so that it can be reliably stored, identified and retrieved.
That is essentially what we need here.
The central relational database does not have to become some gigantic bespoke enterprise software development project.
It can simply be the trusted place where the data resides.
Tables.
Rows.
Columns.
Relationships where required.
The intelligence can remain where it is useful.
Including inside Excel.
For many departmental applications, the Digital Librarian can be something as humble as Microsoft Access.
At larger scale, perhaps SQL Server.
Or another relational database.
The principle is more important than the product.
Separate the data from the spreadsheet.
And Microsoft Provided the Plumbing
This is the part of the story that fascinates me.
Because Microsoft did not overlook this possibility.
During the development of the Microsoft Office generation of the early 1990s, Microsoft was actively developing connectivity between Office applications and external data.
There is a wonderful historical artefact from December 1993.
A Microsoft DevCast.
These were long technical broadcasts — essentially the ancestor of today’s online developer presentation.
One surviving recording is several hours long.
In the middle of it appears a young Microsoft engineer.
His name is…
Satya Nadella.
Yes.
That Satya Nadella.
And the first thing you notice is that he has hair.
But the second thing is considerably more important.
He demonstrates Excel 5 interacting with corporate inventory data.
The scenario itself is simple.
Inventory.
Reorder decisions.
But look beyond the example to what Microsoft was demonstrating.
Excel connecting to relational corporate data.
This was 1993.
Through developments including ODBC and subsequently Microsoft’s data-access technologies, this connectivity became increasingly accessible.
By the Excel 97 era, the plumbing necessary to use Excel within this client-server architecture had become remarkably practical.
And one of the technologies that became particularly important was:
ADO — ActiveX Data Objects.
My Own Discovery
I discovered this capability independently in the 1990s.
Not because somebody taught me enterprise Excel.
Nobody did.
I discovered it by doing something that became one of my principal methods of learning VBA.
I recorded macros.
I would get Excel to do something, record the macro and then examine the code Excel had written.
On one occasion I recorded a macro while using Get External Data with Microsoft Query.
I looked at the resulting code.
And there was the SQL statement.
A SELECT statement.
So I experimented.
What happens if I change the SQL?
And eventually came my breakthrough moment.
I replaced the SELECT with an INSERT.
And it worked.
Excel updated an Access database table.
I was jubilant.
Because suddenly the relationship was two-way.
Excel didn’t merely have to consume information.
It could participate in a process.
GET.
PUT.
Retrieve centrally managed data.
Update centrally managed data.
That discovery completely changed the way I thought about spreadsheets.
And I went on to use the principle in mission-critical client solutions.
Years later, when I discovered the 1993 DevCast recording, I found something wonderfully familiar.
Satya Nadella was demonstrating his example by recording a macro and exposing the SQL statement.
Almost exactly the route by which I had stumbled onto the possibilities several years later.
So Why Are We Still Emailing Spreadsheets Around?
This is the question that interests me enormously.
It is 2026.
We have had the plumbing for approximately thirty years.
Yet the dominant spreadsheet paradigm remains:
Create workbook.
Put data in workbook.
Manipulate data in workbook.
Save workbook.
Send workbook.
Receive another workbook.
Combine workbooks.
Reconcile workbooks.
Control workbooks.
Store workbooks.
Then complain that there are too many workbooks.
Why?
I think there are two important reasons.
Reason One: Popular Excel
The document model is extraordinarily easy to understand.
A beginner opens Excel.
There is a blank sheet.
You type things into it.
You add formulas.
You format it.
You save it.
You have created a document.
Naturally, almost everybody begins there.
And because the largest audience for education is inevitably people who have not yet reached the top of a discipline, popular Excel education gravitates towards that model.
Look at YouTube.
LinkedIn.
Certifications.
Courses.
Competitions.
Influencer content.
Excel is overwhelmingly presented as something that happens inside the workbook.
This is also why I make an important distinction between Popular Excel and Professional Excel.
Popular Excel has a perfectly legitimate purpose.
Its output is often engagement.
Interesting tricks.
New functions.
Clever formulas.
Eye-catching demonstrations.
That is a completely different objective from designing a mission-critical Finance process.
We should not confuse the two.
Even enormously useful technologies can become trapped inside the document paradigm.
Take Power Query.
Power Query is excellent technology.
But look at the dominant way it is taught.
Get data.
Bring it into my workbook.
Transform it for my purposes.
Wonderful.
But what happens next?
If the rest of the organisation needs the consequence of what I have just done, how does that information flow into the next process?
If the answer is:
“I’ll send them the workbook”
…we haven’t fundamentally changed the architecture.
We have simply made Tim better at operating inside the old architecture.
Reason Two: The Excel Replacement Industry
And then we arrive at something rather more interesting.
An entire industry has grown around solving the problems caused by spreadsheet-based Finance processes.
Its sales literature is remarkably consistent.
Too many spreadsheets.
Version-control problems.
Broken links.
Emailing files.
Manual consolidation.
No single version of the truth.
Poor governance.
Poor auditability.
Spreadsheet chaos.
Excel Hell.
And here’s the interesting bit.
I agree.
Those problems are real.
I’ve seen them.
You’ve seen them.
CFOs certainly experience them.
Where I disagree is with the diagnosis.
Because look carefully at what is frequently being compared.
On one side:
A collection of spreadsheet documents being emailed between people, containing duplicated data, using links and manual consolidation.
On the other:
A centrally managed, database-backed, client-server application.
And then comes the conclusion:
“Look how much better our system is than Excel.”
Hang on.
That isn’t necessarily a comparison between two products.
It may be a comparison between two architectures.
And that changes the question completely.
Because what happens if Excel is moved from the first architecture…
…into the second?
The Missing Question for the CFO
This, for me, is the reason Excel for the CFO needs to exist.
Before a CFO is told that Excel must be replaced because spreadsheets suffer from version control, consolidation, collaboration, audit and governance problems, shouldn’t somebody ask:
Could Excel operate within the same architectural principles being proposed by its replacement?
And the answer is:
Yes.
It has been able to do so for decades.
That does not mean Excel should replace every enterprise application.
Of course not.
Nor does it mean every spreadsheet should connect to a database.
That would be equally absurd.
It means something much simpler.
Architecture should be considered before product replacement.
And CFOs deserve to know that the option exists.
The Helicopter Salesman
Which brings me to my favourite way of explaining all this.
Imagine you are sitting in a monumental traffic jam.
You have somewhere important to be.
Perhaps you’re catching a flight.
Perhaps you have an important meeting.
Nothing is moving.
It is raining.
You are becoming increasingly desperate.
Then somebody taps on your window.
It is a salesman.
He has the answer.
A helicopter.
Traffic jams are terrible.
Cars get stuck in them.
Helicopters fly over them.
His logic is impeccable.
Then another salesman appears.
Another helicopter.
Then a third.
Three different vendors offering three sophisticated solutions to your traffic problem.
And given your current predicament, a helicopter sounds extremely attractive.
There are some minor inconveniences.
You have to abandon the car.
You somehow have to reach the helicopter.
You’ll presumably have to deal with the abandoned car later.
But never mind.
Anything is better than this traffic jam.
Except…
You happen to have discovered something.
There is a little switch on the dashboard of your car.
Almost nobody seems to know what it does.
You flick it.
Something remarkable happens.
Your car rises vertically.
One hundred feet above the motorway.
It transforms into a self-driving flying car.
You type your destination into the satnav.
And off it goes.
The three helicopter salesmen stand there watching you disappear into the distance.
Then the driver in the next car notices.
“Bloody hell! What did he just do?”
He looks around his dashboard.
Finds the same switch.
Flicks it.
Up he goes.
Another driver finds it.
Then another.
Before long the traffic jam itself begins thinning out.
Eventually the helicopter salesmen return to the office.
Their manager is delighted.
“You solved the gridlock?”
“Yes!”
“Fantastic!”
The whole sales team cheers.
“What an incredible day’s work!”
Then comes the obvious question.
“So how many helicopters did you sell?”
None.
The Switch
That is my proposition to the CFO community.
For thirty years, CFOs have been shown the traffic jam.
And the traffic jam is real.
Spreadsheet proliferation is real.
Version-control problems are real.
Consolidation problems are real.
Audit problems are real.
Governance problems are real.
Reconciliation problems are real.
The mistake is assuming that these things are inevitable consequences of using Excel.
They aren’t necessarily Excel problems.
Very often…
they are architecture problems.
And before buying the helicopter, perhaps the CFO should at least be shown the switch.
On Windows desktop Excel, one incarnation of that switch has been sitting there for decades:
Microsoft ActiveX Data Objects.
ADO.
It allows Excel to communicate with relational databases.
GET.
PUT.
Read.
Write.
Retrieve.
Update.
Excel becomes a client.
The relational database becomes the Digital Librarian.
And suddenly Excel can participate in exactly the architectural model that transformed enterprise computing more than thirty years ago.
Today there are other plumbing mechanisms as well.
Browser-based environments use web technologies.
JavaScript provides mechanisms such as fetch.
Office Scripts and modern APIs provide other routes.
ADO is not the philosophical point.
The separation of data from the spreadsheet is the point.
For the traditional corporate environment of Windows, desktop Excel and SQL Server or Access, ADO remains an extraordinarily straightforward way of demonstrating and exploiting the principle.
Excel for the CFO
So what is Excel for the CFO?
After this very long explanation, the answer is surprisingly short.
It is one pivotal shift in thinking.
From:
Excel as a document editor.
To:
Excel as a client in an enterprise information architecture.
From moving spreadsheets…
…to moving data.
From independent copies…
…to trusted central data.
From manual consolidation…
…to intrinsic consolidation.
From retrospective forensic audit…
…to designed-in auditability.
From spreadsheet proliferation…
…to spreadsheets participating in a common process.
From Jackson Pollock…
…to Mondrian.
This isn’t primarily about learning another clever Excel feature.
It isn’t about becoming faster with formulas.
It isn’t another course about shortcuts, dashboards, Power Query, PivotTables, Python or whatever happens to be fashionable this year.
Those things can all be useful.
But this sits one level above them.
It is about understanding architecture.
Because the CFO’s responsibility isn’t to become the world’s greatest Excel user.
The CFO’s responsibility is to ensure that Finance processes are efficient, controlled, scalable, auditable and capable of creating value.
And sometimes the most valuable question isn’t:
“What should replace Excel?”
It is:
“What could Excel do if we stopped using it like it was still 1989?”
That is Excel for the CFO.
And that is why I believe we need it.
Add comment