Compare two tables
March's price list and September's, yesterday's records and today's: pick the column that works as the key and see the rows added, the ones gone and, for the rest, which cells changed.
The column that works as the key is everything
Two tables can only be compared properly if you know which row matches which, and that is what the key tells you: the item code, the VAT number, the staff number. Without one, rows get paired by position, which is fragile in a particularly nasty way: one row inserted in the middle and from there on everything looks changed, so the report is full of differences that do not exist. The menu suggests the first column whose values are all different, which is nearly always the right one.
If the chosen column has repeated values, the page does not pair them at random: it says how many there are and which, and those rows stay out of the comparison. It is a matter of honesty and it is worth explaining: with two rows sharing a code, whichever pairing the program picked would produce made-up differences, and the reader would have no way of noticing.
Values are compared, not strings
This is the point where a tool like this becomes useless without anyone noticing: if 1,234.56 and 1234.56 come out different, every row changes and the report is noise. Here the two numbers are recognised as the same value, and the percentage change is worked out only when before and after really are numbers.
There is one case where a decision has to be made, and it is written here because it is the only thing the program picks for you: «1.234» can be one thousand two hundred and thirty-four the Italian way or one point two three four the English way. The rule is the one already used by the other tools on the site: a separator followed by exactly three digits reads as a thousands separator. If your data does not work that way, the road is to go through Clean up a CSV before comparing.
What comes out, and how it gets used
The report comes in three parts: the changed rows, with the column, the value before, the value after and the percentage change on numbers; the added rows; and the ones that are gone. Above them are the totals, including columns that appeared or disappeared, which are a change of structure and not of data. The CSV you download holds everything, even when only the first two hundred rows show on screen.
The typical move is to send that CSV to a colleague saying «these fourteen rows changed», which is far more use than attaching two whole price lists and leaving the work to them. And if that file then has to be opened in Excel without losing the zeros in front of the codes, the right step is CSV to Excel.
Excel files, and why they do not open here
This page reads CSV and pasted text: copying cells from Excel and pasting them into the box brings in tab-separated text, which is recognised on its own, just as semicolons, commas and vertical bars are. An .xlsx file, on the other hand, does not open here, and that is a decision rather than an oversight.
The reason is that the reader for Excel archives already exists on this site, on another page, and keeping two copies is the surest way to make them drift apart: one gets fixed and the other does not, and six months later two tools on the same site read the same file two different ways. So if you have an .xlsx, the step is Excel to CSV, which pulls the CSV out of it; then you come back here.