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