gnucash-user Digest, Vol 165, Issue 23

John Angelico talldad at kepl.com.au
Mon Dec 12 17:00:59 EST 2016


On 13/12/16 04:00, gnucash-user-request at gnucash.org wrote:
> It sounds like you're not missing anything important...yet. The
> reconciliation process shows its value most when there are a relatively
> large amount of items to reconcile. I only reconcile when I get a
> statement, so there may be 80 transactions in a month. If none of my
> historical balances match the final balance from the statement (because a
> transaction that hasn't hit the statement is before one that has), the only
> reasonable way to proceed is the reconciliation process: match transactions
> on the statement to those in the books and deal with extras in both places.
> In fact, if there is such an ordering fiasco (cheques that don't get cashed
> quickly constantly present this problem), it may be that*none*  of my
> historical balances match any daily balances on the statement! The only way
> all the balances would match is if I recorded the transactions in the same
> order they were carried out -- which means cheques were cashed in the same
> order in which they were written.
> 
> Anyway, if you keep your accounts in line with what the bank says daily,
> and you change the dates on your cheques to match the date they were
> withdrawn (rather than the date you wrote the cheques), AND, you never get
> behind(!!) then everything will be fine. This is effectively daily
> hyper-reconciliation, and since the amount of transactions involved is
> small, it's easy enough to do "by eye". I say "hyper" because you're making
> sure your transactions are mirroring what the bank says with no date
> discrepancies while with normal reconciliation, the dates may reflect some
> processing or handling time.
> 
> If you get behind, though, don't call me about the ensuing fiasco;-)
> 
> 
> ------------------------------
Lurker-level accountant weighing in here...

The underlying assumption behind this answer is that you can 
*absolutely, always* trust the accuracy of your bank's processing and 
the timing of their statement delivery to you. :-)

The primary function of any accounting system is to record as accurately 
as possible the financial aspect of your (or your business's) real-life 
actions.

That usually means you will be defining the dates of your transactions 
rather than your bank.

If you are a salaried/wage person, you will receive a pay-slip 
representing work done in the past. But despite best efforts, there is 
no guarantee that the net pay will arrive and be visible in your bank 
account precisely on the same day as you receive the pay-slip. You 
record your pay (gross less tax and deductions if you wish) as at a date 
that you choose, not when the bank chooses.

Then you can keep tabs on how well the bank serves you by having your 
pay available to meet your living expenses.

The process of keeping tabs includes comparing transactions which you 
have recorded with the transactions the bank has recorded.

HTH
John A
Melbourne
Australia


More information about the gnucash-user mailing list