The date format each program expects, why CSV imports drift by months, and how to produce a file whose dates cannot be misread. Convert a statement above.
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF
Uploading...
A date like 03/07/2026 is March 7th to a US statement and July 3rd to a program expecting day first. Both readings are valid dates, so no error appears and the transactions simply land in the wrong month. It only affects the first twelve days of any month, which is why it survives a quick check and surfaces at reconciliation. The reliable fix is to import OFX or QFX instead of CSV, because those formats write dates as YYYYMMDD, which cannot be read two ways.
An import that fails tells you something is wrong. An import with misread dates succeeds quietly and corrupts the period instead.
Day first and month first dates are both valid for the first twelve days of a month, so the importer has no reason to complain and accepts the wrong reading.
Dates from the 13th onward cannot be misread and land correctly, so a single statement ends up split across two months and nothing balances.
The damage usually surfaces weeks afterward, when a period will not close and the cause is buried under categorized transactions.
Formats that allow a two digit year leave the century to the importer, which is how transactions occasionally land decades away.
The same program can expect a different order on each platform, so a file that imported cleanly on one machine misreads on the other.
Most programs make it easy to reverse an import immediately and awkward once the transactions have been matched or reconciled.
Either remove the ambiguity from the file, or check the two dates that reveal it before you reconcile.
OFX and QFX write every date as YYYYMMDD inside the file. There is no setting to get wrong and no way to read it in two orders.
Every row in a converted file uses the same date style, which is what importers expect and what mixed source statements usually break.
Statements that print a weekday next to the date break CSV imports. The converted file keeps the date on its own, in its own column.
After any import, compare the earliest and latest transaction against the statement period. A misread order shows up immediately.
If a program rejects one format, export the same statement as OFX, CSV or Excel from the same upload.
Convert up to 50 statements at once and every file comes out with the same date handling, which matters for a year of catch up work.
Work out what the destination expects first, then give it a file that cannot be misread.
Look up the date order your software wants for file imports. It is not always the convention of the country you are in, and it can differ between the Mac and Windows builds.
Tip: The table below covers the programs people import statements into most often.
Upload the statement and export OFX for software that reads it, or CSV for Quicken. OFX carries dates as YYYYMMDD, so the order question disappears.
Tip: Use CSV only when the destination accepts nothing else.
After importing, check the earliest and latest transaction dates against the statement period before categorizing or reconciling anything.
Tip: If either sits outside the statement period, undo the import now rather than unpicking it later.
Almost always in file imports rather than bank feeds, and most often during catch up work.
Loading a year of history means many imports in a row, so a misread order repeats across every month before anyone notices.
A file prepared on one platform can import differently on the other, which makes the problem look intermittent and hard to pin down.
Each bank prints dates its own way, so a workflow that handles one bank correctly quietly misreads another.
Plenty of accounting products expect day first dates by default, which is the opposite of how every US statement is written.
There is no shared convention, which is the whole problem. This is what the main programs document for file imports.
| Program | Date format for file import | What catches people out |
|---|---|---|
| Quicken for Windows (CSV) | mm/dd/yyyy | Matches US statements, so problems only appear with files prepared elsewhere. |
| Quicken for Mac (CSV) | D/M/YY or DD/MM/YYYY | Day first, the opposite of the Windows build. The same file behaves differently on each platform. |
| QuickBooks Online (CSV) | Whatever you select at mapping | The choice must match every row. A weekday printed beside the date has to be split into its own column first. |
| Zoho Books | DD-MM-YYYY | Day first, so a US statement imported as CSV misreads the first twelve days of every month. |
| Xero (CSV) | Set during import | Date and amount are the minimum required columns. Xero recommends OFX over CSV for this reason. |
| Odoo (CSV) | Set in formatting options | The wizard offers a Test step. Run it, because a bad date mapping imports without any error. |
| QIF files | Loose by design | Two or four digit years are allowed and leading zeros can be dropped, so the same file can be read two ways. |
| OFX and QFX | YYYYMMDD | Fixed inside the file. Nothing to choose and nothing to misread. |
Because the importer was expecting day first and your statement was written month first. Both readings produce a real date, so there is nothing for the software to reject. It writes July 3rd into the register and reports a successful import.
This is why the symptom looks so strange. Only dates where the day is 12 or lower can be swapped, so roughly the first twelve days of each month move and the rest stay put. A single statement ends up spread across two periods, with a balance that will not reconcile and no obvious cause.
Check the earliest and latest transaction dates against the statement period straight after importing. If a statement covering March produced transactions dated in July, or the first transaction predates the statement, the order was misread. Do this before categorizing, while undoing the import is still a single action.
The transaction count is worth checking at the same time. A count that matches the statement while the dates look wrong points at the date format specifically, rather than at a file that was partly read.
OFX, and a bank issued QFX where the destination is Quicken. Both write each date as an eight digit YYYYMMDD value inside the file, so 20260307 can only ever mean March 7th, 2026. There is no import setting to get wrong, no column to map, and no difference between platforms.
That is the practical reason to prefer them over CSV even when a program accepts both. The OFX file format reference shows exactly where the date sits in a transaction record, and if your destination is older software that only reads QIF, note that QIF is the one format on this list that makes date ambiguity worse rather than better, so export OFX or CSV where you can.
Some banks print dates as Mon 03/07/2026. In a CSV import that whole string goes into the date column, and most importers reject it or read it unpredictably, because the weekday is not part of any date format they know.
QuickBooks documentation is explicit that the weekday needs splitting into its own column before the file will import. A converted statement avoids the step, because the extraction reads the date itself rather than the printed string around it.
Where the date sits in an OFX transaction record.
The format whose date rules are loosest, explained.
Convert a statement to OFX and remove the ambiguity.
The QuickBooks import, including CSV column rules.
The other reasons a statement import fails.
Convert a backlog with consistent date handling.
Get started converting bank statements to OFX.
USD
per month
per month
$294 charged today
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion with bulk upload, custom templates and reports.
USD
per month
per month
$894 charged today
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
per month
$ charged today
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
