Hi, Thanks for the support on this. I think the balance of opinion is that a reconciliation process, to be effective, should categorise/flag transactions in such a way that they do not appear on future reconciliations - the process is incremental. The purpose, after all, is to confirm that the QuickFile balance jives with the bank version and allows for a line to be drawn under those transactions that lead to this balanced position.
I am far from an expert on accounting software but I can remember the early Quickbooks reconciliation method (I have not used it for 10 years +), which seemed effective and painless. At a reconciliation point (frequency at user discretion), the opening balance was offered - presumably, the sum of all the previously reconciled transactions [if this was not what was printed on the statement this indicates that a previously reconciled transaction must have been changed - which is up to the user to sort out] - and the final balance from the statement was entered. During the reconciliation, the user would tick inflows (in one column on the left) and outflows (in the right column) from all the unreconciled transaction on the account (irrespective of date) until the balance was reached. Reconciliation was confirmed and the transactions leading to the new position were flagged accordingly.
I can’t remember what happened if there were missing transactions or incorrect figures during the reconciliation process but i think you could sort out these problems on-the-fly without cancelling the whole process and resorting to pen and paper to note which transaction required attention. With QuickFile it may be easier to make adjustments during the reconciliation process as you can open more than one browser tab and add/correct transactions as required and then refresh the reconciliation view in the original tab in order to continue. Once complete, reconciled transactions could be shown on the bank view through a colour change or an icon, or something of that kind.
It seems that the majority of the code to do all this is already in place with the current reconciliation facility - just the flagging required really.
Flexibility to switch reconciliation status on/off manually is preferable to a rigid system of locking transactions according to date or disallowing edits for reconciled transactions as these are programatically much more challenging and burdensome for users. A warning window for changing/unmarking/deleting reconciled transactions would probably suffice.
I think that the suggestion of the number of days of leeway might be over complicating things to be honest. The book-keeper should have the flexibility to post transactions for any dates they want and can simply be offered all unreconciled transactions, irrespective of date, during a reconciliation session. Transactions remain visible until they are reconciled or deleted as erroneous/duplicate.
Be good to get some other opinions.
All the best,
Don