Reconciliation [Proposed Change]

[Keith A. Milner]

On Tuesday 11 September 2007 13:28:34 lingwitt at bellsouth.net wrote:
> On 11 Sep 2007, at 8:05:23 AM, Derek Atkins wrote:
> > Gnucash doesn't store any balances.  It computes all balances on the
> > fly.  So there's no easy way to store an intermediary balance-as-of
> > date for many many dates.
>
> Can't you just scan a selection of transactions and calculate the total
> change?

This won't work on it's own. When (on the current system) Gnucash computes the 
statement balance, it is very likely to be wrong (in my experience, almost 
always).

This is because the transaction data as entered into Gnucash and the actual 
transaction date on the statement are often very different. This can be for a 
variety of reasons, including the payee not banking the transaction 
immediately, cheque clearing house delay, or the artificial few days delay 
the banks insert between debiting one account and crediting the other (c'mon, 
it's 2007. Noone believe this is for anything except the bank extracting 
additional interest benefits).

The upshot is the transaction date can never be relied on to produce an 
accurate statement balance.

Currently Gnucash allows for this by alloowing you to overide it's computed 
balance with that on the statement. Note that this override is temporary and 
purely for the duration of the reconciliation "session". If you postpone the 
reconcilation part-way through, you need to re-enter it when you come back to 
the reconciliation.

If you then have two dates to consider (start and end dates) then the you have 
two balances (start and end balances) and they need to be corrected before 
reconciliation can take place. Currently the start balance for reconcilation 
is computed from the last reconciled date. This is accurate and cannot be 
changed. This is part of the reconcilation cross-check.

Now, it's entirely possible that you could allow arbitrary statements to be 
reconciled out of order, but this would require that the statement dates and 
start/end balances must be entered. I'm guessing it would be a significant 
piece of work to put this in place. It would also mean that it would be 
possibe to have "holes" in the reconciliation if you enter one of these 
values incorrectly.

There's also a massive danger that having such a facility would break the 
currently immutable cross-check of the starting balance needing to equal the 
closing balance of the previous statement. This is a massively useful 
facility and I, for one, would not be happy losing it to provide for (as 
Derek refers to it) a "corner case".

I'm sure if you want to code this and submit a patch to demonstrate how 
seamless and useful this is I'm sure we would all be interested.

Alternatively, change your bank, or report them to the local financial 
authority or banking ombudsman as they may be breaking some code-of-conduct 
or even the law by not providing proper statements.

Cheers,

-- 
Keith A. Milner
mailto:kamilner at superlative.org