KMyMoney Export from Investment truncates shares to 2 decimal places

I have looked for threads relating to the problem, but have found none.

The account/security is set to use 3 decimal places and works as expected, showing 3 decimal places in my ledgers. When I export all the transactions to a CSV file to create a summary spreadsheet for the Probate Court, all the share values are truncated, not rounded, to 2 decimal places in the CSV file. This accumulates over time and causes the spreadsheet to not match the accumulation of shares shown on the statements. I have to go through and add the 3rd decimal place in my spreadsheet from my display of the ledger in KMyMoney.

In the security setup, the “fraction” is set to 1/1000 to create 3 decimal places. The Export to CSV function should go by this Fraction setting of the security and output the correct number of decimal places.

I could not find any settings for the export that might be causing it to truncate to 2 decimal places.

I’m running KMyMoney 5.1.3 on Windows 10.

Should this be reported as a bug, or am I missing something.

Thank you for any help.


It does seem like a bug. In addition, prices seem exported with too many places. I also tried testing master branch, but that has a completely different problem - I can’t tell what account it is exporting, but it is NOT the one selected in the dropdown. Will you report the bug?

I’m a Newbie with KMyMoney. I went to Exporting the transactions, because the transaction reports for an investment account are a mess. The report mixes Investment Shares with Total Money paid. The column has a mixture of shares and dollars and the dollars seem to be treated like shares in the balance column. So, I went to exporting to csv files and then format and create Excel spreadsheets to show the investment transactions like reinvest-dividends and LT Capital Gains received into the IRA investment. The export file calls LT Gains paid as dividends.

To enter a dividend payment and LT Gain payment in this IRA mutual fund, I had to deposit the dividend and the LT Gain separately into the brokerage account and then do a buy with the sum of the two. I guess this would only happen on a mutual fund with automatic reinvestment. Also in the Export, the dividend, LT Gain, and repurchase all happen on the same date. The export should show the deposits to the brokerage account first and then the buy transaction of the re-investment action. Banks always process Deposits for the day before processing withdrawals to prevent an account overdraw that really didn’t happen. The export process should do the same.

I’m not sure how to make a bug report.

There is a lot that could be improved in the investment areas of KMyMoney.

We are well aware of the needed improvements in handling investments. However, please only open a bug if you have found something explicitly wrong. I am slowly working on putting together a list of missing features and needed improvements for investments. This will eventually turn into a blueprint for actually working on those enhancements and fixes. That document will be posted someplace accessible, and an open request will be made for additional contributions and suggestions. Unfortunately, however, this is not likely to happen very soon. Any issues lited here in Discuss, as well as the mailing list, will get included. There are already several bugs in this area, and those will also be included.
I will go ahead and file that bug for the wrong number of digits in shares and prices in the csv export and list the link here later.
I will also read your last post in more detail later, and see if I have any suggestion for easing your short-term pain. As one point, note that since KMM cannot handle cash within an investment account (an original design decision from long ago, that would be too difficult to change without a significant rework of all the investment code) the Investment and Brokerage accounts are separate. CSV export is only done for one account at a time, so you might want to try combining the two exports to see if things look any better.

I finally checked the code. Shares are always formatted to 2 places and prices to 6 places. I’ll see if I can find how to get the right number of places to use.

The problems with the export dialog have been fixed in the meantime.

Thank you both for reviewing this issue.

ostroffjh, you stated: (“As one point, note that since KMM cannot handle cash within an investment account an original design decision from long ago, that would be too difficult to change without a significant rework of all the investment code) the Investment and Brokerage accounts are separate.”). This seems strange to me because when a reinvest dividend is entered, the shares and either the cash price/share or the cash transaction total for the number of shares purchased is entered in the Investment Account. Actually nothing is goes into the the brokerage account for this dividend cash received and then for the stock purchased with the cash dividend. It all happens in the investment account. I use the total transaction cash method for the shares purchased. It calculates the price per share from this information and also records it in the Price table for the investment. It shows in the ledger correctly, but makes a mess of things in a Transaction Report, seeming to treat the cash transaction total as if they are shares.

I’m not sure what your question is here. Cash can certainly be part of the calculations related to an investment transaction, but if there is remaining cash (interest, dividend, sell) then it cannot remain in the investment account, but must end up in a checking/cash/savings account, usually the brokerage account for the investment account. If it is used to purchase new shares (reinvest dividend) then the new shares are added, and there is no cash left.

I also use the enter total amount and number of shares, and have not noted problems in any reports. I’ll have to look at a transaction report to check. If you can provide a specific example, it might help. For a reinvest dividend transaction, the cash total of the transaction should be zero.

It would be really nice to be able to enter investment transactions as number of units and overall cost and for KMM to calculate the cost per unit. The reason for this is to avoid the rounding problems that can come from entering a transaction as number of units and price per unit. Some of my transactions end up a penny or two out due to different rounding techniques. I’ve tried messing with the “remainder” setting in the investments but none of them give consistently perfect results so I end up manually adjusting the price per unit to make the overall cost correct. The point is that the two numbers you really care about are the number of units and the overall cost.

I’d have to hunt for exactly where to set this, but it is already an option (which I’ve been using for years). There is a general setting, and then it can be overridden for each stock account. It sets whether the amount you enter in the Price field is price per share or total price of the transaction.

Wow, thanks! You’ve prompted me to go and look. I didn’t find a general setting but in the New Investment Wizard there is a field called “Price Entry”. The manual says “Price entry. Choose whether the price will be entered as an individual price, or as the total for all shares.”


Yes, just:

  1. Select “Accounts” in the left column.
  2. Right click the Investment account, Not the brokerage account associated with it.
  3. Select “Edit Account” in the context menu.
  4. To the right below the “Notes” box there is a Price Entry Combo box.
  5. Pull down the arrow of the combo box and you can select “Total for all Shares” or “Price per Share”.

Note: It initially shows in the combo box. I’m not sure where that program default is set.

But this has nothing to do with the export function.

Note the export precision has now been fixed in both 5.1 and master branches. The master branch also includes a fix for the crash I was getting. They should be available in the next successful daily build, if you don’t build your own from git.

I reported this as a bug back in Jan 2022.
That bug report is still in the Reported state.
It should be updated to indicate the problem is fixed.

Done, thanks for the notification.