NetSuite Bank Statement Import: Convert PDF Statements to OFX and CSV for the NetSuite Bank Statement Parsers

What format does NetSuite need for bank statements?

NetSuite reads OFX, QFX, CSV, BAI2 and CAMT.053 through its default parsers, and the Bank Statement Parsers SuiteApp adds an MT940 parser. QIF is documented as not supported. PDF is not a supported input in any configuration, which is why a statement downloaded from online banking has to be converted before it can take part in a reconciliation.

Choosing between the accepted formats is mostly a question of what your bank actually provides and how much setup you want to maintain. The table below is the short version.

Can NetSuite import an OFX file?

Yes. OFX is handled by a default parser, and the OFX and QFX parser in the Bank Statement Parsers SuiteApp reads versions 102, 103, 211 and 220, accepting either a period or a comma as the decimal separator. During the import you are asked to select the character encoding for the file. The OFX produced by this converter declares version 102, which sits inside that supported range.

OFX tends to be the path of least resistance for anyone loading statements by hand. Unlike the CSV route it does not depend on matching a column template exactly, and unlike BAI2 it does not depend on your bank being one of the handful the default parser recognizes. It also carries a unique identifier on each transaction, which gives reconciliation a real basis for spotting a line that has already been loaded. There is more on the structure of the format on the OFX file format page.

How do I upload a bank statement in NetSuite?

Statement files go in through the Bank Statement Upload page, which works against a Financial Institution record and the format profile attached to it. The financial institution record holds the bank and account details, the format profile tells NetSuite which parser to run and how fields map, and Banking Import History is where you confirm afterwards that the file parsed and the expected transactions arrived.

One detail worth setting expectations on: the Bank Statement Parsers SuiteApp imports statement data only. It does not create NetSuite transactions from the file. What you get is statement lines available to bank reconciliation, which is exactly what you want for matching, but it is not a shortcut for posting entries that were never recorded.

Why the CSV route is fussier than it looks

Plenty of teams reach for CSV first because a spreadsheet feels like the flexible option. In NetSuite it is the opposite. Importing with the default parser means using the CSV template that downloads from the Bank Statement Upload page exactly as it comes, in UTF-8, with a .csv extension, and a single file can only carry transactions belonging to one account. A spreadsheet assembled by hand, or exported from another tool with its own column order, will not line up.

That is fixable, either by reshaping the export to the template or by building a custom format profile with your own field mappings, and for a recurring monthly file it can be worth doing once. For a one-off catch-up across several accounts it is usually more work than converting to OFX and skipping the mapping question entirely. If a spreadsheet is genuinely the destination rather than a means to an end, the PDF bank statement to CSV converter covers that output directly.

Loading history the bank feed cannot reach

This is the common reason finance teams end up converting statements at all. Bank download screens typically serve about 90 days of activity, while statements go back years, so any NetSuite implementation, account migration or audit request that touches prior periods runs past the edge of what a feed will give you. The statements themselves are the only complete record.

For that kind of catch-up, convert the monthly PDFs as one batch rather than one at a time. Up to 50 files go in a single upload, and when every document belongs to the same account you can merge them first, so twelve monthly statements come back as one continuous file covering the year and one upload into NetSuite instead of twelve. The bulk bank statement converter page covers how batching and merging behave in more detail.

Checking the import before you reconcile

Two checks catch nearly everything. First, compare the transaction count and the closing balance of each converted statement against the printed document, because a missed or misread amount changes the total and a matching closing balance is strong evidence the lines in between are correct. Second, open Banking Import History after the upload and confirm the file parsed and produced the number of lines you expected.

If a file is rejected without an obvious reason, encoding is the usual culprit. The parsers expect UTF-8, the CAMT.053 parser accepts UTF-8 only, and the OFX and QFX import asks you to choose an encoding rather than guessing. Re-saving the file as UTF-8 and re-running the upload resolves a good share of the failures that otherwise look like a corrupt statement.