Formatting errors stop Excel CSV bank imports in QuickBooks Online

QuickBooks Online users who import bank history by hand keep hitting the same wall. The spreadsheet opens cleanly in Excel, the upload starts, and then the file bounces or lands with rows missing. Community threads on the problem repeat a short list of causes, and the accepted answer behind most of them reads like a checklist: headers, dates, zeros, file flavor, and account type.

Why do some rows import and others vanish?

A CSV file has no structure the importer can lean on. Every row must parse under the same rules, and the importer checks them one at a time. When a row breaks a rule, one of two things happens: the whole upload stops with a format error, or that row drops out while its neighbors import.

We rebuilt a sample export to confirm the behavior. A single date with a weekday glued to it was enough for that row to vanish, with no error pointing at it. The surrounding rows imported as if nothing were wrong.

A rejection may cite a line number, but that count rarely matches the row you would click in Excel. The bad row often sits nearby. Keep the original export untouched and edit a copy, and before any retry, delete the rows that already landed. Re-uploading them creates duplicates, and duplicates cost more patience than the original error did.

Which amount columns does the importer expect?

Two layouts work. The first carries a single column named Amount, where money out is negative and money in is positive. The second carries two columns, named Credit and Debit, each holding positive figures. Pick one and use it for the whole file. A file that mixes the two leaves the mapping screen confused, and a file with neither fails outright.

Header wording matters as much as layout. Some banks export the headers as Credit amount and Debit amount, and the extra word is enough to break the match. Delete it so the headers read exactly Credit and Debit. In our test file, that one edit was the difference between a rejected upload and a clean one.

Dates need one format and no weekday

Use one date pattern in every row. The accepted answer recommends dd/mm/yyyy, and the important part is consistency rather than the specific pattern. Mixed formats are the real hazard: a cell reading 03/04 can be March 4 or April 3, the importer will pick one, and the wrong guess imports with no warning.

Some banks append the day of the week, so a cell reads like 05/09/2019 THU. That suffix has to go. In Excel, select the Date column, open the Data tab, and choose Text to Columns. Then:

1. Choose Delimited and continue.
2. Set the delimiter to Space.
3. Keep the column data format as General and finish.

The date and the weekday split into separate columns. Delete the weekday column and save.

Zeros and number-only descriptions fail quietly

Remove zeros from amount cells and leave those cells blank. A zero is not nothing to the importer; it reads as a zero-value transaction, and rows like that stall or drop. Descriptions fail more subtly. When the Description column holds only digits, often a check number or a reference, the row can be misread. Prepend a word, so Check 1182 imports where 1182 alone may not.

Mac Excel saves a different CSV

Excel on a Mac offers several CSV flavors in its save dialog. Choose the one labeled for Windows. The plain Mac option writes line endings the import handles poorly, and the fix costs a single click at save time.

Credit card statements run in reverse

Card files behave opposite to bank files. A payment shows as a negative amount, because paying the card reduces the balance the statement tracks. Import that into a bank-type account and every sign lands on the wrong side. The fix happens at the upload screen: choose the credit card account, not a bank account, and the amounts sort themselves out.

Alternatives when CSV keeps failing

If the bank offers downloads in Quicken, QuickBooks, or Microsoft Money formats, the files usually end in .qfx, .qbo, or .ofx. Use them. A live bank connection typically pulls only the most recent 90 days, while a downloaded file in one of these formats can reach further back.

There is a newer route as well. Upload the statement itself as a PDF or an image, and the software reads the transactions from it for your review. Clean, text-based statement pages work best; a photographed page with a thumb in the corner, less so.

The pattern across every fix here is that the importer is literal. It reads headers, signs, and dates exactly as written and declines to guess on your behalf. Ten minutes with the file before upload prevents most of these failures, and that time is cheaper than the cleanup.