[GNC] How can I add statement balances to my accounts as checks?

[Arman Schwarz]

Thanks Adrien,

I think it's the "if you aren't careful" part of the reconciliation
philosophy that I don't like, but I think your message helped me understand
the intended workflow with GnuCash.

Just to explain my first comment; Reconciliation seems to depend on the
user checking that transactions are correct, and if a mistake is made, it's
unlikely that it will be caught in future. For example, if I enter a
transaction from July 10, 2019 with the incorrect date of July 10, 2010,
then I will just have thrown off 9 years worth of transactions. If I happen
not to notice this mistake during reconciliation (which is not unthinkable,
since I made the mistake in the first place) then I'll probably never catch
it unless I happen to reconcile old balances (which I'll never do).

The issue with "be careful when reconciling" is that if I could be so
careful as not to make mistakes, I wouldn't need reconciliation in the
first place. Well, that's not entirely true, I suppose reconciliation would
then still be helpful in that it would catch mistakes made by the bank or
some other third party. Maybe that's what I'm missing - that reconciliation
isn't intended to catch user errors, just third party errors?

Either way, balances are useful pieces of information that GnuCash is
throwing away. I may end up writing a bash/python script combined with
Christopher's suggestion to implement these assertions myself. If I do I'll
post the result but I don't really have enough (any) expertise with GnuCash
to know whether such a feature could be implemented in the software itself.

Anyway, thanks to both of you for clarifying for me.

On Wed, 2 Oct 2019 at 15:44, Adrien Monteleone <
adrien.monteleone at lusfiber.net> wrote:

> For now, the workflow is that if you alter a reconciled transaction,
> you’ll get a warning. (which is dismiss-able, and which you can elect to
> not be shown) There is at least one (though I think several) bug reports on
> what should trigger this warning when a reconciled transaction is edited,
> depending on what data edit causes the trigger.
>
> However, I know of no mechanism in GnuCash currently that checks to see
> that you’ve entered an historical transaction that *should* have been
> reconciled in the past, or even has an erroneous date and should be in the
> present but affects a reconciled period.
>
> Presumably, since it is required for the math to work out, if you are
> entering a real historical transaction, it should be part of the historical
> reconciliation. Which means if it were not already present, then either you
> have some serious errors in your current record, or, you made a correcting
> entry that needs to be erased/modified now that you have more accurate
> transaction data.
>
> Regardless of if you enter an old transaction that should have been
> included, or mis-enter a date in the past, the next time you reconcile,
> you’ll see that/those old transactions and notice something is amiss. While
> it would be nice to get such warning at the point of entry, there might be
> use cases where warnings are quite a pain, especially for someone
> intentionally entering historical data.
>
> Personally, I don’t have a problem with the current approach.
>
> If you successfully reconcile a period and don’t have to make an adjusting
> transaction, there should be no issue.
>
> If you reconcile but made errors and don’t feel like, or can’t at the
> moment track down why they are there and make an adjusting entry, then
> you’ll realize this at worst, at the next reconciliation.
>
> If you errantly enter an old date on a transaction, you’ll catch this at
> the next reconciliation. (unless you aren’t careful)
>
> Now, it would be nice if upon reconciliation, there were some way to
> indicate in a particular transaction (the last of the reconciled period)
> that the asserted balance was at a certain level. I do this from time to
> time if I happen to count a cash asset, but haven’t gotten around to
> reconciling it yet. I’ll note that at the point of the transaction I had a
> certain amount physically on hand. That way, when I do get around to formal
> reconciliation, I know my balance at that transaction needs to be a certain
> amount. And if it is off, I’ll have to either search for the error, or
> enter a miscellaneous transaction as a correction.
>
> If I ever have to make a balancing miscellaneous transaction to complete a
> reconciliation, I’ll indicate in it whatever that asserted balance was
> supposed to be. That way, if I ever get back to investigating or if I find
> a lost receipt for example, I can either edit that balancing transaction
> accordingly, or erase/reverse it entirely.
>
> But that doesn’t include the case of doing so automatically from an actual
> reconciliation. (rather than being not up to date in doing so, or manually
> noting the asserted balance.) Perhaps an RFE would be in order, however, I
> don’t know how much work would be involved or where that would even appear
> in the UI.
>
> Regards,
> Adrien
>
> > On Oct 1, 2019 w40d274, at 11:51 PM, Arman Schwarz <
> armanschwarz at gmail.com> wrote:
> >
> > Thanks Christopher, also for putting a name to what I was trying to
> > describe.
> >
> > It seems odd to me that the devs would spend time implementing
> > "Reconciliation" and then delete the most important part right after it's
> > provided (the balance). Was this a deliberate design decision or are
> > balance assertions on the roadmap? If not, what was the reason and what
> is
> > the intended workflow to prevent errors creeping into my accounts?
> >
> > On Wed, 2 Oct 2019 at 14:38, Christopher Lam <christopher.lck at gmail.com>
> > wrote:
> >
> >> This is a feature called balance assertions present in ledger-cli,
> another
> >> bookkeeping tool. GnuCash doesn't have it. However you can approximate
> it:
> >>
> >> https://bit.ly/2mMAKmf
> >>
> >> On Wed, 2 Oct 2019, 12:28 armanschwarz, <armanschwarz at gmail.com> wrote:
> >>
> >>> Suppose on July 1, 2019 I get a statement that my account balance is
> $100.
> >>> Since I know this is true and won't change in the future, I should be
> able
> >>> to tell GnuCash that this is the expected balance, and for some kind of
> >>> warning to appear if that condition is ever violated for the
> corresponding
> >>> account in GnuCash (kind of like a unit test).
> >>>
> >>> Looking at the documentation for Reconciliation, it seems like this
> that
> >>> feature more targeted at individual transactions rather than setting
> known
> >>> values for balances at given points in time. If I reconcile an account
> for
> >>> 12 months every month, and then stop reconciling it the year after,
> what's
> >>> stopping all of those historic balances from getting thrown out of
> whack?
> >>> Does GnuCash remember what the balances should be and prevent this?
> >>>
> >>> Also, if I accidentally enter a wrong date every 5% of the time, and I
> >>> accidentally reconcile them incorrectly 5% of the time, then for a
> large
> >>> number of transactions I'm virtually guaranteed to have my history
> broken,
> >>> whereas remembering statement balances would avoid this problem.
>
>
> _______________________________________________
> 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.
>