[GNC] Redo account reconciliations
Christopher Lam
christopher.lck at gmail.com
Sat Sep 4 11:26:48 EDT 2021
> 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
>
More information about the gnucash-user
mailing list