I can assure you that GnuCash reconciliations 'stick'. I very rarely encounter a discrepancy in the opening balance of a bank or credit card account. When I do, there is always a data-related explanation to account for it. It is not related to a software bug or quirk. Any transaction mistakenly backdated or inadvertently deleted may throw those balance figures off, but it's your error, not the software. The software does not 'lock' reconciled accounts such that you are prevented from making the sort of inadvertent goof that inserts or deletes a transaction prior to the date of the previous reconciliation.
-----Original Message----- From: gnucash-user <gnucash-user-bounces+john.layman=ieee....@gnucash.org> On Behalf Of Mark Truelove Sent: Wednesday, September 27, 2023 11:48 AM To: stepbystepf...@comcast.net Cc: gnucash-user@gnucash.org Subject: Re: [GNC] Reconciliation of accounts is not permanent Hi again. Besides my tendency to be details-specific (given my professional background), I also had some college level accounting and understand double-entry, reconciliation, and the basics. No, I am not an accountant, but I have been using GnuCash mostly successfully for more than twelve years now. I am new to this list, but not to the topics we're discussing. Regarding using the wrong year for the reconciliation date, the program suggests an approximate date based on the last, and at the moment that recommendation is 9/24/22. This is not in a vacuum, however, because all of the unreconciled transactions between August '22 and present are still in the ledger awaiting reconciliation against these 12 or so monthly statements that I just re-downloaded. If I'd simply entered the wrong year, this would not be the case. I'd hoped this would have been something familiar to someone, only that I didn't know about because I hadn't been on the list previously. Based on the responses, it's beginning to look a little obscure now. On Wed, Sep 27, 2023 at 10:52 AM Michael or Penny Novack < stepbystepf...@comcast.net> wrote: > > > > The purpose of reconciliation is to verify that from the last > > closing date to the new closing date, the listed transactions > > cleared the account and thus explain the change from the opening > > balance (last closing balance) to the new closing balance listed on the > > statement. > > > > The actual balance, in your books, on a given day, or as of a given > > day, is irrelevant to that reconciliation. > > > Precisely. You EXPECT there to be a difference based on checks written > (appear in the gnucash account) that have not yet cleared. In other > words, the main part of the job (if no errors) is to verify that the > total of checks written but uncleared matches the difference between > the bank statement of the account and the gnucash account as of the > date of the statement. > > When it still doesn't match you then need to find the error, a check > not entered for the correct amount. Usually at your end but once I had > one of these at a bank end. > > Michael D Novack > > _______________________________________________ > gnucash-user mailing list > gnucash-user@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@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@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.
