Why Won't My Bank Statement Import? The 7 Reasons It Fails, and How to Fix Each One

TL;DR: Most failed bank statement imports come down to one of seven causes: the file is a PDF and no accounting program reads PDFs, the format is unsupported by that particular program, the encoding is not UTF-8, the date format does not match what the import expects, the amounts have no sign or the wrong one, the file holds more than one account, or you are on a page that cannot import at all. The error message usually points at none of these. Working through them in that order finds the problem faster than re-downloading the file.

Why won't my bank statement import?

Because the file you have and the file your software expects are almost never the same thing. Banks hand out PDFs by default, and no accounting program imports a PDF. Everything else on this list is a narrower version of the same mismatch: right format but wrong version, right columns but wrong order, right data but wrong character encoding. The fix is always to work out what the destination actually accepts, then produce that exact thing.

What makes this frustrating is that import errors are famously unhelpful. Quicken's OL-220 through OL-226 family, for instance, means the file could not be parsed and the official advice is to contact your bank, which tells you nothing about what is wrong inside it. A common real cause is a missing LEDGERBAL block, a balance section that sits outside the transaction list in an OFX file and that some banks simply omit.

1. The statement is a PDF

This is the single most common cause, and it is absolute. Quicken, QuickBooks, NetSuite, Business Central and Xero all import structured data only. There is no setting, add-on or preference that teaches any of them to read a PDF statement, whether it came from online banking or from a scanner.

The fix is to convert the statement into the format the destination reads before you go anywhere near the import screen. Which format that is varies more than people expect:

Notice that OFX is not universal. Xero and NetSuite read it happily, Quicken does not accept it at all, and Business Central has no OFX parser out of the box. Getting this one choice right removes most import problems before they start.

2. The format is supported but the version is not

A file can be genuinely OFX and still be rejected. OFX has gone through several revisions, and parsers support specific ones. NetSuite's OFX and QFX parser reads versions 102, 103, 211 and 220, so a file built to a version outside that list will not load even though the extension looks correct.

If you are converting a statement yourself, check what version the output declares. The OFX produced by the bank statement OFX converter here is version 102, which sits inside the range NetSuite accepts and the range most other OFX readers handle comfortably.

3. The character encoding is wrong

Encoding failures are the ones that look like a corrupt file. Import parsers generally expect UTF-8. NetSuite's CAMT.053 parser accepts UTF-8 only, its OFX and QFX import asks you to select an encoding rather than guessing, and a file saved as ANSI or with a byte order mark the parser does not expect will be refused without explaining why.

Before assuming the statement itself is broken, open it in a text editor, save it again as UTF-8, and retry the import. That resolves a good share of failures that otherwise send people back to the bank for a fresh download.

4. The date format does not match

This one is dangerous because it often does not fail. It succeeds and puts the transactions in the wrong month. Quicken for Windows expects mm/dd/yyyy in a CSV import, while Quicken for Mac expects D/M/YY or DD/MM/YYYY. The same file moved between the two silently swaps day and month for every date before the 13th, and nothing warns you.

In Business Central the equivalent trap sits in the data exchange definition, which describes how the columns in your file map to fields. If the date format it expects does not match what is in the file, the import can still parse and simply place rows in the wrong period, where they disappear behind the statement date filter. Confirm the format matches rather than assuming a successful import means correct dates.

5. The amounts have the wrong sign

Some banks export files that cannot carry a minus sign and instead mark withdrawals with a separate indicator column. If the import does not know which value means negative, every debit lands as a positive number and the reconciliation is off by twice the total.

Business Central handles this with the Negative-Sign Identifier setting, which names the value in the file that means negative so those amounts get reversed during import. If your file already carries debits as negative numbers you can ignore it and map one signed amount column, which is simpler and harder to get wrong. Details on the setup are on the Business Central bank statement import page.

6. The file contains more than one account

Several import routes assume one account per file. NetSuite's default CSV parser is explicit about it: the template must be used as it comes, and a CSV can only contain transactions belonging to a single account. Combine checking and savings into one spreadsheet and the import either fails or files everything into whichever account you selected.

BAI2 is the exception, since it can hold several accounts in one file when each carries its own account and routing numbers. That is why treasury teams prefer it, though NetSuite's default BAI2 parser only covers TD, Wells Fargo, US Bank, JP Morgan Chase and Bank of America Merrill Lynch. For any other institution you are back to one file per account.

The same logic applies when converting. If you are batching a year of statements, merge only the documents that belong to the same account and keep different accounts in separate files, which the bulk bank statement converter page covers in more detail.

7. You are on a page that cannot import

Sometimes the import action is genuinely not there. In the North American versions of Business Central, the Bank Rec. Worksheet page is built for checks and deposits and does not allow importing bank statement files at all. The Bank Recon. with Auto. Match field on the General Ledger Setup page switches between that worksheet and the Bank Acc. Reconciliation page, which is where Import Bank Statement lives.

NetSuite has a milder version of the same confusion. Statement files go in through the Bank Statement Upload page against a Financial Institution record and its format profile, and the result shows in Banking Import History. Worth knowing before you start: that import brings in statement data for reconciliation and does not create transactions for you. The NetSuite bank statement import page walks through the whole path.

How to check a statement before you import it

Two checks catch nearly everything, and both take seconds. Compare the transaction count in your converted file against the printed statement, then compare the closing balance. A missed or misread amount changes the total, so a closing balance that matches is strong evidence the lines in between are right.

Do this before the import rather than after. Finding a discrepancy in a file is a small problem. Finding it after a few hundred rows have posted into a register means unpicking an import, and in software with no duplicate matching, such as a Quicken CSV import, reimporting a corrected file just adds every row a second time.

If your statements arrive as email attachments each month, it is worth pulling them out of the inbox automatically rather than saving each one by hand, since turning recurring email attachments into structured data removes the step where files get misnamed or missed entirely.

When the format is simply wrong for the job

One last thing worth saying, because it causes problems that look like import failures but are not. CSV carries no unique transaction identifier. OFX and QFX both do, in a field called FITID, and that identifier is what lets software recognize a transaction it already holds.

So if you load overlapping periods from CSV files, nothing on either side can tell that January is already in there, and you get a duplicated month with no warning. Neither Quicken CSV import path does duplicate matching. When you are loading history in batches, use QFX for Quicken or OFX for software that reads it, and keep CSV for cases where the destination is a spreadsheet you will review yourself. There is a fuller walkthrough of the Quicken route on the convert bank statement to Quicken page.