Strangeness in Mortgage/Loan Repayment Druid

Perry Smith pedz at easesoftware.net
Thu Jul 3 00:15:18 CDT 2003


Yes, it is 78's not 77's.  Sorry

So, given a starting principle, interest rate, and number of payments,  
how do you calculate the payment you need to send in each month with  
"your" formula?


On Wednesday, Jul 2, 2003, at 21:56 US/Central, Matthew Vanecek wrote:

> Please do remember to CC gnucash-user with all replies.
>
> On Wed, 2003-07-02 at 07:52, Perry Smith wrote:
>> The world of finance  is often not logical.
>>
>> With car loans, often the "rule of 77's" is used to determine  
>> interest.
>>   This is based upon a sum of digits formula.  It basically causes  
>> more
>> interest to be paid off earlier than later.  Not all car loans do  
>> this.
>>   I've noticed a recent trend not to use this method but use a more
>> standard method.  The only time this really matters is when you want  
>> to
>> pay off your car  loan early and then you are hit with a surprise.
>>
>
> Don't you mean "rule of 78s"?  I've never heard of an auto loan that is
> set up that way.  Mine certainly isn't.  I had a choice of two, and  
> both
> were simple interest.  My last auto loan was simple interest, and I
> payed that one off early--the outstanding principal only.  If car
> dealers where you are are setting up those types of loans, you're
> getting seriously screwed.  Almost *nobody* except the odd  
> high-interest
> personal loan shop uses the "rule of 7whatever" anymore, and especially
> not in my part of the country.
>
>> This brings up the question of paying extra each month.  You need to
>> look at your note and see what happens.  As far as gnucash, there  
>> needs
>> to be a way to enter a generalize formula for such events.  Loans,  
>> done
>> complete and "right" are really really hard.  Quicken and Quickbooks
>> fail at this but it seems "doable" to me.
>>
>
> If you *are* stuck with paying on a "rule of 78s" loan, paying extra
> won't matter.  Key words to look for are "rebates if payed off early",
> etc.  However, for an auto or mortgage, I highly doubt you can find
> anything other than a simple interest loan.
>
>> Getting the monthly payment to match  a bank's idea of the payment is
>> often hard and wierd.  One way to do it that may work is fudge the
>> original principle up or down to make the monthly payment come out
>> right.  You can consider whatever amount you need to add in  to make
>> the monthly payment come out right as "points" or interest paid up
>> front.  Any amount you subtract out you would consider principle paid
>> up front.  Often the last payment is not the same as the monthly
>> payments as well.  This can be handled with a one time entry in the
>> same way.  This basic technique usually works for me in the
>> Quicken/Quickbooks style calculators and it accurately represents  
>> where
>> the money went to.
>>
>
> You got some weird banks.  I can calculate to the ha'penny what's
> interest and what's principal in each month's payment.  All you have to
> know is the compounding period (e.g., 5%/12, or 5%/360, or 5%/365,
> etc.).
>
> I *do* kindof wish my formula below (which is the same as the bank's
> formula) were part of Gnucash, instead of that pmt() function, or in
> addition to.  Put it in there as a simple interest calculation method,
> and allow for extra payments.  I ain't got time to code it myself, so
> I'll be happy with my spreadsheet, but anyone else is free to
> contribute, too...
>
>
>> On Tuesday, Jul 1, 2003, at 22:01 US/Central, Matthew Vanecek wrote:
>>
>>> On Tue, 2003-07-01 at 20:43, Josh Sled wrote:
>>>> On Tue, Jul 01, 2003 at 07:59:40PM -0400, Daniel Hannum wrote:
>>>>
>>>> | I have a number of questions about the mortgage/loan repayment
>>>> druid.
>>>> | BTW, I'm on 1.8.1 (redhat 9). So I this has been fixed, please let
>>>> me
>>>> | know. I'm not prepared to grapple with upgrading (yet)... it was
>>>> easier
>>>> | under Debian......
>>>>
>>>> I don't believe the Mortgage/Loan druid has seen any changes since
>>>> 1.8.0.
>>>>
>>>> | Now, when I put the principal, rate and term into Gnucash's druid,
>>>> it
>>>> | comes up with 374.13, but that's not good, because that's not what
>>>> I'm
>>>> | actually going to pay.
>>>>
>>>> 4 whole cents off?  Good enough for government work... ;)
>>>>
>>>
>>> Perhaps, but not for personal finance.  I resorted to an Open Office
>>> spreadsheet, and enter interest/principal from there.
>>>
>>>
>>>> If it's a constant 0.04, you could modify the formulae to
>>>> add/subtract that
>>>> out, but that's a nasty hack.  OTOH, it might solve your immediate
>>>> problem,
>>>> though I imagine that the rest of the calculations would be off, as
>>>> well. :(
>>>>
>>>> I had expected that the calculation would vary from most people's
>>>> actual
>>>> payments for various reasons ... this is a good example of this.
>>>> Sorry.
>>>>
>>>> | 1. How do I force a particular loan payment? On the page of the
>>>> Druid
>>>> | where you specify the 'Amount' and the accounts where the  
>>>> principal
>>>> and
>>>> | interest will be, I tried replacing the "pmt()" expression with
>>>> $374.09,
>>>> | but it seemed to ignore me; the next page still had 60 payments of
>>>> $374.13
>>>>
>>>> Hmm... that should actually work, IIRC.
>>>>
>>>> In playing with it, it does look like any changes made to the  
>>>> Payment
>>>> field are ignored, which is quite unfortunate.  Filing a bug at
>>>> bugzilla.gnome.org is appreciated.
>>>>
>>>> | 2. What does "pmt( 0.07900 / 12 : 60 : 18495.00 : 0 : 0 )" mean?
>>>> | Obviously, it's rate, term, principal, but what are the last 2
>>>> zeroes?
>>>> | Perhaps I shouldn't care. Or perhaps it could help to know.
>>>>
>>>> This one can be answered by looking in src/scm/fin.scm [I forget  
>>>> where
>>>> it's copied on install, but `locate fin.scm` should find it] -- the
>>>> last
>>>> two terms are the "future value" and "type", as defined by the
>>>> Gnumeric
>>>> 1.0.8 functions of the same name.  Future value could be non-zero,  
>>>> but
>>>> I made the simplifying that it is.
>>>>
>>>> I was hoping to have a more name=value function syntax in the  
>>>> future,
>>>> but
>>>> time's a bitch.
>>>>
>>>> | 3. If I were to start paying the loan off faster, with irregular
>>>> | amounts, I would have to put these transactions in by hand. Does  
>>>> it
>>>> seem
>>>> | correct to take the balance after the previous payment, multiply  
>>>> it
>>>> by
>>>> | 7.9%/12 and use that as the interest portion? I would think that
>>>> would
>>>> | be right, but when I try that with the current balance, it doesn't
>>>> come
>>>> | up the same as what the scheduled transaction generator is
>>>> producing...
>>>> | so you guys must have a different algorithm.
>>>>
>>>> Yes ... there's an existing bug [and some design-time requests which
>>>> were
>>>> not incorporated] that any future transactions should be based on  
>>>> the
>>>> present value of the account at the time of payment... this would  
>>>> be a
>>>> nice expansion of the feature. :(
>>>>
>>>> | Any help would be appreciated.
>>>>
>>>> I fear that wasn't a lot of help, unfortunately, but hopefully it's
>>>> more clear.  My time to enhance this [or any] part of the codebase  
>>>> is
>>>> non-existant at present, a situation I don't think will be resolved
>>>> for
>>>> some number of months.  Hopefully someone will step up to this.
>>>>
>>>
>>> My auto loan is simple interest.  Here's how the payment breakdown
>>> works
>>> out.  Suppose an interest rate of 5%:
>>>
>>> bal = initial/running principal balance
>>> prin = principal portion of payment
>>> int  = interest portion of payment
>>> days = payment date - last payment date
>>> amt  = amount of payment
>>>
>>> int  = (days * (5%/365)) * bal
>>> prin = amt - int
>>> bal  = bal - prin
>>>
>>>
>>> This formula matches my bank's numbers perfectly, so I'm pretty happy
>>> with it.  Unfortunately, I couldn't get Gnucash to do the same thing,
>>> so
>>> I just transfer the numbers from the spreadsheet.  Using the
>>> spreadsheet
>>> also allows me to insert rows for extra payments.  I tried all the  
>>> PMT
>>> and INT and FPV and NPV formulas--they all seemed to be a few pennies
>>> off at the closest.  So I just use my own.  *shrug*worksforme. YMMV,
>>> etc., etc.
>>>
>>>
>>>
>>> --   
>>> Matthew Vanecek
>>> perl -e 'print
>>> $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
>>> ********************************************************************* 
>>> **
>>> *********
>>> For 93 million miles, there is nothing between the sun and my shadow
>>> except me.
>>> I'm always getting in the way of something...
>>>
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> gnucash-devel at lists.gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
> -- 
> Matthew Vanecek
> perl -e 'print  
> $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
> *********************************************************************** 
> *********
> For 93 million miles, there is nothing between the sun and my shadow  
> except me.
> I'm always getting in the way of something...
>




More information about the gnucash-devel mailing list