StatementEdge

Free tool

OFX file validator — know exactly what will import

Drop an .ofx, .qbo or .qfx file (the formats QuickBooks, Xero, Sage and Quicken read). We parse the header, validate the envelope, count the transactions and flag the things that silently break imports — duplicate FITIDs, missing dates, dates outside the statement period — before you waste a sync.

Runs entirely in your browser. The file is parsed locally — nothing is uploaded unless you choose the PDF-to-OFX path.

Runs in your browser
No upload, no signup. Your file never leaves your device.
Free and unmetered
Use it as often as you need. No daily quota, no credit card.
EU-built, GDPR-first
Hosted in Frankfurt. Built by a small EU team that takes privacy seriously.

Why validate an OFX file before importing it?

OFX, QBO and QFX are all variants of the same Open Financial Exchange format that QuickBooks, Xero, Sage, Quicken and GnuCash use to pull bank transactions. The file looks simple — a list of dated transactions wrapped in a few envelope tags — but accounting tools are strict about its shape. A single missing <FITID>, a date outside the declared period, or a header that says it's OFX 1.02 when it's really 2.0 can produce a silent failure: the import succeeds, but rows are dropped or duplicated, and you only notice when reconciliation explodes a month later.

This validator parses the file the same way your accounting tool will, then surfaces every quirk it finds — header version, account details, currency, declared period, ledger balance, every transaction, plus a full list of issues (duplicate FITIDs, missingDTPOSTED, mis-matched dates, missing envelope tags). You see exactly what would land in your accounts before you commit.

What the validator checks

  1. Format detection. OFX 1.x (SGML, with theOFXHEADER:100 preamble) vs OFX 2.x (XML, with an<?OFX VERSION="200"?> processing instruction). Both variants are supported.
  2. Header integrity. Version, encoding, security flag, charset. Most importers ignore these but a mismatched encoding can quietly corrupt non-ASCII transaction descriptions.
  3. Envelope structure. Presence of<SIGNONMSGSRSV1> and one of<BANKMSGSRSV1>, <CREDITCARDMSGSRSV1> or<INVSTMTMSGSRSV1>. Missing either makes most tools refuse the import.
  4. Account block. <BANKID>,<ACCTID>, <ACCTTYPE>,<CURDEF>. The account ID is what your accounting tool uses to map the import to the right ledger — without it, you get a manual mapping step.
  5. Transactions. Every <STMTTRN> block is parsed and we report its date, type, amount and FITID. Sums of debits and credits are shown so you can sanity-check against the statement total.
  6. FITID uniqueness. Importers dedupe by FITID — re-importing a file with duplicate FITIDs causes the second copy to be silently dropped. We flag every duplicate.
  7. Date sanity. Transactions outside the declared statement period, dates in the future, missing or unparseable DTPOSTED — all reported.
  8. Balance. Presence and value of <LEDGERBAL> and<AVAILBAL>. QuickBooks uses the ledger balance to confirm the import; missing it means manual reconciliation later.

OFX vs QBO vs QFX — what's the difference?

All three are the same underlying format, with small extensions:

  • .ofx — generic Open Financial Exchange. Used by GnuCash, KMyMoney, Sage and most direct-from-bank exports.
  • .qbo — QuickBooks Online / Desktop. Adds an INTU.BID(Intuit Bank ID) tag so QuickBooks knows which bank to associate. QuickBooks won't accept a .qbo without one, but accepts plain .ofx in some workflows.
  • .qfx — Quicken. Similar to .qbo but with an INTU.USERIDtag tied to a paid Quicken-Direct-Connect-enabled bank. For most use cases a .ofx file renamed to .qfx works fine.

The validator treats all three identically — the file shape is the same. If you need a .qbo specifically, use our CSV to QBO converter to generate one.

Common reasons OFX imports break

  • Duplicate FITIDs. The bank generated the same ID for two transactions. The accounting tool dedupes silently and you lose one. Re-export from the bank or regenerate the IDs.
  • Stale dates. Transactions dated outside <DTSTART> /<DTEND>. Some importers reject the file outright, others import the outliers but warn. The validator flags both.
  • Missing <CURDEF>. The importer defaults to USD — if your statement is in EUR or GBP, every figure is now off.
  • Encoding mismatch. The header declares USASCII but the body has UTF-8 characters (often in payee names with accents). QuickBooks shows garbled descriptions; the math still imports.
  • OFX 2.0 file with a 1.x extension. Some banks export .qbofiles that are actually XML. Most importers handle this but a few (older QuickBooks Desktop builds, KMyMoney) refuse.

If you don't have an OFX file yet

Drop a PDF bank statement into the same widget — we'll run it through our main converter (using one of your 7 free pages a day), synthesize a QBO file from the result, and validate that. You get to see exactly what a clean export of your statement would look like, without leaving the page.

Once it validates, download a real .qbo file from our CSV-to-QBO converter or use the main converter to export QBO, OFX or QFX directly.

FAQ

Is my OFX file uploaded anywhere?
No. The validator parses the file in your browser — nothing is uploaded. The exception is if you drop a PDF, in which case the PDF goes through our main converter (which does run server-side) so we can synthesize a clean OFX from it. The validation step itself stays local.
What's the difference between OFX 1.x and OFX 2.x?
OFX 1.x is an SGML-style format with header lines like 'OFXHEADER:100' and tags that aren't always closed (e.g. <TRNAMT>50.00 without a closing tag). OFX 2.x is well-formed XML with a '<?xml ?>' declaration and properly closed tags. The validator detects both automatically and parses each correctly.
Why does the validator say 'duplicate FITID' when my file looks fine?
Banks occasionally generate the same FITID for two different transactions — typically when the same merchant is debited twice on the same day for the same amount. Accounting tools use FITID as the dedupe key, so the second transaction is silently dropped on import. The validator flags it so you can either edit the file or accept the loss.
Can I validate a credit-card export (.qbo)?
Yes — the validator detects <CREDITCARDMSGSRSV1> sections as well as bank statement sections. The import preview, FITID checks and balance display all work the same way.
What does 'transaction outside statement period' mean?
The <DTSTART> and <DTEND> tags declare the date range the statement covers. If a transaction's <DTPOSTED> falls outside that range, the file is internally inconsistent. Some accounting tools reject the whole file; others import the outliers but warn. Re-export from your bank with a wider date range, or trim the offending rows.
Will the validator catch a forged or tampered OFX file?
No — OFX has no signature or hash. The validator only checks structural consistency (well-formed tags, valid dates, unique IDs). If you need authenticity verification, the only reliable path is to export the file directly from your bank's portal yourself.
Why don't accounting tools just validate the file themselves?
They do — but most use 'tolerant' parsers that accept malformed files and quietly skip whatever they can't read. You only notice the problem when your reconciled balance is off by a few hundred. A strict validator like this surfaces the issues up front.

Related tools and guides