CSV vs QBO File: Which Format to Use to Import Bank Transactions into QuickBooks

Run QuickBooks Desktop and the question is settled: you need a .qbo, because Desktop has no bank CSV import path in any version. Run QuickBooks Online and you can use either, but pick .qbo if you import on a schedule, if your date ranges ever overlap, or if the file is more than a thousand rows. Pick CSV only for a one-off cleanup of a small file where nothing has been imported before and nothing will be imported again over the same dates.

If your bank only offers a CSV download, that is not a dead end. Converting the CSV to a .qbo gives you the duplicate protection and the fixed dates without changing where the data came from.

A CSV is a comma separated text file with no rules about what the columns mean, so QuickBooks has to ask you which column is the date, which is the description and which is the amount. A .qbo is an OFX document with a defined structure: it declares the account, the statement period, the closing balance and every transaction with a type, a date, an amount and a unique identifier. QuickBooks reads it without asking you anything.

The .qbo also carries an INTU.BID, a numeric code that tells QuickBooks which financial institution the file came from. That is the field that makes a converted file behave like a bank download rather than a foreign import.

No. A CSV has no transaction identifier, so QuickBooks has nothing to compare against and will happily import the same transaction twice. A .qbo gives every transaction a FITID, a value that must be unique within the account and is never reused for a different transaction, and QuickBooks tracks the IDs it has already taken in. Re-import an overlapping .qbo and the transactions it has seen are skipped.

There is a wrinkle worth knowing. QuickBooks remembers a FITID even after you delete the transaction it created, so a row you deliberately discarded can be skipped on the next download rather than coming back. That is the opposite of the CSV failure mode, and it is much easier to live with than silent duplicates.

The practical rule for CSV work: if an import went wrong, delete the whole batch before you upload a corrected file. Never overlap, and never patch a partial import with a second CSV. Cleaning up duplicate transactions in QuickBooks Online is slow work once they are in the register.

Yes. QuickBooks Online accepts a CSV with either three columns (Date, Description, Amount) or four columns (Date, Description, Credit, Debit). The file must be in English and 350 KB or less, and an upload is capped at 1,000 transactions. Larger statements have to be split into smaller date ranges and uploaded in batches.

The formatting rules are fussier than they look. Remove the word amount from the Credit and Debit headers, leave cells that contain only a zero blank rather than typing 0, strip numbers out of the Description column, and split the day of the week out of the Date column if your bank appends it. Any of these can fail the whole file rather than a single row.

Not for bank or credit card transactions, in any version. The Import Excel and CSV toolkit that Intuit ships handles four list types only: customers, vendors, items and the chart of accounts. There is no path that turns a bank CSV into register transactions on Desktop, which is why every Desktop workflow that starts with a CSV has to pass through a .qbo at some point.

This catches people migrating off a discontinued bank connection. When a bank drops Direct Connect, the download you are left with is usually a CSV, and Desktop cannot read it. The Direct Connect alternative for QuickBooks Desktop covers that transition.

Because a date like 04/01/2026 is April 1 in one order and January 4 in the other, and QuickBooks applies your company region rule regardless of what your bank meant. The import succeeds, the amounts are right, and every transaction sits in the wrong month until reconciliation exposes it. A .qbo has no such ambiguity: OFX writes dates as YYYYMMDD, so 20260409 can only be April 9, 2026.

Excel makes it worse rather than better, because it reinterprets dates by your machine's locale the moment the file is opened. The QuickBooks CSV import date format guide has the full list of what breaks and how to check a file before you upload it.

For getting bank transactions into QuickBooks, yes, on every axis that matters: it works on both products, it protects against duplicates, its dates cannot be misread, it needs no column mapping and it carries the account and balance information a CSV throws away. The only advantage a CSV has is that you can open and edit it, which matters when you need to correct a description or drop rows before importing.

That is the workflow most bookkeepers land on. Clean the CSV where cleaning is easy, then convert it to a .qbo so the import itself is safe.

When the data is not bank transactions. Customers, vendors, items, the chart of accounts, invoices and journal entries all come in through CSV or Excel paths, and there is no .qbo equivalent for any of them. A .qbo describes a bank statement and nothing else, so it cannot carry a customer list or a journal entry no matter how the file is built.

CSV is also the right pick for a genuinely one-off import: a single small account, under a thousand rows, no prior history in QuickBooks, and no chance of re-importing the same dates. Outside that narrow case the duplicate risk is doing you no favors.

Upload the CSV or Excel export to the converter above, confirm which columns hold the date, description and amount, and download the .qbo. The converter normalizes the dates into the fixed OFX format, assigns a unique identifier to every transaction so QuickBooks can dedupe on re-import, and writes the account header QuickBooks expects. From there it is Banking, then Upload from file in QuickBooks Online, or File, Utilities, Import, Web Connect Files in Desktop.

Files that come out of accounting systems rather than banks work the same way, and so do spreadsheets. If your transactions are in a workbook rather than a CSV, the Excel to QBO converter takes .xls and .xlsx directly.

Neither format helps until the data is out of the PDF. A PDF statement is a picture of a table, not a table, so it has to be extracted into rows first and then converted. Extraction accuracy is the thing to watch: a mis-read amount or a merged column will travel all the way into your register, and a .qbo will not flag it because the file is structurally valid.

Check the extracted rows against the statement totals before you convert, then treat the result exactly like any other CSV.