QuickBooks Won’t Import Your Bank CSV? Format, Dates and Signs, Fixed

Last updated: August 2026 · By the CSVUndo team · 7 min read

The quick answer: QuickBooks Online refuses a bank CSV for one of five common reasons: the file is not in one of the two layouts it accepts (3-column Date, Description, Amount or 4-column Date, Description, Credit, Debit); the dates are in a format the import screen was not told about; the amounts carry the wrong sign convention, currency symbols or thousands separators; the bank added summary rows above or below the transactions; or the file’s encoding confuses the parser. Fix those five things and the same file imports cleanly. This guide shows how to spot each one — including the notorious 1/1/1970 date symptom — and how to prepare the file without letting Excel do fresh damage along the way.

QuickBooks Online bank imports are built around two layouts — a 3-column Date, Description, Amount file or a 4-column Date, Description, Credit, Debit file — and Intuit’s guidance is that your file should be one of the two. Extra columns can sometimes be left unmapped on the import screen, but cutting the file down to exactly 3 or 4 columns is what works reliably. QuickBooks Desktop is a different product here: it does not import bank transactions from CSV at all, it wants a Web Connect .qbo file, and its Excel/CSV import is only for lists.

Why won’t QuickBooks import my bank CSV?

The frustrating part is that the error messages rarely say what is wrong — you get a generic “we can’t import this file” or a mapping screen where nothing lines up. Underneath, the importer is doing something very literal: it reads the first row as column headers, tries to slot the remaining rows into one of two fixed layouts, parses the date column against one chosen pattern, and parses the amount column(s) as plain numbers. Any row that breaks any of those assumptions can sink the whole upload.

So the diagnosis is a short, ordered checklist. First, is every row in the 3-column or 4-column shape, with the headers on line one? Second, does every date match one consistent pattern the import screen can be pointed at? Third, are the amounts bare numbers with the right sign convention — no $ or £, no 1,234.56 commas, no accountant-style (54.20) parentheses? Fourth, has every bank-added row above and below the transactions been deleted? Fifth, is the file plain, sane text rather than a mangled-encoding export or an Excel re-save? One more thing to check before you start on any of that: Intuit caps a manual bank upload at 350 KB and 1,000 transactions, so a full-year export can be rejected on size alone no matter how clean it is — shorten the date range at the bank, or split the CSV into smaller files and upload them in turn. The rest of this guide takes those in order.

What is the QuickBooks 3-column vs 4-column bank format?

The 3-column format is one header row followed by Date, Description, Amount. The single Amount column is signed: money out is negative, money in is positive. The 4-column format is one header row followed by Date, Description, Credit, Debit: money gets a column each, every value is a plain positive number, and each row fills exactly one of the two money columns.

Three rules trip people up. Don’t mix conventions: a 4-column file with minus signs in it, or a row with values in both Credit and Debit, is exactly the kind of ambiguity the importer gives up on. Watch which column your bank calls Credit: from the bank’s point of view a “credit” is money into your account, but some exports reverse the pair — if every payment imports as a deposit, swap the two column headers and re-import. Extra columns are dead weight: balance-after-transaction and reference columns can often be skipped on the mapping screen in QuickBooks Online, but the two canonical layouts import reliably everywhere, so when an upload keeps failing, cut the file down to exactly 3 or 4 columns and try again.

Why do my dates land on 1/1/1970 — or in the wrong month?

Seeing every transaction dated 1 January 1970 looks alarming and means something boring. 1/1/1970 is “time zero” — the Unix epoch — the value date software commonly falls back to when it cannot parse the text it was given. Intuit does not document the behaviour, but the symptom is a well-known one on the QuickBooks community forums and it always points the same way: an unparsed date column. Your bank data is fine; the date column simply didn’t match the pattern the importer expected — DD/MM/YYYY data read as MM/DD/YYYY, a two-digit year where four were expected, or a stray non-date row poisoning the column. Fix the mismatch and the real dates come back, because the original text is still in the file.

The subtler failure is the DD/MM vs MM/DD flip, and it is nastier precisely because nothing errors. Read 04/07/2026 with the wrong convention and it silently becomes 7 April instead of 4 July — a plausible-looking, wrong transaction. Only days of 13 or higher are unambiguous (there is no 13th month), which is why a flipped file often half-works: some rows import, the rest fail or land months away. Two defences: on the QuickBooks import screen, pick the date format that matches what the file actually contains, not what your region usually uses; and spot-check a transaction whose day is 13 or higher after import. If Excel already rewrote the dates before you got to QuickBooks, that is its own repair job — see Excel changed my CSV date format.

Should amounts be negative? Getting the sign convention right

In the 3-column format, yes: the lone Amount column is signed, so a payment is -54.20 and a deposit is 250.00. In the 4-column format, no: signs are expressed by which column a value sits in, so everything is a plain positive number. Applying the 3-column rule to a 4-column file (or vice versa) either fails the import or — worse — imports every transaction with the wrong direction, doubling your apparent income until you notice at reconciliation.

The amount cells themselves must be bare numbers. Strip currency symbols ($54.20 and £54.20 are text, not numbers, to the importer), strip thousands separators (Intuit asks for them to be removed, and an unquoted 1,234.56 splits into two fields in a comma-separated file, shredding column alignment), and replace accounting-style parentheses like (54.20) with a plain minus. Two smaller rules from Intuit’s own checklist catch people out as well: leave any Amount, Credit or Debit cell that holds nothing but a zero blank rather than 0, and drop the word “Amount” from Credit and Debit headers — Credit Amount must be plain Credit. If your statement comes from a European system that writes 1.234,56, convert the decimal comma before anything else — our guide to European number formats in CSV files covers exactly that trap.

Why do the extra rows my bank adds break the import?

Almost every bank export is a statement first and a data file second. Above the transactions you get the account name and number, a “Statement period” line, maybe a blank spacer row; below them, “Opening balance”, “Closing balance”, a total, a disclaimer. QuickBooks expects row one to be the column headers and every following row to be one transaction — so each of those extras is either a parse error or, sneakier, a fake transaction. A “Closing balance” row that slips through imports as a deposit for the full balance amount, and your books are wrong by thousands until reconciliation catches it.

The fix is honest manual work plus a little automation. The labelled rows (“Opening balance” and friends) contain text, so no generic tool can safely guess which rows are transactions and which are furniture — delete those few lines yourself in any spreadsheet or text editor. The mechanical clutter, though — blank spacer rows, stray leading/trailing spaces that make headers unmappable, fully-empty padding columns — is exactly what our CSV cleaner strips in one pass.

Could the encoding — or an Excel round-trip — be the problem?

Two quieter failure modes remain. The first is encoding. Some banks export UTF-16 or tab-separated files with a .csv name, which import as one useless column; others use Windows-1252, so accented payee names arrive as mojibake like Café instead of Café. If the columns won’t split or the payees look garbled, run the file through our encoding checker and, if needed, the broken-character fixer before going anywhere near QuickBooks.

The second is the Excel round-trip. Opening the CSV in Excel “just to tidy it” and re-saving invites fresh damage: dates re-localised to your machine’s convention, card and reference numbers collapsed into scientific notation like 4.51124E+15, and leading zeros stripped from account codes. Some of that is repairable — but be honest about the limits. Excel keeps only 15 significant digits, so if a 16-digit card number was truncated to …0 and that version was saved, the lost digit is gone from the file forever; the only real fix is re-exporting from the bank. And not every value that looks damaged is: 2E5 can be a genuine reference code, which is why our repair tool checks the context of a value instead of blindly expanding everything shaped like scientific notation. When you do have real damage, the CSV repair tool fixes it locally in the browser. Better still, avoid the round-trip: make edits in a plain-text editor, or follow how to open a CSV in Excel without breaking it.

Frequently asked questions

Sources: Intuit documents both accepted layouts in “Format CSV files in Excel to get bank transactions into QuickBooks” on QuickBooks Learn & Support. For more guides, see the full CSVUndo guide index.