Can I just upload the CSV my bank gives me?

Sometimes, and it is worth trying first — it costs nothing. But a bank’s own CSV is written for a human reading it, not for Intuit’s importer, and it usually has more than four columns, which is the one thing QuickBooks Online will not accept. If it bounces, the rules on this page tell you what to change.

Why does my import fail with no useful error?

Because several of Intuit’s rules produce a failure at the mapping step rather than at upload, where the message does not name the real cause. The usual culprits are a fifth column, a header reading “Credit Amount” instead of “Credit”, zeroes written as 0 where the cell should be blank, or an asterisk or hash inside a bank description. Picking QuickBooks as the export destination handles all four of those for you.

My statement is a year long. How do I get it under 1,000 lines?

Intuit’s documented answer is to shorten the date range and upload in batches. That is real work, and it is work a bank statement converter leaves with you when it hands back one file for the whole year. A QBO import is not subject to the limit, which is the simpler way out.

Importing bank statements into QuickBooks Online

Q: Is QBO better than CSV for QuickBooks?

For getting the file in, yes, and by a wide margin: none of the CSV rules on this page apply to a QBO file. There is no column count to match, no 350 KB ceiling, no 1,000-line split, no header wording, no date format to normalise. The one cost is a single dropdown — QuickBooks asks which account the file belongs to, because we deliberately leave the Intuit bank ID blank.

QuickBooks Online will take a CSV of your bank transactions. It will also refuse one for reasons that have nothing to do with whether your bank statement converter read the PDF correctly. Those reasons are published, stable, and short enough to fit on one page.

The CSV rules, in full

Intuit’s upload documentation is specific. A file that breaks any one of these will not import.

The file itself must be in English, 350 KB or smaller, and hold no more than 1,000 transaction lines per upload. A year of a busy current account exceeds both the size and the line count. The documented fix is to shorten the date range and upload in batches — which means a converter that hands you one file for the year has quietly handed you a splitting job as well.

There are exactly two accepted column layouts. Three columns — Date, Description, Amount — with money out written as a negative number. Or four columns — Date, Description, Credit, Debit — with money in and money out separated. Five columns fails. Four columns in a different order fails. And it typically fails at the mapping step rather than at upload, which is why the error reads like a problem with your data.

Zero values must be removed and the cells left blank. A literal 0 in an amount cell is not the same thing as an empty cell as far as the importer is concerned.

The Credit and Debit headers must read exactly that. If your spreadsheet says “Credit Amount” and “Debit Amount”, strip the word “Amount” — Intuit documents this specifically.

Every date must be in one format throughout the file. Mixed formats in a single column are a common failure when a statement prints one style in the transaction table and another in a header.

On a Mac, the file has to be saved as a Windows CSV, not the default. This one catches people who did everything else right.

Sources: Intuit, manually upload transactions into QuickBooks Online.

The rule that catches almost everyone

Intuit’s error guide adds one more: special characters in a transaction description can block the import outright.

Bank descriptions are full of them. POS PURCHASE *1234, ACH DEBIT #77-A, TRANSFER TO A/C 0000/1234 — asterisks, hashes and slashes are how banks abbreviate. A converter that faithfully reproduces the description as printed, which is what you want for every other purpose, hands you a file whose most accurate column is the one that stops the import.

Source: Intuit, common errors for importing bank transactions using CSV.

What we do instead: QBO

None of the above applies to a QBO file. QBO is QuickBooks’ own flavour of OFX — the transaction data plus a few tags Intuit’s software looks for — and it is what Intuit’s importer is built to read. No column count to satisfy, no 350 KB ceiling, no 1,000-line split, no header wording, no date format to normalise, no special-character problem.

There is one deliberate cost. When you import our .qbo file, QuickBooks asks which account it belongs to instead of matching one automatically, because we leave the Intuit bank ID blank. Intuit assigns that number to participating banks; we are not a bank and have not been assigned one, and we will not borrow someone else’s — if that file lands in a QuickBooks company with a live connection to the bank whose number we used, your transactions can be filed against the wrong account. The full reasoning is on the QBO page.

One dropdown, against six rules and a manual year-splitting job, is a trade worth taking.

Or take the CSV, written to the rules above

QBO is the shorter road, but it is not the only one — some people want the spreadsheet, and some bookkeepers want to eyeball the rows before anything reaches the ledger. So pick QuickBooks as the destination and we write the CSV to every rule on this page rather than handing you our own layout:

Three columns or four, your choice. Date, Description, Amount, or Date, Description, Credit, Debit with money in and money out separated. Nothing else in the file.
Header wording exactly as Intuit specifies it — Credit and Debit, never Credit Amount.
Zeroes left as blank cells, not written as 0.00.
One date format throughout, MM/DD/YYYY by default, switchable if your QuickBooks region expects something else.
The characters Intuit documents as blocking imports — *, #, ? and their neighbours — replaced with spaces rather than deleted, so POS*AMZN #123 stays searchable as POS AMZN 123. The bank’s original wording is kept verbatim in the description_raw column of the plain CSV.
No UTF-8 byte-order mark, which would otherwise turn your first header into Date with an invisible character in front of it and break the column mapping.
Split at 1,000 rows and 350 KB, one file per account, numbered, delivered as a zip. Upload them one at a time — that is Intuit’s own documented answer to a file that is too big, and we do the splitting rather than leaving it to you.

One thing you should know before you use it. Every file we write normally carries its own warnings inside it — anything we could not read, anything that does not balance — because you often forward these files to someone else, and a warning that lives only on a web page does not travel. QuickBooks will not accept a CSV containing any line that is not a transaction, so for this destination those comment lines would stop the import. We do not delete them; we move them. The file arrives named …-CHECK-BEFORE-IMPORT.csv, a split export carries a READ-ME-FIRST.txt in the zip, and the plain thirteen-column CSV still spells everything out in full.

If QuickBooks still refuses the file

Two things are worth checking before assuming the conversion is broken.

QuickBooks Desktop expects Web Connect files to be imported through File → Utilities → Import → Web Connect Files, not by double-clicking them. And some versions refuse a file whose date range overlaps transactions already imported — that is a duplicate guard, not a format error.

Before you import anything: check the file

Whichever route you take, the import is not the first thing to verify. A file can import perfectly and still be wrong.

Add the opening balance to every credit, subtract every debit, and compare the result against the closing balance printed on your statement. If those two do not meet, something was dropped, duplicated or read with the wrong sign, and importing it will put a broken month into your books rather than a broken file on your desktop.

We run that check on every upload before you pay, per account rather than across the whole document, and we separately report anything in the PDF that never made it into the table at all — because a balance check cannot see a block that was never read.