OFX SGML vs XML: Why Bank Files Look Different

The OFX SGML vs XML difference comes from the format's two generations. Version 1 files use SGML, with a plain text header and tags that often never close. Version 2 files use XML, with a declaration at the top and every tag closed. Most finance software reads both, so it matters mainly when a strict reader meets the wrong kind.

Telling an SGML OFX file from an XML OFX file by its header

You can tell the two apart from the first few lines. An SGML OFX file starts with plain NAME:VALUE lines such as OFXHEADER:100 and DATA:OFXSGML. An XML OFX file starts with <?xml and an <?OFX ... ?> line carrying OFXHEADER="200". Open the file in any text editor to check.

Here are the opening lines of each, with made-up values:

An SGML (version 1) file:

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252

<OFX>
<SIGNONMSGSRSV1><SONRS>
<STATUS><CODE>0<SEVERITY>INFO</STATUS>
<DTSERVER>20261015

An XML (version 2) file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?OFX OFXHEADER="200" VERSION="220" SECURITY="NONE" OLDFILEUID="NONE" NEWFILEUID="NONE"?>
<OFX>
<SIGNONMSGSRSV1><SONRS>
<STATUS><CODE>0</CODE><SEVERITY>INFO</SEVERITY></STATUS>
<DTSERVER>20261015</DTSERVER>

The table sums up what differs:

The transaction tags themselves, such as STMTTRN, DTPOSTED, TRNAMT and FITID, are the same in both. Only the wrapping differs.

Why were OFX version 1 files written in SGML?

OFX version 1 files were written in SGML because OFX predates the wide use of XML. The FDX OFX Work Group page says OFX began with version 1.0 in SGML syntax, calls version 1.6 the last of the SGML specifications, and says the 2.x specifications are XML based.

SGML is the older, looser parent of XML. It lets a document leave out closing tags when the structure makes them obvious. In OFX 1.x files that means a value tag like <TRNAMT>-48.20 simply ends at the next tag.

XML is stricter. Every tag must close, and a reader can reject a file that breaks the rule. With version 2, standard XML tools can read and check an OFX file.

Many banks never moved. The same FDX page says both SGML and XML OFX are supported by most processors in the current market. Many QFX and QBO downloads from US banks still use the version 1 header.

Which software reads SGML OFX, XML OFX or both?

Most finance software reads both SGML and XML OFX, and the FDX OFX Work Group says as much for most processors. The exceptions are strict or home-made readers: a script built on a standard XML parser, or an older program that only knows the version 1 header.

A rough guide for common cases:

• Quicken and QuickBooks. These read the QFX and QBO files banks produce, which are often SGML. If a Quicken import fails, the header style is rarely the first suspect. Importing a QFX file into Quicken covers the usual causes.
• QuickBooks Desktop Web Connect. Intuit's article on fixing Web Connect import errors says the bank file must be a .qbo file, the only type Web Connect can read. An OFX file of either style still needs the QBO treatment.
• Spreadsheet tools and scripts. A generic XML parser reads version 2 files and fails on version 1, because of the missing closing tags.
• Converters. Good ones accept both styles. Test yours with a version 1 file if your bank sends those.

If you are choosing between file types for QuickBooks in the first place, CSV vs QBO for a QuickBooks import compares the options without the OFX detail.

When the OFX SGML vs XML difference breaks an import

The OFX SGML vs XML difference breaks an import in three cases: a strict XML reader gets a version 1 file, someone hand-edits a file and mixes the two styles, or a converter writes an XML body under an SGML header. In each case the reader stops at the first tag it cannot place.

Hand edits cause the most trouble. People open a QBO or OFX file to fix a date or remove a line, then save it with closing tags added to some values and not others, or with the blank line after the SGML header deleted. Some readers tolerate it. Others report that the file is damaged.

Signs you have a style problem rather than a data problem:

• The error mentions parsing, a tag or an unexpected end of file, not a bank or account.
• The file opens in a text editor and looks fine, but no program will read it.
• The header says DATA:OFXSGML while the body has </TRNAMT> closing tags everywhere, or the reverse.

The fix is to keep one style per file. Re-download the original from the bank if you can, and make edits that change only values, never tags. If a converter mixed the styles, try a different one.

Files that are not OFX at all can look similar at a glance. A QIF file starts with !Type: and has no tags, and converting QIF to QBO explains that route. A BAI2 file is comma-separated records with numbered codes, used by business banks, and the BAI2 file format guide covers it.

SimpleBankConvert, which is in early access, is being built to write CSV and QBO files from PDF bank statements, so you get a file built for the QuickBooks upload rather than one to repair by hand. See the SimpleBankConvert homepage for what it does now.