7 reasons your QuickBooks CSV import keeps failing (and the fix for each).
QuickBooks Online's "invalid file format" error is one of the most generic, least helpful messages in modern accounting software. It tells you the file is wrong without telling you which wrong. Here are the seven things it almost always means, with the diagnostic step for each.
1. There's an invisible BOM at the start of the file
What happens: You hit upload. QBO immediately shows "Invalid file format" or "Unable to read the file" with no preview. Open the file in Excel and it looks perfect.
The cause: A byte-order mark — three invisible bytes (EF BB BF) at the start of the file that some tools add to mark UTF-8 encoding. QuickBooks reads them as if they were part of the first column header and rejects the row.
The fix: Open the CSV in a text editor like VS Code, Sublime, or Notepad++. Look at the encoding indicator (usually bottom-right). If it says "UTF-8 with BOM" or "UTF-8 BOM," change it to plain "UTF-8" and save. The file will look identical, but QBO will now read it.
2. Dates are in MM/DD/YYYY but QBO thinks they're DD/MM/YYYY
What happens: The import succeeds, but when you look at the transactions, every date is shifted by months. February becomes November. Recurring monthly bills land on impossible days.
The cause: QBO infers date format from your locale. If your Intuit account is set to UK/EU/AU formatting, it reads 10/03/2025 as 10 March 2025, even though your bank wrote it as 3 October. Then it silently mis-imports the entire file.
The fix: Convert dates to ISO 8601 (YYYY-MM-DD) before uploading. There's no ambiguity in that format. In Excel: select the date column, Format Cells → Custom → yyyy-mm-dd. In Google Sheets: same thing, or use =TEXT(A2,"yyyy-mm-dd") in a helper column.
3. Amounts have currency symbols, commas, or parentheses
What happens: The import either fails outright or imports zero-amount transactions. Hundreds of rows of $0.00 in your bank feed.
The cause: CSV importers expect amounts to be plain decimals. Anything else is treated as a string. $1,250.00 isn't a number to a parser — it's a five-character mess. (32.18) isn't negative 32.18 — it's "open paren, three two, dot, one eight, close paren." QBO either fails or zeros it.
The fix: Find/replace the currency symbol with nothing. Find/replace the comma in amounts (be careful not to remove commas in descriptions — do this in the amount column only). Convert (1250.00) to -1250.00. Excel: =-VALUE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A2,"(",""),")",""),",","")) wrapped around the original cell.
4. The file has separate Debit and Credit columns
What happens: The import succeeds with the wrong amounts. Every transaction is half-right. Spending shows as income or vice versa.
The cause: Most bank exports — Citi, some Wells Fargo formats, every credit union — give you two columns: Debit and Credit. QBO wants one signed Amount column. If you map the Debit column to "Amount," every spend becomes positive. If you map Credit, every income disappears.
The fix: Add a new column called Amount. Formula: =C2-B2 if column B is Debit and C is Credit (the sign convention depends on your bank — sometimes it's the opposite, check one transaction you know). Delete the old Debit and Credit columns before exporting.
Skip to the end
If you're three reasons into this list and exhausted — that's normal. VelvetCSV handles all seven of these automatically. Drop a file in, get a clean QBO-ready CSV back. Free for 3/month, no account.
5. There's a header row inside the data (or the file has no header)
What happens: The first transaction shows up as the literal text "Posting Date · Description · Amount" instead of real values. Or the import skips your first real transaction because QBO thinks it's a header.
The cause: Bank exports vary. Wells Fargo gives you no header at all. Chase puts the header at row 5, with summary stats in rows 1-4. Some BofA exports repeat the header mid-file at month boundaries.
The fix: Delete every row that isn't a transaction. Keep exactly one header row (Date, Description, Amount) at the top, or delete it entirely. Don't leave stray rows.
6. Descriptions contain smart quotes, em dashes, or other encoding gremlins
What happens: The import succeeds, but descriptions display as Coffee Bar 'COFFEE' or contain question-mark diamonds. Sometimes a single bad character breaks the entire row.
The cause: Mixed encoding. Your bank wrote the file as UTF-8, then Excel re-saved it as Windows-1252 or Latin-1, and now the curly quotes that bank-generated descriptions love don't decode cleanly on QBO's side.
The fix: Open in a text editor and re-save as UTF-8 (no BOM). Or open in Google Sheets, which is more forgiving about re-encoding, then File → Download → CSV. Avoid Excel for the final save step if you can.
7. The file is too big (you don't see the error, but transactions go missing)
What happens: Import succeeds without complaint. You import 900 transactions. QBO imports 350.
The cause: QBO's CSV import is undocumented-capped around 350–400 rows. The UI lets you upload bigger files, but the import truncates silently. There's no error. No row count comparison. Just missing transactions you'll find at year-end.
The fix: Split big files by quarter or month. Three files of 300 rows each beats one file of 900. Name them with the date range so you can track what's imported.
One drop. All seven, fixed.
VelvetCSV detects and fixes BOMs, date formats, currency symbols, debit/credit merges, headers, encoding, and even auto-splits large files. Runs entirely in your browser — no upload. Free for 3 conversions/month, $3/month unlimited, or $49 lifetime (limited time).
Try VelvetCSV nowHow to diagnose which one you're hitting
When the error appears in QBO, work this checklist top to bottom — they're roughly in frequency order:
- Open the file in a text editor. Does the first character render? If you see
or "" at the start, it's a BOM. - Look at a known date. Is it ISO? If not, check whether your QBO locale matches the file's date format.
- Look at one negative amount. Does it have a minus sign? Or is it in parentheses, or in a separate column?
- Count the columns. Three is right. More needs trimming.
- Count the rows. Over 300 — split it.
Two minutes of triage usually finds the culprit. The fix is then a five-minute search-and-replace job, or a thirty-second drop into a tool that does it for you.