Building a Reconciliation Tool in One HTML File

Written about a prototype I built for an internal innovation challenge. No company data, systems or figures appear here.

Every day, somebody compares two spreadsheets.

One lists what was planned. The other lists what happened. Someone checks that they match, finds the differences, and tells the right people. It takes a while, and it’s easy to miss things when you’re tired.

I wanted to see if a small tool could do the first pass. I built a prototype in about two weeks, and it’s a single HTML file.

You open it in your browser, drop in two Excel files, and it highlights the differences. Nothing is installed. Nothing is uploaded to a server. I used AI as a reference while I built it.

Here’s what I learned.

Why one file?#

The best tool is the one people will actually use.

A single HTML file means no installation, no permissions request, and no server for anyone to approve. You can email it, open it, and see it work. That removes most of the reasons people give for not trying something.

It uses a library called SheetJS to read Excel files in the browser itself.

Three rules I set before writing any code#

Read-only. The tool never changes the source files. This is the first thing people ask about, and “it can’t” is a very reassuring answer.
Show the urgent things first. Items closest to breaching a service level go to the top. A list sorted alphabetically is a list nobody reads.
Never score individuals. It compares work items, not people. I decided this early, and I’d decide it again. Tools that quietly evaluate staff lose trust fast.

Constraints are a feature. Each rule made the tool easier to trust.

It broke on the first real file#

In testing, it worked beautifully.

Then I tried a real spreadsheet. A title row at the top, a header on row three, a few merged cells. It fell over immediately.

My clean test file looked nothing like what people actually use. I had built for the spreadsheet I wished existed.

I rewrote the parser to find the header row rather than assume it, and to handle gaps without crashing. Then I kept a small set of rows where I knew the right answer, and checked them every time.

Test on messy, real input early. Your sample data is lying to you.

Product decisions still matter#

Writing code isn’t the hard part anymore. These were the questions I had to answer myself:

Q: What should it do when two rows nearly match?
- A: Flag it, don’t guess. A wrong silent match is worse than a visible question.
Q: How should it show differences?
- A: One screen, sorted by urgency, with a short reason beside each item.
Q: What happens when a file is in the wrong format?
- A: A plain message saying what’s wrong and how to fix it.
Q: Should it try to be smart?
- A: Not yet. Simple rules first, and a human decides.

I could have asked for ten more features. Most of them would have made it worse.

Numbers should be honest#

A nice number you can’t defend is worse than no number.

What I’d do differently#

Talk to the people doing the work before writing code, not after.
Write the test rows first.
Make the first screen simpler.

Conclusion#

I learned more about spreadsheets, parsing, and trust than I expected. Do I expect this prototype to change the world? No. But it taught me that a small, careful tool beats a big, impressive plan.

If you do the same repetitive task every day, try to build one small thing for it. It doesn’t need to be perfect. It just needs to exist.