Why Excel breaks your CSV, and how to stop it
A CSV file is text. Open it in Excel and it stops being text, because as Excel reads each field it decides what that field must be and rewrites it to match. Usually the guess is right and nobody notices. When it is wrong the damage is silent, it becomes permanent the moment you save, and it gets blamed on whoever sent the file.
Leading zeros go first
A field holding 007 looks to Excel like the number seven with two redundant characters in front, so seven is what it becomes. The same happens to postcodes, bank branch codes, part numbers, and every identifier whose width carries meaning.
This is the easy one to catch, because the column visibly jumps to the right and the zeros are gone. It is also the one people patch by hand, retyping values with an apostrophe in front, which works right up until the next export.
Excel keeps fifteen significant digits and no more
This is the one that does real damage, because nothing about it looks wrong. A value stored as a number in Excel keeps fifteen significant digits. Paste in a sixteen-digit order reference, a long transaction id, or a card-style number, and the last digit becomes a zero.
The cell still shows a long number. Nothing is highlighted, no warning appears. The value is simply not the one you had, and every lookup against it now fails for a reason that takes an afternoon to find. Anything past fifteen digits has to be stored as text, and no change of display format recovers it afterwards, because the digits are already gone from what was written to disk.
Codes that resemble dates become dates
Type 3-1 and Excel hands back the 1st of March. Type SEPT1 and you get the 1st of September. This is not a contrived example: it happened to genetics at scale, because gene symbols such as SEPT1, MARCH1 and DEC1 are precisely the shape the date parser is hunting for.
The problem was widespread enough that in 2020 the committee responsible for naming human genes renamed the affected symbols rather than keep losing the argument with a spreadsheet. If renaming genes was the easier path, it is safe to assume your own product codes are not special.
The encoding problem is separate, and just as annoying
A CSV saved as UTF-8 without a byte order mark opens in Excel under the system legacy encoding, which turns every accented or non-Latin character into mojibake. Add the byte order mark and the identical file opens cleanly.
This is why one colleague sees a perfect spreadsheet and another sees garbage from the same export. The file did not change between them; the two machines simply guessed different encodings.
Even the delimiter is not fixed
Excel does not always split on commas. Where the decimal separator is a comma, which covers much of Europe, Excel expects semicolons between fields, and a comma-separated file arrives as one tall column of text.
The file is not malformed. It is being read under a regional assumption different from the one it was written with, which is the same class of problem as the encoding and produces the same complaint: it works on my machine.
What actually prevents all of this
Stop opening CSV files by double-clicking them. Use the import path instead, under Data, and set every fragile column to Text before the data lands in the sheet. That import dialog is the only moment where the decision belongs to you rather than to Excel.
Recent versions also expose the guessing as a setting, under Options and then Data, where the automatic conversion of dates, long numbers and leading zeros can be switched off individually. On a machine that handles exported data regularly it is worth switching all of them off.
The durable fix is to stop sending CSV to people who will open it in Excel. In a real .xlsx workbook every cell carries its own type, so a column written as text stays text regardless of who opens it, on which machine, under which regional settings.
Checking a file that has already been through Excel
Once a file has been saved from Excel the damage lives in the stored values, not in the display, so widening the column proves nothing. Look for identifiers shorter than they ought to be, long numbers ending in a suspiciously round zero, and anything in a code column that has quietly become a date.
The fastest check is to open the original file as plain text rather than as a spreadsheet and compare a handful of known values against what the spreadsheet shows. If they disagree, the spreadsheet is not a view of your data. It is a different dataset, and the text file is the one worth keeping.