Your converted file has a date column reading 03/04/2025, and Excel has decided that means the fourth of March. The statement means the third of April. Nothing in the file is corrupted, no digit was misread, and the converter did its job. The value is simply ambiguous, and something downstream had to guess.
This is worth being blunt about at the outset, because most advice on the subject skips it: for any date where both the day and the month are 12 or lower, the correct reading cannot be recovered from the value. Not by a smarter parser, not by a better converter, not by you looking at it harder. Roughly two thirds of the days in a year fall in that range. The order has to come from outside the number.
The part that is genuinely unresolvable
Take 03/04/2025 on its own. It is the third of April under DD/MM, and the fourth of March under MM/DD. Both are real dates, both are plausible in a statement period, and the string contains no signal that favours either. Any tool that tells you which one it is with confidence is applying an assumption, usually your operating system's regional setting, and that assumption is invisible in the output.
The consequence in a spreadsheet is worse than a single wrong cell, because the ambiguity is not uniform across the column. Consider a statement column that contains 03/04, 07/04, and 19/04. If Excel is assuming MM/DD, the first two parse happily as 4 March and 7 April, both wrong. The third has no valid month 19, so Excel cannot parse it and leaves it as text. You end up with a column that is part date, part string, sorts incorrectly, and gives no visible sign that anything went wrong until a transaction turns up in the wrong month at reconciliation.
That mixed column is the fingerprint. If part of your date column converted and part of it refused, the ones that refused are the days above the 12th, and the ones that converted have all been misread. Run COUNT over the column against the row count to see how many fall in each group. The 13th and above are the only dates the software could not get wrong.
It is also a signal about the file as a whole. A date column that arrived as raw ambiguous strings means whatever produced the file never established the statement's locale, which means it never read the statement's header, which means it was working from positioned characters rather than from an understanding of the document. Dates are simply where that shows first, because a date is the one field where a wrong reading is still a valid value. Assume the same guesswork was applied to the columns where you cannot see it.
Where a statement actually declares its order
The statement usually tells you. It just does not tell you in the transaction table, and on a heavily abbreviated export there may be nothing to find at all, in which case the issuing institution is the only source left.
- A date above the 12th. Scan the column for any transaction on the 13th or later. If it appears as 19/04, the leading position is the day and the whole statement is DD/MM. This settles it in seconds and needs nothing else. Do this first.
- The statement period line. Headers usually carry a period such as "1 April 2025 to 30 April 2025" or "04/01/2025 through 04/30/2025". The long form resolves the order outright; the numeric form resolves it because a 30 can only be a day.
- The issuing country and branch address. US statements are typically MM/DD, and most of the rest of the English-speaking world along with most of Europe is typically DD/MM. Treat that as a prior rather than a rule. The convention can follow the product, the export route or a language setting rather than the country, and Canada is genuinely mixed, which is why one banking brand can date its Canadian statements one way and its US statements the other and trip you up on what looks like the same document. Confirm it against a date above the 12th wherever the statement gives you one.
- A long-form date anywhere on the page. Print dates, "statement produced on" lines, interest calculation dates and page footers are often written out in full, and one of those settles the whole document.
- The value date column, if there is one. Statements with both a transaction date and a value date give you two columns following the same convention, and a mismatch above the 12th in either one resolves both.
Establish the order once per bank, not once per statement. A bank rarely changes its date convention from one month to the next, so the answer holds for as long as the layout does. Record it alongside whatever else you keep about that account's layout and the question stops recurring. Re-run the check on a date above the 12th when a statement turns up looking different from the last one, because a template change, a new export route or a migration onto a different product can move the convention without any announcement.
Forcing the interpretation in Excel
The fix is to stop Excel guessing and tell it what it is receiving. It requires no retyping, but it does require you to have settled the order first, because the procedure does exactly what you tell it and has no opinion about whether you are right.
- 1
Establish the source order first
Find a date above the 12th, or read it off the statement period line. Do not start until you know whether the source is DMY or MDY. - 2
Import the date column as text
If you are opening a CSV, use Data then From Text/CSV, and set the date column's type to Text in the preview. This stops Excel converting anything before you have decided how it should be read. - 3
Run Text to Columns on the column
Select the column, choose Data then Text to Columns, and click Next twice without changing the delimiter settings. The point of the pass is step three, not the splitting. - 4
Set the column data format to Date
In step three, choose Date and pick the code that matches the source, DMY for a UK or European statement, MDY for a US one. Excel now reads the incoming string in that order rather than in your system's order. - 5
Verify against a known transaction
Pick a transaction you can identify on the statement and confirm the parsed date lands on the day the statement prints. Check one near the start of the period and one near the end.
Text to Columns is doing something specific here that a cell format change cannot do. Formatting a cell only changes how an existing value is displayed. If Excel has already stored 4 March, formatting the cell as DD/MM will show you 04/03 and you will still be a month out. The DMY and MDY setting in step three of Text to Columns is where you tell Excel how to read the incoming string rather than how to display the result. It is not the only route to that: the From Text/CSV import lets you set a locale for the column, Power Query has an explicit locale-aware date conversion in its own editor, and DATEVALUE fed a rearranged string will do the job by formula. What Text to Columns offers is the shortest path for a column that is already sitting in the sheet as text, which is why the fix runs through a dialog that appears to be about splitting columns. The same dialog causes trouble when it is used for its advertised purpose on statement text, which is covered in the guide to Text to Columns on bank statements.
The same job in Google Sheets
Sheets parses against the spreadsheet's own locale setting rather than your browser's language. Open File, then Settings, and set the locale to match the statement's country before you import. A UK statement into a sheet set to United States will misread every date below the 13th in exactly the way Excel does. Changing the locale after import does not reparse the values that already converted, so set it first, then paste.
If the column has already arrived as text, DATEVALUE will parse it according to the sheet's locale, so the locale still has to be right. For a stubborn column, splitting the string and reassembling with DATE, feeding the pieces in the order the source actually uses, removes the guesswork entirely at the cost of one helper column.
Why dates land as text in the first place
Ambiguity is one of two problems here. The other is a date column that will not parse at all, and the cause is usually mechanical rather than semantic.
- A trailing space or non-breaking space. Statement layouts pad columns, and padding sometimes survives extraction. Whether Excel tolerates " 03/04/2025" with a leading space depends on the version and on how the value arrived, so you cannot predict it; a non-breaking space is invisible in the cell and much less likely to be forgiven. Clean the column before you diagnose anything else, so you are not chasing a locale problem that is really a whitespace problem. TRIM handles ordinary spaces and does not touch a non-breaking one, which has to be removed with SUBSTITUTE by character code.
- A separator the locale does not expect. Dots as in 03.04.2025 are standard in German and Swiss statements. Whether a given separator parses depends on your locale and on the route the value took into the sheet, so test one cell rather than assuming: hyphens are widely accepted in English locales and dots much less so.
- A two digit year. 03/04/25 parses in most locales but the century assumption is silent, and old statements can land in 2025 rather than 1925 or the reverse.
- A month name in another language. "3 Apr 2025" parses. "3 avr. 2025" and "3 Apr. 2025" with the trailing full stop generally do not.
- The column was never a date column. Some statements print the date only on the first row of a group of transactions sharing a day, leaving the rest blank. A converter that carries the date forward gives you a full column; one that does not leaves gaps that break any sort.
A spreadsheet will clear all five of these. TRIM removes the padding, find and replace swaps the separator, Text to Columns forces the parse. What none of them does is tell you whether the resulting date is the date the bank printed. Parsing and correctness are different questions, and every tool in that list answers only the first. The ambiguous case makes the gap obvious, because there the information you need was never in the file to begin with; it was in the statement header, and it was discarded before the column reached you.
Convert statements with the date convention already settled
That is the distinction worth holding on to. Reading the convention off the document, once, is the only way the ambiguity is actually resolved rather than deferred. Everything else moves the guess to a different piece of software.
Confirming the column before you import it
Once the column parses, check it against the statement rather than against itself. A wrongly parsed column is internally consistent and will pass every sanity check that only looks at the data.
The strongest check is that every parsed date falls inside the statement period printed on the document. A month-order error scatters dates across a range of months, so a column that parses entirely within the stated period is almost certainly correct. The second check is that every cell actually became a date. Default alignment is a quick visual signal, since a spreadsheet right aligns dates and left aligns text, but alignment can also be set by hand or inherited from a style, so confirm it with a count rather than with your eyes: COUNT over the column returns the number of cells holding a real value, and it should equal the row count exactly. Anything short of that is a value still sitting there as a string, and on an ambiguous column those stragglers are the days above the 12th, which means the rest of the column parsed the wrong way round.
Do both checks before the file goes anywhere. Once misread dates are inside a ledger they distribute themselves across periods, and a transaction booked to the wrong month is far harder to find than one that never parsed. The related problem of an amount column that imports as text is worth resolving in the same pass, since both usually arrive from the same extraction, and a file exhibiting both is telling you plainly how much of it was inferred.
The convention only ever has to be established once per account. Establishing it from the statement rather than from the operating system is what separates a date column you can rely on from one that happens to look right this month.
Frequently asked questions
Is 03/04/2025 the 3rd of April or the 4th of March
It is impossible to tell from the value alone. Any date where both parts are 12 or lower is ambiguous, so roughly two thirds of the days in a year are unresolvable without knowing the statement's locale. You have to establish the order from the statement itself, not from the data.
Why are my dates left aligned in Excel after importing a bank statement
Left alignment is the default for text, so it usually means Excel stored the value as a string rather than as a date. Confirm it with COUNT over the column, since alignment can also be set by hand. It happens when the format does not match your system locale, or when a stray space or non-breaking character is attached to the value, so Excel gives up parsing and keeps the raw string.
How do I tell which date order my bank statement uses
Look for a transaction dated on the 13th or later in one position, which settles the order immediately. Failing that, check the statement period line, the issuing country, and any date printed in long form such as 3 April 2025 in the header or footer.
How do I convert text dates to real dates in Excel
Select the column, open Data then Text to Columns, click through to step three, choose Date, and pick the code that matches the source order, DMY or MDY. This tells Excel how to read the incoming string rather than guessing, and it converts the whole column in one pass.
Can I fix wrong dates after they have already imported
Only if none of them were ambiguous, which is rarely true. Once Excel has read 03/04 as 4 March, the original intent is gone from the cell, and days above the 12th will have been left as text while the rest silently converted. Re-import the column as text and parse it deliberately.
Will sorting by date fix an out of order statement
No, not if the dates were misread. A mixed column sorts into two blocks, the values Excel converted in date order and the ones it left as text ordered as strings, and the converted block is a confident but wrong sequence. Fix the parsing first, confirm a known transaction lands on the day the statement shows, then sort.