OFX file won’t import: common errors and fixes
An OFX file can fail even when it came directly from a bank, credit card provider, payroll system, or finance export tool. The file may have the right extension, and it may even look readable in a text editor, but the accounting application still says the import failed, the file is invalid, or the statement contains no transactions.
OFX is a family of formats rather than one perfectly uniform file shape. Some exports use older SGML-style OFX with a header block at the top. Others use XML-style OFX with explicit closing tags. Some applications accept both. Others only accept a narrow subset. That is why the same file can import into one product and fail in another.
If you need a quick diagnosis before you edit anything, run the file through the checker:
Confirm that the file is really OFX
Start with the boring check: make sure the file actually contains OFX data. Banks sometimes offer several export choices from the same screen. It is easy to download CSV, HTML, PDF, or a web page error response and save it with the wrong extension. A true OFX file usually starts with an OFX header such as OFXHEADER:100, or with XML declaration text followed by an <OFX> root.
If the first lines contain a login page, HTML tags, a spreadsheet header, or a bank error message, the accounting app is not the problem. Download the file again and choose the OFX, QFX, or QBO export option explicitly.
Header and version problems
Older OFX files often begin with a block like this:
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONESome importers are strict about these fields. A missing OFXHEADER, unsupported VERSION, or inconsistent ENCODING can stop the import before the application reaches your transactions. Other importers ignore part of the header and attempt to parse the body anyway. That inconsistency creates confusing support situations: the bank says the export is valid because one app imports it, while your destination app refuses it.
Header issues are especially common when software converts CSV or internal ledger data into OFX. The converter may produce a body that looks close enough but forget fields that older importers still expect.
XML and SGML shape problems
OFX SGML allows tags that are not closed the way XML tags are closed. XML-style OFX requires matching opening and closing tags. If a converter mixes these styles, the file can become ambiguous. A missing </OFX> closing tag, an unescaped ampersand in a memo field, or a partially written transaction block can break the parse.
This is also why copying and pasting statement data between tools is risky. One invisible character in a memo, payee name, or bank-provided description can make the file invalid XML. Common offenders include raw &, control characters, smart quotes from office software, and non-UTF-8 bytes declared as UTF-8.
Date formats that look right but fail
OFX dates commonly appear as compact timestamps such as 20260131120000 and may include timezone offsets. Many accounting apps tolerate plain dates, but not all tolerate malformed timestamps. Typical breakage points include:
- month or day values outside the real calendar
- timestamps with punctuation where the importer expects compact digits
- timezone suffixes in a form the destination app does not support
- posted dates later than expected because the export used authorization dates
- empty or repeated date fields inside a transaction
Dates matter because many importers use them to decide whether a transaction is new, already imported, or outside the selected statement range.
Missing account identifiers
An OFX bank statement usually needs an account block that identifies the institution and account. Checking and savings files often use BANKACCTFROM; credit card files often use CCACCTFROM. If routing, bank ID, account ID, or account type fields are missing, the importer may not know where to attach the transactions.
This problem is common after anonymizing a file for support. Redacting account numbers is reasonable, but replacing a required field with an empty value can change the import behavior. If you need to share a sample, replace sensitive digits with realistic placeholder digits rather than deleting the entire tag.
Duplicate or missing FITID values
FITID is one of the most important OFX transaction fields. It is the transaction identifier importers use to avoid duplicates. If every transaction has the same FITID, some apps import only one transaction. If FITID is missing, an app may reject the file or generate unstable IDs on each import.
Duplicate IDs often come from homegrown converters. The converter may use the date as the ID, which breaks when several transactions post on the same day. A better ID usually combines stable source fields such as posted date, amount, sequence, and institution transaction ID.
Amount and sign problems
Amounts should be machine-readable, not localized display text. A value like -42.15 is usually safer than -$42.15, 42,15, or (42.15). Decimal separators, thousands separators, and currency symbols can all create trouble. Some exports also invert signs, causing deposits to appear as withdrawals or card payments to appear as charges.
Before importing a repaired file, scan a few representative transactions and confirm the sign convention matches the destination app.
Symptoms you may see in accounting apps
Different products describe the same OFX problem in different language. One app may say the file is not valid. Another may say the selected account cannot be used. Another may import the statement but show no new transactions. Those messages can all point back to the same underlying file issues.
Common symptoms include:
- the app rejects the file immediately
- the app asks you to choose an account, then fails after selection
- the account appears to import, but transaction count is zero
- only the first transaction imports
- balances appear but transactions do not
- transactions import with the wrong signs
- repeated retries create duplicates
The exact message matters less than where the import stops. If it fails before account selection, suspect file type, header, XML, or institution metadata. If it fails after account selection, suspect account mapping, account type, dates, or statement range. If it imports partially, suspect transaction IDs, malformed transaction blocks, or specific characters inside one row.
When not to edit the file
Manual editing is useful for diagnosis, but it is not always the safest fix. Do not edit the only copy of a statement. Do not edit a file after it has partially imported unless you understand what was already posted. Do not remove account identifiers entirely when redacting a file for support, because empty required fields can create new errors.
If the file came from a bank, try another export first. Shorter date ranges often help. A full year of transactions may fail because one row is malformed, while a one-month export can identify the bad range. If your bank offers OFX, QFX, QBO, and CSV, download more than one format and compare the transaction count and date range.
What to do next
Do not keep retrying the same broken file. Each retry can create duplicate imports, partial imports, or confusing account mappings. Use this sequence instead:
- Keep an untouched backup of the original export.
- Confirm the file is actually OFX content.
- Check header, body structure, account fields, dates, amounts, and
FITIDvalues. - Import a small repaired sample before importing a full statement.
- Reconcile totals after import.
correctbankfile.com is designed for that first diagnostic pass. It checks the file shape and points out likely blockers before you retry the import.
Upload your OFX file and see what is blocking import
Check your bank file before you import again
Upload the export and get practical diagnostics for finance-file import failures.