“Some dates imported wrong and others are fine”
The giveaway is that some dates are right and some are not. A wholesale format problem breaks everything; this one breaks only the days from the 13th onward, because up to the 12th both readings are valid and nothing looks wrong.
Symptoms
Transactions before the 13th of each month look correct; later ones do not Some dates were rejected outright while others imported silently wrong March 4th and April 3rd have swapped places
What actually causes it
CSV does not declare its date order
The file contains 03/04/2026 and nothing else. Whether that is 3 April or 4 March is decided by whoever reads it, so a European export read by American software silently relabels every ambiguous date.
The import setting did not match the file
Most importers ask for the date format, and the default follows your computer's locale rather than the file's origin. Accepting the default is what turns this into a silent problem instead of an error.
The file mixes formats
Exports assembled from more than one source sometimes contain both ISO dates and locale dates. No single setting can read both, so one group always fails.
How to fix it
- Drop the CSV into the checker below and look at the reported dates — seeing a value above 12 in the first position tells you the order immediately.
- Redo the import and set the date format explicitly to match the file rather than accepting the default.
- Reverse the wrong import first; leaving it in place means every later reconciliation fights those dates.
- If the file genuinely mixes formats, split it by format and import each part with its own setting.
Related import problems
Skip the manual edit — fix it automatically
The checker reports what the date fields contain, which is how you tell day-first from month-first without opening the statement. Free, no signup, no upload.
Open the fixer