Bug 103181: not-monthly repayment schedules not supported in Mortgage/Loan Druid

alessandro basili alessandro.basili at cern.ch
Tue Jan 14 18:12:13 EST 2014

Hash: SHA1

Hi Derek,

On 1/14/2014 5:15 PM, Derek Atkins wrote:
>> Uhm, isn't a 'balance as of date' automatically calculated? 
>> Executing the past transactions would immediately lead you to how
>> much you 'should have paid so far'. Am I missing something?
> No, it is not.  The P/I splits assume you always pay the exact 
> amount. If you over-pay your principal the P/I splits do not 
> reflect the lower principal (and therefore different P/I split 
> ratio).  E.g., if your mortgage is $995 (P+I) and you pay $1000, 
> you've paid down your principal by $5 and therefore are paying 
> interest on $5 less principal. GnuCash does not know how to handle
>  this, so over time your auto-generated P/I splits get further and
>  further from reality.

I see. This is something I haven't thought of and is a practice that
usually comes with a fee from the lender (at least in countries I've
lived in, like Italy, Switzerland and France).

I know it may seem 'insulting' but I've found this
Someone's-Favorite-Spreadsheet template which does handle extra payments:


It looks like if the extra payment can be done with a variable in the
SX that is asked for at each scheduled transaction. A simple checkbox
could be introduced in the UI to allow the user to select if (s)he
wants to have an 'extra-payment' feature in the scheduled transactions.

>>> I've been told this would be complicated, but I toss it out 
>>> with hope...
>> For the sake of discussion (and understanding), isn't a 
>> 'compounding frequency' field be needed at the very beginning of
>>  the calculation? The Financial Calculator has it, so I wonder 
>> why the Loan Assistant does not.
> I don't think that would be required necessarily for handling 
> principal pre-payments.

AFAIK there are basically three formulas involved in the prepayments:
pmt, ipmt and ppmt, where ipmt + ppmt = pmt. All of them require the
payments frequency to be evaluated and all of them require the
effective rate which depends on the payments frequency *and*
compounding frequency as well.

To my taste the SX editor should not be visible before those
parameters have been set and actually if the user has already filled
in the needed information to create pmt/ipmt/ppmt there's not even the
need for an SX editor to be there.

> But the complication of the balance-as-of-date is more a UI issue,
>  where you want the user to be able to select the account and have
>  the name shown in the UI, but you want to store the Account GUID 
> in the SX itself.
> Right now the SX editor doesn't do that, it's a direct string 
> store<->display.

But the editor shows a 12 months compounding frequency by default,
which is not the case when you need to handle different compounding


p.s.: I'm not sure if the irc channel is preferred over the mailing
list, but in my case I seldom have the possibility to stay online and
have a normal chat, therefore I'd rather prefer this list.

- -- 
Alessandro Basili
PGP Fingerprint DCBE 430E E93D 808B 45E6 7B8A F68D A276 565C 4450
PGP Public Key available at keys.gnugp.net
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the gnucash-devel mailing list