Created attachment 188774 [details] Ledger with no balances *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY Ledger does not show balance STEPS TO REPRODUCE 1. Open file 2. Open any ledger OBSERVED RESULT Balance has --- EXPECTED RESULT The running total SOFTWARE/OS VERSIONS Windows: 10.0.19045 KMyMoney 5.2.1-914c61b ADDITIONAL INFORMATION
What is the sort order for the l edger. A running balance is only shown if the transaction date is the first item in the sort order.
Created attachment 188777 [details] attachment-3091667-0.html I changed the order so that Post Date is first. That does allow the Balance to be shown. This is a breaking change from 5.0.6. I have The same setting in 5.2.1 The balance will not show. Is there any plan to change the behavior. Thanks, Mike On 1/21/2026 6:55 PM, Jack wrote: > https://bugs.kde.org/show_bug.cgi?id=514924 > > Jack<ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #1 from Jack<ostroffjh@users.sourceforge.net> --- > What is the sort order for the l edger. A running balance is only shown if > the transaction date is the first item in the sort order. >
Created attachment 188778 [details] TPTikQmSAjU9V50L.png
Please - when you reply to a bug by email, remove everything except your response. Remove everything from the previous message. Your entire email becomes the next attachment, and if you reply in HTML and not just plain text, the HTML becomes an attachment. The extra material makes it very hard to follow the flow of the bug. See https://bugs.kde.org/show_bug.cgi?id=514924#c2 as an example. I believe the change was made in 5.1.3, already a very long time ago. I think it is unlikely the developers will change this behavior, as it is generally accepted that a running balance is not actually meaningful if the first sort item is not post date. I'm closing as INTENTIONAL, but I suppose you can reopen as a wishlist, although it is very unlikely to be accepted.
Created attachment 188788 [details] attachment-3268765-0.html Thanks for the information. Where could I download 5.1.2 for windows and Linux (Ubuntu). Mike
Basically, you can't, at least nowhere officially supported. That's not fully true - as you might find 5.1.3 available for some Linux LTS distros, but you need to remember 5.1.3 is no longer supported. 5.1.3 for Windows (if you can find one) is likely to still work, but 5.1.3 for Linux will only work for distros which still support Qt5, and that group is slowly shrinking - I am assuming LTS distro versions will be the last to go. Can you state your use case for wanting a running balance when Post Date is not the first sort item?
Created attachment 188796 [details] attachment-3339167-0.html Here is a picture of the ledger With the reconciliation state first then post date
Created attachment 188797 [details] 5D9edctEkg80QuvC.png
I can see your point. I have actually thought about why the Reconciled header is shown in red (as not matching the running balance) when it is (usually clearly) because there are not reconciled transactions prior to the reconciliation date. Although I'm still not sure anything will be changed in this area, it might be worth converting this to a wish-list, perhaps just for this particular sort order of Reconciled State before Post Date.
How would I do that?
I'm not sure if you as OP have sufficient permissions, so I've done it for you, and altered the Subject as (hopefully) appropriate. I think we agree that in general, anything other than Post Date as first sort item leads to a non-meaningful running balance, but with this specific combination (Reconcile Status, Post Date) the running balance does make sense, and can help compare local records to the institution, particularly in between reconciliations.
Thanks!