CSV, QBO, QFX, OFX and QIF: finding the file your app accepts

Your import screen decides which file to use

We're looking at bank-statement imports here, not whole-company migrations or investment-trade conversion. We checked vendor documentation on October 17, 2026, but didn't test imports. The QuickBooks sources are US help, and Quicken separates Windows file import from Web Connect. Xero sources include its Canadian site and Xero Central. For Sage, this means Sage 50 Canada 2023 Bank Services, not every Sage product.

If your bank offers the suggested file below, start there. Before converting, check your country, edition, account type and available menu, because the route matters too.

QuickBooks Online's page lists QBO, QFX and CSV in its file guidelines but adds OFX in the upload instructions. With that inconsistency, go by your upload screen rather than renaming an OFX file to get around it. The page also documents PDF and image uploads, which may save you from creating a transaction file at all.

Xero's Canadian page also advertises native PDF upload. Its more specific PDF import guide limits it to US and Canadian organizations, excludes the Xero Ledger plan and lists statement requirements. Check your account against those conditions first.

QBO also means QuickBooks Online, but a “QuickBooks CSV” is still CSV, not a .qbo file. QFX and QXF are different too: Quicken's Windows import guide describes QXF as a transfer format between Quicken products, not a bank QFX download.

Quicken for Windows has a separate CSV importer with seven columns in a fixed order, so our three-column sample won't fit. Its Create Sample File option gives you the layout to use. Be careful with overlapping history: this importer adds every row without checking or matching existing transactions.

The same three transactions in each format

Our fictional USD checking account starts October with $1,000.00. This isn't customer data or a bank export. In this account, positive amounts increase cash and negative amounts decrease it; every sample contains the three transactions below.

Net movement is 250.00 - 75.25 - 4.75 = 170.00. Closing cash is 1,000.00 + 170.00 = 1,170.00. The calculated running balances aren't in the sample files. Correct arithmetic doesn't verify categories, reconcile your ledger or authenticate a document.

The $1,000.00 opening balance isn't a fourth transaction, so importing these rows adds $170.00 net without setting the starting balance. Leave out the fee and closing cash becomes $1,174.75, or $4.75 too high. That calls for restoring the missing source row, not adding a balancing entry.

CSV tells the importer very little about its columns

Date,Description,Amount
2026-10-02,Client deposit,250.00
2026-10-05,Office supplies,-75.25
2026-10-06,Bank fee,-4.75

These year-month-day dates and signed amounts are choices for our example, not CSV rules. RFC 4180, published October 2005 covers comma-separated records, optional headers and quoting. It doesn't define bank columns, dates, currency, categories or debit signs.

That leaves the layout to the importer. Intuit requires Date, Description, Amount or Date, Description, Credit, Debit. YNAB instead maps Date, Payee, Memo, Outflow and Inflow, allowing one signed Amount column to supply both flows. A CSV prepared for one screen won't necessarily fit another.

With separate columns, the deposit is 250.00 in money in, while the purchase and fee are 75.25 and 4.75 in money out. Before mapping Debit and Credit, check how the destination interprets them rather than relying on the labels alone. See how to convert debit and credit columns into a signed amount.

If the template has no place for account, currency, transaction IDs or balances, keep them in a separate review copy. That preserves the detail without adding unsupported columns to the import file.

OFX has an older SGML-style syntax and an XML syntax

OFX means Open Financial Exchange. The standards publisher's OFX page distinguishes older SGML-based versions from XML-based OFX 2.x. Our excerpts show only the transaction list, so they aren't uploadable files. A complete bank response needs its header, sign-on and response wrappers, account, currency and ledger balance.

OFX 1.x uses 1.0.2-style leaf tags

<BANKTRANLIST>
  <DTSTART>20261001
  <DTEND>20261101
  <STMTTRN>
    <TRNTYPE>CREDIT
    <DTPOSTED>20261002
    <TRNAMT>250.00
    <FITID>DEMO-001
    <NAME>Client deposit
  </STMTTRN>
  <STMTTRN>
    <TRNTYPE>DEBIT
    <DTPOSTED>20261005
    <TRNAMT>-75.25
    <FITID>DEMO-002
    <NAME>Office supplies
  </STMTTRN>
  <STMTTRN>
    <TRNTYPE>FEE
    <DTPOSTED>20261006
    <TRNAMT>-4.75
    <FITID>DEMO-003
    <NAME>Bank fee
  </STMTTRN>
</BANKTRANLIST>

Individual values can end at the next tag, although aggregates such as STMTTRN still close. Full legacy files have colon-delimited headers, including OFXHEADER:100, DATA:OFXSGML and VERSION:102. Because this isn't XML syntax, a generic XML parser rejecting it doesn't prove the OFX file is broken.

OFX 2.x closes every element

<BANKTRANLIST>
  <DTSTART>20261001</DTSTART>
  <DTEND>20261101</DTEND>
  <STMTTRN>
    <TRNTYPE>CREDIT</TRNTYPE>
    <DTPOSTED>20261002</DTPOSTED>
    <TRNAMT>250.00</TRNAMT>
    <FITID>DEMO-001</FITID>
    <NAME>Client deposit</NAME>
  </STMTTRN>
  <STMTTRN>
    <TRNTYPE>DEBIT</TRNTYPE>
    <DTPOSTED>20261005</DTPOSTED>
    <TRNAMT>-75.25</TRNAMT>
    <FITID>DEMO-002</FITID>
    <NAME>Office supplies</NAME>
  </STMTTRN>
  <STMTTRN>
    <TRNTYPE>FEE</TRNTYPE>
    <DTPOSTED>20261006</DTPOSTED>
    <TRNAMT>-4.75</TRNAMT>
    <FITID>DEMO-003</FITID>
    <NAME>Bank fee</NAME>
  </STMTTRN>
</BANKTRANLIST>

The values are the same, but each leaf element now has a closing tag. A complete OFX 2.x file starts with an XML declaration and an OFX processing instruction using OFXHEADER="200" and the chosen OFX version, such as VERSION="220" for 2.2. The description in OFX Banking 2.3, sections 2.2 and 2.8 covers both header styles and the transition from 1.0.2.

DTPOSTED is the posting date: YYYYMMDD, optionally with time and timezone. OFX treats a date-only value as midnight GMT, so timezone conversion may change the displayed date. Keep supplied timestamps rather than inventing times to fix a preview. Our excerpts begin October 1, with November 1 as the exclusive download boundary. That's where the server stopped looking, not necessarily the last transaction date. See sections 3.2.7 and 3.2.8.

Dates and amounts aren't enough for OFX

A posted bank transaction needs a type, posted date, signed amount and FITID under OFX Banking 2.3, section 11.4.4.1. A description can't replace any of them.

It's TRNAMT's sign, not TRNTYPE, that determines the balance effect. Putting DEBIT beside positive 75.25 doesn't make it our 75.25 withdrawal. OFX uses the customer's perspective, so card payments are positive and purchases negative. A different card CSV convention doesn't apply here, as explained in credit-card signs and account perspective.

The surrounding bank response needs CURDEF for currency, BANKACCTFROM for the account and LEDGERBAL with an amount and as-of date. The bank account includes BANKID, ACCTID and ACCTTYPE; branch requirements vary by country. BANKID is a routing/transit number in the US and Canada, a sort code in Great Britain. Credit-card statements use a different account aggregate. See sections 11.3.1, 11.3.2 and 11.4.2.

Account identifiers need to stay as text to retain leading zeros. Web Connect branding IDs, routing numbers and account numbers aren't interchangeable, so keep your source identifiers rather than copying a real bank's identity from an example.

QBO and QFX also have to pass vendor rules

QBO and QFX belong to the OFX family, not separate spreadsheet layouts. Intuit's OFX connectivity overview identifies Web Connect as an OFX connection type. Its connection-type documentation names QBO for QuickBooks and QFX for Quicken, and ties Web Connect to a contracted Intuit branding ID. OFX section 2.7 separately defines how organisations can extend tags.

The extensions aren't interchangeable. Desktop Web Connect accepts only QBO. Quicken's Web Connect troubleshooting guidance requires a supported bank and online-services access, and warns about expired subscriptions and unsupported versions. Correct file structure can't bypass those rules. We didn't verify a complete vendor-extension schema and don't recommend hand-editing branding IDs to pass validation.

Quicken also says it doesn't support third-party-converted QFX files or help when they fail to open. That's a reason to prefer your bank's QFX when available: an exporter offering QFX doesn't mean Quicken endorses it or guarantees import.

In QIF, each line has a job

!Type:Bank
D10/02/2026
T250.00
PClient deposit
^
D10/05/2026
T-75.25
POffice supplies
^
D10/06/2026
T-4.75
PBank fee
^

This QIF uses US month/day/year dates, so D10/02/2026 means October 2. !Type:Bank starts the banking records. D is the date, T the total, P the payee and ^ the record end, with negative amounts for money out. See GnuCash's historical QIF format explanation. Its version 5 importer manual says you may need to select date order, default account and currency during import.

The date, amount, record terminator and account-type header need to stay; your importer sets the other requirements. This sample leaves out optional memo, check-number and category fields. Unlike basic OFX bank transactions, QIF has L for category or transfer account and S, E and $ for split category, memo and amount. Those splits must sum to the transaction total, though our three-record sample has none.

Quicken's QIF guidance conflicts. Its Windows support article, updated June 5, 2026, excludes checking, savings, credit-card and brokerage accounts. But Quicken's Windows QIF help page says current versions can import any account type. With those conflicting instructions, check the QIF account selector and support guidance for your installed version rather than relying on a blanket prohibition. QIF import is separate from QFX Web Connect.

FITIDs help with duplicates, but they aren't the whole check

OFX section 3.2.3 defines FITID as an ID assigned by the financial institution or its service provider, mainly to detect duplicate responses. It must be unique within the account and institution regardless of service provider, but needn't be sequential. The limit is 255 characters; 32 or fewer is recommended. Even so, keep the supplied ID rather than shortening it.

Our DEMO-001, DEMO-002 and DEMO-003 IDs are fictional. In overlapping downloads, the same deposit should keep its ID because a new one defeats ID-based matching. Reusing the deposit's ID for the fee risks merging different rows instead. A converter's ID isn't necessarily the bank feed's ID, and date plus amount isn't always unique either.

Bank corrections use CORRECTFITID and CORRECTACTION to reference and replace or delete an earlier transaction, which is why those fields need to stay. If a correction goes wrong, ask the bank or importer rather than inventing a FITID to force it through. See section 11.4.4.1.

CSV and this QIF sample lack an OFX FITID, but importers can still detect repeats: YNAB's current guide says it skips imported transactions with the same date and amount. Since importers differ, compare overlapping files with the account's existing rows before importing. See importing historical statements without duplicates.

Skipped rows need a look too, because two real payments can share a date and amount. Meanwhile, Quicken's Windows CSV importer does no duplicate matching. A success message doesn't prove you got every intended row and nothing else.

The import file can leave categories, balances and evidence behind

These samples have no bookkeeping categories and only one amount per transaction: OFX's FEE type isn't a chart-of-accounts assignment. QIF can carry categories and splits, while a bank CSV may lack categories. The importer has to support them too. YNAB explicitly says file import can't add categories or splits, and categories an app assigns afterward don't prove they came from the file.

None of these excerpts carries the table's running balances, either. Basic OFX STMTTRN fields don't include them, and statement-level LEDGERBAL is different. A CSV can have a Balance column without the template being able to import it.

The samples contain no PDF pages, receipts or source-line links, so keep the original statement and a detailed review copy separate from the import file. Correct totals don't prove authenticity or correct classification. You still need to check the transaction data and reconcile with the books after import, rather than inventing a balance-adjustment row to make the file look complete.

Readable text and a valid file are different things

Our samples use ASCII to separate format from encoding, but real payees may need other characters. If text is misread, use your importer's accepted encoding rather than deleting accents to hide the problem.

For CSV, RFC 4180 describes CRLF line endings and allows a charset parameter, while acknowledging that implementations differ. Fields containing commas or line breaks, such as Supplies, paper, need quotes, and quotation marks inside quoted fields need doubling. Your destination decides the required encoding and delimiter.

Legacy OFX headers declare encoding/charset, while XML OFX uses its XML declaration. Either way, the declaration must match the bytes. OFX 2.x follows XML whitespace rules rather than requiring one tag per line, and literal ampersands in XML text must be escaped as &. See OFX sections 2.2, 2.3 and 2.8.

QIF fields end at the line ending, so flattening the file into one line destroys its structure. Quicken's QIF help describes ASCII text. We didn't test non-ASCII encoding or CRLF-versus-LF acceptance, so check those with your importer.

A readable preview isn't enough: well-formed XML can lack required OFX fields, and complete OFX can still fail a vendor's import rules. Those are three separate checks.

Give the file a check before importing it

An unfamiliar import calls for a desktop backup or an appropriate test company. If available, use an accepted bank-native download and keep an untouched copy.

1. Check the product, version, country, account type and import route so you know the file is intended for this screen.
2. Confirm the account identifiers, currency and requested history window, then check how dates are read and inspect one incoming and one outgoing amount.
3. Compare row count and net movement with your review copy and statement. Check overlaps against ledger entries without regenerating bank transaction IDs.
4. Review the preview before importing. Afterward, match, categorize and reconcile; getting the file accepted doesn't finish the bookkeeping.

If all you have is a PDF

Your app's native statement upload is still the first option to check. For a few rows, filling its CSV template manually is another option. If you need extraction into another format, AnyStatement converts PDF statements and exports CSV, QBO, QFX, OFX and QIF, including QuickBooks three-/four-column and Xero CSV layouts. That doesn't guarantee every destination, bank identity or account type accepts them, and Quicken's third-party QFX support limit still applies.

What we checked, and what we didn't test

We opened the linked sources on October 17, 2026: Intuit's Online, Desktop and OFX partner guidance; Quicken's import and Web Connect help, including Windows CSV; Xero's Canadian bank-feed page and Central guides; YNAB's September 22 guide; GnuCash's version 5 manual and historical QIF explanation; Sage 50 Canada 2023 help; RFC 4180; and FDX's OFX Banking 2.3 specification, dated October 2020. In a browser, we expanded Xero Central's PDF requirements and import sections. That specific guide documents the limited US/Canada PDF route cited here, even though its general manual-import and OFX pages still say PDFs can't be imported.

We built the fictional samples and parsed CSV and the XML transaction list in Python. We then compared dates, descriptions and signed amounts across CSV, SGML-style OFX, XML OFX and QIF, and checked three distinct FITIDs. Python Decimal confirmed $170.00 net movement, balances of $1,250.00, $1,174.75 and $1,170.00, and the $4.75 missing-fee error. We also checked OFX fields and QIF tags against the cited documentation, and the export list against repository implementations rather than live imports.

We didn't run live imports, full OFX schema validation or an SGML parser, and the OFX excerpts aren't downloadable bank responses. We also didn't test non-ASCII encodings, timezone display, Quicken's conflicting QIF restrictions or vendor authorization. These checks cover sample consistency and arithmetic, not certified compatibility, bookkeeping reconciliation or document authenticity.