Convert PDF bank statements to OFX

An OFX file is tagged text rather than rows and columns: every value sits inside a named tag, so an importer reads fields rather than guessing at column positions. Here is the header of a file generated from a sample checking-account statement.

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE

Then the statement's own context: currency, the account it belongs to, and the date range the transactions cover.

<CURDEF>USD
<BANKACCTFROM>
<BANKID>021000021
<ACCTID>****4821
<ACCTTYPE>CHECKING
</BANKACCTFROM>
<BANKTRANLIST>
<DTSTART>20260301
<DTEND>20260328

• CURDEF is the statement currency, taken from the account or, for an imported file that did not record one, from the transactions themselves.
• BANKACCTFROM holds the routing number, the account number and the account type (CHECKING or SAVINGS). A credit card uses CCACCTFROM with just the card number.
• DTSTART and DTEND are derived from the earliest and latest transaction dates in the file, not from the statement period printed on the page.
• LEDGERBAL, at the end of the statement body, states what the account stood at and when. An importer can compare that figure against its own register after loading, which a CSV of the same rows gives it no way to do.

Each transaction is a STMTTRN. Six tags, and every one of them means something specific.

TRNTYPE follows the sign of the amount written beneath it. DTPOSTED is a date with no time component. TRNAMT is signed, negative for money out of a bank account. NAME is capped at 32 characters by the format, so a longer description is repeated in full in MEMO rather than being lost.

A CSV row is a sequence of values whose meaning lives in a header you agree on separately. An OFX record names each value in the file itself. Three things follow from that.

First, no column mapping. An importer reading OFX already knows which value is the date and which is the amount, so there is no wizard step where you tell it, and no chance of a mapping that silently swaps two columns.

Second, account context travels with the data. The file states its currency, its account and its closing balance. A CSV of the same rows states none of that unless you add columns for it.

Third, each transaction has an identity. That is what the next section is about, and it is the field most often described inaccurately.

Every transaction in an OFX-family file carries a FITID. It is an identifier, and an importer may use it to recognise a transaction it already holds. Whether it does, and what it does when it matches, is entirely the importer's behaviour. Xero, for instance, documents its own duplicate handling on import; other products handle it differently or not at all.

What is under our control is what goes into the field. The value is built from two things only: the date the row posted, and where the row sits in the file. So the second row of the March sample is 20260303000001. Re-exporting an unchanged review reproduces every value exactly; changing a description or a figure touches none of them; and removing or adding a row renumbers everything below it, because position is half the identifier.

In practice: re-import a file you have not touched and any importer that checks identifiers will recognise it. Change which rows are in the file and you are relying on that importer's own matching instead.

Worth knowing before your first import. Where a statement prints an opening balance, that line is kept as a row so the running balance in the extraction can be checked from the start. It has a date and a balance but no amount, and in an OFX file it comes out like this:

<STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20260301
<TRNAMT>0.00
<FITID>20260301000000
<NAME>Opening Balance
</STMTTRN>

Most importers ignore a zero-amount transaction or post it harmlessly. Some list it as a transaction you then have to reconcile against nothing. If yours is the second kind, delete that row in the review step before exporting; it exists to make the balance check possible, and the check has already happened by then.

A short list of destinations whose current documentation names OFX, rather than a long list of logos.

• Xero documents importing OFX bank statements and recommends OFX over its other supported formats where the bank offers it. Its current guidance also says PDF bank statements cannot be imported through that workflow.
• QuickBooks Online accepts OFX in its transaction-list upload, though it can also take a statement PDF directly.
• GnuCash documents OFX and QFX among its file import formats.
• Sage documents OFX for bank statement import in more than one product, though the accepted format list differs by product; check the one you use.

If your software is not here, look for OFX in its own import documentation rather than assuming either way. It is a widely read format, and this list is short on purpose.

• Quicken: QFX , which adds the Intuit institution tags Quicken's Web Connect expects.
• QuickBooks Desktop Bank Feeds: QBO .
• Review by a person, or a workpaper: Excel .
• Custom mapping, scripts, databases: CSV .