[GNC-dev] About 3.9 and reconciliation balances

[Geert Janssens]

Thanks for this overview. It matches mostly with how I understand reconciliation.

I will add a few comments in between.

Op zondag 12 april 2020 07:14:22 CEST schreef David Cousens:
> I don't see any problem with the reconcile status at present as implemented
> in the QIF, OFX imports or even the AQbanking import of transactions and
> balances, provided the bank accepts that record is a statement of the
> account on their part. With AQbanking and OFX directconnect import of
> records, the process.

I don't understand this sentence.

> If the process of querying the bank server for
> records can provide a starting balance at the end of any past downloads of
> data, the transaction split details for the account and relevant details and
> the bank's record of the ending  balance at the end of that group of
> transaction splits then it should be in principle be reconciled using an
> instance of the current procedure where the date entered for the
> transaction = reconcilation date of the split = end date of the
> statement=date at which reconciliation was carried out.
> 
I don't understand this either.

As far as I understand the statement date should not necessarily be the transaction date. A 
statement can have transactions spanning several days.

> In the more general case there are multiple relevant properties and dates
> associated with a reconciliation cuirrently recorded:
> *date entered* -  a transaction property
> *date posted*  - also a transaction property
> *reconciliation status* split property ["n","c","y" ]  only the "y"
> indicates reconciliation. being cleared is different from being reconciled.
> *reconciliation date* - split property - currently set by the reconciliation
> process to the end date of the statement as the date to which that split is
> reconciled AFAIK.

Apparently not all of our importers do that, only manual reconciliation does.

> 
> and some which are currently not recorded AFAIK but could be useful if
> maintained in a reconciliation history for the account as a list:
> *date of reconciliation* - date at which a reconciliation was carried out
> -limited use but may be of some use in tracking down errors
> *statement start date*
> *starting balance>*
> *statement end date>*.

I agree this is useful extra information and also what Christopher Lam has been playing with.

>From an implementation point of view I'd structure this slightly differently:
1. instead of adding an account property with a list of reconciliation history, I would introduce a 
new object, like a "statement" This object would have the fields you mention before (date of 
reconciliation, statement start date, statement starting balance, statement end date) and some 
more:
*statement id* - most bank statements has a unique number which may be helpful to track
*statement ending balance* - particularly useful to verify manual transaction entries. If you 
explicitly enter a start and ending balance in addition to the transactions themselves, amount 
typos will be caught by the numbers no longer adding up.
*account" - the account this statement refers to.

Lastly each split should get an additional field "statement id" referring to the statement which 
includes it. The split "reconciliation date" field would no longer be necessary. That info is 
encapsulated in the associated statement.

This mapping would be much closer to the real world order of things:
* during reconciliation a split is matched to a line on a statement
* each split can be linked to only one statement
* in case of reconciliation trouble in the past, the extra statement details make it easier to dig 
up the related external source (there's a statement id in addition to a reconciliation date).
* it is more clear which splits were reconciled together - they are tied to the same statement, 
where in the past there was only a reconciliation date, which may have been wrong for various 
reasons.

Regards,

Geert