Refuting the “Rocket Science” Myth: Why Mark Proctor’s View on Excel Reconciliation Misses the Point

By Hiran de Silva

Podcast narrated by Charlie.

Mark Proctor is a respected voice in the Excel community, and in one of his videos, he walks through a method of performing account reconciliation using Power Query. It’s detailed and well explained—but it takes 45 clicks to set up and relies heavily on Power Query’s modern Excel interface. His conclusion? The more scalable, flexible, and automation-ready approach that I demonstrate—built using core Microsoft Office capabilities and simple VBA—is too advanced for his audience. In other words, it’s rocket science.

This article is a direct response to that claim.

A Tale of Two Architectures

Let’s start with the architecture. In my reconciliation demo workbook, there’s a sheet titled “Reconciliation Hiran.” It contains two dropdowns that let the user select any two account lists (stored as CSV files) for reconciliation. The process is this:

1. Select two account lists using dropdowns.
2. Click button one: it loads the first CSV.
3. Click button two: it loads the second CSV.
4. Click button three: the reconciliation is performed.

The output shows the totals of each list, a breakdown of reconciling items, and a verification check. You can try all combinations. You can upload new CSVs. It scales. It works unattended. It doesn’t require Power Query, nor does it require modern Excel knowledge.

This approach can set up an unlimited number of reconciliations to be carried out automatically in the background, unattended, as frequently as needed, or on demand. The results stored for later review, or anomalies notified to manager.

So what’s the real difference between this and Mark’s approach?

Mark’s architecture is Power Query-based. Local. Mine is built on the classic GET and PUT mechanism using VBA and ADO—capabilities that have existed in Microsoft Office for decades.

The Real Power Behind Microsoft Office

Mark argues that while my approach may be more scalable and enterprise-friendly, it is inaccessible to his audience of “citizen developers.” I disagree.

Why?

Because I’m using nothing that isn’t already included in Microsoft Office. This isn’t about advanced IT tooling. It’s about leveraging what users already have, and teaching them in a way that builds real understanding—principles, not just procedures.

Let’s be clear: ADO (ActiveX Data Objects) is built into Office. Access is part of Office Professional. Excel is a common user interface. These are not add-ons or niche developer tools—they’re standard features intended to empower users, not restrict them.

Mark’s narrative—that database connectivity is outside the grasp of average users—conflicts with Microsoft’s entire philosophy for Office. Indeed, you don’t achieve a certification in Microsoft Office User (MOS) without this knowledge. I would ask, if data concept are beyond the average user, how does Microsoft expect any significant take-up of recently-added tools and technologies such as Power Automate and Office Scripts?

Learning Through Logic, Not Memorization

A key principle of my approach is GET and PUT. Here’s the essence of it:

• GET: Retrieve data from a database into Excel.
• PUT: Upload data from Excel into a database.

To do this, we write a few simple lines of VBA. We connect to the database, run a SQL command, and either receive results or push data. That’s it. No rocket science.

Here’s the punchline: 80% of Excel users we tested were able to understand and apply these concepts after a short introduction—especially when the training included real-world logic puzzles like:

“Here’s a list of unknown length. How can we tell Excel when to stop looping?”

This is not a trick question. It’s the sort of practical thinking Excel users already do every day. We show them how to find the last row using .End(xlDown) or .Cells(iRow, Col).Value loops. It’s intuitive once explained, and vastly more powerful than just clicking through pre-recorded Power Query demos.

Teach Principles, Not Click Paths

Here’s where we part ways with Mark’s methodology.

Power Query demos are often taught like recipe cards: watch the clicks, then repeat them. That works—until the user encounters a slightly different problem. Then what? They go hunting for another video with that exact scenario.

With GET and PUT, we teach principles:

• What is a loop?
• How do you reference a cell dynamically?
• How do you stop at the end of data?
• How do you paste results into a report, fill a pivot table, or dropdown programmatically and dynamically?

Armed with these ideas, users can tackle any new challenge—not just the one they saw on YouTube.

Real Enterprise, Real Impact

We even go further. Imagine this use case:

• A central Access database holds all your rock stars and their bands.
• You create a dropdown in Excel that fetches a unique list of bands.
• When you select a band, Excel retrieves all members and their details (e.g. name, SSN, bank balance) onto the sheet.
• A colleague in Tokyo selects another band and does the same—without writing code, just clicking.

That’s real enterprise power. And it’s accessible. You don’t need to be a rocket scientist. You need to be shown how GET and PUT work—and how to think.

And there’s more. Your colleague in Tokyo adds a new band on his spreadsheet. Instantly, it appears in the dropdown in your spreadsheet!

In Conclusion

Mark’s claim that this is “too advanced” reflects a misunderstanding of what “advanced” really means. Complexity is not the same as difficulty. Power Query might seem more friendly because it hides the logic behind a GUI—but it’s actually harder to scale, reuse, and adapt without deep platform knowledge.

By contrast, my approach—based on Office-native capabilities and logical teaching—gives users tools they already have and the mindset to use them well.

This isn’t rocket science.

It’s just good Excel.

And the best way to find out? Test it. Teach both methods. Watch who learns faster, solves better, and enjoys more autonomy.

Because real empowerment doesn’t come from simplifying the tool—it comes from demystifying the architecture.