nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Importing .qif and share fractions

Steve Horrocks

Quicken Windows Classic, Windows 11, R64.25, Build 27.1.64.25

A financial institution I use does not support direct exports into Quicken. The institution exports a .qif file which may be imported into Quicken.

They performed some transactions which resulted in a sale of 0.00009 shares of a holding for $0.38.

GS Dec IRA AZO transactions.png

The resulting downloaded .qif file reported the transaction as 9E-05 (scientific notation for the 0.00009 share transaction). Q=# shares transacted. T=Value of shares transacted.

GS Dec IRA QIF file download.png

When the .qif was imported into Quicken, Quicken interpreted the transaction as an over 900 share sale and that investment account is now reported in Quicken as several million dollars in the red.

Quicken Dec IRA Imported AZO transactions.png

I can fix the transaction by correction the number of shares transacted to the correct value, 0.00009.

Is this normal for Quicken to mis-interpret small transactions such as this? This is a seven decimal place error!

I am going to ask the financial institution a similar questions.

Steve

Quicken user since DOS 3.

Find more posts tagged with

Comments

splasher

The issue is with the financial institution. Quicken is expecting a number in normal numeric format of digits and a decimal point, such as 12.34 or .00009 in your case.

The FI is supplying the number in scientific notation which has letters in it. 9E-05 which translates to a 9 with the decimal point being moved to the left (because of the minus sign) 5 places making the number .00009 .

You need to complain to the FI to have it done right or edit the .QIF file whenever there are numbers small enough that they revert to using scientific notation.

Steve Horrocks

I complained to the FI. They were only wanting to tell me to use a CSV.
A CSV has to be manipulated by rearranging the columns. What a pain!

In this case the easier thing to do is to edit the transaction to the correct number of shares.

I tried editing and it seemed to correct the issue.
Apparently, the FIs don't really care if the files don't work. This specifc FI used to support .QFX downloads.

I just need to fix the transaction and move on!

Thanks,
Steve
Quicken user since DOS 3.

Chris_QPW

The first thing to understand about the QIF syntax is that it was never standardized.

This has lead to incompatibles like this where different entities like financial institutions and countries just make up “extensions” to what Intuit originally published. And that includes Intuit themselves (they added their own extensions without publishing them). The QIF format was never created for the purposes it is now being used. It was created as a tool for Intuit support personal.

This one of the reasons Intuit actively tried to discourage it use starting in its use in favor of QFX/OFX which is a standard.

And Quicken Inc took the steps to remove almost all processing of QIF imports and put them directly into the register.

Steve Horrocks

How nice! Thanks for the info.
I presume this .qif syntax problem is why one FIs accounts are spot on with holdings and share balances..because they use Direct Connect.
While another FIs accounts in my Quicken are a ROUGH estimate..because they only export a .qif or .csv.

Guess it is just tooooooo hard to use a standard and they complain that not many people use Quicken anymore.

Steve
Quicken user since DOS 3.

Chris_QPW

QIF format has its limitations like no syntax for security lots, but accurate number of shares isn’t one of them. It also has its strengths. For instance it can encode a category in the transaction, whereas none of the other formats allow this.

This is really all on the financial institutions. None of the connection methods disallow accurate share amounts.

Another piece of history is the US(and Canada) governments not requiring any standards for this, this resulted in a mishmash of different attempts at try to do this with different connection methods.

The OFX standard was created years ago, but only about 400 financial institutions adopted it at its height and much less now. QFX is a slight variation of OFX which Quicken calls Direct Connect. This lead Intuit to create Express Web Connect, which should be called Connection by agreement. Intuit makes an agreement with the financial institution how they my have their servers login to the financial institution’s website and download the data in some agreed format (which can be different for different financial institutions) and then convert it into what Quicken needs. Just the idea that a server logs in as you is a flawed idea.

This put “aggregators” in the middle. I say aggregators because Intuit isn’t the only one that had try the same thing.

Now we have the push for Express Web Connect +. This is better it is a standard called FDX (but one that isn’t generally available to the public), and is secure. It is created with a model that requires an aggregator. But as each of the conversions on here is showing it is difficult to switch to it and get it right. As such I predict the even less financial institutions will adopt it then the one that adopted QFX at its height.

Note that the EU mandated their financial institutions to adopt either OFX and/or another standard many years ago.