Thanks for this.
So it looks like I'm doing it the most mechanically efficient way I can. Good 
to know.
I'm not well organised with it though.  I haphazardly reconcile and update 
transactions at the moment. While I am learning.  And going about setting up 
this second set of books for the business.
p.s. I did learn the Bayesian matching was causing problems with my transaction 
imports to gnu cash.  Since switching that off they're trouble free.

Good to have your help,  thankyou.
:)
ab
 

    On Monday 20 January 2025 at 09:53:40 am ACDT, David Cousens 
<davidcousen...@gmail.com> wrote:  
 
 Arthur,
If your bank has OFX/QFX export of the transactions this is usually the most 
reliable way of importing bank records into GnuCash as it is a fairly well 
defined standard protocol.  CSV often takes a bit of work to do it relaibly as 
the protocol is less strictly defined.
I used to diligently enter transactions from receipts while I was running a 
business but now that I am retired and  I no longer have a check book and I get 
most receipts from most stores by email or sms in any case and most EFTPOSand 
credit card transactions appear in my account almost immediately, there was 
little advantage for me in doing this, so I just import the Bank records 
periodically and like Ken keep a close eye out for any unexpected changes in 
the account balances at the bank
You may want to do reconciliations more frequently while getting up to speed on 
using Gnucash. Most banks issue statements monthly so there is little point in 
doing them more frequently than that. My bank has a facility to provide me with 
a statement at a specific date (for which they charge me extra) beyond the 
monthly cycle, but I would only use that where I have detected a discrepancy 
and i haven't had one for more than 5 years now.
Whether you can use the aqbanking DirectConnectOFX interface will depend upon 
on whether your bank makes that interface available.  Most banks in Australia 
don't for example  ( they place stricter security requirements for software to 
have direct connections which open source software generally cannot meet) but I 
gather many US and European banks do.
GnuCash has a lot of features to help improve the import of data mainly in 
matching imported transactions to existing transactions and automatically 
assigning the correct transfer account to the second entry of imported 
transactions. This is a statistical Bayesian matching and is  "trained" by the 
account assignments you make in the import matching window of the import 
process. The training only occurs if you assign the accounts in this process 
and then complete the import and does not reflect any changes to the account 
assignments made after completion of the import process.  Once this is trained 
and working well, the import process is generally a lot quicker.  I might have 
to manually assign 6-8 transactions a month on import (usually out of ~100 
transactions imported) although it does pay to check that the import matcher 
has assigned the correct account to each transactions Allowing it to import to 
an incorrect account trains it to do the wrong thing.
You currently are replying only to my direct email and not to the mailing list 
"gnucash-user@gnucash.org". If there is no "reply all,"or "reply to list" in 
the yahoo mail client ( it may be there but hidden),  just add that email 
address to the "To" line in your reply. I have forwarded your email which came 
directly to me to the list.
David Cousens
On Sun, 2025-01-19 at 22:32 +0000, arthur brogard wrote:
Thank you for that.

Very pertinent and important observations you make.
At this early stage of my involvement with gnu cash I'm still unsure if my 
usage of it is optimal: am I doing things the easiest/best way?
The 'mechanics' of it, you might say.
Seems to me I do a lot of work just to get my transactions out of the bank and 
into gnu cash and reconcile.
Seems to me I've heard of direct bank to gnu cash connection perhaps?
Or even without that it could well be that I'm doing things a wrong way round 
and I'd love to know if so.
:)
ab
p.s.  am I doing this right?  I'm just using 'reply' on my Yahoo mail client. I 
don't see where I can do the suggested 'reply list' or 'reply all'


    On Monday 20 January 2025 at 08:33:43 am ACDT, David Cousens 
<davidcousen...@gmail.com> wrote:  
 
 
There is no best reconciliation strategy. An appropriate strategy
depends on exactly what you are using GnuCash for. 

A business with a high number of transactions will have a need for
relatively frequent reconciliation to detect errors, uncashed checks,
etc. and to satisfy any internal and external reportingand audit 
requirements. In the case of  personal finances, the frequency of
reconciliation required likely depends on the complexity of your
personal finances. 

Like Ken most of my transactions are cashless these days, and being
retired a lot fewer than they were when I was working and running a
business. Then monthly reconciliations proved to be both necessary and
useful. Now I reconcile usually quarterly or even semi-annually. Like
Ken I check my accounts usually on a daily basis for major
discrepancies in the balances and  for the automatically direct debited
transactions that some websites sign you up for on the pretence of
paying for a one-off (I do try to avoid them) and obvious bank errors,
but my bank has a pretty good error rate (haven't found one in the past
5 years).  One factor that may influence  timing would be a bank's
policies with regard to how long you may have to dispute errors and
relevant regulatory legislation that constrains application of such
policies so it is worth checking up on what those policies may be.

On updating I prefer to stay up to date with the latest version of
GnuCash. Most Linux distributions are often well behind the most recent
version. If you lag behind, particularly across the major version
boundaries updating can become a little bit more complex. There are
very rarely any major problems with the core functionality of Gnucash
in updates. The developers have done a very good job of making updates
as painless as possible with procedures to update data files built into
the update where necessary changes are made to the data file
structure. 

I build GnuCash from the stable source tarballs on release. I did a
little bit of minor work on some code areas in the past so building
from scratch does not faze me but some users may find it more daunting,
mainly in having all the necessary dependency versions and development
headers available.

David Cousens

On Sat, 2025-01-18 at 21:06 +0000, arthur brogard via gnucash-user
wrote:
> i just keep personal books for the family.
> my update and reconcile procedure works but is a bit tedious.  I
> can't think of any better way and I doubt there is one but i thought
> it might be good to ask.
> At sort of almost random times I decide to update the books.  So I
> download from CBA transactions from the bank accounts.
> then I put them in a spreadsheet.  in date order.
> then I inspect and compare with a transaction report from gnu cash -
> one for each account - and identify transactions not yet in gnu cash.
> delete all but those from the spreadsheet.
> sort on description.
> attach a fourth column for target account.
> import to gnu cash.
> that's the update
> balances should agree.  that's the reconcile.
> all that downloading, spreadsheeting, sorting blah, blah.....  any
> better way or that's just it?
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

  

  
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Reply via email to