I was not aware that AQbanking does a reconcile on the fly. I also use OFX, CSV nad very occasionally QIF imports (but not from Quicken) but not that heavily any more. I think it would be useful to have this information about the reconcile marking process documented at least in the importing section of the help manual. There are sections on reconciliation in several sections of the guide and the help manual. I suspect it is covered but there isn't a nice summary.
I don't know enough about how AQbanking works at the bank level, e.g. whether it only makes transactions available after all bank internal processes (clearing) have occurred as my bank hasn't implemented it and refuses to on security grounds (but it does allow MYOB and a number of other commercial packages direct server access but only on business accounts not personal accounts - no doubt for a hefty fee) but it is clearly regarded as the equivalent of a statement. In my manual OFX downloads for my credit card, the bank records transactions as pending in their web portal, which I have made, but are not yet cleared through VISA, until they get a clearnce from VISA. I can't include the pending transactions in either a CSV or OFX download which makes sense. The shortened times for electronic clearance between banks these days usually means that i have had no conflicts between downloads and statements for several years now unless I have had finger trouble in importing. On my Savings account I can't remember having had a transaction marked as pending since electronic clearing came in. I will put it on my to do list to find an appropraite places to put such a summary. I tried to rationalize the Guide recently by having a general section Ch4 on reconciliation and then pointing to the existing sections which were focussed on reconciling specific account types. It makes sense to me to store the last reconciliation date and the ending balance at that date in the account data then by comparison with calculations of the starting balance on the fly, there would be a good mechanism for detecting any altered transaction splits invalidating a previous reconciliation and alert the user. Even more useful perhaps than just the last reconciliation date and end balance would be a complete reconciliation history for each account but that introduces alot more complications for forward/backward compatability but it would improve the ability to verify account integrity and to locate when a change affecting the account integrity was introduced. By "fix" in this context are you referring to the exclusion of the future reconciliation dates from the starting balance sums or a manual or auto fix to the future reconciliation dates themselves. I am still trying to work out if an autofix is possible for the future reconciliation dates case. It may be possible from the transaction dates posted and dates entered for splits which have a future reconciliation date to identify a potentially valid reconciliation date if you were also able to construct a list of all reconciliation dates used by the account which was what i did manually i.e. suggest the earliest and latest reconciliation dates a user could choose to be consistent with the rest of the account data. The same approach may also be the basis of an internal check on the stored reconciliation data validity. David ----- David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel