Why did QuickBooks import my transactions dated January 1, 1970?

1/1/1970 is the Unix epoch — the zero point of computer time. When QuickBooks can't parse a date string in your CSV (wrong format, stray characters, or Excel re-encoding), the failed parse becomes zero, and zero renders as 1/1/1970. It's a formatting failure, not corrupted data.

What date format does QuickBooks want in a CSV?

US-style MM/DD/YYYY with four-digit years (03/05/2026). Two-digit years, day-first orders (05/03/2026 meaning March 5), ISO dates (2026-03-05), or month names (5-Mar-26) are all parse risks depending on the import path.

How do I fix the file?

Reformat the date column to MM/DD/YYYY as text and re-import. In Excel, format cells as a custom MM/DD/YYYY *text* format or use TEXT(A2,"MM/DD/YYYY") in a helper column — and export a fresh CSV. Delete the 1/1/1970 transactions from QuickBooks first so the re-import doesn't sit alongside them.

My dates imported without errors but some are in the wrong month. Why?

That's the dangerous cousin of the 1970 bug: a day-first file (DD/MM/YYYY) where days ≤ 12 parse 'successfully' as the wrong month. 05/03/2026 imports as May 3rd instead of March 5th, while 25/03/2026 fails visibly. If any dates look shifted, assume the whole file was day-first and re-import all of it.

Does Excel cause this?

Often. Opening a CSV in Excel silently re-renders dates in your system's locale format, and saving writes that format back. If you must edit in Excel, format the date column explicitly before saving — or edit in a plain-text editor.

QuickBooks imported every date as 1/1/1970 — the fix

Published August 28, 2026

The short answer: 1/1/1970 means QuickBooks failed to parse your date strings and fell back to computer time's zero point. The fix is mechanical: delete the 1970-dated imports, rewrite the CSV's date column as MM/DD/YYYY with four-digit years, re-import. The rest of this guide covers what corrupted the dates and the wrong-month variant that's easy to miss.

What actually happens

Unix systems count time from January 1, 1970. When an importer can't make sense of 05-03-26 or 2026/03/05 or a date cell Excel re-encoded, the unparseable value becomes timestamp zero — and every failed row renders as 1/1/1970. One bad date is a typo; every date at 1970 means the whole column's format is wrong for the importer.

The three usual culprits

Day-first exports. Non-US banks (and some US credit unions' tooling) export DD/MM/YYYY. Days above 12 fail to 1970; days 12 and under quietly become the wrong month — the worse outcome, because it posts.
Excel round-trips. Opening the CSV in Excel re-renders dates in your locale and saves them back that way. The file you exported is not the file the bank gave you.
Nonstandard renderings: two-digit years, 5-Mar-26 month names, ISO 2026-03-05, or trailing spaces/invisible characters around the date.

The fix, step by step

In QuickBooks, delete the imported 1/1/1970 transactions (Transactions → filter by date).
In the CSV, rewrite every date as MM/DD/YYYY — in Excel, a helper column with =TEXT(A2,"MM/DD/YYYY") then paste-as-values; in a text editor, find-and-replace if the pattern allows.
Confirm the amounts and columns still follow the other CSV import rules while you're in the file.
Re-import, and spot-check dates near both ends of the statement period.

Skipping the problem entirely

This bug lives specifically in CSV date parsing, so the durable fix is not handing QuickBooks a CSV with ambiguous dates in the first place. Our converters detect day-first ordering in the source (statement PDFs and bank CSVs both) and always emit MM/DD/YYYY QuickBooks CSVs — or a .qbo Web Connect file, whose structured date fields bypass CSV parsing altogether. Xero users have the same trap in the other direction, which is why the Xero export ships both date orders as separate downloads instead of guessing.

Questions people ask

Why did QuickBooks import my transactions dated January 1, 1970?: 1/1/1970 is the Unix epoch — the zero point of computer time. When QuickBooks can't parse a date string in your CSV (wrong format, stray characters, or Excel re-encoding), the failed parse becomes zero, and zero renders as 1/1/1970. It's a formatting failure, not corrupted data.
What date format does QuickBooks want in a CSV?: US-style MM/DD/YYYY with four-digit years (03/05/2026). Two-digit years, day-first orders (05/03/2026 meaning March 5), ISO dates (2026-03-05), or month names (5-Mar-26) are all parse risks depending on the import path.
How do I fix the file?: Reformat the date column to MM/DD/YYYY as text and re-import. In Excel, format cells as a custom MM/DD/YYYY *text* format or use TEXT(A2,"MM/DD/YYYY") in a helper column — and export a fresh CSV. Delete the 1/1/1970 transactions from QuickBooks first so the re-import doesn't sit alongside them.
My dates imported without errors but some are in the wrong month. Why?: That's the dangerous cousin of the 1970 bug: a day-first file (DD/MM/YYYY) where days ≤ 12 parse 'successfully' as the wrong month. 05/03/2026 imports as May 3rd instead of March 5th, while 25/03/2026 fails visibly. If any dates look shifted, assume the whole file was day-first and re-import all of it.
Does Excel cause this?: Often. Opening a CSV in Excel silently re-renders dates in your system's locale format, and saving writes that format back. If you must edit in Excel, format the date column explicitly before saving — or edit in a plain-text editor.

This guide is about file conversion and bookkeeping tooling — it isn't tax, accounting, or legal advice. Verify converted data against the source statement before filing or posting it.