Quicken for Mac 2018 v5.4.x Released

Quicken Marcus · December 2017

Daniel A Baker said:
I am currently running version 3.5.2 and have yet to be able to update or import my 2017 file both for Mac.

Oh that's not good. I'll reach out to you via email.

smayer97 · December 2017

jacobs said:
I'm happy to see the ongoing incremental improvements in reports, but I continue to be frustrated with the report architecture that displays/prints subtotals on TOP of the data it totals. This is unlike any financial software I've ever used, and the reports are therefore unlike any financial reports I've ever read. Marcus, I hope moving subtotals below data (or at least an option to do so) is on your development roadmap.

I just had to add that if you have read any of my detailed posts on this issue (Request for Customizable Reporting Engine, Create Useful Category/Transaction Detail Report, and essential related report features), I am of the opinion that 3 things working correctly with full functionality serves a better purpose and is more satisfying than a dozen things only working half right and not being able to make them do what you want, leaving one frustrated at every turn.

(If you find this reply helpful, please be sure to click "Like", so others will know, thanks.)

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.

I would often use the Commission field to add or subtract one or two cents to make my transactions work due to rounding.

I do likewise. And QM2007 even will adjust the commission field if you adjust other fields, to keep things all balanced.

At the very least, preserving the balance in user's data is paramount. And clearly that must be true for migrating from other versions of Quicken.

And as for dealing with these fields, I do not know if there is a better way but QM2007 works by allowing users to change any of the fields, and automatically uses one of the other fields to keep them all in balance...does sometimes get a little frustrating fighting the program when making adjustments because you do not always have control over which field it will automatically adjust...but I get what it is doing.

smayer97 · December 2017

D H Grif said:
I am using 2018 for MAC. The budgeting does not work. Even editing will not list all the income or expenses. It is totally worthless. I have used Quicken for over twenty years. This is by far the most frustrating issue I have ever come across.

No, No...not too much info. It actually helps to understand the context in which you have to develop things to better appreciate the timing of delivery, rather than wondering in wait with no insight... :-)

Quicken Marcus · December 2017

smayer97 (QM2007, CDN user since '92) said:
Interesting times with the release of the Canadian version...Thx.

I posted the following questions here (before these notes), but you have more or less answered the first 2 from that list in your notes. I am posted the rest of them here:
2. So essentially the CA version is just the US version with US specific features turned off, based on the Home Currency? Or is there more to it?
3. Does the CA "version" of QM2018 include the ability to download from US FI/Banks?
4. The US version of QM2018 includes ability to download from CDN FI/Banks. Will this continue to be true?
5. The footnotes indicate that Quicken Mobile only works in Canada. Is this a unique version for Canada? Does it not link to US accts?
6. I also see that Quicken Mobile is listed to only work with QM2017 and later but the US site lists it as working will all versions of QMac...is there a different versions of QMobile to work with QM2015 and QM2016?
7. Is Premium support not available for QM2018 CA like it is for the US? After all, they are effectively the same product (the CA version having reduced functionality)?

I'll try to answer everyone's Canadian questions.
1) There is only 1 Mac product for both US and Canada. This is both a good thing and a bad thing. The good thing is that it means everything in the US version is actually in the Canadian Version too. The bad thing, of course, is that it means that we have to come up with a way for users to be able to hide and turn things on based on their preferences and making the product feel like it's geared to one's country without cluttering up the user experience. We are most likely going to add a preference where someone can turn all features on if they work, live or invest in both countries. This is NOT in the product yet but will be. So to answer your question, if you are a Canadian member today we will turn off Bill pay and Bill Presentment and there won't be a way to turn them back but we will have an option in the near future.
2) Yes, both US and Canadian bank accounts can be downloaded if the customer has the US or Canadian membership. We don't do anything in regards to the accounts. You've always been able to download both in the Mac product and that doesn't change.
3) Yes, to get Premium Service for the Mac product, a Canadian customer could just purchase the Canadian Home and Business membership even though it doesn't say anything about Mac. Mac will work.
4) Multi-Currency - One's opinion about multi-currency capabilities depends on what you need. My guess most won't be satisfied with where it's at today. We now download currency conversion and will calculate the sidebar in a single currency. If you try to create a linked transfer to an account of a different currency you'll get a dialog like you get in Quicken Windows and we'll let you create a transaction in the other account that converts the value into the other currency. The downside is that it's not a linked transfer but 2 separate transactions. This is because the Mac fundamentally doesn't support linked transfers with 2 different values. Throughout the product we separate reports, budgets, and combined registers into separate currencies but don't let you merge them into a single currency.
5) Quicken Windows import - We definitely have a bad bug where linked transfers to accounts if different currencies mess up the balances. This will be fixed in the 5.4.4 release. Again, the Mac fundamentally doesn't support linked transfers of different currencies so on import we're going to break the link and keep the transactions as 2 separate transactions and the category will be changed to Transfer. This means the balances will be correct.
6) Security prices in US Dollars - I'm going to have to investigate that a little more to better understand what's going on. We get our security prices from a service called Markit On Demand which is the same service as Quicken Windows. If you pick from TSE or VSE I would have thought the prices would be in Canadian currency but it sounds like they are in US. MH, thanks for reporting this issue and I'll look into it more.

Snoopy FC · December 2017

Just downloaded 5.4.4. No issues so far. Just waiting for more updates on issues I've raised previously.

Snoopy FC · December 2017

jacobs said:
I'm happy to see the ongoing incremental improvements in reports, but I continue to be frustrated with the report architecture that displays/prints subtotals on TOP of the data it totals. This is unlike any financial software I've ever used, and the reports are therefore unlike any financial reports I've ever read. Marcus, I hope moving subtotals below data (or at least an option to do so) is on your development roadmap.

Amen! Amen! Amen!

smayer97 · December 2017

smayer97 (QM2007, CDN user since '92) said:
Interesting times with the release of the Canadian version...Thx.

I posted the following questions here (before these notes), but you have more or less answered the first 2 from that list in your notes. I am posted the rest of them here:
2. So essentially the CA version is just the US version with US specific features turned off, based on the Home Currency? Or is there more to it?
3. Does the CA "version" of QM2018 include the ability to download from US FI/Banks?
4. The US version of QM2018 includes ability to download from CDN FI/Banks. Will this continue to be true?
5. The footnotes indicate that Quicken Mobile only works in Canada. Is this a unique version for Canada? Does it not link to US accts?
6. I also see that Quicken Mobile is listed to only work with QM2017 and later but the US site lists it as working will all versions of QMac...is there a different versions of QMobile to work with QM2015 and QM2016?
7. Is Premium support not available for QM2018 CA like it is for the US? After all, they are effectively the same product (the CA version having reduced functionality)?

Thanks so much for the clarifications. And it is very good news that 2) is being preserved for both countries in one product.

Sounds like the direction you are leaning regarding US vs CA features is to turn on all for US or only a subset for CA based on initial default, then allow user to turn on ALL if they so choose. I suggest another option would be to default features based on original country but then allow turning on other features one at a time on a needs basis. Consider that some user's needs change...start in one country then move to another for a period (or indefinitely) and so their needs may vary over time...Not sure if this option is better or not...just food for thought.

There are not that many features that are unique to Canada: account types (many mostly just in name), tax categories, but the biggest difference is around taxes themselves...category links to tax lines, the way gains and loss are tracked and/or calculated, and mortgage calculations.

jacobs · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.The key thing is that the way Quicken 2007 works doesn’t create problems with my investment data, where Quicken 2015-2018 does. A transaction confirmation or monthly statement from my financial institution tells me the number of shares, share price, and total dollar amount of every transaction. The modern Quicken accounts for rounding by changing the share price based on the total cost and number of shares. So the share price is *wrong*. It’s only off a tiny bit, but it’s wrong. I didn’t have this problem in Quicken 2007, because I could use the commission field when needed to account for the penny or two of rounding, instead of Quicken making up a bogus share price.

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Ultimately, one of the fields HAS to be made wrong to account for rounding issues but price is a real thing determined by the markets and should not be the one...I agree that using the commission field has worked well in being the least of evils while at the same time preserving the accuracy of the shares and account balance.

Unknown · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.So how can we get Quicken to change something so that the QM2007 transaction total is respected? I have no idea how to bring this to their attention, and I won't start using QM2018 until this is fixed.

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Well, at the moment, there is this thread that seems to still be monitored by Quicken Marcus. Then there are the avenues I mentioned above at this post.

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Ok...I can see your point...but does QM2018 preserve buy and sell price to accurately calculate gains/losses or are these also rounded?

Of course, the greater issue is how do users migrate their data over from QM2007 with the current set-up as it is triggering changes in the account balance and therefore creating discrepancies?

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.To add to that, how would reinvested dividends reported by brokerages be handled (or other similar situations), because this affects cost basis, based on the brokerage's reported price? Unless QM2018 has a way to handle this while preserving the reported price?

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Am I missing something? Is TOTAL COST an entered value in QM2018? If so, then I see the disconnect...because in QM2007 TOTAL COST is a CALCULATED field based on PRICE, therefore, preserving PRICE becomes hugely important to get the correct TOTAL COST/PROCEEDS, which affects all the other values...cost basis, realized gain, etc. If it is calculated, which is what I believe, this means the problem is in how QM2018 calculates it...

The problem with import is summarized in Scott Schmidt's post:

What is happening on the import is bizarre:
The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

So, does QM2018 have a commission field or are there only the 3 fields, price # shares, total cost?

Unknown · December 2017

rangersix said:
I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

Hi Marcus,
I'm not sure what you mean by the sort order. I can sort by date and yes the column does appear in the header. The one user who stated "if it ain't broke don't fix it". It's broke! I enter all my transactions in my checking account and I put in future reminders for bills coming up for the next month. The balance is important because I need to know how much money I"ll need to pay bills in the future. I was using a calculator which is ridiculous. I have 6 other checking accounts and all the balances show. I've been using Quicken since 1994. I recently changed to Mac this year. There are other problems that I'm not going to mention. The copy and paste problem is a pain because I have to duplicate the transaction then I have to drag it into another account which is more clicks and movements compared to copy and boom paste. One movement instead of 5.
Also, when I reconcile my checking account it doesn't ask for interest for the month and it doesn't have a box for bank fees so there's a balance adjustment and the end of the reconciliation instead of interest for the month. There are other issues. The program is not near as refined as the windows program. I updated from windows 2013 and that program doesn't have a cl itch in it. I use to be able to search reports in a second by going into "memorized transactions". Now creating a report is laborious to say the least. I'm sticking with this program because Mac computers blow away PCs. Bill Gates just never figured it out regarding viruses and windows slowing down because of malware etc. Then you put a virus program in your computer and it turns into a snail but I appreciate the response. I opened a new checking account and the balance works in that one as it should so I'm good. If by chance you find out why this happened it would be great but it's broken and needs to be fixed. It's only with one checking account. All my other accounts work so maybe it was the conversion process when I switched over to mac from a PC. Cheers!

jacobs · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Yes, there is a commission field. But using it isn’t as useful as it was in QM2007. In 2007, entering a penny or two as commission got the total cost field to the correct value, but there was still some hidden fractional rounding taking place. In QM2015-2018, you can add or subtract a penny of commission, but the share price is still going to be calculated to 6 decimal places, even though the FI only may show 3.

RickO: you’re right about intraday stock prices, but rhat’s not the case with mutual funds. If Vanguard says I bought or sold a fund at $30.25, that should be what I record in Quicken, not the calculated $30.249326 that Quicken might show.

Further, while I agree with you about cost, not price, being used for calculating gain/loss when selling a specific lot of a stock, I wonder how Quicken calculates average cost per share when selling shares otherwise; are you sure the purchase/sale share price is never used in any calculation anywhere?

Zoolook · December 2017

When are you going to fix the multi-currency migration issue we spoke about at launch, and when is Quicken Mac going to have useful reporting? It’s a very expensive product to only have basic list reports - almost every other Mac based financial management application has far superior reporting.

brucel · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Cost basis, including commission, and total number of shares are all that matter for tax filing regardless of the equity type (stock, mutual fund, etc). Capital gain/loss = total sale price - total cost. So I enter the exact total cost and the exact total number of shares for a trade and let Quicken solve for the per-share share price. The slightly arithmetically adjusted per-share price is benign to the accuracy required for gain/loss analysis and tax filing because you use total cost and total shares per lot to report cost basis. I have been tracking trades like this in Quicken for Mac since 1991 without any tax filing issues or performance analysis issues.

Concordman · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.That is exactly the way I see it, I enter the total cost of the transaction , then number of shares, & the commission. QM then calculates the price of the purchase which matches what my Fi shows for the share price.

Unknown · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Total amount of the investment transaction and the total shares are the only amounts that really matter...and it's been that way in Quicken for almost forever.

Even in Quicken Windows (and Quicken Mac), you should always let Quicken calculate the price per share...always enter the total cost and number of shares.

Rarely does Quicken's price, expanded to eight or nine places, coincide with my investment company's statement. And that's not Quicken's fault. Even my investment companies round their price per share (or price per unit) so that it rarely agrees 100% with Quicken's calculation.

Personally, I don't really care. The following day when prices get entered, the total is usually within a few cents of what's really there (most days it's spot on).

And since most of us use our investment companies 1099's for tax reporting anyways, what difference does it make?

smayer97 · December 2017

rangersix said:
I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

@Paul Treppedi re:

...when I reconcile my checking account it doesn't ask for interest for the month and it doesn't have a box for bank fees...

You can add your VOTE to Add ability to add service charge or interest during start-up.

First, click on the underlined link above to go there, then click VOTE at the top of THAT page, so your will vote count for THIS feature and increase its visibility to the developers by seeking to have the features you need or desire end up in the latest version.

While you are at it, you may want to add your VOTE to related IDEAS found on the

Click on each underlined link, then follow the instructions to add your vote to more related ideas. Your VOTES matter!

(If you find this reply helpful, please be sure to click "Like", so others will know, thanks.)

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.The issue is not so much about how QM2018 does it but rather what the OP has raised...how to migrate reconciled and balanced amounts from QM2007 into QM2018. As it stands, discrepancies result due to the differences, at least for this user.

smayer97 · December 2017

Scott Schmidt said:
Can this be FIXED soon?

When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.

You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value.

And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.

What is happening on the import is bizarre:

The import completely ignores the total transaction cost that was entered in Q2007.
It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.

In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.@RickO

...and I barely remember what I had for breakfast...

lol...so true sometimes...

John Morrow · December 2017

I can't figure out how split works. I've read the manual, I think I understand the theory, but in practice it seems to work in creative ways whose logic I cannot understand.

EXAMPLE 1
1. Create a new transaction
2. Enter a category, for example Gift (this is the season) and an amount, for example -100,60
3. Click Split
4. Go to the second split line (it is empty)(the first line is the Gift of -100,60)
5. Enter a category, for ex. Transfer, then an amount, for ex. -39
6. The total is changed to -139,60, WHICH IS NOT want I want or assumed. My expectation is the total would keep constant and the first Split line would become -61,60

7. If I delete the first Split line, or the Second, or both, things get weirder. Sometimes QM asks me if I want to adjust the total, sometimes not. I cannot understand the logic between the two different behavior.

So I tried this instead:

EXAMPLE 2
1. Create new transaction
2. Don't enter a category or amount, but to directly to the Split screen
3. Enter Transfer and -39 on the first Split line
4. Go to the second Split line. But I know only the total of -100,60, NOT the difference (-61,60) ! (and I don't want to compute it)

The behavior that I am expecting is as follows:
1. Create a new transaction, enter the total (which I know from the receipt), for example -100,60
2. Go to the first Split line, enter an amount, for ex. -39 (which I read from the receipt also)
3. Go to the second Split line, enter a second amount, for example -10 (which I read from the receipt also)
4. Automatically, the third Split line is changed to -51,60 (= -100,60 - 39 - 10) (which I don't know for the receipt because it is a sum of many small items, which I don't want to compute manually. Using the diff is much faster)

Unknown · December 2017

rangersix said:
I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

Oh! I fixed it:)

My account was sorted by date but the balance still wasn't showing so I removed it from the columns by clicking it in the "show registry columns". Then I clicked sort again in the date column and re-entered it in the "show registry columns" WHALA! It's working. Thanks guys. I truly appreciate your help.
On another note: It would be great if you could put the "memorized transactions" back in there. For me, it was the easiest way to search reports. I know there are other ways to search but it was really easy when I was able to go into memorize transactions and scroll in alphabetical order to a company and click REPORT! If not, I'll get use to this version.

Happy Holidays!

John Morrow · December 2017

Reconcile no longer works for Credit Card accounts.

STEPS TO REPRODUCE:
1. Download transactions
2. Reconcile
3. Transactions just downloaded and cleared DO NOT appear in the reconcile window.

This happens for 2 different Credit Card account. This used to work as of a few days ago. There is no such issue for Checking accounts. I am using QM 2018 5.4.4

CREDIT CARD ACCOUNT:

RECONCILE WINDOW:

4 transactions are missing and cannot be reconciled.

Unknown · December 2017

John Morrow said:
Reconcile no longer works for Credit Card accounts.

STEPS TO REPRODUCE:
1. Download transactions
2. Reconcile
3. Transactions just downloaded and cleared DO NOT appear in the reconcile window.

This happens for 2 different Credit Card account. This used to work as of a few days ago. There is no such issue for Checking accounts. I am using QM 2018 5.4.4

CREDIT CARD ACCOUNT:

RECONCILE WINDOW:

4 transactions are missing and cannot be reconciled.

Reconcile for credit cards works just fine. I have zero problems with any of my credit cards reconciling in Quicken Mac.

Try finding the missing transactions. Or...the date of your statement ending date is incorrect. What happens if you change it to 12/13/2017?

Quicken Harold · December 2017

John Morrow said:
Reconcile no longer works for Credit Card accounts.

STEPS TO REPRODUCE:
1. Download transactions
2. Reconcile
3. Transactions just downloaded and cleared DO NOT appear in the reconcile window.

This happens for 2 different Credit Card account. This used to work as of a few days ago. There is no such issue for Checking accounts. I am using QM 2018 5.4.4

CREDIT CARD ACCOUNT:

RECONCILE WINDOW:

4 transactions are missing and cannot be reconciled.

Splitting from a different topic.

Please reference the new conversation here: Credit Card Reconcile Issues

Quicken Harold · December 2017

John Morrow said:
I can't figure out how split works. I've read the manual, I think I understand the theory, but in practice it seems to work in creative ways whose logic I cannot understand.

EXAMPLE 1
1. Create a new transaction
2. Enter a category, for example Gift (this is the season) and an amount, for example -100,60
3. Click Split
4. Go to the second split line (it is empty)(the first line is the Gift of -100,60)
5. Enter a category, for ex. Transfer, then an amount, for ex. -39
6. The total is changed to -139,60, WHICH IS NOT want I want or assumed. My expectation is the total would keep constant and the first Split line would become -61,60

7. If I delete the first Split line, or the Second, or both, things get weirder. Sometimes QM asks me if I want to adjust the total, sometimes not. I cannot understand the logic between the two different behavior.

So I tried this instead:

EXAMPLE 2
1. Create new transaction
2. Don't enter a category or amount, but to directly to the Split screen
3. Enter Transfer and -39 on the first Split line
4. Go to the second Split line. But I know only the total of -100,60, NOT the difference (-61,60) ! (and I don't want to compute it)

The behavior that I am expecting is as follows:
1. Create a new transaction, enter the total (which I know from the receipt), for example -100,60
2. Go to the first Split line, enter an amount, for ex. -39 (which I read from the receipt also)
3. Go to the second Split line, enter a second amount, for example -10 (which I read from the receipt also)
4. Automatically, the third Split line is changed to -51,60 (= -100,60 - 39 - 10) (which I don't know for the receipt because it is a sum of many small items, which I don't want to compute manually. Using the diff is much faster)

Splitting Transactions

Please reference the new conversation here: Split Transactions

Quicken for Mac 2018 v5.4.x Released

Comments

Categories