You are quite welcome :-). I noticed that I forgot to put in that final UPDATE to store the calculated Total Interest back into the main LOANS table, so I have updated my post above with that logic. I also included a SELECT * FROM #LOANS at the end of the test queries to make it easy to see that it did record the final total value correctly.

Please note that the final payment amount for each of the 3 test cases is not only different from the initially calculated payment amount, but it is sometimes greater than the initial amount and sometimes less.

Please also note that while the stored procedure does allow for passing in a value for "payments per year", the payment date logic only works with monthly (i.e. a value of 12). The dates will not calculate correctly if someone tries to use a value of 24 for bi-monthly payments or a value of 26 for bi-weekly payments.

I should also mention that the second example is also based on a past mortgage that I had that I do have the amortization schedule for. The reason I didn't mention that one matching exactly is that it doesn't exactly match ;-). At least, it doesn't match the updated SQL# function now that I have made the changes to use the correct MONEY (decimal in .NET) datatypes. But, oddly enough, the amortization schedule does match exactly to the current version (3.3.x) of the SQL#[/url] Math_CompoundAmortizationSchedule function, which is using all FLOATs (and I did, years ago, validate the function against another mortgage from another lender. It is a little discouraging that the banks can't even be consistent in this matter. I suppose I would have to have a copy of the function using all FLOATs again to have each way of looking at it. Maybe someday. For now I feel that using DECIMAL / MONEY is more accurate / popular.

Take care,

Solomon...