I just uploaded all of our company's contract information.  Most of it calculated correctly but I noticed a handful of line items were calculated incorrectly.  For instance, I have several contracts that are extended in the middle of our fiscal year.  I did not enter an extension percentage increase amount as we don't anticipate an increase.  However, Apptio is automatically applying an increase and causing a variance of hundreds to thousands of dollars depending on the line.  The weird part is, we have several 3 year agreements and Apptio will apply an increase for the 2nd year, but then go back to normal in the 3rd year.  Has anyone else had this issue?  We use the same Straight Line by Duration for all of our contract reference data so I can't imagine that is the issue.  I've checked and re-checked our start and end dates and extension percentage.  Everything checks out on our end but Apptio seems to be going rogue and adding extensions.  Any ideas?

I haven't seen this. Is the extension percentage blank or does it say 0%?

Hi Charles,

I have not seen that happen before without an extension amount being filled in and the extension box being checked. In your initial upload are those columns blank? As Jason said above does your extension say 0%?

Thanks,

Lauren Griessel

Thanks Lauren.  I've checked several times.  The extension percentage is 0% and it is blank in my original upload.  Here is an example. We have a renewal for $872,400 from 6/1/18 - 5/31/19.  Our fiscal year begins in August.  So for August - May it is showing $72,700 (correct).  From June through the following April it jumps to $79,309/month.  A 9% increase.  The weird thing is, that's only for 11 months(Jun '19-Apr '20).  We have a 6 year forecast, and after those 11 months that are off, it goes right back to $72,700.  I've noticed this happens on pretty much every renewal we have that we entered 0% in the extension amount column.  We use straight line by duration - could next year being a leap year be part of the problem?  It just seems like it's not calculating something correctly?  Or maybe we need to use a different amortization method?

Charles,

Maybe good news? I was able to recreate the error that you were getting on my version. Why is that good news? I changed the start date and end date from 6/1/18-5/31/19 to 6/1/18-6/1/19 and it eliminated the increase. Shows a duration of 13 months instead of 12 months. Doesn't really answer the question of why is this happening, but it eliminates the error.

Thanks for looking into it Jason.  I actually just noticed the same when playing around with the dates.  I suppose that will have to do for now but it just seems odd how Apptio is calculating the amortization.

Here is an example pulled from this document Amortization methods for contracts  (Outdated; click for updated version)  on how Apptio calculates the amortization:

Example

Amortization examples are based on a contract that shows the following:

• Amount: $400.00
• Start Date: August 20, 2017
• End Date: December 19, 2017
• Duration calculated using month only (used by Even Periods method): 5 months
• Duration calculated using month and day (used by Duration method): 4 months

NOTE   Amounts will calculate to exact values. The amounts round to the nearest whole unit of currency (for example, USD).

It sounds like based on your example above you would want to choose straight line even periods as your depreciation method as the straight line by duration only reads a full month if the full month is included in the end date (I.E changing it from 5/31 to 6/1)

Let me know if you still have questions,

Lauren Griessel

We actually saw this when we were trying to figure out which methods to use.  It appears that making the end date 5/31 still reads a full month as it shows the duration as being 12 months.  If I change it to 6/1, we now have a 13 month duration.  To us, Straight Line by Duration made sense because it aligned more closely to our accounting policy. 

I just tried my same example above, but I changed the dates to 6/1/19 - 5/31/20 and it is showing the correct amount ($72,700) all the way across the board.  It almost seems like there is some sort of glitch in the way this is calculating the extension.  I really wonder if the leap year in 2020 is throwing off the calculation of the extension.  So then I tried 6/1/22 - 5/31/23.  The extension for this would occur in 2024 - the next leap year.  When the extension occurs (6/1/23 - 5/31/24) the same issue happens.  It increases to $79,309 at 6/1/24.  Hopefully what I'm saying makes sense, I could be way off but it does seem peculiar that it is calculating 11 month extensions when the extension portion falls in a leap year.  

I think you have a good point about the leap year. I played around with other dates and it seems like the start date and end date have to be at least 365 days apart.

Agreed. I tried doing a contract in 2023 that would extend in 2024(the next leap year) and the same exact issue arose.  I also tried a contract in 2021 and it had no issues because the extension doesn't occur in a leap year.  Very bizarre.

I see the same thing with leap years when testing. I suggest opening a support ticket on this Charles and asking about the leap year. If you reference this thread they will understand the ask and an engineer can look at it.

Thanks Lauren!

This post references the Straight Line by Duration issue we submitted on Oct 12th and mentioned during our meeting last week in Vegas.   @Rodney Bohuslav @Nathan Reese @Andrew Edeen @Samir Banker  I have forwarded a link the original ticket for reference.  @Brett Yates is also familiar with our testing if you have questions.

Peggy, are you saying you noticed the same exact issue?  Was there a resolution?  I'd love to hear your input.

Yes, we had been waiting for the "extend" functionality to be made available for all amortization types and did extensive testing in our sandbox following the update.  We found that FY2019 and FY2021 results were very different from FY2020 and submitted a support ticket.  The ticket resolution indicated that Straight Line by Duration was working as designed and suggested that we utilize Straight Line Even Periods since it does not take into account the number of days in any given period, but months.   As a result we asked for a review of the ticket during meetings at TBMC18 last week.