Excel Turns Numbers and Codes into Dates — How to Stop It

Guide · Updated July 24, 2026 · By the CSVUndo team · About a 5-minute read

You export a clean CSV, double-click it, and Excel silently rewrites your data. The SKU 1-2 is now 2-Jan. The part code MAR1 reads 1-Mar. The fraction 3/4 has become 4-Mar. Nobody typed a date, yet a whole column of them appeared — and if you save the file, the values you started with are gone. This guide explains exactly which inputs trigger it, why the loss is usually permanent, what can honestly be recovered, and the import settings that stop it from happening again.

The symptom: what turns into a date

Excel does not wait for you to format anything. The moment a CSV opens, it inspects each cell and converts anything that looks like a date into one. The usual casualties:

• Short numeric codes with a separator. A SKU or bin location like 1-2 becomes 2-Jan; 12-3 becomes 3-Dec. Anything shaped like month-day or day-month is fair game.
• Fractions. A recipe quantity or ratio entered as 3/4 is read as March 4 and stored as 4-Mar. 1/2 becomes 2-Jan.
• Letter-plus-digit codes. Part numbers such as MAR1 and SEPT2 match month abbreviations and land as 1-Mar and 2-Sep.

That last category produced the most famous casualty of all. Human gene symbols including SEPT2 (Septin 2), MARCH1, and DEC1 were being turned into 2-Sep, 1-Mar, and 1-Dec every time a researcher opened a shared spreadsheet, quietly corrupting published datasets. After a decade of losing the fight, in 2020 the HUGO Gene Nomenclature Committee formally renamed 27 human genes — SEPT2 became SEPTIN2, and so on — specifically so their names would survive contact with Excel. It is one of the few times a scientific standard changed to accommodate a spreadsheet bug.

Why Excel does this

A CSV is plain text with no type information, so Excel guesses. Its guesser is tuned to be helpful with dates and is extremely aggressive: any token that resembles a calendar value under the General format is parsed as a date on open, with no prompt and no undo checkpoint you would notice.

The parsing is also locale-dependent, which is why the same file behaves differently on different machines. On a US regional setting Excel reads 3/4 as month/day — March 4 — and stores 4-Mar. On a UK or most European settings it reads day/month, so the same 3/4 becomes April 3 (3-Apr). Send a file across a team and the corruption is not even consistent from person to person.

Why the damage sticks once you save

Here is the part that catches people out. On screen 2-Jan still looks like it might be your code. But internally Excel has thrown away the text 1-2 and replaced it with a date serial number — an integer counting days from January 1, 1900. January 1, 2023 is stored as 44927. The display string 2-Jan is just a mask over that number.

Two things follow from this:

• If you press Save while the file is open as a CSV, Excel writes out the displayed date text. Your CSV now literally contains 2-Jan where 1-2 used to be.
• If you reformat the column to Number or General to "see what's really there," the mask drops and you get the bare serial number — 44927 — not your original code back. Reformatting cannot undo a conversion that already happened; it only changes how the stored number is shown.

Either way, the link between the cell and your original value is severed the instant Excel parsed it. Saving just makes it official on disk.

Can it be fixed? An honest answer

We build CSV repair tools, so you would expect us to promise a one-click cure. We are not going to, because it would not be true. CSVUndo cannot magically restore date-mangled values, and neither can any other tool — once a value became a serial number and the file was saved, mapping it back is guesswork. The reason is that the conversion is many-to-one: 1-Mar could have come from MAR1, from 1-3, from 3/1, or from someone who genuinely meant March 1. Nothing in the saved file distinguishes those cases.

There are only two situations where recovery is realistic:

• The file still shows text like 2-Jan (not a raw serial like 44927) and you know the original pattern. If you are certain every value in the column was a month-day SKU, you can reconstruct it by hand or with a formula — but you are supplying the missing knowledge, not extracting it from the data.
• You still have the original export. This is the real fix, and it is boring on purpose: go back to the source system, re-export the CSV, and this time import it as text (next section) so the conversion never runs.

If the file that reached you was also damaged in ways that are reversible — scientific-notation barcodes, stripped leading zeros, garbled accents — those we can genuinely repair without re-exporting. Open the CSVUndo tool, paste your data, and it flags each recoverable issue so you can fix the ones that survived in the cells and re-source only the columns that truly need it.

Prevent it: import as text

Because the damage happens on open, the entire game is won or lost before your data reaches a cell. Never double-click the CSV. Instead:

1. Open a blank workbook, then go to Data → From Text/CSV and choose your file.
2. In the preview, click Transform Data to open the Power Query editor.
3. Select the affected column, set Data Type → Text, and choose Replace current when prompted.
4. Click Close & Load. Codes and fractions arrive as literal text — no date parsing runs at all.

On older Excel, Data → Get External Data → From Text opens the classic Text Import Wizard; in step 3, click each code column and set Column data format to Text.

Excel 365 has a global switch too. Go to File → Options → Data → Automatic Data Conversion and turn off "Convert continuous letters and digits to a date" (and, if you like, the other conversion toggles). This stops the parser at the source for the codes that most often get eaten, though importing as text is still the safest habit for whole files.

Google Sheets has its own guard. Use File → Import rather than opening the file directly, and in the dialog set Convert text to numbers, dates, and formulas to No. Sheets then leaves 3/4 and SEPT2 exactly as written.

Excel rarely damages a file in just one way. If your export also lost the zeros off ZIP or product codes, our guide on why CSV leading zeros disappear covers the same import-as-text discipline for numeric identifiers. And if long barcodes turned into 8.85909E+11, see how Excel converts CSV numbers to scientific notation — that one is often recoverable. A related but different trap is when Excel keeps your real dates but flips the day and month: that’s a locale mismatch, covered in Excel changed my CSV date format (DD/MM ↔ MM/DD). You can also browse all repair guides.

Frequently asked questions