I simply do not agree with the argument that editing the _description_ or _memo_ of a transaction should cause its reconciliation state to change. That makes no sense to me.

The current implementation is based on observing how several commercial accounting packages in my area work (which I used as a basis for this decision).

However this issue has also been raised on the gnucash mailing list recently and from that I can only conclude the way things are done around here (Belgium) is not representative for other parts of the world.

Expect this to be revisited in a future release.

However don't expect an option to leave edited transactions as reconciled. That flatly defeats the whole purpose of reconciliation. If you change a transaction after reconciliation you are expected to redo the reconciliation. Period.

I do plan to revisit which fields can sensibly be protected by reconciliation.

If I have a transaction with multiple splits, and I change one or more of the unreconciled splits, I don't see why it would "defeat the whole purpose of reconciliation" for the reconciled split in that transaction to remain reconciled.

When I reconcile my credit card statement and then realize a month later that I miscategorized one of the expenses from that statement, recategorizing that expense has zero bearing whatsoever on the fact that the credit card statement, including that charge, was correctly reconciled, and shouldn't suddenly become unreconciled.

Since reconciliation is per-account, then un-reconciliation should be per-account as well.

A the VERY LEAST, the UX surrounding this needs to be MUCH BETTER. It took me over an hour of poring over transactions, restoring old gnucash files from backup and diffing them, etc., to figure out why it was that when I attempted to reconcile my credit card statement, the initial balance showing up in the reconcile window was not the correct initial balance for the month, despite the fact that it had been correct when I had finished reconciling the previous month's statement. This is simply unacceptable.

I honestly don't how I would ever have figured it out if I hadn't had those backups and the skill to diff files and look at the changes to figure out that a split had invisibly, silently, been marked un-reconciled.

Note that in my particular case this was complicated by the fact that _two_ changes had been made since the last reconciliation, one of them due to this bug and one of them due to correct behavior that was my own fault, but regardless the result was that the amount of the difference between what the initial balance should have been and what it actually was wasn't the amount of a single transaction I could obviously identify in the reconciliation window.

(In reply to Jonathan Kamens from comment #3)
> If I have a transaction with multiple splits, and I change one or more of
> the unreconciled splits, I don't see why it would "defeat the whole purpose
> of reconciliation" for the reconciled split in that transaction to remain
> reconciled.
> 

It doesn't and GnuCash won't unreconcile the other splits.

> When I reconcile my credit card statement and then realize a month later
> that I miscategorized one of the expenses from that statement,
> recategorizing that expense has zero bearing whatsoever on the fact that the
> credit card statement, including that charge, was correctly reconciled, and
> shouldn't suddenly become unreconciled.
> 

Exactly and GnuCash behaves like that as far as I can tell.

> Since reconciliation is per-account, then un-reconciliation should be
> per-account as well.
> 

That's how it is.

You may be confused by the fact that "description" is not a split property but a transaction property. As is transaction date. If any protected transaction property changes, the whole transaction is considered unreconciled. The debate here is now which transaction properties should be considered protected. From my local understanding of reconciliation I thought those were date and description. That is now under discussion.

> A the VERY LEAST, the UX surrounding this needs to be MUCH BETTER. It took
> me over an hour of poring over transactions, restoring old gnucash files
> from backup and diffing them, etc., to figure out why it was that when I
> attempted to reconcile my credit card statement, the initial balance showing
> up in the reconcile window was not the correct initial balance for the
> month, despite the fact that it had been correct when I had finished
> reconciling the previous month's statement. This is simply unacceptable.
> 
The handling of that initial balance is not something I have ever looked at. I agree it looks flawed.

On the other hand GnuCash by default warns you when you perform an action that would unreconcile a split. That should be a prompt to redo reconciliation of that split's period prior to moving on to the next reconcilation. You may have turned off that warning in which case you're on your own.

> I honestly don't how I would ever have figured it out if I hadn't had those
> backups and the skill to diff files and look at the changes to figure out
> that a split had invisibly, silently, been marked un-reconciled.
> 
> Note that in my particular case this was complicated by the fact that _two_
> changes had been made since the last reconciliation, one of them due to this
> bug and one of them due to correct behavior that was my own fault, but
> regardless the result was that the amount of the difference between what the
> initial balance should have been and what it actually was wasn't the amount
> of a single transaction I could obviously identify in the reconciliation
> window.

I agree the UX is pretty weak and dated and also that the handling of the initial balance is pretty flawed. Hopefully someone will find time at some point to improve this.

(In reply to Geert Janssens from comment #2)
> If you change a transaction after reconciliation you are
> expected to redo the reconciliation. Period.
> 
> I do plan to revisit which fields can sensibly be protected by
> reconciliation.
This wasn't the case in gnucash for several years, and you've even stated you plan to re-examine which parts of a transaction should be protected, so I'm surprised you feel justified in making such firm declarations.

In my use for personal finance, I appreciated the flexibility to tweak older transactions to correct typos, recategorize expenses, or nudge transactions at the end of the month by a day or two to improve monthly reports (getting paid twice in January but not at all in February looks weird). I'm not a professional accountant and I don't have any auditors checking the accuracy of my work, so I don't value the level of traceability you seem to be pursuing. I do value distinguishing old transactions that haven't cleared from transactions I edited in ways that don't ruin the utility of my records.

To be absolutely clear about my field protection expectations, I will upload an annotated screenshot of a sample transaction.

Created attachment 373166 [details]
Field protection expectations from user James

red dot = protected
yellow dot = no preference
green dot = not protected

(In reply to James from comment #5)
> (In reply to Geert Janssens from comment #2)
> > If you change a transaction after reconciliation you are
> > expected to redo the reconciliation. Period.
> > 
> > I do plan to revisit which fields can sensibly be protected by
> > reconciliation.
> This wasn't the case in gnucash for several years, and you've even stated
> you plan to re-examine which parts of a transaction should be protected, so
> I'm surprised you feel justified in making such firm declarations.
> 
These two parts of my answer come from different contexts.

The first part is a reaction to your request for an option to leave edited transactions unreconciled. My main point was I don't intend to add an option. So to be clear my assertion is if *a* field protected by reconciliation is changed, reconciliation should be rerun. If this field is part of the transaction any split previously reconciled in that transaction will have to be reverified because they are all affected by this change. Which fields should be protected are indeed under debate as I said in the later part of my answer.

By the way to be pedantic gnucash has no concept of a "reconciled transaction". It can only reconcile splits. However some data you find on a bank statement is not mapped to splits in gnucash but to a transaction property, like date and description. You don't seem to care about either to be validated and protected by reconciliation. I can see this for description, I have more problems with date.

But I think *this* part of the discussion is better done on the mailing list as I'm sure there are plenty more people that have an opinion on this.

> In my use for personal finance, I appreciated the flexibility to tweak older
> transactions to correct typos, recategorize expenses, or nudge transactions
> at the end of the month by a day or two to improve monthly reports (getting
> paid twice in January but not at all in February looks weird).

You can recategorize expenses now without affecting reconciliation if by that you mean changing the transfer account of an unreconciled split.

Nudging transactions and correcting typos would be things to do before or during reconciliation. I mean reconciliation means declaring transactions/splits as verified and not intended to be changed again. You still can change them but at the higher cost of redoing reconciliation.

Can you point me to the mailing list thread(s) where I can add my voice to the discussion? I looked through the last three months of archives for gnucash-devel and gnucash-user, and the closest thread I could find was this one:
https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081909.html

Sure. I think the most relevant discussion is this one:
https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081797.html

I'm going to jump in here after many months.

I have been using GnuCash for my complicated personal finance for six months or so, and I'm still cleaning up transfers from Quicken, etc.

Today I was working on an account with a long string of CD renewals. Usually the interest was rolled into the CD at renewal time, but in one case the interest was transferred to my checking account. 

The checking account had been reconciled, but the CD account at that point had not been.

That transaction was poorly documented, so I edited the description. The R[econcile] column remained 'n' as expected. But when I looked at the checking account, I saw that the R column had silently changed from 'y' to 'n'

I believe this will throw off the opening balance when I next reconcile the checking account. In other accounts I have had mysterious changes that have caused reconciliation problems by the boatload because I had inadvertently un-reconciled transactions in accounts that I had not touched by cleaning up transactions' opposite accounts.

At the very least, I think a warning should be presented to the user along the lines of "Editing this transaction will change the status of the linked/opposite transaction from reconciled to unreconciled. Do you want to proceed?"

Also, it may be appropriate to consider two alternative paradigms: (a) a 'hard' approach, designed for environments subject to audit where strict accounting rules are the norm; in this case ANY change in the transaction would unreconcile all that transaction in all accounts to which it is linked, or (b) a 'soft' approach, designed for environments like personal finance, used by individuals keeping track of their accounts and spending; in this case some information in the transaction (e.g. memo, date, or description) could be changed without affecting the reconciled status of linked accounts, or perhaps even the account where the change was made.

Art

Also jumping in here, I hate the current intended behaviour and don't think transaction description is a protected field.

I've filed related bug 797514 since even this intended behaviour is not consistent, and I'm deliberately exploiting that as a workaround.

I would say it's illogical to consider transaction description as protected by reconciliation - description is transaction-level and unobservable (unlike date of transaction), reconciliation protects on the split level.

It is extremely likely (e.g. interbank transfer) that the two halves of a simple transaction do *not* show up on their respective statements under the exact same name. Now, if reconciliation is supposed to protect the entered name for the transaction, which one of the two (if any) should be used?

In fact, the logic that says transaction description should be protected by reconciliation applies far more strongly to the memo on the reconciled split - but that information is not protected.

As not a professional auditor, the only invariant I expect from reconciliation is that the amount of each reconciled split be protected. There are arguments that date should be protected but I have no strong personal preference, especially as the double-entry invariant that one transaction needs a single date overrides accurate reporting of dates as seen in accounts.

Since it seems there are multiple environments that have different possible requirements on field protection, I propose the following:

1. attempting to change a transaction-level field (date, num, description) on a transaction with any reconciled split triggers a warning
2. warning is roughly "Attempting to change [field] in a transaction with reconciled splits. Do you wish to unreconcile all splits in this transaction? [+implications]"
3. user choices are
a. abort
b. unreconcile all (happens immediately and opens field to editing)
c. unreconcile none (opens field to editing)
d. unreconcile none and don't ask again (session/persistent saved user option)
e. unreconcile all and don't ask again? (if this is saved, clearly the warning still needs to exist to allow user to abort)

This should be per-field, so if a user changes description and chooses not to unreconcile, they should see another warning when they move cursor and attempt to change date. Technical note: may complicate data structure of an uncommitted transaction edit if attempting to change description (none, do not save), attempting to change date, returning to changing description does not trigger a second warning.

For the protected fields on a reconciled split, I propose the following:

1. attempting to change a protected field on a reconciled split (account, amount) triggers a warning
2. in addition to warning about unreconciling that split, if other splits are reconciled it should ask the user if all splits should be unreconciled at once
3. user choices are abort/unreconcile this split (saveable)/unreconcile all splits (saveable?)
4. even with a saved preference the warning needs to exist to allow user abort

Additionally, this same dialog could be used for currently unprotected fields on a reconciled split (action type, memo): all choices of unreconcile none/this/all have valid user stories.

Just to add I agree fully that modifying transactions *Descriptions/Num/Memo* should not reset reconcile status.

I find myself downloading OFX from bank, importing (and matching accounts), and reconcile.

Later on, I may go back to a previous transaction T to add further annotation in the desc/memo. When the reconcile status is reset, it messes up the whole reconciliation process for future reconciliations.... to fix(*) it back requires unreconciling all transactions between T and TODAY, redo the reconcile process, and click Finish to mark them all reconciled.

(*) Otherwise, I find myself with the awkward position whereby I can run "Reconcile on 15/02/2020, ending balance $2000" and this matches the bank statement's position, then finding the Reconciliation Dialog shows a different Reconciled Balance because there are transactions between 15/02/2020 and TODAY already reconciled, thus I cannot reconcile at all.(**)

(**) I think because reconcile dialog shows xaccAccountGetReconciledBalance(acc) instead of xaccAccountGetReconciledBalanceAsOfDate(acc,reconcile_date) (***)

(***) would this fix be an acceptable stop-gap solution?

Documented last issue as bug 797640

(In reply to James from comment #8)
> Can you point me to the mailing list thread(s) where I can add my voice to
> the discussion?

Two discussions:

https://lists.gnucash.org/pipermail/gnucash-user/2018-August/078991.html

https://lists.gnucash.org/pipermail/gnucash-user/2019-April/084685.html

This issue is open for more than a year now, partly due to my reluctance to just revert the changes.

My motivation to protect date and description under reconciliation comes from a business context where you're not supposed to make any changes to transactions marked as reconciled. At the time I was heavily focused on making gnucash more business compliant.

That bit has changed. I no longer have enough time available to do so. And I understand in a personal accounting context it makes much less sense to be that strict.

So at this point I no longer object to relax the reconciliation restrictions on transaction fields.

For description changes I agree it would be sufficient to ask the user whether s/he really wants to change the description of a transaction with reconciled splits. On yes, just allow it without effect on the reconcile status, on no, don't make the change.

For date changes I have no strong preference though I'm inclined to apply the same logic as for description to avoid unnecessary code complexity.

This will be fixed as described in comment 15 for gnucash 3.9 to be released this weekend.

Thanks gjanssens, the fix is perfect. The new behaviour is now:

Modifying the following has no effect on reconcile status:
- date
- num/desc/memo/action

Modifying the following will reset reconcile status
- account
- amount

(There's less pressing need for bug 797640 now. I will still aim to complete a 'sanity-check' type report which verifies all reconciled balances against old reconciliation data!)

*** Bug 797071 has been marked as a duplicate of this bug. ***

*** Bug 785958 has been marked as a duplicate of this bug. ***

I hope this resolves the additional issue that has caused me grief from time to time, i.e. is it possible to somehow reconcile a single very old transaction that somehow was accidentally un-reconciled, deleted or whatever against the original statement date when it was reported as cleared by the bank without needing to un-reconcile and re-recocile everything after that date?

Currently the work-around is to just start the next reconcile with an incorrect starting balance and reconcile the old transaction to the current statement date.  This works, but it would be nicer to give that rogue transaction the correct reconcile date and start the next reconciliation with the correct starting balance.

That is what I found to be the most annoying thing about attempting to repair an old mistake.

(In reply to David Carlson from comment #20)
> I hope this resolves the additional issue that has caused me grief from time
> to time, i.e. is it possible to somehow reconcile a single very old
> transaction that somehow was accidentally un-reconciled, deleted or whatever
> against the original statement date when it was reported as cleared by the
> bank without needing to un-reconcile and re-recocile everything after that
> date?

No and I don't think gnucash ever will. I made changes to allow this last year or two and received both public and private push back against this change.