[Content Suggestion] Clarify what is included in FOCUS "Amortization"

[AWS-ZachErdman]

Description

The FOCUS spec often refers to Amortization in a number of places and each time it provides a description of what Amortization is, but the exact definition has felt ambiguous to readers I've spoken with. Some examples of where Amortization is described:

First, a short line from FOCUS spec section “2.18.3 Description”:

"relevant purchases (one-time or recurring) paid to cover future eligible charges".

Second, a description from “2.18.3.2 Concerning Amortization Approaches”:

Eligible purchases should be amortized using a methodology determined by the provider that reflects the needs of their customer base and is proportional with the Pricing Quantity and the time granularity of the row.

Third, a longer description from “3.4 Discount Handling”:

Amortization is a process used to break down and spread purchase costs over a period of time or term of use. When a purchase is applicable to resources, like commitment-based discounts, the amortized cost of a resource takes the initial payment and term into account and distributes it out based on the resource's usage, attributing the prorated cost for each unit of billing. Amortization enables users of billing data to distribute purchase charges to the appropriate audience in support of cost allocation efforts. Discount Handling for purchased commitments is commonly used for scenarios like calculating utilization and implementing chargeback for the purchase amount.

While providers may use different terms to describe discounts, FOCUS identifies a discount as being a reduced price applied directly to a row. Any price or cost reductions that are awarded after the fact are identified as a "Credit" Charge Subcategory. One example might be when a provider offers a reduced rate after passing a certain threshold of usage or spend.

Proposed approach

We propose that the FOCUS spec provide an explicit and clear definition of what Amortization should include. Based on the text above, the definition could be something like:

"Amortization applies only to "Purchases" that are made solely for the purpose of covering future charges, as opposed to current charges.

Any rate reductions that occur from reaching a certain usage threshold (pricing tiering) would affect the usage where it begins and are NOT included in Amortization. Any cost reductions that would affect previous charges due to hitting a certain spend or usage should be issue as credits and are NOT included in Amortization."

Github issue or Reference

N/A

Context

N/A

[flanakin]

I agree the first two references are a bit confusing. The third seems more detailed but could be more explicit. I'm not following the two suggestions, however. Perhaps we should make a list of independent points we think need to be explicitly included in the definition of amortization to make sure we have them all clearly defined before we put it into a paragraph.

[AWS-ZachErdman]

I felt the third explained a lot of what the benefits of amortization are, but without explaining how a provider should do it.

I like the idea of creating a list of independent points. I think what I was trying to explain in my suggestions was defining what should be included in amortization, while clarifying what are some expected misconceptions that should not be included.

What SHOULD be amortized:

• "Purchases" that are made solely for the purpose of covering future usage, as opposed to current usage.

What SHOULD NOT be amortized:

• Any rate reductions that occur from the amount of usage causing pricing tiering changes which usually lowers the rate. (The lower rate appears in both BilledCost and EffectiveCost).
• Any cost reductions that would affect previous charges due to hitting a certain spend or usage. (These are issued as credits.)

Did this make it more clear, or not so much?

[rileyjenk]

I also agree including a explanation of what amortization is in multiple places is both unnecessary and problematic.

We held off on being prescriptive on what is amortized and the approach to that amortization because of the variation that exists provider to provider. I do like your SHOULD and SHOULD NOT list, however we held back from including this because the decision to include amortized data rests with the provider.

For example if I purchase data on the AWS marketplace for an offering there that is for an entire year, this is a purchase for covering future charges/future usage but is not to amortized.

I wonder if we could enhance your list such that it give guidelines and include that in a single location.

[jpradocueva]

@rileyjenk, Riley, this PR has been assigned to you to drive it from here to discussion and final review and approval. Please let me know if I can be of any assistance.

[jpradocueva]

Move to v1.1 as the consistency review for release v1.0 has started.

[SonalGarg-SG]

We should put a PR, discuss and standardize the definition. Also clean up the specs and always refer back to this standard definition. PR needed.

[shawnalpay]

@ijurica Do you believe this legacy issue is a sufficient description of what needs doing for clarifying the term "amortization" per AI #875?

[shawnalpay]

Discussed in May 8 Members call. @ijurica will review with @sid-mengde and @jpickardgreen and determine how to fold into their AI #875. This issue will then be closed.

[shawnalpay]

Closing in favor of #1009.