Why won't my CSV file upload to QuickBooks?

Eight causes, in the order worth checking. The first one isn't a fault in your file at all — and it's the one that wastes the most time.

Before anything else: which QuickBooks?

QuickBooks Desktop has no CSV import for bank transactions. Not a strict one — none. There is no amount of fixing that will make a CSV go in. If you're on Desktop, stop debugging the file: you need a .qbo, which is what this converter makes from the same CSV.

QuickBooks Online does read CSVs, and that's where the rest of this page applies. Nearly every "just import the CSV" answer you'll find online was written by someone on Online, which is why it doesn't work for you.

1. It isn't really a CSV

The most common cause, and the least obvious, because the filename says otherwise. Two ways it happens: a spreadsheet saved as .xls/.xlsx and then renamed to .csv, or a bank "download" button that hands you an HTML table with a .csv name.

How to check: open it in a plain text editor — Notepad, TextEdit, anything that isn't Excel. A real CSV is readable lines of text with commas between the fields. If you see <html> or a screen of binary garbage, that's your answer.

Fix: open the file in Excel and use File › Save As to properly write a CSV. Or skip the round trip — our Excel converter reads .xlsx directly.

2. The wrong number of columns

QuickBooks Online recognises exactly two layouts, with a header row: Date, Description, Amount, or Date, Description, Credit, Debit. That's it.

Almost no bank exports either. Chase checking gives you seven columns including a running balance and a transaction type; Wells Fargo gives five and no header row at all. Everything extra has to be deleted and the rest put in order.

Fix: rearrange in a spreadsheet, or convert to .qbo, which has no column rules because the layout is worked out from the file itself. Full detail: the two layouts Online accepts.

3. The dates

Two separate problems hide here, and only one of them produces an error.

The loud one: mixed formats in a single column — a few rows as 1/5/24 and the rest as 01/05/2024, usually because the file was opened and re-saved in Excel at some point. Online refuses the lot.

The quiet one: 03/04/2024 is 3 April or 4 March depending on convention, and a file where every day-of-month is 12 or lower contains no evidence of which was meant. It imports without complaint and lands a month out. Online asks you to pick a date format during the mapping step — that's the moment, because nothing downstream will catch it.

Fix: format the whole date column consistently before uploading, and read the date-format dropdown carefully. (Our converter warns you when a file is genuinely ambiguous rather than silently picking one.)

4. The amounts aren't plain numbers

$1,234.56, 1.234,56, (45.20) for a negative, 45.20 DR, a trailing minus like 45.20- — all of these are how the figure is displayed, not what it is. Currency symbols, thousands separators and accounting-style brackets all have to come out.

Fix: select the amount column in Excel and format it as a plain number with two decimals, negatives shown with a minus sign rather than brackets or red. Watch for the thousands separator surviving as text.

5. Extra rows above or below the table

Bank exports are built for humans first. Above the transactions there's often an account name, an address block, and a statement period; below there's a total, a closing balance, and a blank row or two. To an importer those are all data rows in the wrong shape.

Fix: delete every row above the header and every row below the last real transaction, blanks included. Then check that row 1 is the header and row 2 is the first transaction.

6. The sign convention is reversed

This one never produces an error, which is what makes it the worst on the list. In the three-column layout, money leaving the account has to be negative. Credit card statements do the opposite: purchases are positive, because from the card's point of view a purchase increases what you owe. Payments to the card are the negatives.

Upload one unchanged and every transaction goes in backwards. It reconciles to a number that looks nearly right and isn't, and you find out weeks later.

Fix: before accepting the import, find one purchase you actually remember and confirm it's showing as money out. One line, ten seconds. (This is the reason our converter puts a single transaction in front of you and asks you to confirm the direction, rather than just handing over a file.)

7. Characters and encoding

Merchant names carry things a CSV isn't always ready for: a comma inside an unquoted description shifts every column after it by one; a stray double quote can swallow the rest of the file; accented characters saved in the wrong encoding arrive as é or a row of question marks. A UTF-8 byte order mark — invisible, added by Excel on some Save As paths — can make the importer read the first header as Date and fail to match it.

Fix: in Excel, Save As → CSV UTF-8 is usually the safest option. If a single description is doing the damage, editing that one cell is faster than diagnosing it.

8. Too much at once

QuickBooks Online publishes hard limits on a manual upload: the file must be 350 KB or smaller and hold at most 1,000 transactions, one per line. A full year of a busy account clears both of those easily.

The failure mode is unhelpful — a generic error or a timeout rather than "your file is too big" — so it's worth checking the file size before assuming the contents are at fault.

Fix: split by month or quarter and upload in pieces. If you do that, watch for overlapping date ranges: a CSV upload has no per-transaction ID, so overlap means duplicates. (This is one of the real advantages of a .qbo — it carries a unique ID per transaction, so a re-imported overlap gets matched and skipped.)

Still refusing?

At this point you've spent longer on the file than the file is worth. A converted .qbo sidesteps every rule on this page — no column layout to match, no date format to declare, no sign convention to get right, and duplicate protection included. Drop the CSV your bank gave you into the converter exactly as it came.

It reads whatever columns your bank happened to export, tells you what it found, and shows you the first transaction so you can check the direction before you download anything. Free, no account, and the file never leaves your browser.

Frequently asked questions

QuickBooks says "file not supported". What does that actually mean?

Nine times out of ten, cause 1 above: the file isn't a CSV despite its name. Open it in a plain text editor and look. The second most likely meaning is that you're on Desktop, where CSV isn't a supported import format for transactions in the first place.

Can I just retype the transactions?

For a handful, yes, and it's often faster than debugging a file. For a month of a business account it isn't, and hand-entry introduces its own errors — which surface at reconciliation as a difference of a few dollars that takes an afternoon to find.

My bank's CSV worked last month and doesn't this month. What changed?

Usually the bank changed the export — an added column, a renamed header, a different date format after a website update. Compare the two files side by side in a text editor; the difference is normally obvious once you look at the raw text rather than the spreadsheet view.

Does a .qbo file have the same restrictions?

No. The column-layout, date-format and sign-convention rules are all properties of QuickBooks' CSV importer specifically. A .qbo declares its own dates, amounts and directions in an unambiguous form, which is why converting is the shortcut when a CSV keeps failing — and the only route at all on Desktop.

Is my bank data uploaded anywhere if I use your converter?

No. It runs in your browser, and the page ships a Content Security Policy with connect-src 'none' — your browser refuses to let the page make any network request. Watch the Network tab in developer tools while you convert; it stays empty.

Related