What changed since last week
Somebody on your team does this every month. Export this month’s run to a spreadsheet. Export last month’s beside it. Write a lookup down one column, colour the mismatches by hand, then spend the afternoon explaining to the person who asked that four of the twelve differences are not differences at all, they are lines that were added.
It is the most common thing anybody does with a grid and almost no grid does it for them. So the work leaves the screen where the data lives, moves into a spreadsheet nobody else can see, and arrives back as a screenshot in an email.
Point it at last month and ask
The grid above is holding this month’s billing run, 18,001 lines, with last month’s signed-off run of 18,000 behind it as a baseline. Nothing was exported to get there.
Five lines moved. Each one is banded, the cell that actually changed is tinted,
and inside that cell, beside the new figure, is the old one with a line through
it. Line BL-000002 went from 35 units to 41, and both numbers are on the
screen without opening anything. Three lines are new this month and carry their
own mark, in their own colour, so nobody mistakes an arrival for a change. Two
lines that were on last month’s run are not on this one at all, and since they
are not in this month’s data there is no row to paint: the grid answers that
question instead of drawing it. The eye on the rail names them.
Five changed, three added, two removed. That is the whole reconciliation, and nobody had to build it.
The part that matters in a review is that everything else on the screen still works. Sort by amount and the marks travel with the rows. Filter to one account and the changes inside that account are still marked. Group by region and the totals are still correct. The comparison is not a separate view you switch into and lose your place in, it is a property the rows carry while you carry on working.
The comparison you do not use is free
The reason a feature like this normally arrives as a separate screen is cost. Comparing every cell of eighteen thousand rows against eighteen thousand other rows, before anybody has asked anything, is a real bill, and a grid that pays it on arrival gets slow in exactly the situation where you have most data.
This one does no comparing until it is asked. The baseline sits there as rows. The first question indexes it, once, and everything after that reads through the index. We measured it on our own machine, in Chrome, on 100,000 rows against a 100,000-row baseline: building the grid with a baseline cost 20.2ms against 23.9ms without one, which is inside the run-to-run noise, and the first question asked of it cost 18.1ms with the next twenty totalling 0.16ms.
So the cost is paid on first read rather than never, and a grid nobody has asked a comparison question of has not paid it. That is what lets this be on by default in an operational screen rather than a button somebody presses when they have twenty minutes.
What it is for
Month-end. A billing run against the last one. Today’s inventory against Friday’s. A stock file against the file the supplier sent. Anywhere two versions of the same list exist and somebody has been reconciling them by eye, or worse, by lookup.
It is deliberately not a merge tool and it does not ask you to accept anything. It shows you what moved and leaves the judgement where it belongs, with the person who knows why the rate went up.
For your users this arrives in the box: nobody on your team writes a comparison screen, maintains it, or explains why it disagreed with finance. For the people in front of it, the afternoon with the two spreadsheets stops happening.