OL-222 Error

Utilize the trial version of this app to isolate the issue. If the same error persists, your bank is the problem.

https://www.moneythumb.com/?ref=110

If facing issues while bank synchronization, Follow this to fix QuickBooks Error Code OL 222.

Thank you every one for bearing with me thru this.

I followed the instructions in this link to update my fidir file.

https://quickbooks.intuit.com/learn-support/en-us/bank-feeds/update-the-financial-institutions-directory-in-quickbooks/00/186398

I still get the OL-222. I appreciate the help. 

@mistymossy  I have what I think is a somewhat definitive answer, based on some troubleshooting I did for a customer.

We offer several tools that create OFX/QBO/QFX files, including the  BRC Excel to OFX/QFX/QBO Converter , BRC QIF to OFX/QFX/QBO Converter and the BRC OFX Cleaner .

A customer of ours using the Excel to OFX Converter upgraded to the latest release and then got an OL-222 error. They assumed it was something to do with the upgrade. Instead, though, it had to do with the contents of the file, which QuickBooks was choking on - incorrectly.

It appears that when QuickBooks can't parse the OFX file according to the OFX standard, it will issue an OL-222 error. In hind-site, this may be the only trigger for this particular error, given the history of cases I can remember over time.

In my customer's case, the OFX file is valid, but QuickBooks is parsing the file and then applying various rules in the wrong order. 

I checked its validity using the OFX File Analyzer, published by Microsoft, which is very picky and very closely follows the OFX standard. The OFX standard was created by Microsoft, Intuit, and CheckFree. And then Intuit immediately bastardized it and created the QFX and QBO sub-file formats so they could charge banks to connect to Quicken and QuickBooks. Nice, huh?

My customer's file passed the OFX File Analyzer with flying colors, so I decided to find out what QuickBooks thought was wrong with the file.

After some testing I realized that QuickBooks is testing the length of various fields against the OFX standard maximum lengths before it is decoding the text to revert it to the original length. It is important to decode the text first, because the escape encoding replaces one character with up to 6 characters, making the text much longer.

Many characters must be encoded in this way in OFX files including ampersands (&) and many high-ascii character like those used in various European languages. ASCII characters with numeric values smaller than 32 and larger than 127 have to be encoded.

For example, consider this made-up name, which is 35 characters long:

Renéaldo Lacért Schönenfeld Limited

The <NAME> field in the OFX standard has a (rather ridiculous) field length limit of 32 characters. So, the name must be truncated:

Renéaldo Lacért Schönenfeld Limi

Then the special characters é and ö have to be encoded, where 233 and 246 are the ASCII numbers for the characters. Added to the OFX file, the name will (correctly) look like this:

Ren&#233;aldo Lac&#233;rt Sch&#246;nenfeld Limi

When processing the file, QuickBooks should decode the <NAME> before testing the length, but it does not. Instead, it tests the length first and then issues an OL-222 error. At the same time, most other OFX enabled apps work just fine, including the parser mentioned above, because they actually follow the rules.

There was a suggestion on this thread by Intuit that encoding like this is not supported, but that is incorrect.  QuickBooks handles it just fine in cases where the name added to the file with encoding is shorter than the max length. For example, this will work just fine, because it is only 25 characters long:

Ren&#233;aldo Lac&#233;rt

After importing, the name will look like it should:

Renéaldo Lacért

Escape character sequences include:

&amp;  for "&"

&lt;  for "<"  

&gt;  for ">"

and &#ASCIIID;  for ASCII characters 1 through 31 AND 128 and on up.

You can see the characters and number values here: https://ascii.cl/htmlcodes.htm

So, if the file you're working with contains any of these escape character sequences, and the resulting encoded field length is longer than what is allowed, and QuickBooks is choking, then the banks are right: This is Intuit's fault for writing buggy code.

The only solution, until Intuit fixes QuickBooks (don't hold your breath), is to edit the OFX/QBO file using a text editor and shorten the fields so they pass the length test with the encoding, or remove the encoded characters completely, which will make the remaining text short enough.

Both the <MEMO> and <NAME> field max lengths are 32 characters.