An Empirical Test with the ‘Accounts Model’

By Hiran de Silva

There is a fairly reasonable assumption about technological progress.

Time moves forward. Technology improves. Capability increases. And what we are able to accomplish should improve with it.

Computers become faster. Storage becomes cheaper. Networks become more powerful. Software acquires new capabilities. Knowledge accumulates. Techniques developed by one generation become the foundations upon which the next generation builds.

Moore’s Law is perhaps the most famous technological expression of this idea. Strictly speaking, Moore’s Law concerned the historical tendency for transistor counts on integrated circuits to roughly double over a period of about two years—not five—but the broader principle is familiar.

Technological capability compounds over time.

And that gives us an interesting opportunity with Excel.

Because Excel has now existed for more than 40 years.

During that period we have moved from relatively primitive desktop computing through Windows, ubiquitous corporate networks, the Internet, cloud computing, enormous increases in processing power and, most recently, artificial intelligence.

Excel itself has changed enormously.

We now have Power Query.

Dynamic arrays.

LAMBDA.

Office Scripts.

The Power Platform.

Cloud integration.

Python.

Copilot.

And, outside Excel itself, generative AI systems such as ChatGPT.

So here is the research question.

What has nearly 30 years of technological progress actually done to our ability to solve a real business problem with Excel?

Not theoretically.

Not according to a feature list.

Not according to Microsoft’s marketing material.

And not according to what happens to be fashionable on social media.

Empirically.

We are going to take a genuine business requirement from 1997 and ask how we would solve it today.

There is one unusual advantage to this experiment.

I still have the 1997 solution.

So we can actually compare them.

---

The Research Proposition

The experiment begins with a very simple proposition.

If technological progress works as we normally expect it to work, then a competent Excel practitioner in 2026 should have considerably greater capability available to solve this problem than I had available to me in 1997.

Nearly three decades have passed.

The technology is vastly more powerful.

The software is vastly more sophisticated.

The educational resources available are incomparably greater.

We have YouTube, LinkedIn, online courses, forums, Microsoft documentation and communities of Excel experts sharing knowledge globally.

And now we have AI.

Therefore, the modern solution should surely demonstrate some substantial advancement over the solution developed with the technology and knowledge available in 1997.

That is the proposition we are going to test.

---

The Historical Business Requirement

The experiment is based upon an actual requirement that emerged at one of my clients in 1997.

The accounting system produced the organisation’s monthly accounts.

Among those reports were Profit & Loss statements.

There was an overall company P&L and approximately 60 departmental P&Ls, one for each budget holder.

At the time, these reports essentially came out of the accounting system as reports.

I saw an opportunity.

Instead of treating the monthly accounts simply as reports produced by the accounting system, what if we could distribute them electronically through Excel?

That gives us Level One of the experiment.

---

Level One — Distribute the Accounts

The accounting system contains the underlying financial data.

There are approximately 60 departments.

Each department has a budget holder.

The requirement is:

Produce approximately 60 departmental Profit & Loss statements in Excel and distribute the appropriate accounts to each budget holder.

The spreadsheet should reproduce the required accounting presentation.

That is the first challenge.

Imagine that this requirement arrived on your desk today.

How would you approach it?

What technology would you use?

What would you automate?

Where would the data reside?

Would you use Power Query?

Dynamic arrays?

Office Scripts?

Power Automate?

Python?

VBA?

SQL?

Copilot?

Something else?

Or some combination of them?

At this stage, there is no prescribed answer.

We are interested in the thinking.

---

Level Two — Explain the Numbers

Now we introduce the next business problem.

When budget holders receive their departmental accounts, they naturally look through them.

And sooner or later somebody sees a number they do not understand.

Perhaps Travel is £17,463.

The budget holder wants to know:

What is that £17,463 made up of?

Historically, the response was predictable.

They contacted somebody in Accounts.

The accountant then had to stop what they were doing, return to the accounting system, investigate the transactions and explain the number.

Multiply that across 60 budget holders and numerous P&L lines and it becomes a substantial interruption to the monthly accounting process.

So Level Two is:

Provide the budget holder with the transaction-level breakdown behind the numbers in their P&L.

They should not have to telephone Accounts merely to discover what a number consists of.

Again:

How would you accomplish that today?

---

Level Three — Capture the Queries

Giving people the detail does not eliminate every question.

A budget holder might discover a transaction that appears to belong to another department.

They might question an accrual.

They might identify an incorrect allocation.

They may simply need clarification.

Therefore, the system now needs to work in the opposite direction.

The budget holder must be able to communicate a query or proposed correction back to Finance.

So Level Three is:

Provide a controlled mechanism through which approximately 60 budget holders can submit queries, comments and potential adjustments back to the Finance team.

Now we are no longer merely distributing spreadsheets.

We have information moving in both directions.

How would you design that today?

---

Level Four — Manage the Deluge

Success creates another problem.

Suppose dozens of budget holders submit comments.

Finance now potentially has a deluge of queries and proposed adjustments.

Some are valid.

Some are not.

Some require journal entries.

Some require explanations.

Some may already have been dealt with.

Finance therefore needs to see, manage and process the incoming information systematically.

Level Four becomes:

Provide Finance with a consolidated mechanism for reviewing, managing and actioning the queries and proposed adjustments received from all 60 budget holders.

The problem has now moved considerably beyond spreadsheet calculation.

We are dealing with workflow.

Status.

Control.

Consolidation.

Auditability.

And multiple users.

How should Excel participate in that process in 2026?

---

Level Five — Close the Loop

Finally, Finance makes the appropriate adjustments.

The accounts change.

But the process is not complete until the revised accounts return to the budget holders.

They need to review the final numbers and confirm that they are satisfied.

Therefore, Level Five is:

Redistribute the revised accounts to the 60 budget holders and provide a mechanism through which they can confirm approval of the final version.

The circle is now complete.

Accounts → Budget Holder → Finance → Revised Accounts → Budget Holder Approval.

That is the complete business process.

---

The Experiment

We now have our benchmark.

It is deliberately based upon a normal business requirement rather than a contrived Excel puzzle.

Participants are not being asked to demonstrate a particular feature.

They are being asked:

Given the Excel ecosystem available today, how would you solve this business requirement?

Importantly, the five levels should initially be considered sequentially.

This allows us to observe something potentially more interesting than the finished solution.

We can observe how the architecture develops as the requirement develops.

Does the Level One solution naturally accommodate Level Two?

Does Level Two survive Level Three?

Or does each new requirement require another technology, another workbook, another process or another workaround?

At what point—if any—does the participant realise that the problem is not fundamentally about producing spreadsheets?

That is itself part of the experiment.

---

What We Will Measure

The comparison should not simply ask whether a proposed solution technically works.

We should evaluate it across several dimensions:

• Architecture — Is this a collection of documents or a coherent business process?
• Scalability — What happens at 60 users? What happens at 600?
• Automation — How much human intervention is required each month?
• Data integrity — Where is the authoritative version of the data?
• Distribution — How efficiently does information reach the correct people?
• Feedback — How efficiently does information return from those people?
• Auditability — Can we establish who did what, and when?
• Maintainability — What happens when departments, account codes or requirements change?
• Security and access — Can users see only what they are entitled to see?
• Performance — How efficiently can information be retrieved and updated?
• User experience — What does the budget holder actually have to do?
• Finance workload — Does the system eliminate work or merely move it around?
• Technical complexity — How much technology is required to achieve the result?
• Explainability — Can somebody else understand and support the solution?
• Dependency — How many products, services, platforms and specialist skills are required?

And perhaps most importantly:

Which modern technologies actually contribute something useful to solving the business requirement?

Having a feature available does not necessarily make that feature relevant.

---

The Control Sample: 1997

There is one final component to the experiment.

After the modern approaches have been considered, we introduce the control.

The working solution developed in 1997.

This is important.

I do not intend merely to describe what I remember doing nearly 30 years ago.

I have a working model from that period.

We can therefore examine the actual architecture and compare its capabilities with the solutions proposed today.

That changes the nature of the exercise.

This is no longer:

Was Excel better in the old days?

Nor is it:

Is Modern Excel better than old Excel?

Those would largely be matters of opinion.

Instead, we have something much more interesting.

The same business problem.

Two points in technological history.

Observable solutions.

Comparable outcomes.

---

The Central Research Question

The obvious expectation is that the 2026 solution will outperform the 1997 solution.

After all, it has nearly 30 years of technological progress behind it.

But there is another possibility.

Technology may have progressed while professional competence in applying Excel to certain classes of business problem has not progressed with it.

It is even possible that some knowledge once available to practitioners has become less visible as attention has shifted towards different features, techniques and definitions of Excel expertise.

That is a much more provocative hypothesis.

But it is only a hypothesis.

The purpose of this project is to test it.

If today’s approaches produce cleaner, faster, more scalable, more maintainable and more controlled solutions, the experiment should demonstrate that.

If the 1997 architecture remains competitive, that is interesting.

And if the 1997 architecture solves dimensions of the problem that many contemporary approaches fail even to recognise…

that is extremely interesting.

Because it would suggest that technological progress and professional progress are not necessarily the same thing.

---

Excel: 1997–2026

Last year marked Excel’s 40th anniversary.

Understandably, much was written about how far Excel has come.

This project proposes a slightly different anniversary celebration.

Instead of examining the product brochure, we examine a business problem.

Instead of counting features, we measure capability.

Instead of asking what Excel can do, we ask what people know to do with it.

And instead of assuming that 30 years of technological progress must have produced 30 years of corresponding professional progress…

we test it.

One real business requirement.

Five levels of increasing organisational complexity.

A modern Excel ecosystem containing some of the most sophisticated technology ever available to spreadsheet users.

And, sitting quietly on the other side of the laboratory…

a working Excel solution from 1997.

Let the experiment begin.