Bank statement to OFX
The open standard your bank would have given you, if it had given you anything but a PDF.
OFX (Open Financial Exchange) is the format banks use when they let you download transactions directly. Most accounting software accepts it without any column-mapping step: you open the file and the transactions are simply there, with dates, amounts and descriptions already in the right places.
If your software supports OFX, it is usually the best of our five exports to use. Nothing to map, nothing to configure, no date-order ambiguity.
Which version we write, and why it looks old
We write OFX 1.0.2, which is SGML — tags that are not closed — rather than the newer 2.x, which is XML.
This is deliberate and it is not a shortcut. A large share of the software people actually import into, including QuickBooks Web Connect, rejects the XML form outright. A file that validates beautifully and will not import is worth nothing. So the file we hand you is the dialect the importers accept, encoded as Windows-1252 with Windows line endings for the same reason.
If you specifically need OFX 2.x XML, we do not produce it today.
Transaction types
OFX asks every transaction to declare a type. Your PDF does not carry one, so we derive it from what is printed: the direction of the amount and the wording of the description. A negative amount described as a card purchase becomes a debit, an incoming transfer becomes a credit, and so on.
Where the statement gives us nothing to go on, the transaction gets the generic type rather than a guess that looks specific. A wrong-but-confident type is harder to spot later than a vague one.
Long descriptions, and re-importing the same file
OFX limits the payee name to a short field, so a long description is truncated there and written out in full in the memo field alongside it. Nothing is lost; your software decides which of the two it shows you.
Each transaction also carries an identifier built from where it sat in your PDF. That has a useful consequence: importing the same statement twice does not duplicate the transactions, because your software sees the same identifiers and skips them. It also means that if you convert a corrected statement where rows have moved, the identifiers move too — check the import preview in that case.
What else is in the file
Above the transactions, the file carries the header that declares it as OFX 1.0.2 SGML, and then one statement block per account. Each block states the currency, the account number as printed on your statement, the account type mapped to the OFX vocabulary — checking, savings, credit line — and the statement period, taken from the dates the statement itself prints rather than from the day you ran the conversion.
Where the statement prints a closing balance, it is written as the ledger balance, dated to the end of that period. Where it does not, the field is left out rather than filled with a total we worked out ourselves; the same rule as everywhere else in the export.
One field is deliberately fake and you should know which: the routing number is written as zeros. We are not your bank and we will not put your bank’s real number into a file we generated.
What the file does not claim to be
The OFX file identifies the account by the number printed on your statement — normally already masked by your bank — and does not claim to come from your bank’s servers. It is a conversion of a document you already had, and it is honest about that. See QBO for the one place where this has a practical consequence you need to know about.
The “we could not read this” warning
If part of your PDF did not make it into the file, the warning is written into the OFX file itself, after the transaction data, where importers stop reading. Your software will not choke on it, and anyone who opens the file in a text editor will see it.
The same warning is shown on screen before you download, and it is never hidden behind payment. Knowing that a conversion is incomplete is not a premium feature.