PDF to OFX converter
Convert PDF bank statements into .OFXfiles that import into almost any accounting or personal-finance app — no CSV, no column mapping. FlowParse AI reads any bank's statement and builds a ready-to-import bank-feed file, with .QBO (QuickBooks) and .QFX (Quicken) on the same download.
Any bank · scanned or digital · balance-validated · unique transaction IDs
Free to start · QBO, QFX and OFX files included on every plan
A real sample: bank statement (us style) — to a ready .OFX bank feed
A fictional sample document converted by the same engine you get — flip through the source PDF and every export format, or download the files themselves.
One open format, almost every finance app
OFX (Open Financial Exchange) is the open bank-feed standard the whole industry agreed on — the format banks use to send transactions to your software. If your bank only gives you PDF statements, an .OFX file is the most portable way to get that history into your books, because the long list of apps that read it includes GnuCash, MoneyDance, Banktivity, Sage and many more.
FlowParse extracts every transaction from your PDF statement and writes a valid .OFX you import in one step — no columns to map. Need an Intuit-tagged variant? The same engine builds .QBO for QuickBooks and .QFX for Quicken.
In the file
Imports into
Why an .OFX beats a CSV import
A CSV is just raw text: your app has to be told which column is the date, which is the description and which is the amount — every single time. Day-first dates, split debit/credit columns or currency symbols inside the amount all break the mapping and send you back to cleaning a spreadsheet.
An .OFX file is already structured the way finance software expects. Date, signed amount, description and a unique transaction ID are all tagged, so your app just reads it — no mapping, no guesswork — and the transaction IDs give you duplicate protection for free.
| CSV import | .OFX file | |
|---|---|---|
| Column mapping | Manual, every time | None — auto |
| App compatibility | Varies per app | Universal standard |
| Duplicate protection | No | Yes (FITID) |
| Debits & credits | You fix the signs | Pre-signed |
| Import speed | Minutes of fiddling | One step |
.OFX, .QBO and .QFX — which one?
All three are the same OFX family. Plain .OFX is the generic file most apps read; the .QBO and .QFX variants add an Intuit identifier so QuickBooks and Quicken accept them as Web Connect downloads. Pick .OFX unless your software specifically asks for one of the Intuit variants.
| Format | Use it for |
|---|---|
| .OFX | GnuCash, MoneyDance, Banktivity, Sage & most apps |
| .QBO | QuickBooks Online & Desktop (Web Connect) |
| .QFX | Quicken (Web Connect) |
Prefer a spreadsheet? The same data also exports to Excel and CSV.
From PDF to bank feed in three steps
1 · Upload the PDF
Drop your PDF bank statement — digital or scanned, any bank, any number of pages.
2 · AI builds the file
FlowParse extracts every transaction, signs the amounts, checks the balances and writes a valid .OFX / .QBO / .QFX.
3 · Import anywhere
Open your app's File → Import → OFX and select the file. Transactions post automatically — no mapping.
How to import the .OFX
GnuCash: File → Import → Import OFX/QFX → choose the file → map it to the right account on first import.
MoneyDance / Banktivity: File → Import → select the .OFX → confirm the account.
Sage / Wave: import the .OFX (or the spreadsheet export) under the matching bank account — see bank statement to Sage and bank statement to Wave.
Because each transaction carries a unique ID, importing the same file twice won't create duplicates. Two different PDFs covering overlapping dates are not protected that way — see how duplicate protection works.
Works with any bank's PDF
Because extraction is AI-based rather than template-based, FlowParse reads layouts it has never seen — so you don't need a converter per bank:
Converting a whole year across several accounts? Use Smart Merge to consolidate first.
Validated before it reaches your books
A bad import is worse than no import. Before the .OFX is built, FlowParse checks the data so what lands in your software is complete and correct:
See the validation engine for how the checks work.
Any bank → one portable bank-feed file
Upload statements from every account you have — FlowParse turns each into a clean .OFX you can import anywhere.
What an OFX file from a PDF statement looks like
An OFX file is plain text. Open one in a text editor and you see a short header followed by tagged blocks: who produced the file, which account it belongs to, the list of transactions and the balance. This is a shortened version of what FlowParse writes for a two-line checking account statement:
OFXHEADER:100
DATA:OFXSGML
VERSION:102
ENCODING:USASCII
CHARSET:1252
<OFX>
<SIGNONMSGSRSV1><SONRS> … </SONRS></SIGNONMSGSRSV1>
<BANKMSGSRSV1><STMTTRNRS>
<STMTRS>
<CURDEF>EUR
<BANKACCTFROM><BANKID>000000000<ACCTID>****4821<ACCTTYPE>CHECKING</BANKACCTFROM>
<BANKTRANLIST><DTSTART>20261001<DTEND>20261031
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20261003
<TRNAMT>-64.20
<FITID>2026100301N6420k3x9
<NAME>CITY ELECTRIC
<MEMO>CITY ELECTRIC | Ref 88412
</STMTTRN>
<STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20261015
<TRNAMT>1850.00
<FITID>2026101502P185000p2am
<NAME>PAYROLL NORTHSTAR LTD
</STMTTRN>
</BANKTRANLIST>
<LEDGERBAL><BALAMT>3412.55<DTASOF>20261031</LEDGERBAL>
</STMTRS>
</STMTTRNRS></BANKMSGSRSV1>
</OFX>| Tag | What it holds | Where it comes from |
|---|---|---|
| CURDEF | Currency as an ISO code (EUR, GBP, USD…) | The statement's currency; € or £ become EUR or GBP; USD when none is printed |
| ACCTID | Account number | The account number as printed, often masked (****4821) |
| DTSTART / DTEND | Statement period | First and last transaction date |
| TRNTYPE | DEBIT, CREDIT or OTHER | The sign of the amount |
| DTPOSTED | Booking date (YYYYMMDD) | The transaction date on the statement |
| TRNAMT | Signed amount, two decimals | Money out negative, money in positive |
| FITID | Transaction ID | Built from date, position, amount and payee — the same file always gets the same IDs |
| NAME | Payee, up to 32 characters | The description, shortened if longer |
| MEMO | Full detail, up to 255 characters | Description plus extra columns such as reference |
| LEDGERBAL | Closing balance and its date | Printed closing balance, else the last running balance |
The file uses OFX version 1.0.2 in its SGML form — the version that Web Connect downloads use, and the one that GnuCash, Moneydance, Banktivity and most other apps still read most reliably. It is written without a byte-order mark on purpose: a BOM in front of OFXHEADER:100 makes many importers reject the file as unreadable.
Two fields are worth knowing about before you import. The payee is limited to 32 characters by the format, so a long line such as a card purchase with a merchant city and terminal number is shortened in NAME — the full text is kept in MEMO. And the file carries one balance: the closing balance as of the last transaction. OFX 1.0.2 has no place for the opening balance in a statement download, so you set it once when you create the account in your software, and every file after that continues from there.
How duplicate protection works — and where it stops
Every transaction in the file has a FITID, and finance apps remember the FITIDs they have imported into an account. FlowParse builds the ID from the transaction's date, its position on the statement, the amount and the payee. Convert the same PDF again and you get the same IDs, so importing that file a second time — by accident, or because you were not sure the first import went through — is skipped rather than doubled.
The protection is per transaction ID, not per payment. If you import a September statement and later a quarterly statement that also covers September, the same payment appears in two different files at two different positions, with two different IDs, and the app sees two transactions. The fix is simple: import each period once. When you have several statements to bring in, merge them with Smart Merge and export the merge as a single .OFX — the transactions from all files go into one statement covering the whole period.
There is a second kind of duplicate that happens before the file is even written. Some banks print the same charge twice inside one statement: once in the transaction table and once in a notice block that announces it — “Avisos de lançamento” on Portuguese statements, “Avis de prélèvement” on French ones, “Lastschriftankündigung” on German ones. The notice row repeats the date and amount but has no running balance, because it is not part of the account's balance chain. FlowParse drops exactly those rows. Two genuine identical charges on the same day both sit in the table with their own balances, so both are kept.
Bank account or credit card: why the file type matters
OFX has two kinds of statement: a bank statement (checking or savings) and a credit card statement. They use different blocks in the file, and finance software treats them differently. If a credit card is imported as a checking account, the app offers to link it to a bank account, the balance has the wrong meaning and the card never reconciles.
FlowParse writes a card statement as a credit card statement. Purchases are negative, payments to the card are positive, and the closing balance is what you owe. When you import it, link it to a credit card account in your software — not to the current account the card is paid from. If you prefer a spreadsheet for card statements, see the credit card statement converter.
OFX, QFX, QBO, QIF or CSV?
The right file depends on what your software imports, not on which format is newest. This is how the options compare for bringing a PDF statement in:
| Format | Best for | Mapping on import | FlowParse |
|---|---|---|---|
| .OFX | GnuCash, Moneydance, Banktivity, Sage and most finance apps | None | Yes |
| .QFX | Quicken (Web Connect) | None | Yes |
| .QBO | QuickBooks Online and Desktop (Web Connect) | None | Yes |
| .QIF | Older Quicken and apps that never added OFX | Little, but no IDs or balance | No — use OFX or CSV |
| .CSV | Any app with a column-mapping import; spreadsheets | Date, payee and amount columns | Yes |
| .XLSX | Review, analysis, working papers | Not an import format | Yes |
One rule of thumb: if your software has an “Import OFX” or “Web Connect” option, use it. You skip column mapping, the signs are already right and you get duplicate protection. Keep CSV for apps that only accept a mapped file, and Excel for checking and analysing the data.
When an OFX import goes wrong
Most failed imports come down to a handful of causes. Check this list before you convert again:
| What you see | Usual cause | Fix |
|---|---|---|
| “File not recognised” | The file was opened and saved in Excel or another editor, which changed its encoding | Download it again and import it without opening it |
| QuickBooks or Quicken refuses the .OFX | Intuit products expect their own variant | Download the .QBO or .QFX instead — same data |
| Card shows as a bank account | A card was imported against a checking account | Link the file to a credit card account |
| Balance in the app is off by a fixed amount | The opening balance was never set | Enter the opening balance from the first statement once |
| Some payments appear twice | Two files with overlapping dates were imported | Delete the overlap; next time import each period once or merge first |
| Payee names are cut off | NAME is limited to 32 characters | Read the full text in MEMO, or set a payee rule in your app |
| Amounts in the wrong currency | The statement printed no currency, so the file used USD | Check CURDEF; set the account currency in your app |
Converting a PDF statement to OFX, step by step
- Upload the PDF. A digital statement downloaded from online banking gives the cleanest result; a scan works too. Password-protected PDFs ask for the password first.
- Check the preview. Look at the balance check first. If opening balance plus transactions does not reach the closing balance, find the row that breaks it and correct it before exporting.
- Choose the format. .OFX for most apps, .QBO for QuickBooks, .QFX for Quicken.
- Import into the right account. On the first import your software asks which account the file belongs to. Pick the existing account, or create one with the statement's opening balance.
- Spot-check the result. Compare the account balance in your software with the closing balance on the PDF. If they agree, the import is complete.
Why not just rename a CSV to .ofx? Because an OFX file is not a table. Renaming a CSV gives a file with the right extension and none of the tags — no account, no currency, no IDs — and every importer rejects it. Writing OFX by hand is possible for a few rows, but at fifty transactions a month the risk of one wrong sign or a missing closing tag is high, and one broken tag stops the whole import.
Catching up on months of statements? Upload them together, merge them, and export one .OFX for the whole period. You set the opening balance once, import once, and the closing balance in the file matches the last statement you hold. For QuickBooks the same applies to .QBO, and for Quicken to .QFX.
Who converts PDF statements to OFX
GnuCash & open-source users
Get PDF history into GnuCash, MoneyDance or Banktivity with a single OFX import.
Accountants
Move client transactions into whatever ledger they run, without re-keying.
Bookkeepers
Catch up months of statements in minutes — upload, download .OFX, import.
Small businesses
Import old or missing statements your bank only offers as PDFs.
Sage & Wave users
Bring bank history into Sage or Wave via OFX or the spreadsheet export.
QuickBooks & Quicken users
Get the Intuit-tagged .QBO or .QFX from the same upload instead.

