Excel Changed My CSV Dates From DD/MM to MM/DD

Updated July 2026 · By the CSVUndo team · 6 min read

The quick answer: A CSV is plain text with no date type, so Excel reads every date using your computer’s regional (locale) settings. If the file was written DD/MM/YYYY but your Excel is set to US MM/DD/YYYY, a value like 04/11/2023 that meant 4 November is silently read as 11 April. The fix is to import through Data → From Text/CSV and set the date column’s type Using Locale to match the file’s origin — not to reformat the cells afterwards, which never sticks. The permanent cure is to store dates as ISO YYYY-MM-DD at the source, an order that is unambiguous everywhere.

Why Excel flips the day and month

Excel flips the day and month because a CSV carries no type information — it is just characters separated by commas, with nothing to say whether 04/11/2023 is the fourth of November or the eleventh of April. To fill that gap, Excel guesses using your computer’s regional (locale) settings. A machine set to US English reads dates as MM/DD/YYYY, so it takes the first number as the month; a machine set to UK or most of Europe reads the same characters as DD/MM/YYYY.

Nothing in the file is wrong: the digits are exactly what the source wrote, which is why the same file can look correct on a colleague’s UK laptop yet broken on your US one. The difference is the locale, not the data. Microsoft’s own support threads confirm the parser follows the regional short-date setting, not anything stored in the CSV (Microsoft Q&A).

The tell-tale: half your column is dates, half is text

Here is the giveaway that a locale mismatch is to blame: one date column ends up half genuine-but-flipped dates and half untouched text, with a ragged left/right alignment down the page. The reason is arithmetic. When the day is 12 or less it is also a valid month number, so Excel happily reinterprets the value as a date and the cell becomes a right-aligned serial number. When the day is 13 or more it can never be a month, so Excel gives up, leaves the value alone, and the cell stays left-aligned text.

The days above 12 stay put and are obviously safe; the days 12 and under get quietly swapped. That is the danger — the flipped ones look like perfectly good dates, and only the mixed alignment or a total that stops matching tips you off. If Excel is instead turning genuine non-dates such as SKUs into dates, that is a related but separate trap covered in when Excel converts numbers to dates.

Import a CSV so Excel keeps the correct date format

Don’t double-click the file — import it through Power Query, where you can tell Excel which locale the dates came from. Double-clicking runs the automatic guess with no chance to intervene; the From Text/CSV path is the only place you get a say.

1. Open a new blank workbook in Excel.
2. On the Data tab choose From Text/CSV and select your CSV file.
3. Click Transform Data. In the editor, select the date column, then set its Data Type using “Using Locale…” and choose the region the file was created in (for a DD/MM file, pick a locale such as English (United Kingdom)). To keep the exact original string untouched instead, set the column type to Text.
4. Click Close & Load. The dates arrive parsed correctly and Excel stops re-guessing them.

Why reformatting the cells never sticks

Changing the cell format in Excel does not save back into the CSV, so it can never be the fix. A CSV holds only raw characters, with no place to record that a column should be shown as a date. When you re-apply a date format and save as CSV, Excel writes out whatever value it already parsed — the flipped one — and drops the formatting. Reopen the file and the identical reinterpretation happens again, because the parse is redone from scratch every time.

This is the misunderstanding behind hours of lost work: people re-type the dates, format the column, save, and email the file — and the recipient sees the same mess. Formatting is a display layer inside the workbook, not inside the CSV, so the only durable levers are the import locale and the text stored in the source file.

The permanent fix: store dates as ISO 8601

The best long-term fix is to store dates as ISO 8601 — YYYY-MM-DD — in the source system. Because the year leads and every part is a fixed width, there is no ambiguity about which number is the day and which is the month, so Excel imports it consistently on any machine, in any country. A value like 2025-04-03 can only mean 3 April 2025; there is no US-versus-UK argument to have.

If you own the export, set its date output to ISO order and this class of bug disappears for everyone downstream. If you only receive the file, the import-locale route above is your reliable path — and ISO is the format to request from whoever generates the data.

Which flipped dates you can actually recover

If a file was only opened and viewed, nothing is lost — the original characters are still on disk and a correct re-import fixes everything. The danger is a misread file that was re-saved: once Excel writes 11 Apr in place of 4 Nov and you save as CSV, the file now literally says April.

At that point only the days above 12 are self-evidently safe, because they could never have been valid months and so were never touched. For rows where the day was 12 or less, you often cannot tell from the file alone which were flipped and which were genuine — 05/06/2025 is plausible read either way, so that ambiguity may be unrecoverable. When in doubt, do not guess: re-export from the source system, ideally in ISO format, rather than trust a repaired copy. Microsoft’s guidance walks through the safe import path in detail (Microsoft Support).

Frequently asked questions

Sources: Microsoft’s Q&A on CSV dates importing in the wrong order and the official guide to importing text and CSV files. For more guides, see the full CSVUndo guide index.