[GNC] Redo account reconciliations

Christopher Lam christopher.lck at gmail.com
Sat Sep 4 09:10:21 EDT 2021


Derek,
Consider a well-used bank account. You reconcile every end of the month
successfully up to 31 Aug 2021.
Accidentally you unreconcile a Feb 2021 split.
You retrieve your 28 Feb 2021 bank statement, try to re-reconcile and fail
because the reconciliation end balance also tallies splits from March 2021
onwards.
C

On Sat, 4 Sept 2021 at 13:01, Derek Atkins <derek at ihtfp.com> wrote:

> Chris,
>
> On Sat, September 4, 2021 8:36 am, Christopher Lam wrote:
> > I agree that if an account reconciliation is done periodically correctly
> > every time, then it works well. If an old reconciled split is
> unreconciled
> > and we need to re-reconcile a previous reconciliation date, then the code
> > falls apart.
>
> I'm curious why you say it falls apart?
>
> > It may be an idea to allow batch unreconciliation of all splits whose
> > reconcile date is after the reconciliation date in the Reconciliation
> > dialog, thereby allowing the user to re-do reconciles.
>
> That could be a good idea.
>
> -derek
>
> > On Sat, 4 Sept 2021 at 06:34, Borden via gnucash-user <
> > gnucash-user at gnucash.org> wrote:
> >
> >>
> >>
> >> > The starting balance is computed from all the reconciled transactions
> >> "to
> >> > date".  It *can* be safe to ignore the starting balance if, for
> >> example,
> >> a
> >> > transaction became unreconciled.  For example, let's say you reconcile
> >> > from some starting balance X to a final balance of $1000.  Then you
> >> > accidentally unreconcile a $100 transactions.  If you try to
> >> re-reconcile
> >> > that same statement/date/ending-balance of $1000, it won't show X as
> >> the
> >> > starting balance, but something else (PROBABLY $900, but I'm not 100%
> >> > sure).  But that's okay -- just ensure the ending balance is correct
> >> and
> >> > all the transactions that SHOULD be reconciled ARE reconciled.
> >> >
> >> > There is no way to get a transaction to reconciled status (y) manually
> >> --
> >> > the only way is through a reconcile process.  So if you have
> >> reconciled
> >> > transactions, that must've happened through a reconcile.
> >> >
> >> > I would recommend you just go ahead with March, ignore the starting
> >> > balance, enter the correct March ending balance, and see if the
> >> > reconciliation works (ensure you re-reconcile anything from earlier
> >> that
> >> > might have become unreconciled).
> >> >
> >> So I just want to build a bit on this answer. GNUCash doesn't have QBs
> >> reconciliation system - so don't equate the two. As an accountant who
> >> doesn't need to be handheld or leashed, I  find GNUCash's system better
> >> than QBs - albeit there is room for improvement. However, I wouldn't
> >> recommend GNUCash to someone less comfortable with bare-ledger
> >> accounting -
> >> controls exist for a reason.
> >>
> >> I don't know how the backend works, but my experience is that the
> >> "Opening
> >> balance" is basically a running total of all the transactions marked
> >> "Reconciled" in that account. Whereas QB will _prevent_ you from
> >> attempting
> >> to reconcile August if July's reconciled balance differs from what it
> >> previously reconciled, GNUCash doesn't care - it just says "The
> >> transactions marked 'Reconciled' for this account total to $X." And
> >> that's
> >> good for when you have to go back and fix things... and know what you're
> >> doing.
> >>
> >> When you reconcile a transaction, again based on  my experience, GNUCash
> >> toggles the "Reconciled" flag on the account _and_ inserts the
> >> reconciliation date. I personally like this because  I can, say, start a
> >> fresh reconciliation for March having reconciled through August  to pick
> >> up
> >> the transactions that _should_ have been in the March reconciliation but
> >> weren't because I readded them (or whatever). However, I need  my
> >> calculator with me because I need to adjust the "closing balance" to
> >> reflect not the statement balance but what GNUCash's "running total"
> >> balance should be. Contrast this to having to undo every rec in QB back
> >> to
> >> March and redo every rec again.
> >>
> >> Still, as I said, there's room for improvement in GNUCash:1) Since the
> >> rec
> >> date gets stored with the Rec flag, GNUCash can  have a function that
> >> unreconciles every transaction before a given rec date. This would be
> >> analogous to QB's batch rec undo.
> >> 2) One should be able to rec from the ledger  as QB lets you do - and
> >> prompt for a rec date. Yes it's dangerous, poor practice, etc., but the
> >> GNU
> >> philosophy is not to leash the user. If a user wants to sudo rm -rf /
> >> their
> >> installation, GNU warns them first, but ultimately lets them. User knows
> >> best. If you want your computer to dictate what you're allowed to do
> >> with
> >> it, that's what Apple's for.
> >>
> >> I hope that helps a bit
> >> _______________________________________________
> >> 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
> >> If you are using Nabble or Gmane, please see
> >> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> >> -----
> >> 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
> > If you are using Nabble or Gmane, please see
> > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
>
>
> --
>        Derek Atkins                 617-623-3745
>        derek at ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>
>


More information about the gnucash-user mailing list