[GNC] Reconcile Operation overrides User-entered Ending Balance

Tom Route36 tom.route36 at gmail.com
Thu Aug 6 13:58:10 EDT 2026 

Hi Sherlock,

I guess I should apologize for taking up folks time with this one. I was 
sure that with the bug propagating thru all the previous GnuCash 
versions that it would still be there.  But today I went and installed 
stable Build ID: git 5.16-64-gc935c2fbb8+(2026-07-26); and yes, I can 
confirm that the Reconcile bug is gone now.  Thanks for pushing me to 
check it out.  Apologies again.  Looking forward to the official 5.17 
release.

Tom


On 08/06/2026 01:06 AM, Sherlock wrote:
> Hi Tom,
>
> I would appreciate it if you would confirm that the problem has 
> already been addressed.  If you haven't already, please download and 
> install any of the recent nightly builds (after July 7th 2026) from 
> https://code.gnucash.org/builds/win32/stable/ and let us know if you 
> can still reproduce the issue.
>
> Thanks,
>
> Sherlock
>
>
> On 8/5/26 11:39 PM, Tom Route36 wrote:
>> John,
>>
>> I have to agree.  Changing the date on the offending $150 transaction 
>> is really just a workaround, not a fix.  But the root cause seems to 
>> be something wrong in the code that transfers the user-entered data 
>> (the date and amount) from the Reconcile Info window to the Main 
>> Reconcile window.  Basically, the code logic when calculating the 
>> Ending Balance for the Main Reconcile window seems to be something 
>> like this:
>>
>>    IF (TransDate = StatementDate) THEN (MainEndingBal = InfoEndingBal 
>> + TransAmt)
>>
>> I realize that's a very simplistic way of putting it; but that seems 
>> to be how the logic is working for calculating what Ending Balance 
>> amount ends up in the Main Reconcile window.  Of course, then there's 
>> the weird complication where changing the Info Ending Balance by a 
>> penny seems to invalidate this simple If-Then formula. And it also 
>> doesn't explain why other folks aren't able to reproduce the same 
>> problem on other systems.
>>
>> Anyway, I'm more than happy to do additional testing or provide added 
>> info if any wants to look into this further.  If I don't hear back 
>> though, I'll just go ahead and use the workaround, and move on.
>>
>> Tom
>>
>>
>> On 08/05/2026 09:21 PM, John Ralls wrote:
>>> Tom.
>>>
>>> I’d say that date manipulation—changing the date of the added 
>>> transaction—works around the problem you’re reporting rather than 
>>> fixing anything unless you left out that you also advanced the date 
>>> passed to reconcile info (that’s the real name of the little dialog 
>>> that collects the reconcile date and ending balance before the main 
>>> reconcile window comes up) to 7/28: The 7/27 default ending balance 
>>> will be the $800 you want.
>>>
>>> FWIW (and at this point I’m not sure it’s worth much) that’s not 
>>> what I meant about the date being irrelevant. I was referring to the 
>>> remarks about the date really being 7/26 because at 00:00:01 7/27 
>>> the balance was still $800.
>>>
>>> Regards,
>>> John Ralls
>>>
>>>
>>>> On Aug 5, 2026, at 19:41, Tom Route36 <tom.route36 at gmail.com> wrote:
>>>>
>>>> Hi John,
>>>>
>>>> I managed to get back to the system here tonight.  I have some 
>>>> important new info; but before I get into that let me go and 
>>>> provide the Preference settings you asked for.  Here they are:
>>>>   =====
>>>>   Reverse Balanced Accounts:  Credit accounts
>>>>   Reconciling:  Check cleared transactions - checked
>>>>   Reconciling:  Automatic credit card payment - unchecked
>>>>   Reconciling:  Always reconcile to today - unchecked
>>>>   Reconciling:  Enable autoclear tools in reconciliation - unchecked
>>>>   =====
>>>> Also, I can confirm that none of the splits are cleared. All of the 
>>>> transactions that are part of this statement period / 
>>>> reconciliation operation all still have 'n' in the Reconcile column.
>>>>
>>>> Now, on to the new info.  One of the things you said yesterday was 
>>>> that the date stuff was irrelevant.  But based on my additional 
>>>> testing today, I'm going to have to disagree with you.  It seems to 
>>>> be a key factor here.
>>>>
>>>> I first repeated the same test of reconciling with the 7/27 
>>>> Statement Date and the $800.00 Ending Balance using every 
>>>> conceivable sequence of tabbing around and mousing around and 
>>>> hitting enter that I could come up with. Nothing changed the 
>>>> result.  The $800 entry in the Reconcile popup window always ended 
>>>> up getting overwritten with the $950 amount after hitting OK.
>>>>
>>>> But then I made one change.  In the register, I edited the 
>>>> offending $150 transaction that had the 7/27 date. And I simply 
>>>> changed the transaction date to 7/28 -- the day *after* the 
>>>> Statement Ending Date.  Then I did the Reconcile operation.  And 
>>>> when I hit OK?  Now my $800 Ending Balance carried thru to the 
>>>> Funds In vs Funds Out window as $800. Problem solved!
>>>>
>>>> There may be some additional factors playing into this that's 
>>>> causing the issue to only show up on this particular account on my 
>>>> system. And I'm not really sure what those other factors might be.  
>>>> But the key factor appears to be when you're doing a Reconcile 
>>>> operation on an account in which there's a non-zero transaction in 
>>>> the register with a date *equal* to the Statement Date that the 
>>>> user is entering in the Reconcile popup window.  When those 
>>>> conditions occur, that seems to cause the user-entered Ending 
>>>> Balance to get overwritten. At least, that's what appears to be 
>>>> happening on my system here.
>>>>
>>>> I'm still not following thru with the reconciliation of this credit 
>>>> card account just yet.  I'm keep things as they are in case you'd 
>>>> like me to run some additional tests or need other info first.  
>>>> Just let me know what you need.
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 08/05/2026 10:58 AM, John Ralls wrote:
>>>>> Tom,
>>>>>
>>>>> No rush, respond when you have time and are with your machine.
>>>>>
>>>>> That’s an interesting behavior that I still can’t reproduce, but 
>>>>> maybe I need to set up a test book with the right conditions to be 
>>>>> able to duplicate it exactly.
>>>>>
>>>>> Please do provide the preferences you have set to help with 
>>>>> replication efforts.
>>>>>
>>>>> Regards,
>>>>> John Ralls
>>>>>
>>>>>
>>>>>> On Aug 5, 2026, at 01:24, Tom Route36 <tom.route36 at gmail.com> wrote:
>>>>>>
>>>>>> John,
>>>>>> A correction to my availability for testing.  It's Wednesday 
>>>>>> (today) that I won't have my test system.  So if you have other 
>>>>>> questions for me, I'll be back Thursday.  Sorry for the 
>>>>>> confusion. (It's been a really long day for me ... whatever day 
>>>>>> this is now.)
>>>>>> Tom
>>>>>>
>>>>>> On 08/05/2026 01:57 AM, Tom Route36 wrote:
>>>>>>> Hi John,
>>>>>>>
>>>>>>> I can go and provide you with all the settings you asked about 
>>>>>>> here; but before I do that I have an important -- and weird -- 
>>>>>>> update I think you might want to hear about first.  Bear with me 
>>>>>>> while I explain step-by-step the additional testing I just did.
>>>>>>>
>>>>>>> First, in this credit card account where I'm doing the testing, 
>>>>>>> I have deliberately *not* actually completed any 
>>>>>>> reconciliation.  So all of the past month's transactions are all 
>>>>>>> staying in their un- reconciled state.  All I'm doing is 
>>>>>>> bringing up the Reconcile popup window repeatedly and trying 
>>>>>>> different dates and amounts there to see what happens in the 
>>>>>>> resulting Reconciliation summary box after I click OK in the 
>>>>>>> popup window.  In other words, I'm trying to maintain the same 
>>>>>>> testing baseline.
>>>>>>>
>>>>>>> Having said that, here's the exact routine that I'm following. 
>>>>>>> With the credit card account open, I click the Reconcile button 
>>>>>>> at the upper right corner of the GnuCash window.  That opens the 
>>>>>>> Reconcile popup window.  The Statement Date field has the 7/25 
>>>>>>> date. And the Ending Balance field, which is highlighted by the 
>>>>>>> current cursor position, shows the $800 amount.  I click in the 
>>>>>>> Statement Date field to put the cursor there.  And I tap the 
>>>>>>> plus key (+) on my numeric keypad twice to advance the date to 
>>>>>>> 7/27. As soon as I do that the $800 amount in the Ending Balance 
>>>>>>> field changes to $950.
>>>>>>>
>>>>>>> Once the Ending Balance field changes to $950, I hit the Tab key 
>>>>>>> twice to move the cursor to the Ending Balance Field, which 
>>>>>>> highlights the $950 amount.  Then I type in my correct Ending 
>>>>>>> Balance amount, which is the $800 amount from my credit card 
>>>>>>> statement.  Then I use the mouse to click the OK button.  That 
>>>>>>> closes the Reconcile popup window; and takes me to the Funds In 
>>>>>>> vs. Funds Out window where I see the Reconcile summary box in 
>>>>>>> the lower right corner.  And that's where I see that the Ending 
>>>>>>> Balance in that summary box is $950 instead of the $800 that I 
>>>>>>> just entered previously.
>>>>>>>
>>>>>>> Okay.  So the above description is what I'm doing step-by-step. 
>>>>>>> Now, brace yourself for the weird part.
>>>>>>>
>>>>>>> Like I said above, when I put $800 as the Ending Balance in that 
>>>>>>> popup window and click OK, the summary box then lists the Ending 
>>>>>>> Balance as $950.  So my entry got overridden, just as I've been 
>>>>>>> reporting all along.  So for my testing now, I decided to change 
>>>>>>> the value that I entered in that popup window -- still setting 
>>>>>>> the Statement Date to 7/27.  For the Ending Balance I typed in 
>>>>>>> $799.99.  And to my surprise, when I clicked the OK button, the 
>>>>>>> Reconcile summary box kept and displayed the Ending Balance as 
>>>>>>> $799.99, exactly as I entered it.
>>>>>>>
>>>>>>> So since the Reconcile popup seemed to like one cent less than 
>>>>>>> the actual ending balance, I figured why not try one cent more?  
>>>>>>> Next go round in the popup window I entered $800.01.  And once 
>>>>>>> again, when I clicked the OK button, the summary box kept and 
>>>>>>> displayed the Ending Balance as $800.01, again exactly as I 
>>>>>>> entered it. No more overriding of my entered values.
>>>>>>>
>>>>>>> Problem solved??  Nope!  I went back again to enter the proper 
>>>>>>> value of $800.00 exactly.  And once again, when I clicked OK, 
>>>>>>> the summary box insisted on showing the $950 value again.  Like 
>>>>>>> I said ... weird!
>>>>>>>
>>>>>>> I can still provide those other details if you think it will 
>>>>>>> help.  But unfortunately, I'm going to be away from my test 
>>>>>>> system here all day Thursday.  If there's any other info or 
>>>>>>> testing you'd like though, just let me know; and I'll try to get 
>>>>>>> to it on Friday.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>> On 08/04/2026 09:59 PM, John Ralls wrote:
>>>>>>>> Tom,
>>>>>>>>
>>>>>>>> Yes, all the date stuff is irrelevant. The problem you describe 
>>>>>>>> is that the entry isn’t getting read before the dialog is 
>>>>>>>> closed and the ending balance is copied to the reconcile 
>>>>>>>> window. This seems closely related to 
>>>>>>>> https://bugs.gnucash.org/show_bug.cgi? id=799650, which 
>>>>>>>> reported that under some circumstances using the enter key to 
>>>>>>>> complete the reconcile info dialog after editing the ending 
>>>>>>>> balance field didn’t read the new value in that field. As 
>>>>>>>> Sherlock said he fixed it a year ago.
>>>>>>>>
>>>>>>>> Since none of us can reproduce the problem—and while nobody yet 
>>>>>>>> has tried on Windows it’s pretty unlikely to be OS related—you 
>>>>>>>> may have found a new corner case. Please record carefully, step 
>>>>>>>> by step, exactly what you type and click to reproduce the 
>>>>>>>> behavior.
>>>>>>>>
>>>>>>>> There are also some preferences that might be germane: What are 
>>>>>>>> your settings for Reverse Balanced Accounts in the Accounts 
>>>>>>>> page and all of the Reconcile options in the Register tab?
>>>>>>>>
>>>>>>>> One more possible difference: Are any of the splits cleared 
>>>>>>>> (the Reconcile column between the account and debit columns is 
>>>>>>>> ‘c’ instead ’n’?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> John Ralls
>>>>>>>>
>>>>>>>>
>>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

More information about the gnucash-user mailing list