Bank account balance incorrect after import from Quicken

Wed Sep 2 13:39:49 EDT 2015

Here's my guess at an explanation of what happened: the importer was
confused because there was no Equity:Opening Balances account, so created
an opening balance but placed the other leg of the opening balance in the
same account as the opening balance. One leg was reconciled but the other
leg was not because you were then expected to manually adjust the account.
I'm just guessing, but it should be easy enough to confirm by checking the
source code.

Probably that behaviour would be seen very seldom because most people start
with standard account trees which include Equity:Opening Balances, and
probably in most other cases the opening balance would be 0 which would
import fine even without Equity:Opening Balances.

On 2 September 2015 at 06:29, Tom Allred <tallred7 at triad.rr.com> wrote:

> David,
>
> Thanks for the reply.  I'm hoping that gnucash will be a suitable
> replacement for quicken which has served me well for 20 years.  Yes, it's
> been a little frustrating so far.  It's nice that folks have offered
> suggestions but the focus seems to be my lack of understanding of
> accounting
> or some error I made during import.  The only thing that's confusing me is
> why an accounting program would arbitrarily create an erroneous
> transaction.
> Magical transactions don't seem fundamentally sound.  People seem to assume
> that gnucash can't make errors so it must be me.  I couldn't have entered
> an
> incorrect balance during import because there are no questions like that
> during the import process.  It's actually very nice that the import process
> is so automated.  Just not comforting that the process is sticking in
> transactions that don't exist in my quicken data that causes errors.  I
> guess it must be that people aren't really familiar with the import
> process.
> Perhaps my posts in this thread will serve as the write-up of my experience
> since I think I've already detailed it as well as I can. If I discover
> other
> flaws from the import then I'll add to the thread.
>
> Fingers crossed,
> Tom
>
> -----Original Message-----
> From: David T. [mailto:sunfish62 at yahoo.com]
> Sent: Tuesday, September 01, 2015 11:47 PM
> To: tallred7 at triad.rr.com
> Cc: edodd at billiau.net; gnucash-user at gnucash.org
> Subject: Re: Bank account balance incorrect after import from Quicken
>
> Tom,
>
> I suspect that what happened was that when you imported your Quicken file,
> you were asked what your opening balance was, and you told GnuCash the
> amount. GnuCash then created an Opening Balance transaction to account for
> the existence of your money. Since your Quicken file already had an opening
> transaction, however, this caused a duplication. Instead, you should have
> simply skipped having GnuCash account for your opening balance, since you
> had already done so.
>
> I believe that deleting the transaction (as you describe) is perfectly
> fine.
>
> Once you have determined that the balances are accurate, you should most
> likely focus your attention on determining that GnuCash has used accounts
> for your transactions that make sense for your accounting situation. Many
> find that the import causes transactions to be categorized in unexpected
> ways. These are easy enough to fix, but it is helpful to look for them.
>
> As an aside, Quicken is less strict in its accounting implementation, and
> will allow transactions to be one-sided. GnuCash requires every transaction
> to have at least two splits. I used Quicken for 15 years before
> transitioning to GnuCash 10 years ago, and dimly remember having to clean
> up
> a bit.
>
> Also, since GnuCash is a volunteer effort, some areas (like documentation)
> are not as well maintained as others. As a user, I have attempted to help
> out with the documentation, and I can understand the frustration at holes
> such as this. Since you seem to be quite engaged in this, I would humbly
> ask
> you if you could write up your experience of the overall import process;
> there is currently a drive to document the import procedures better, and
> having a first-hand write up would be excellent.
>
> Cheers,
> David
>
> > On Sep 1, 2015, at 11:15 PM, Tom Allred <tallred7 at triad.rr.com> wrote:
> >
> > David,
> >
> > I haven't been using this mailing list long enough to know how easy it
> > is to look back at a thread but there are more details in the previous
> > posts.  One of the problems of using a list instead of a forum...  I
> > appreciate your willingness to help.  First, I'm not a newbie to
> > accounting.  I've taken a couple of accounting courses in the past,
> > ran my own business for a long time, and have been using quicken for
> > 20 years.  Yes, quicken uses "categories" instead of "accounts" but
> > you still have to have at least two sides in a transaction.  I have
> > read the gnucash manual through chapter 3 plus other sections that
> > seemed like they may be pertinent, including the parts on importing
> > quicken QIF files which, BTW, has 3 blank pages where some QIF topics are
> supposed to be.
> >
> > Yes, the closing balance in gnucash doesn't match quicken.  The
> > problem is the "magic" transaction gnucash created during import that
> > offset the opening balance entry in the account in 1995.  There is my
> > original transaction opening the account with a deposit, and the
> > "magic" transaction reversing it with a withdrawal on the same date.
> > Both entries are exactly alike except one is a deposit and one is a
> > withdrawal.  If I delete the withdrawal then I have the correct
> > current balance.  When Geert replied to my original post he said the
> > account an opening balance entry is normally applied against is
> > "Equity:Opening Balances" which didn't exist in my account list after
> > creating the database by importing the QIF file.  Today's post was
> > explaining what I had discovered since our previous exchange.  My plan
> > at this point is to delete the "magic" transaction, which has a
> > Reconciled flag of "n", and continue looking for other inconsistencies
> > between gnucash and quicken.  If it doesn't matter that gnucash used
> > the Retained Earnings account instead of Opening Balances for the
> > opening balance entries in other accounts then I'll just leave them alone
> and carry on.
> >
> > Thanks,
> > Tom
> >
> > -----Original Message-----
> > From: David T. [mailto:sunfish62 at yahoo.com]
> > Sent: Tuesday, September 01, 2015 10:20 PM
> > To: tallred7 at triad.rr.com
> > Cc: edodd at billiau.net; gnucash-user at gnucash.org
> > Subject: Re: Bank account balance incorrect after import from Quicken
> >
> > Tom,
> >
> > Whether GnuCash uses "Equity:Retained Earnings", "Equity:Opening
> > Balances", or even "Equity:What The Heck!" is immaterial. What matters
> > is the amount that gets put into the checking account in this
> > transaction. If this amount is not correct, then we have to examine
> > what number GnuCash used for the opening transaction, and why it is being
> added.
> >
> > Also, can you explain a little more fully how you are determining that
> > the balance has been thrown off? Is it because the closing balances don't
> match?
> > Or that you ran a reconciliation and the numbers didn't match?
> >
> > Please also go back and read chapter 2 in the GnuCash Guide on
> > Accounting Basics-especially section 2.1.3 on double entry accounting.
> > It clearly explains *why* GnuCash creates what you are calling an
> > "offsetting transaction"-and it may help you to understand what is going
> on.
> >
> > David
> >
>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> 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.
>

-- 
Edward Doolittle
Associate Professor of Mathematics
First Nations University of Canada
1 First Nations Way, Regina SK S4S 7K2

« Toutes les fois que je donne une place vacante, je fais cent mécontents
et un ingrat. »
-- Louis XIV, dans Voltaire, Le Siècle de Louis XIV, Chap. XXVI