QuickBooks Online rejected your bank statement upload

The manual bank transactions upload in QuickBooks Online accepts four formats, CSV, QBO, OFX and QFX, and a statement document straight from your bank is none of them, which is why the upload screen tells you the file type is not supported. That screen is where the constraint lives. Nothing inside the upload dialog changes it, and the file has to become a CSV, QBO, OFX or QFX before that screen will look at it.

Intuit does ship document-reading features elsewhere in the product, and what is available to you depends on your region, your subscription and how recently things moved. None of them feed the bank transactions upload. So that is the whole answer to the error, and the rest of the work is deciding which import path you are actually standing on, because QuickBooks Online has several places that take a file and only one of them creates bank transactions.

Work out which import path you are on

People hit this error from at least four different screens, and the fix is different for each.

• The bank transactions upload. This is the one that creates lines in the review queue for a bank or credit card account. It accepts CSV, QBO, OFX and QFX. This is the path you want if you are trying to get transactions into the books.
• Receipt capture and bill capture. These accept images and statement-style documents, and they read a document to draft an expense or a bill. They do not create bank feed lines, and they are not a way to load a month of statement activity.
• Attachments. You can store a statement document against an account, a transaction or a reconciliation for the audit trail. Nothing is extracted from it. Useful, but not an import.
• Third-party apps. Apps connected to your QuickBooks company can push transactions in through the API. What each app accepts is its own business, and it varies widely.

Anything that reads a statement document and hands you transactions sits outside the bank transactions upload, before it. Whether QuickBooks itself offers any feature that reads a statement document varies by region and by subscription tier, and Intuit changes this. The reliable test is the upload screen in your own company file: if it lists only CSV, QBO, OFX and QFX, that feature is not available to you and the conversion has to happen before you get there.

What each accepted format gives you

The four accepted formats are not equivalent, and the difference matters more than most people expect.

QBO, OFX and QFX are structured banking formats. Each transaction line normally carries its own identifier, which gives QuickBooks a key to match on when it meets a line it has seen before, so a re-imported line can be recognised rather than added again. That is not an absolute guarantee, because what happens depends on the file, the account and what is already sitting in the register, but it is a real matching key and it is worth a lot when you are filling a gap next to an active bank feed.

CSV is a plain table, and the bank transactions import maps a date, a description and an amount out of it without looking for an identifier column. Even if your file carries one, nothing in it tells QuickBooks that a given line is the same line it already has. Upload an overlapping range twice and you are relying on whatever duplicate warning the review queue happens to raise, which works from a rough match on date, description and amount and is a much weaker position than a file that carries its own keys. That is not a QuickBooks defect; there is simply nothing dependable in the file to match on. If you are choosing between formats for an import that sits next to a live feed, the comparison of statement export formats is the decision worth making before you convert, not after.

The column shape a QuickBooks CSV needs

A CSV for the bank transactions upload is deliberately minimal. QuickBooks needs a date, a description, and the amount. The amount can arrive in one of two shapes, and you tell QuickBooks which during the mapping step of the upload.

In prose: the file needs a date column, a description column, and either a single amount column where money out is negative and money in is positive, or two separate columns holding debits and credits as unsigned numbers. A running balance column is not required. You can leave it in the file and simply not map it, and doing so is often worth it because the balance is what lets you verify the conversion before you upload.

Three details cause most of the rejections that survive the format fix:

• Mixed date formats. One file, one format. If some rows read 03/04/2026 and others read 3 April 2026, the import will misread part of the file or refuse it. Pick the format that matches what the statement itself declares and apply it to every row.
• Preamble above the header. Many bank exports and some converters place account details, an address block or a period range above the column headers. QuickBooks expects to find the header row at the top of the file, and preamble above it is a common reason an otherwise valid CSV is refused or mapped to the wrong fields. Delete everything above the header before you upload.
• Amounts that are not numbers. Currency symbols, thousands separators, parenthesised negatives and trailing DR or CR markers all turn an amount into text. Strip them to a plain number with a leading minus where needed.

The standard the file has to meet is arithmetic, not format

QuickBooks validates the shape of your file. It will complain about a date it cannot parse, an amount that is not a number, or a column you have not mapped. What it cannot do is check the file against the statement it came from, because it has never seen the statement. Nothing in the upload screen tells you that four transactions went missing at a page boundary, that a digit was misread, or that a wrapped description orphaned a row with no amount attached. The file will import cleanly and the account will refuse to reconcile three weeks later, at which point you are hunting one bad row through a quarter of activity.

The check that catches this is the statement's own arithmetic: the opening balance, plus every movement in the period, equals the closing balance printed on the statement. It is the strongest automatic check available on a converted file, because a misread amount or a dropped row breaks it arithmetically and cannot pass unnoticed. It is not the whole picture, since it says nothing about a description that came out garbled or a date that landed in the wrong month, so pair it with a row count against the statement's own transaction count. Those two together are the standard worth holding every import to, whatever produced the file. They are also the reason the running balance column matters even though QuickBooks never asks for it, and they are precisely what a converted statement should hand you already verified line by line.

Getting from a statement document to an accepted file

1. 1

   Convert the statement documents for the period

   Produce a table carrying the date, description and amount columns above, plus the running balance so the period can be checked.
2. 2

   Verify the converted file against the statement

   Confirm the opening balance, the closing balance and the transaction count match the figures printed on the statement. Do this before the upload, not after.
3. 3

   Trim the file to the range you actually need

   Remove any rows falling inside a period the bank feed already covers. Overlap is the single most common source of duplicate transactions after a manual import.
4. 4

   Upload and map the columns

   Choose the account, upload the file, and map each column explicitly. Confirm the date format and the amount shape on the mapping screen rather than accepting the defaults.
5. 5

   Review the queue before you accept

   The imported lines land in the review queue alongside anything the feed brought in. Scan for pairs before you accept them into the register.

The verification step is the one people skip, and it is the one that decides whether the month closes. Checking that the closing balance in your file equals the closing balance printed on the statement takes under a minute and catches the entire class of error that is otherwise invisible until reconciliation.

When the upload works but the numbers are wrong

A file that QuickBooks accepts is not necessarily a file that is right. Two problems survive a successful import.

The first is sign convention. If your file uses a single amount column and the converter emitted every value as a positive number, every withdrawal will post as a deposit. Check one known debit in the review queue immediately after import.

The second is duplication against the feed. If the feed was live for part of the range you uploaded, the overlapping days are now in twice unless the review queue happened to flag them, and its matching is a heuristic rather than a guarantee. This is common enough that it is worth handling deliberately rather than cleaning up afterwards; the approach to backfilling a gap left by a broken bank feed covers how to cut the boundary so the two sets meet without touching.

If you are working in QuickBooks Desktop rather than QuickBooks Online, the import path and the failure modes are different: Desktop uses Web Connect files and rejects them for reasons that have nothing to do with the column shape, which is covered in the guide to Web Connect QBO file errors in QuickBooks Desktop.

The constraint on that screen is straightforward and has held for a long time: the bank transactions upload reads structured transaction data, not documents. Everything upstream of it is about producing that structure accurately, and the running balance printed on the statement, checked against the file before it goes anywhere near the upload, is the strongest evidence available that you did.