Reconciliation window: closing balance distorted and reconciliation date

Tue May 6 10:03:15 EDT 2008

Jannick Asmus <jannick.news at gmail.com> writes:

> On 05.05.2008 18:04, Derek Atkins wrote:
>> Jannick Asmus <jannick.news at gmail.com> writes:
>>
>>>> What puzzles me is why you reconcile a transaction before it has
>>>> even occurred.
>>> This is because of transactions becoming due today with due date in
>>> the future. I described it in a previous email within this thread.
>>>
>>> For my purposes the process of reconciliation is rather a closing
>>> of transactions because they are logically consistent with all
>>> other transactions and information from outside and can, thus, be
>>> frozen'.
>>
>> That's not reconciliation. That's "clearing".
>
> Call it clearing or reconciliation. This is just a question of definition.

Actually, no, it's NOT just a question of definition.  It really
implies different states of the transaction.

Cleared means "I know that the 'financial institution' has processed
this transaction so the money has actually moved into (or out of) this
account".

Reconciled means "I have reviewed this account and compared it to a
periodic statement from my financial institution and this transaction
was listed on the statement"

Also, the processes are different.  You "clear" a transaction in
the register.  To RECONCILE you need to run through the reconciliation
process which includes a reconciliation date and ending balance.

GnuCash also keeps the Cleared Balance and Reconciled Balance, so you
can see the differences.

> What is needed for a proper accounting is that transactions are "frozen"
> such that they cannot be (easily) changed any more. I use the
> reconciliation feature for this. Since it is not restricted to accounts
> which should only be reconciled according to your definition, it can
> be used for other purposes, too. And I hope it will remain like that.

AH!  See, GnuCash does not have that functionality.  Period.

Even a reconciled transaction can later be changed (although it will
become unreconciled).  GnuCash MAY warn you about it, but it will let
you go ahead anyways.  However the user can disable that warning dialog
with a simple checkbox thereby removing any "freezing benefit" you
may think you have.

> This feature to freeze transactions is one of the biggest issues here in
> Germany why GnuCash might not get as popular as it could be, since
> German tax authorities do not accept it most likely due to the lack of
> "freezing" transactions. Everybody interested in this might visit a
> long, but informative thread on this in the German mailing list over
> the last months.

Unfortunately there's nothing on the German list that would ever be
"informative" to me, as I don't know German so I'd be completely lost.
I'd maybe understand one in five words at best.

There are many ways to "freeze" data in GnuCash.  The best way is
to write it to a CD-ROM.  :)

>> From the register
>> click in the 'R' column and it will change from 'n' to 'c'.  (Or
>> at least those are the terms in English).
>
> Yes, I know. I guess 'n' stands for no, 'c' for confirmed and - I
> suppose - 'y' for yes or reconciled.

Correct.  (This is all in the documentation)

>> You should NEVER "reconcile" a transaction in the future, because
>> you should ONLY reconcile against a printed statement from your
>> bank.
>
> Thanks for the hint, but the question I have brought up is rather
> about "freezing transactions" in GnuCash. This applies to all
> transactions involving P&L and balance accounts and I hope that the
> feature will not be restricted to assets such as bank accounts and,
> e.g., receivables.

There is no such thing as "freezing" transactions currently.
Actually, that's not completely true.  There is a "make txn readonly"
API, but there's no UI method to apply that that a transaction (or set
of transactions).

> BTW: What about a bank account statement printed between the
> transaction and the value date? Waiting till after the value date? ;)

I don't completely understand what you mean by "transaction and value
date".  I think I MIGHT understand....   Could you explain if my
example here doesn't apply?

There are multiple dates involved in transactions.  There's the
date you "commit" the transaction, the date you enter it into
gnucash, and the date the institution processes it.  In some cases
there's another date which is the date the OTHER institution
processes it.

As an example look at the process of writing a check from my Bank to,
say, pay off a Credit Card.  I write the check on May 1 (and happen to
enter it into GnuCash on May 1, but that doesn't have to be the case).
So the GnuCash transaction "Post Date" is May 1.

The Credit Card company receives the check on May 3 and starts
processing it.   My Bank removes the funds from my account on
May 4 (the "cleared date"), and the Credit Card company actually
posts it to my account on May 5 (the OTHER institution cleared date).

The on May 15th the Bank creates their statement, which you receive on
May 21st.

So, how to enter this in GnuCash?

Well, first, you enter the check transaction with a date of May 1st.
That's because you've promised the funds as of May 1st.  You want
to make sure you don't promise more funds than you have.  This way
you know your projected balance in the account which is all the promised
funds in and out, cleared or not.

Let's also assume you can get your transaction history online.  So on
May 7th you login to the bank website and see that your check has
cleared.  At this point you can change the reconciled flag from
"no" to "cleared".  This adjusts your Cleared Balance which tells
you (if you're good about clearing), the ACTUAL balance on any day.
Your Cleared Balance should match what your bank says online as your
balance at any time.

Then on the 21st you receive your statement.  You reconcile your
account vs. your statement and the check is there.

Now, if the check was written on the 10th and didn't clear until
the 17th, it would NOT be on the statement on the 15th..  So
you would NOT reconcile it when you receive your statement on the
21st.  Instead you could clear it, but you wouldn't reconcile it
until the next month.

>>> If a second party is involved in the transaction providing a
>>> balance amount to date, the process of reconciliation includes
>>> comparing the balances on each side (information from outside). If
>>> there is no balance of the second party involved available, there
>>> is no other way to check the double-entry accounting by the
>>> extended understanding of the technique of reconciliation. For
>>> in-house transactions (e.g. transfers between liabilities - cf. the
>>> correspondence with Maf.) reconciliation means freezing the account
>>> after a check of consistency.
>>
>> Your liabilities don't provide you periodic statements of activity?
>
> What do you mean - liabilities with contractual rights? Or those
> contingent upon certain specified events? Or are you talking about
> (deferred) tax liabilities? ...

Yes.

I mean a Loan, a Credit Card, or even tax liabilities.  They all
provide some statement (although I suppose in the last case the
statement would be when you file your taxes).

>>> I have real big number of transactions each week and I am really
>>> keen on   closing the accounting cases in GC, since keeping
>>> transactions open can lead to unintentional changes and is time
>>> consuming twice.
>>>
>>> I hope this could make my point of view a bit clearer. :-)
>>
>> It does, but you're still wrong.  ;-)
>
> Thanks one more time. ;) ... according to your definition one could
> agree that you will be right. But the question is not about sticking
> to a more or less formal definition of reconciliation, but to have a
> software tool fulfilling requirements of users or/and local
> authorities. I am afraid to say that I do doubt that GnuCash gains
> significantly more popularity here in Germany, if it does not face up
> to issues like that. Of course I cannot say anything about other
> countries with respect to this issue.

That's fine..  But GnuCash just doesn't do what you want right now,
and the fact that you're trying to shoehorn what gnucash DOES do
is just causing you pain..  So I'd ask that you NOT complain about
the fact that you cannot shoehorn the existing functionality into
your needs, but instead let's focus on your needs and what new
functionality is required to meet those needs.

Reconciliation is NOT the answer for you.

>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>>
>> -derek
>
> J.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available