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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> > > 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, <[email protected]> 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 > [email protected] > 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 [email protected] 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.
