Some Info May Be Missing From Your File: How to Fix the QuickBooks CSV Bank Upload Error

TL;DR: "Some info may be missing from your file" almost never means a transaction is missing. It means QuickBooks Online could not line your CSV up with one of the two column layouts it accepts. Six things cause it: extra columns left in the bank export, header names that do not match, currency symbols or thousands separators in the amount cells, mixed date formats, a file over 350 KB or 1,000 lines, and stray characters in the description. Work through them in that order and the file loads.

What does "Some info may be missing from your file" actually mean?

It means QuickBooks could not read your CSV into the shape it expects, and the wording is misleading. Nothing has usually gone missing. QuickBooks Online accepts a bank CSV in exactly one of two layouts, either 3 columns (Date, Description, Amount) or 4 columns (Date, Description, Credit, Debit), and anything that stops it matching your file to one of those produces this message or its cousin, "We can't read this file".

That is why the error feels so unhelpful. It is a single catch-all for a whole family of formatting problems, so it tells you that something is wrong without telling you which thing. The good news is the family is small. Six causes cover nearly every occurrence, and they can be checked in a couple of minutes if you check them in the right order.

The six causes, in the order worth checking

Start with the columns, because that is usually it

Open the CSV and count the columns. A raw bank export almost always has more than QuickBooks will take: a running balance, a check or reference number, sometimes a branch code, a posted-versus-cleared status, occasionally the account number repeated on every row. All of that has to go. QuickBooks does not ignore surplus columns, it fails on them.

What should be left is either Date, Description, Amount, with money out written as a negative number, or Date, Description, Credit, Debit if your bank splits the two directions into separate columns. Pick whichever matches how your export already works rather than converting between them, because every conversion is another chance to flip a sign. Then check the order, since QuickBooks maps by position as well as by name, and a file with the right columns in the wrong sequence fails just as completely as one with extra columns.

Then look inside the amount cells

This is the cause that survives a visual check, because a column of amounts formatted as currency looks more correct to a human than a column of bare numbers. QuickBooks wants the bare numbers. A cell containing $1,234.56 carries a dollar sign and a thousands separator, and both can stop the row parsing.

In Excel, be careful here: changing the cell display format to plain number does not always change what gets written to the CSV, so it is worth opening the saved file in a text editor to confirm what actually came out. What you want to see is 1234.56 and -892.10, nothing else. While you are in there, check for blank amount cells too. Intuit's guidance is to leave cells that would contain only a zero blank rather than filling them with 0.

Dates are the quiet one

Mixed date formats within a single file are common and hard to see, especially when a spreadsheet has been edited by hand across a few sessions or assembled from two exports. Excel is helpful enough to display several underlying formats the same way, so rows that look identical on screen can be stored differently underneath.

Set the whole column to one explicit format, save, then reopen the CSV as text to confirm the rows genuinely match. For a US QuickBooks company file, MM/DD/YYYY is the format to standardize on. This is also worth a second look on any statement period that falls entirely before the thirteenth of the month, because in that range a day and a month can be swapped without the result ever looking wrong. A silently transposed date does not throw an error at all, which is a worse outcome than a rejected file.

Size limits catch the year-long uploads

QuickBooks Online caps a bank upload at 350 KB, in English, with up to 1,000 lines per file, and each line is one transaction. A single month of a small business checking account is nowhere near that. A full year of a busy operating account crosses it comfortably, which is why this cause tends to show up during catch-up work rather than in a normal month.

The fix is to split the period rather than to compress the file. Quarters are usually enough, months if the account is heavily used. Keep the blocks non-overlapping, because CSV rows carry no transaction identifier and nothing in the file tells QuickBooks a row has already been imported. Upload two files whose date ranges overlap by a week and you get that week twice, then remove the duplicates by hand. That deduplication problem is exactly what formats like OFX and QBO solve, since both carry a unique identifier on every transaction, which is worth knowing if you are choosing a format rather than stuck with one.

When the file is clean and it still fails

Split it in half and upload each half separately. This sounds crude and it is the fastest diagnostic available, because a single malformed row is a genuinely common cause and reading a thousand lines looking for it is not a good use of an afternoon. Two or three halvings narrow it to a handful of rows, and the culprit is usually obvious once you are looking at ten lines instead of a thousand.

The rows that tend to be responsible are the ones a bank never intended as transactions: interest summary lines, carried-forward balances, a header repeated mid-file where two statement periods were pasted together, or a description containing an embedded comma or line break that quietly shifts every following field one column to the left. That last one is worth checking specifically, since it produces a file that looks perfect in Excel and is broken in the actual text.

If you are converting from a PDF, fix the shape at the source

Most of this cleanup exists because bank exports are built for reading, not importing. If you are starting from a PDF statement rather than a bank CSV, it is worth producing the right shape at conversion time instead of reshaping a spreadsheet afterwards. Converting the PDF bank statement to CSV gives you clean date, description and amount fields with the extra presentational columns already gone, so the only remaining decision is where to split the period.

For a backlog, convert the whole set in one pass. Statements for a single account can be merged before extraction, so a year of monthly PDFs comes back as one continuous dataset that you then cut into upload-sized blocks, and the bulk bank statement converter covers how that batching behaves. If you would rather skip CSV entirely and hand QuickBooks a Web Connect file, that is a different route with its own requirement: a QBO file is OFX plus Intuit's own institution tags, and a QuickBooks-ready QBO file has to carry a recognized institution identifier or QuickBooks rejects it before reading any transactions. The full set of accepted formats and their rules is on our guide to importing a bank statement into QuickBooks.

A short checklist

• Delete every column except the 3 or 4 QuickBooks accepts, and check the order
• Strip currency symbols and thousands separators from amounts
• Standardize every date row to one format, MM/DD/YYYY for a US company file
• Keep each file under 350 KB and 1,000 lines, with no overlapping date ranges
• Clean stray characters, embedded commas and line breaks out of descriptions
• Still failing? Halve the file until the bad rows are obvious

Run in that order, most rejected files load on the second attempt. The error message will keep being unhelpful, but it is only ever pointing at this short list.