Reconciliation window: closing balance distorted and reconciliation date

[Jannick Asmus]

Hi,

On 02.05.2008 12:35, Maf. King wrote:
> On Friday 02 May 2008, Jannick Asmus wrote:
>> Hi James,
>>
>> thanks for your input.
>>
>> On 02.05.2008 11:27, James Kerr wrote:
>>> On Friday 02 May 2008, Jannick Asmus wrote:
>>>> Hi,
>>>>
>>>> the following problems occur after opening the reconciliation window:
>>>>
>>>> 1. Closing balance inappropriate when reconciliation date is before date
>>>> of advanced transactions already reconciled:
>>> I always type in the closing balance from the bank statement. I think
>>> that's what you're supposed to do. There will often be a difference
>>> between the date transactions are recorded by the bank and the date you
>>> record them in gnucash.
>> That's correct with regard to the bank account. Here I get the current
>> balance with the online banking module. I think this is better. But
>> unfortunately this method does not apply to other accounts like tax
>> liabilities.
>>
>> So the problem is still open.
>>
> 
> Hi, 
> I'm not quite understanding what you are trying to do here.  
> I think that you are entering transactions in advance (because you know that 
> they are going to happen), 

... correct

> then you get a statement from the organisation 
> concerned (who don't assume anything about your future) which doesn't show 
> the future transactions?

I am afraid this is exactly not what I meant. I just copy the 
explanation from my original posting which might be clearer than the 
short headline of the following paragraph(s):

I have transactions in advance I manually enter (e.g., transfer from 
liability undue to liability due at some due date in the future). So the 
other party is me. Certainly I do reconcile these transactions as they 
are supposed to be frozen in GC.

When the reconciliation date is *before* the due date of the advanced 
booking _already reconciled_, then the closing balance includes it. This 
makes it impossible to reduce the difference to zero.

I can avoid this happening by choosing the reconciliation date after any 
due dates which is recorded in GC. This is not what I want it to do, 
since this date is somehow artificial to make GC letting me pass. I 
prefer the proper reconciliation date recorded.

The starting balance appears to be always correct.

> As I understand it (& IANAA) "Reconciling" is a process where two parties (eg. 
> you and your bank) communicate to agree what transactions _have_ happened, 
> and thus, what the balance owing on a set date is.
> 
> How can you reconcile a txn, until you have a "statement" from the other 
> party? Could you expand a little on what you are trying to do?

I am not a specialist at accounting, either. :-)

The thing is that there are liabilities for undue payments (I think this 
can be called reserve) which become due at date D2 in the future. At 
date D1 before D2 the status of the liability is changed to 'due' with 
due date D2.

D2 is the transaction date entered at D1 *and* reconciled at D1, since 
otherwise I will have to reopen the case at D2. For reasons of process 
optimization I would like to streamline my process for this and do all 
the bookings at D1.

>>>> 2. The default date is not the current date - _sometimes_. Does GC store
>>>> the date when it was manually changed? If so how can GC "forget" this
>>>> information?
>>> In my experience it assumes that the statement date is one month on from
>>> the date of the last statement. (This will not always be the case,
>>> depending on how your bank deals with weekends and holidays etc.) It only
>>> uses the current date if the next "due" date is later than the current
>>> date.
> 
> I think that GC uses slightly more intelligence than (last_date+1_month).  
> IIRC, the new statement date is calculated using the time gap between the 
> last two statements - ie something like:
> last_date + (last_date-previous_date).  I'm sure that if I have this wrong, a 
> dev will point it out!
> 
>> Hmm, I am not sure whether my GC behaves like this. It seems that for
>> some accounts there is a reconciliation date stored which is independent
>> of any other date like the current date.
>>
> I see what you mean, in that the default date generally works for my monthly 
> bank/credit card statements, but certain accounts where I only get annual 
> statements often show the wrong date.  So far, I've just lived with it as a 
> minor inconvenience which happens a couple of times a year.

I do my transactions weekly or rather every 3 days since I have a real 
bunch of transactions on different accounts. And this includes VAT (in 
Germany called "Umsatzsteuer" I am obliged to pay monthly with one month 
delay - here you see where my problem above comes from), payments, 
invoices and so on. The number of transactions per month is about 200 to 
300.

> HTH,
> Maf.

Thanks for your information.

Best wishes,
J.