OFX to CSV Converter

An OFX file is a bank's answer to a question, not a table of numbers. The format was designed in 1997 around a request-and-response conversation between finance software and a bank server, and the file you download is one frozen response from that conversation. That is why it opens with a sign-on block reporting a status code, wraps the statement in a transaction-response envelope carrying its own status, and only then declares which account this concerns before listing what happened to it. Most of the document is protocol scaffolding; the transactions are the payload buried inside.

Converting to CSV keeps the payload and discards the envelope. Each transaction record yields one row with five fields: the posted date, the signed amount, the description, the transaction type, and the FITID. Dates are normalised from the OFX timestamp — which carries a time and a bracketed timezone offset such as [-5:EST] — down to a plain YYYY-MM-DD that Excel and Google Sheets recognise as a date without being told. Descriptions are read from MEMO where the bank filled it and from NAME where it did not, and every field is properly quoted, so a payee containing a comma stays in one cell.

The statement-level facts stay behind, and that is usually the right call. LEDGERBAL and AVAILBAL report the closing and available balances for the whole statement, and DTSTART and DTEND bound the period it covers — one value each for the file, not per transaction, so putting them in a column would mean repeating the same number down every row. If you need them, they are readable in a text editor at the bottom of the statement block. What people actually reach for the CSV to do is reconcile against an accounting system line by line, pivot a year of spending by month, hand transactions to a bookkeeper who does not use their software, or check what a bank actually sent before importing it anywhere.

Excel turned my FITID column into scientific notation. Many banks build FITIDs out of long digit strings, and Excel treats anything that looks numeric as a number, so a sixteen-digit ID becomes 1.23457E+15 and the original value is gone. Import with Data > From Text/CSV and set the FITID column to Text before loading, rather than opening the file by double-click.

Long descriptions are cut off mid-word. That truncation comes from the bank. NAME is conventionally limited to 32 characters, and institutions that do not also populate MEMO leave you with the abbreviation and nothing else. The converter prefers MEMO precisely because it is usually the longer field — if the output is short, the long form was never in the file.

A day's transactions appear on the previous or following day. OFX timestamps carry a timezone offset in brackets, and a transaction posted late in the evening in one zone can carry a date that reads as the next day in another. The date is taken exactly as written in DTPOSTED, without shifting it into your local timezone — so an occasional off-by-one against your bank's web view reflects that offset rather than a parsing error.

The file produced no rows at all. Three causes account for nearly all of these: an investment statement, which stores activity in a different record type than bank and card statements do; a genuinely empty date range; and an HTML page saved with an .ofx extension after a bank session expired mid-download. Opening the file in a text editor distinguishes them immediately — an HTML error page is unmistakable.