[GNC-dev] About 3.9 and reconciliation balances

[David Cousens]

David T, Christopher, Dale et al


In accounting terms a reconciliation is always a confirmation of the details
of the splits to an account against some external record independent of the
particular set of books records are kept in. This is generally done in a set
of contiguous periods over which that external record is available. A
statement like a bank statement which is issued periodically is the most
common example and probably the most systematic. 

(I have in the past had to reconcile a statement from a supplier of credit
dealings against A/P and Payments for example and many similar processes for
a business a process not necesarily as easily automated or defined as
against an account but I don't think reconciliation in this wider sense is
what we are dealing with here.)

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.  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.

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.

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>*.

This would obviously need additional data structures, data file
modifications, ie not short term.

If we are going to try and verify the integrity of the account and
reconciliation process we need to to 



> Looking this over, it seems to me that your goals could only be achieved
> by adding a statement date data element to each transaction, which would
> tie that transaction to a specific statement. 

David the problem with this is that reconciliation (and its parameters like
reconciliation date and status) are the  property of a particular group of
splits to a particular account so any data elements that record whether a
record is reconciled or not and to what statement period it is reconciled
properly belong with the split where they are now. If one is recording the
end date of the last reconciliation period and any associated balances which
pertain to the whole group, these really should be properties of the account
that was reconciled rather than a transaction which has links to two or more
accounts and can be independently reconciled in each of those accounts.

David Cousens



-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html