Excel can't read .ofx files natively. Here are three ways to get the data into a spreadsheet — one takes about ten seconds.
Drop your file below — runs entirely in your browser, nothing is uploaded.
You downloaded an .ofx file from your bank, tried to open it in Excel, and got either nothing or a screen of angle brackets. Nothing is broken. An OFX file is a financial data format, not a spreadsheet, and Excel has never shipped an importer for it.
An .ofx file is Open Financial Exchange data — the bank-neutral standard that Quicken's QFX and QuickBooks' QBO are both built on, and what most banks emit when the download isn't tied to one product. Whatever produced it, the contents are Open Financial Exchange data — markup designed for software to read rather than people. Excel has no importer for it, so you get one of three unhelpful outcomes.
Open one in a plain text editor and you'll find something like this. Each transaction is a STMTTRN block, inside a statement section identifying the account:
<BANKACCTFROM>
<BANKID>021000021
<ACCTID>1234567890
<ACCTTYPE>CHECKING
</BANKACCTFROM>
<BANKTRANLIST>
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20250601120000[0:GMT]
<TRNAMT>-45.20
<FITID>202506010001
<NAME>STARBUCKS STORE 04821
<MEMO>CARD PURCHASE
</STMTTRN>
</BANKTRANLIST>Note the missing closing tags on leaf elements — valid OFX 1.x, and exactly what breaks generic XML tools. Note DTPOSTED too: a date, a time and a timezone marker in one field. Only the first eight digits matter for bookkeeping, which is why a good converter strips the rest and a lazy one hands you the raw string in a date column.
FITID is worth keeping. It's the bank's unique ID for that transaction, and it's what accounting software uses to avoid importing the same transaction twice.
Worth knowing if you'd rather not use a tool at all. Copy the file, change the extension to .xml, open it in Excel and choose "As an XML table". Excel builds a table from the tags.
Two caveats. It only works on OFX 2.x files with proper closing tags — a parse error means your file is SGML-style and this route is closed. And you get raw fields: dates as 20250601120000, one column per tag, account details interleaved with transactions. Cleaning that up by hand takes longer than the conversion did.
A common surprise: people looking for a OFX-to-Excel converter often don't have a OFX file. Most banks only offer structured downloads for recent months — beyond that window you get a PDF, which no format converter can help with.
That needs a statement parser: something that infers the column layout from the document itself, handles scanned pages with OCR, and checks the running balance reconciles so a misread row surfaces instead of quietly landing in your books.
| Method | Handles scans | Uploads your file | Effort | Output |
|---|---|---|---|---|
| Converter on this page | n/a | Seconds | Clean .xlsx, one sheet per account | |
| Rename to .xml | n/a | 10–20 min per file | Raw tags, manual cleanup | |
| PDF statement converter | Seconds | Excel, CSV, QBO, OFX, QIF |
A OFX file means your bank gave you structured data — which most banks only do for the last few months. Beyond that you get a PDF, and a PDF won't open in Excel. BalanceExtract reads those directly: it works out the column layout from the document itself, handles scanned statements with OCR, checks that every running balance reconciles, and flags any row it isn't confident about before you export.
Same Excel output, same on-device processing, nothing uploaded.
That's the raw DTPOSTED field: date, then time, sometimes a timezone marker like [0:GMT]. Only the leading eight digits are meaningful. The converter here keeps just the date; if another tool gave you the full string, you're seeing the field untouched.
OFX signs from the account's point of view — money leaving is negative, money arriving is positive. Credit-card files follow the same rule, so a purchase is negative and a payment towards the card is positive. It reads backwards at first but it's consistent.
That's FITID, and you want it. Accounting software uses it to spot transactions it has already imported. Deleting the column before importing is how you end up with every transaction twice.
Your download bundled several statements. Each account gets its own sheet in the Excel export here — if a tool gave you one interleaved list, it read the transactions without reading the account sections around them.
Same format underneath, different extension and header. The converter above accepts all three, so there's nothing to change.
Check the warnings shown after conversion. Records with an unparseable date or amount are reported and counted rather than dropped silently — a converter that shows no warnings and fewer rows than you expected is the one to distrust.
Select the table, Insert → PivotTable, then Payee as rows and Amount as values. Two clicks to see where the money actually went, which is usually the reason for the conversion.
Transactions are categorised on your device as part of the conversion. Sort or filter by it to split business from personal, or sanity-check a month before it reaches your books.
The Balance column carries the bank's own running balance. If it doesn't move by the Amount on every row, something upstream is wrong — a genuinely useful check that almost nobody uses.
QuickBooks, Xero, Wave and FreshBooks all take CSV. To skip column mapping, convert to native QBO or OFX instead and import that.
Honest side-by-side write-ups, including where each of them is the better choice.