403b loan

David dgpickett at aol.com
Tue Feb 11 14:26:52 EST 2014


I am not an accounting guru, but if the pending potential liability is something you want to show on the books, you could make a future dated account payable against OP for the unpaid balance.  As it is paid, you need to reduce the liability and perhaps adjust the date of 'loan terms violated'.  However, every time I post my salary, I do not want to have to post a tax estimate to show there is that account payable liability.  I do no post future late fees on my mortgage, although mail service has been so bad I have occasionally been punished unfairly that way.  The future is full of possible liabilities, and I suppose one could write an app to quantify them and assign them probabilities, more in the land of insurance.

 

 

 

-----Original Message-----
From: gnucash-user-request <gnucash-user-request at gnucash.org>
To: gnucash-user <gnucash-user at gnucash.org>
Sent: Tue, Feb 11, 2014 12:01 pm
Subject: gnucash-user Digest, Vol 131, Issue 25


Send gnucash-user mailing list submissions to
	gnucash-user at gnucash.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.gnucash.org/mailman/listinfo/gnucash-user
or, via email, send a message with subject or body 'help' to
	gnucash-user-request at gnucash.org

You can reach the person managing the list at
	gnucash-user-owner at gnucash.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gnucash-user digest..."

 
Today's Topics:

   1. Re: Python bindings on Mac OS 10.9 (John Ralls)
   2. Re: 403b loan (Christopher Singley)
   3. Opening Balances (Brenda Reed)
   4. Re: Opening Balances (Michael Hendry)

 
	
Attached Message
	
		
			
From:
			
John Ralls <jralls at ceridwen.us>
		
		
			
To:
			
R. Victor Klassen <rvklassen at gmail.com>
		
		
			
Cc:
			
GNU Cash User <gnucash-user at gnucash.org>
		
		
			
Subject:
			
Re: Python bindings on Mac OS 10.9
		
		
			
Date:
			
Tue, 11 Feb 2014 07:41:11 -0800
		
	



On Feb 11, 2014, at 5:49 AM, R. Victor Klassen <rvklassen at gmail.com> wrote:

> I re-ran jhbuild bootstrap.  
> 
> I did happen to notice a series of errors go by:
> 
> make install DESTDIR=/Users/victor/gnucash-stable/_jhbuild/root-gtk-osx-docbook
> ./install.sh
> sed: RE error: illegal byte sequence
> sed: RE error: illegal byte sequence
> sed: RE error: illegal byte sequence
> sed: RE error: illegal byte sequence
> 
> I’m guessing these don’t matter, as it appears to be related to documentation.
> 
> After re-bootstrapping, I got a re-tried the ‘which xzcat’ from within jhbuild 
shell.
> 
> /Users/victor/gnucash-stable/bin/xzcat
> 
> So I tried a fresh jhbuild build, which semi-failed at osx-docbook - which, 
again, I guessed was not a problem so I selected option
> 2? (ignore and continue).
> 
> Numerous errors occurred when it attempted to build libgcrypt.  All of them 
being 
> mpih-div.c:104:6: error: invalid use of a cast in a inline asm context 
requiring an l-value: remove the cast or build with -fheinous-gnu-extensions
> 
> with various places from which the macro was expanded.  Don’t know whether to 
build with heinous gnu extensions (for that matter, I’m not sure how to).
> 
> Again, took option 2 - which caused it to generate very much the same errors 
for mpi, at the end of which it complained about an error during the install 
phase of libgcrypt.
> 
> Chose 3 - give up on module.
> 
> Several checkout phases failed on the first attempt.  On the second, they 
appeared to work.  
> 
> Later…
> 
> *** Checking out iso-codes *** [54/56]
> curl --continue-at - -L http://pkg-isocodes.alioth.debian.org/downloads/iso-codes-3.47.tar.xz 
-o /Users/victor/gtk/source/pkgs/iso-codes-3.47.tar.xz
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  
Current
>                                  Dload  Upload   Total   Spent    Left  Speed
> 100   325  100   325    0     0     82      0  0:00:03  0:00:03 --:--:--    82
> xzcat -d "/Users/victor/gtk/source/pkgs/iso-codes-3.47.tar.xz" | tar xf -
> xzcat: /Users/victor/gtk/source/pkgs/iso-codes-3.47.tar.xz: File format not 
recognized
> *** Error during phase checkout of iso-codes: could not unpack tarball 
(expected iso-codes-3.47 dir) *** [54/56]
> 
>   [1] Rerun phase checkout
>   [2] Ignore error and continue to configure
>   [3] Give up on module
>   [4] Start shell
>   [5] Reload configuration
>   [6] Go to phase "wipe directory and start over"
> choice: 1
> *** Checking out iso-codes *** [54/56]
> xzcat -d "/Users/victor/gtk/source/pkgs/iso-codes-3.47.tar.xz" | tar xf -
> xzcat: /Users/victor/gtk/source/pkgs/iso-codes-3.47.tar.xz: File format not 
recognized
> *** Error during phase checkout of iso-codes: could not unpack tarball 
(expected iso-codes-3.47 dir) *** [54/56]
> 
> At which point I chose [3].   It continued, and “finished” shortly thereafter, 
with
> 
> *** module gnucash not built due to non buildable aqbanking *** [56/56]
> *** module gnucash not built due to non buildable meta-gtk-osx-webkit *** 
[56/56]
> *** module gnucash not built due to non buildable iso-codes *** [56/56]
> *** the following modules were not built *** [56/56]
> libgcrypt gnutls gwenhywfar aqbanking glib-networking libgnome-keyring libsoup 
WebKit meta-gtk-osx-webkit iso-codes gnucash
> 
> Thoughts?

The problem with gtk-doc-utils is that it needs the libxml2 python extensions, 
and those require manual intervention at the moment, but that's for 
documentation so you can ignore it for the moment. I've been fiddling with it 
the last couple of days to try to automate it, but it's so far resisting.

For the heinous gnu extensions, add this to your .jhbuildrc-custom:
    append_autogenargs('libgcrypt', 'CFLAGS="$CFLAGS -fheinous-gnu-extensions"')

alioth.debian.org has been out of commission for  a while. I've uploaded the 
last iso-codes tarball that I've got to http://sourceforge.net/projects/gnucash/files/Dependencies/iso-codes-3.47.tar.xz/download, 
so get it from there and put it in your gtk downloads directory 
(~/gtk/sources/pkgs is the default location).

Regards,
John Ralls





 
 


 
	
Attached Message
	
		
			
From:
			
Christopher Singley <csingley at gmail.com>
		
		
			
To:
			
Mike and/or Penny Novack <stepbystepfarm at mtdata.com>
		
		
			
Cc:
			
clavenrn <clavenrn at onepost.net>; GnuCash Users List <gnucash-user at gnucash.org>
		
		
			
Subject:
			
Re: 403b loan
		
		
			
Date:
			
Tue, 11 Feb 2014 15:44:57 +0000
		
	


On Tue, Feb 11, 2014 at 3:10 PM, Mike or Penny Novack <
stepbystepfarm at mtdata.com> wrote:

>
>
>> OP said "loan" not "withdrawal", so I presume the plan administrator
>> agrees that the distributions qualify under the rules.  I repeat, there are
>> no tax consequences to qualifying 403(b) loans that are properly repaid.
>>  There are tax consequences to withdrawals.
>>
>>  Excuse me please, but the loan is always going to be a POTENTIAL
> withdrawal which is why it must be properly accounted for. You even
> included the proviso "that are properly repaid" but apparently do not
> recognize that as a future conditional event which may or may not take
> place. What happens if future events conspire that the loan cannot be
> repaid?
>
> Michael
>

If the loan can't be repaid, OP is going to get screwed by IRS.  He'll pay
taxes & penalties.  This can be fully accounted for by JEs booked in the
period when the screwing is administered - e.g. credit cash, debit tax
expense.  This is completely orthogonal to the accounting treatment
(especially on the balance sheet) during prior periods.  How would this
screwing be better accounted for by having previously maintained a
full-blown accounting of all the different tax buckets comprising his share
of the plan's assets and liabilities?  You're not going to need to
calculate your own penalties and interest; you'll get a nice letter from
IRS informing you of your obligations.  There's your backup, book your JE,
administer some moisturizer to relieve the chafing.  All done.

Look, defined contribution plans are less paternalistic than defined
benefit plans, but a major policy goal of sections 401 and 403 of the IRC
is that the burden for tax accounting should fall upon the plan
administrator, rather than requiring high school dropouts to maintain
scrupulous distinctions between pre- and post-tax contributions, deferred
wages and company profit-sharing contributions, basis and earnings.  While
these things are of importance to developers who write software for
financial institutions, there are very limited circumstances under which
plan participants actually need to gain an independent understanding of
these things, rather than relying upon information spoon-fed to them by the
plan administrator... and most of those circumstances are usually forbidden
by the plan trust documents, to make life easier for the sponsors &
administrators.

I personally would track the plan loan balance, because it matters to me...
most materially, because outstanding borrowings limit further borrowings
against plan assets, and sometimes having a tight reckoning of all my
sources of liquidity is an analysis I wish to perform.  But that certainly
isn't necessary - all that's really necessary is to track tax consequences,
and again, there really aren't any here.  Pretending the whole thing
doesn't exist (i.e. eliminating the asset/liability upon consolidation) is
certainly a valid accounting treatment, and it's exactly how the OP said he
thinks about the situation (i.e. shifting money from his left pocket to his
right pocket, which is the economic substance of this transaction).
"Natural" and "intuitive" are appealing features of any accounting system,
no?  Is there some important blocker to the KISS principle here?  Poor dude
just wants his books to balance in GnuCash, not do a deep dive on treasury
rules & regs.


 
 


 
	
Attached Message
	
		
			
From:
			
Brenda Reed <brendareed123 at gmail.com>
		
		
			
To:
			
gnucash-user at gnucash.org
		
		
			
Subject:
			
Opening Balances
		
		
			
Date:
			
Tue, 11 Feb 2014 08:08:53 -0800
		
	


I received payment against a bus invoice in 2014 but the inv was created in
2013 in the other software package I was using. I didn't account for it at
all in GnuCash that it was invoiced. What accounts should be used in
GnuCash and what are their assoc debits & credits? Thanks for your help.
PS, I'm using "cash basis" accounting.


 
 


 
	
Attached Message
	
		
			
From:
			
Michael Hendry <hendry.michael at gmail.com>
		
		
			
To:
			
Brenda Reed <brendareed123 at gmail.com>
		
		
			
Cc:
			
Gnucash Users <gnucash-user at gnucash.org>
		
		
			
Subject:
			
Re: Opening Balances
		
		
			
Date:
			
Tue, 11 Feb 2014 16:36:04 +0000
		
	


On 11 Feb 2014, at 16:08, Brenda Reed <brendareed123 at gmail.com> wrote:

> I received payment against a bus invoice in 2014 but the inv was created in
> 2013 in the other software package I was using. I didn't account for it at
> all in GnuCash that it was invoiced. What accounts should be used in
> GnuCash and what are their assoc debits & credits? Thanks for your help.
> PS, I'm using "cash basis" accounting.

Not an accountant, but…

Your previous accounting software would have held balances in various accounts 
at the end of the financial year, and when you started up GC you would have 
copied them in as Starting Balances (for example, your current (checking) and 
credit card accounts).

Presumably, there would be an Accounts Receivable account in your old software, 
and this too should have been entered as a starting balance in the corresponding 
account in GC.

Michael

> _______________________________________________
> 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.




 
 
_______________________________________________
gnucash-user mailing list
gnucash-user at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user

 


More information about the gnucash-user mailing list