Reconciliation window: closing balance distorted and reconciliation date

Maf. King maf at chilwell.net
Fri May 2 07:41:02 EDT 2008


On Friday 02 May 2008, you wrote:

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



Hi,

Oh, I understand now.

If you try to reconcile an account today, but you already have a transaction 
for next week reconciled, then the (default/register balance) "ending 
balance" and the "reconciled balance" can't be made to agree. (diff <> 0.00)

I suggest that you will have to manually over-ride the ending balance when you 
start the reconcile, or adjust it using Reconcile-> Reconcile Information 
once you know what the discrepancy is.

There is a "bug" (deviation from user expectation) in how the reconcile dialog 
ending balance figure is auto-filled when you start the process.

Does Umsatzsteuer work in the same way as UK VAT - you charge some % on every 
invoice you write, the total of which should be paid to the government at 
some date in the future - but before you make that payment, you deduct the 
taxes you have paid with your purchases during the same period?

I don't reconcile my liability:VAT accounts, so I haven't hit your situation, 
although I think I understand where it comes from now.  

Regards,
Maf.


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


More information about the gnucash-user mailing list