How to Import Bank Transactions into QuickBooks

The short answer

Connect the bank if you can. Upload a file if you cannot, or if you need history older than a connection will reach. Type it in only for a handful of transactions on an account nobody else touches.

The screens for these are in different places and their failure modes have nothing in common, so it is worth knowing which one you are doing before you start.

Route one: connect the bank directly

In QuickBooks Online this lives under Transactions, then Bank transactions, then Link account. In Desktop it is Banking, then Bank Feeds. Either way you authenticate with the bank and transactions arrive on their own from then on.

Where it can work, it should. A live connection beats a file every time: there is no export step to get wrong, no date-format question to answer, and no chance of pulling the wrong period. Two limits are worth knowing before relying on it.

• History is short. A new connection typically brings in only the last 90 days. Anything older has to come from a file, which is why plenty of people end up needing both routes rather than choosing between them.
• Not every bank offers it. Coverage varies by institution and by account type, and business accounts at smaller banks are the usual gap. Two accounts at the same bank can differ.

If a feed used to work and has stopped, that is its own problem with its own fixes: see what to do when a bank feed stops working before falling back to files, because a feed that broke for a clearable reason is usually quicker to repair than a month of statements is to convert.

Route two: upload a file

This is the route that actually needs explaining, because it is where the format questions live. QuickBooks Online's upload screen takes four things:

• CSV. A plain table. The most forgiving, and the only one with a step where you say which column is which.
• `.qbo`. Web Connect. An OFX document carrying an Intuit institution identifier.
• `.qfx`. The Quicken flavour of the same document.
• `.ofx`. The open format the other two are built on.

On Online, prefer CSV unless you were handed one of the others. It sidesteps the institution-identifier question entirely, and its mapping step is a chance to catch a wrong column or a misread date before the transactions land rather than after.

QuickBooks Desktop is stricter

Desktop's Bank Feeds screen wants .qbo specifically, which is why that extension causes so much more trouble there than on Online.

Desktop checks the five-digit institution identifier inside the file against its own list of banks, and refuses anything it cannot match. That check is about the header, not the transactions: a file can be perfectly formed, carry every transaction correctly, and still be rejected because the identifier names a bank the software does not recognise.

If Desktop refuses a file that looks fine, the identifier is the first thing to suspect, not the data. It is the most common reason a technically valid .qbo will not go in.

Getting the file out of your bank

Before any of this there is an export, and a few things about it are worth getting right first time.

• Take the widest date range the bank allows. Trimming it later is trivial; going back for a second export because you were three days short is not.
• Check whether the export includes pending transactions. If it does and your books do not, the totals will disagree by exactly the pending amount and nothing will look wrong.
• Note which order the rows are in. Plenty of exports run newest first, which inverts every running-balance check you might do on them.
• Prefer CSV over a spreadsheet where the bank offers both, if only because there is one less layer to go wrong. A spreadsheet works too, but its dates are stored as numbers with a display format attached, which is its own source of trouble.

Route three: entering them by hand

Worth stating plainly because it is sometimes right. For fifteen transactions on a rarely-used account, typing them in takes less time than exporting, converting, mapping and reviewing, and it produces no format problems at all.

The threshold is lower than people think. Somewhere around thirty rows, or the second month of doing it, the file route wins and keeps winning.

Dates read the wrong way round

A date written 05/01/2026 is the fifth of January in the UK and most of Europe, and the first of May in the US. Nothing in the file says which. If your transactions land in the right order but the wrong months, this is why.

The tell is a file where some dates are unambiguous, meaning anything with a leading number above twelve like 19/02, while the rest are not. Those files parse inconsistently unless the tool is told which convention to use, giving you a statement where most rows are right and a few are six months out.

Check the mapping screen's assumption every time. It is one glance, and it is the single most common way a clean import produces a wrong ledger.

Thousands separators splitting a column

In a CSV, an amount written 1,800.00 is read as two columns rather than one number. Every row containing a figure over a thousand then has one field too many, and the import either rejects the row or shifts everything after it one place to the left.

Amounts have to go in plain, with no grouping separators and a leading minus for money out. This is worth checking before upload rather than after, because the symptom, a handful of rows missing or descriptions appearing in the amount column, does not obviously point at its cause.

European exports add a second version of the same problem: 1.234,56 means one thousand two hundred and thirty-four, and a tool assuming US conventions reads it as one point two three.

Duplicates, and the opposite problem

OFX-family files give every transaction a unique id, and QuickBooks uses it to recognise rows it has seen before. That is helpful right up until two genuinely separate transactions get the same id, say two identical charges at the same shop on the same day, at which point one is treated as a duplicate and silently dropped.

It is a nasty failure because nothing reports it. The file imports, the count looks plausible, and the account is short by one transaction that you will meet again at reconciliation.

CSV has no such id, so QuickBooks matches on date and amount instead. That is less reliable in both directions: it can merge two real transactions, and it can let a genuine duplicate through when a description differs.

Rows that were never transactions

Bank exports carry a header block naming the account and period, sometimes a page footer, and often a totals row at the bottom. None of those are transactions.

An importer that treats them as such produces entries with strange dates or no date at all, and a totals row imported as a transaction is particularly unhelpful because it is a real number that doubles part of the account's movement.

Anything doing this properly skips them and tells you how many it skipped, so you can check that count against what you saw in the file.

Check the total, every time

All four failures above share a shape: the import succeeds and the numbers are wrong. Nothing turns red. You find out at reconciliation, weeks later, when the figure is off by an amount you now have to go and find.

The habit that prevents it is dull and takes ten seconds. Before accepting a batch, total the amount column and compare it against the difference between the opening and closing balances on the statement. If those two figures agree, nothing was lost on the way in.

Frequently asked questions

How far back can I bring transactions? A new bank connection usually reaches back about 90 days. Files have no such limit: if your bank lets you export a year of history, that year can be converted and uploaded in one go, which is the usual reason people use files even when a feed is working.

Which format should I choose on QuickBooks Online? CSV, unless you have been handed one of the others. It carries no institution identifier to be rejected over, and its mapping step lets you catch a wrong column or a misread date before the transactions land.

My bank only offers Excel, not CSV. Is that a problem? No. A spreadsheet holds the same transactions; it just needs converting first, and dates need care because a spreadsheet stores them as numbers with a display format attached rather than as text.

Will uploading the same file twice create duplicates? Usually not for OFX-family files: each transaction carries a unique id and previously-seen ids are skipped. For CSV there is no such id, so QuickBooks matches on date and amount instead, which is less reliable in both directions.

Why were some rows skipped? Almost always because they were not transactions: a totals row, a repeated column heading, a page footer or a blank line. Anything doing this properly reports the count so you can check it against the file rather than wondering.