The .ofx file.
Also .qfx, .qbo, which are read the same way.
- Carries
- A bank-assigned unique id per transaction
- Type codes
- Debit, credit, fee, interest, transfer and more, as declared values
- Dialects
- SGML in older files, XML in newer ones
- Variants
- .qfx for Quicken, .qbo for QuickBooks
- Read here as
- Direct. Type codes and references make matching far better than a CSV.
- Status
- Ready
- Fidelity
- Read directly
- Largest file
- 25 MB free, 250 MB once a project is bought
What it actually is
Transactions come with their own type codes and references, which makes matching far better than a CSV.
OFX is the interchange format banks use for statements. Each transaction carries a unique id assigned by the bank, a type code distinguishing a debit from a fee from a transfer, an amount, a date, and the free-text memo and payee fields.
The unique id is the important one, because it is what makes a transaction identifiable at all rather than a date and an amount that two rows might share. Nothing here deduplicates across two uploads, though, so an overlapping export still arrives twice.
Quicken's .qfx and QuickBooks' .qbo are OFX with a vendor block on top, and fold into this page. The older Microsoft Money .ofx files are SGML rather than XML, and both dialects are read.
Upload one
The analysis runs before there is anything to pay for.
You see what it found, and the evidence behind it, first.
No account needed to start. You only pay when you like what you see.
What goes wrong, and what is done about it
3 named failures, each with the repair.
Transfers between your own accounts counted as income
Moving money from a savings account to a current account produces a credit that looks exactly like revenue in the receiving account. A year of that inflates income by whatever you moved, and the total still reconciles against the bank.
What is done: Nothing pairs the two sides. Transactions are read as the bank wrote them, so a transfer arrives as a credit in one file and a debit in another, and taking it back out of income is work for a person.
Dates that shift by a day
OFX timestamps carry a timezone offset that some banks emit incorrectly or omit entirely. A transaction at 23:40 then lands on the wrong day, which matters at every month boundary.
What is done: The date arrives as the bank wrote the field, offset and all. Nothing converts it into an account timezone, so a transaction near midnight can land on either side of a month boundary depending on what the bank emitted.
Memo fields that are the same merchant three ways
A statement says SQ *THE COFFEE HOUSE 04, not "lunch", and the descriptor changes when the merchant changes payment processor. Categorising on the raw string produces three merchants where there is one.
What is done: Nothing normalises them. The memo arrives exactly as the bank wrote it, so three descriptors for one merchant stay three, and collapsing them is a step to take in the file before it is uploaded.
If you have the choice, send something else
If your bank offers both, OFX beats CSV and both beat a PDF statement. A PDF has already discarded the reference field that invoice matching runs on, so a PDF-only project reconciles less and says so.
Questions people ask
About this format, not about the product.
Does this connect to my bank?
No, and it never asks for a login. It reads files you export yourself. There are no credentials stored and no ongoing access to revoke.
Can I upload several accounts?
You can, and each one is read and converted. They are not analysed together, though, the analysis runs on a single table, so a transfer between two of your own accounts is not paired up across them.
What if I upload overlapping periods?
The bank's transaction ids arrive in the data, but nothing deduplicates against another file. Two overlapping exports mean the transactions in the overlap are present twice, so trim the periods before uploading rather than afterwards.
Keep reading
The jobs people do with this file, and the formats beside it.