[GNC] Redo account reconciliations
David H
hellvee at gmail.com
Sat Sep 4 17:45:54 EDT 2021
Christopher, I wasn't even aware this was visible by hovering over the
recon flag and I've been using Gnucash since early 2010 for my personal
finances and rental property :-) I generally just rely on the recon date
column in the accounts register to see when I last reconciled an account.
I've picked up the odd unreconciled txn as part of doing the latest
reconciliation and realised I must have changed an old txn and it just got
swept into the latest bunch to be reconciled but the closing statement
balance agreed so all was well in the world. Never had a use for the
reconciliation report either. Can't see any real use for when individual
txns were reconciled - I think most of us wouldn't care too much about when
a particular txn was reconciled, we care more about when the account was
reconciled.
Cheers David H.
On Sun, 5 Sept 2021 at 01:29, Christopher Lam <christopher.lck at gmail.com>
wrote:
> > I guess it depends on how fussy you are about details. Since there is no
> way to see the reconciliation date there is little reason to insist on that
> date being correctly recorded (...)
>
> Yes, some users may be fussy. After all the reconcile_date *is* visible in
> the UI -- you need to hover on the 'y' reconcile status. It's also visible
> in the 'Reconciliation Report' and is used as the date filter.
>
> Adding UI to reset the reconciliation status will allow fastidious users to
> 'redo' reconciliation piecemeal and record statement dates accurately.
> Otherwise they'll need to reset reconcile status one by one by clicking on
> 'y'. I've done this a couple of times while searching for errors.
>
> On Sat, 4 Sept 2021 at 15:01, David Carlson <david.carlson.417 at gmail.com>
> wrote:
>
> > I guess it depends on how fussy you are about details. Since there is no
> > way to see the reconciliation date there is little reason to insist on
> that
> > date being correctly recorded. The GnuCash code displays an incorrect
> > starting balance in the Reconciliation window. When you follow Derek's
> > suggestion and just ignore the starting balance error in the current
> > month's reconciliation, the old transaction is recorded as being
> reconciled
> > in the current month.
> >
> > If you really do want to record the correct reconciliation month for
> every
> > transaction, you need to unreconcile all transactions after the date of
> the
> > statement* before* the month that is not correct before starting the
> > rereconciliation.
> >
> > On Sat, Sep 4, 2021 at 9:19 AM Derek Atkins <derek at ihtfp.com> wrote:
> >
> >> Ah... But that's NOT how you are supposed to recover from that.
> >> If you reconciled up for 31 Aug 2021, and you un-reconcile a
> transaction,
> >> it doesn't matter what date the transaction has -- you should
> re-reconcile
> >> 31 August! You just need to re-check the February transaction.
> >>
> >> -derek
> >>
> >> On Sat, September 4, 2021 9:10 am, Christopher Lam wrote:
> >> > 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
> >> >>
> >> >>
> >> > _______________________________________________
> >> > 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
> >>
> >> _______________________________________________
> >> 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.
> >>
> >
> >
> > --
> > David Carlson
> >
> _______________________________________________
> 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.
>
More information about the gnucash-user
mailing list