Volume-Based Tiered Pricing Structure: Case Study

Many companies structure their contracts using “tiered pricing” contingent on future events; this means that the fee per event decreases as the number of events increases. Examples include hours of processing time, number of social media posts, clicks on a web-based advertisement, or volume of transactions processed. Many such contracts are found in the Software-as-a-Service (SaaS) industry, especially among Financial Technology (FinTech) companies. Within the broader SaaS industry, FinTech focuses on services such as transaction and payment processing, financial lending and investing, mobile banking applications, and remote check processing, to name a few. This case study follows a typical FinTech contract, focusing on the proper accounting for a tiered pricing structure when applying Accounting Standards Codification (ASC) 606: Revenue from Contracts with Customers.

Case Study Background

MoneyModem (MM) is a FinTech company based out of San Francisco, CA. They specialize in transaction processing in a SaaS environment, and have many large global clients, mostly consisting of large banks. Like many FinTech companies, MM often employs a tiered pricing structure with its clients, and the tier thresholds in each contract are client-specific. Contracts also generally include a minimum fee in case of unforeseeably low processing volume, but neither party expects the minimum fee to be necessary in the normal course of business. To date, MM’s contracts have yet to consider the minimum fee element because the normal fees have always surpassed the contractual minimum. MM has a December 31 year-end.

On July 1, 20X1, MoneyModem enters into a non-cancellable transaction processing arrangement with Pursuit Bank (PB), a large multinational bank. The contract states that MM will process all end-user-initiated transactions for PB over the three year (36 month) contract period from July 1, 20X1 through June 30, 20X4. The two firms negotiated the following tiered pricing structure, in which the declining per-transaction fee is applied prospectively and resets monthly:

For example, if MM processes 180,000 transactions in a given month, then the total processing fees due from PB to MM would be (100,000 x $0.20) + (80,000 x $0.18) = $34,400.

The contract includes a minimum fee of $3,000,000 for the full contract term. MM is not certain how many transactions it will process for PB, but has determined the following probabilities of various levels of monthly transaction volumes after considering its own experience with other customers and PB’s internal data:

During the first month of the contract term, MM actually processes 1,800,000 transactions for PB. For illustrative purposes assume that each month, the actual number of transactions processed increases by 1 percent from the previous month.

Accounting Analysis

Step One: Identify the Contract

MoneyModem and Pursuit Bank sign a legally enforceable contract that meets all the ASC 606 requirements of a contract. Given this information, MM identifies this transaction as a contract with a customer.

Step Two: Identify Distinct Performance Obligations

Once the contract is identified, ASC 606 requires MM to assess the goods and services transferred to PB and identify performance obligations. Per ASC 606-10-25-14, MM may “identify as a performance obligation each promise to transfer to the customer either (a) A [distinct] good or service, [or] (b) A series of distinct goods or services that are substantially the same and that have the same pattern of transfer to the customer.” MM has agreed to be available at any time to process an unknown number of transactions over a three-year period. MM considers this a promise to stand ready to provide transaction processing services every day over the course of three years.

The nature of this daily stand-ready service may meet the definition of a series as described above. According to Transition Resource Group (TRG) Memo 39, paragraph 15, “If the nature of the entity’s promise is the act of standing ready or providing a single service for a period of time (that is, because there is an unspecified quantity to be delivered), the evaluation would likely focus on whether each time increment, rather than the underlying activities, are distinct and substantially the same.” Accordingly, we must analyze whether each day in the series is distinct, substantially the same, and has the same pattern of transfer.

Distinct

MM must see if these daily service increments are both capable of being distinct and distinct within the context of the contract. MM determines that each day’s service is capable of being distinct because each day’s stand-ready service provides a benefit to the PB in conjunction with something that is readily accessible to PB—that is, MM’s stand-ready obligation is beneficial to PB because PB can meet the needs of its existing end-users and account holders whenever they wish to transfer funds.

Although these services are capable of being distinct, MM must ensure that they are distinct within the context of the contract. ASC 606-10-25-21 provides three factors that may indicate that a promised good or service is not distinct within the context of the contract:

If an entity “provides a significant service of integrating” multiple goods or services in the contract, the goods and services are not distinct within the context of the contract. A common illustrative example of integration is when a good or service is used as an input to produce an output, such as screws and wood (inputs) when building a house (output). For MM’s contract, one day’s stand-ready service is not an input to any subsequent day’s stand-ready service and is not part of any significant integration.
If a good or service “significantly modifies or customizes” another good or service in the contract, they are not distinct within the context of the contract. One day’s service does not modify or customize another day’s service.
If a good or service is “highly interdependent or highly interrelated” with another good or service, they are not distinct within the context of the contract. One day’s service has no bearing on another day’s stand-ready service.

According to the ASC 606 criteria discussed above, each of the 1,095 days’ service of standing ready to process an unknown number of transactions is a distinct service because each day is both capable of being distinct and distinct within the context of the contract.

Substantially the Same

The promise of standing ready to process transactions on a specific day is substantially the same as every other day in the contract. While the specific activities performed each day and the volume of transactions processed will vary, the promise to stand ready each day may still be considered substantially equivalent.

Pattern of Transfer

Each day in the series also has the same pattern of transfer because each day meets the criteria in ASC 606-10-25-15 of (a) being recognized over time, and (b) being measured the same when measuring progress towards completion—specifically, each day uses the output method with time as a measure, as explained in Step 5 below. This is consistent with an analogous example found in ASC 606-10-55-157B through 55-157E, where each distinct day of hotel management services can be combined as a series in a single performance obligation.

In summary, the contract with PB has one performance obligation made up of a series of distinct daily services of standing ready to process transactions.

Step Three: Determine the Transaction Price

A transaction price may have fixed consideration, variable consideration, or both. MM estimates the transaction price based on current and expected circumstances at the time of the initial contract and updates this estimate each reporting period as necessary.

Variable Consideration, Fixed Consideration, and/or Material Right

The total amount of consideration MM will receive is unknown because the underlying number of transactions to process is unknown. This qualifies as “consideration … contingent on the occurrence or nonoccurrence of a future event,” as stated in ASC 606-10-32-6, and is therefore variable consideration. While a minimum fee clause exists in the contract, it is extremely unlikely that MM will have to enforce the minimum payment element. MM has always processed enough transactions in all of its contracts to overcome the minimum fee. Because this minimum fee is not “substantive,” it will not be considered as a form of fixed payment. The guidance in TRG Memo 40, paragraph 26c, suggests that the variable consideration alone represents the value transferred to the customer, and that a non-substantive minimum fee may not need to be considered when applying a variable consideration practical expedient. All consideration in the contract is considered variable, and no amount is treated as fixed consideration.

MM must also consider if any part of the contract gives rise to a customer option that provides a customer with a material right, specifically as it relates to the tiered pricing structure. This is an area of considerable judgement, as acknowledged by TRG Memo 48. Any rights or obligations, and the nature of the promise to the customer in the current contract must be considered. The nature of MM’s promise to PB is to process all transactions over a three-year period, and each day is considered its own distinct service. TRG Memo 48, paragraph 19(a), explains that additional goods or services are a key differentiator between customer options and variable consideration; variable consideration is present if the “customer’s actions do not obligate the vendor to provide additional distinct goods or services.” Later, in paragraphs 31 through 37, the TRG staff addresses IT outsourcing and transaction processing arrangements and determines that in its given example, which is analogous to MM’s transaction, customer options do not exist and that variable consideration is present. The staff’s rationale is as follows:

“…The customer does not control the number of transactions processed and is contracting for access to the processing platform. Because the customer does not control the number of transactions processed, entering into the initial contract is the purchasing decision after which the customer does not have the ability to choose quantities processed. As such, because the vendor is already obligated to provide continuous access to the platform (and receive consideration for that service), the events that result in payment occur after (or as) the vendor transfers the service and do not result in an obligation for the vendor to transfer additional goods or services” (emphasis added).

PB will not be making a separate purchasing decision to have MM process additional transactions in the future. MM has already agreed to process an unspecified number of transactions over a fixed time period. Processing an unexpectedly large number of transactions, even if processed at a lower price per transaction, does not obligate MM to provide any services in addition to those promised in the current contract. Therefore, MM does not provide PB with any customer options in the contract. The current contract has only variable consideration.

Variable Consideration

By definition, variable consideration is unknown at contract inception and is therefore estimated. Most contracts with variable consideration require an initial estimate, and often updates to that estimate, over the course of the contract. The estimate of variable consideration is used in determining the transaction price, allocating that transaction price, and recognizing revenue at different points in the contract period when goods and services are transferred to the customer. While the different methods of estimating the variable consideration and total transaction price are explained here, the allocation and recognition of revenue presented in steps four and five below render such an estimation operationally unnecessary with the current case facts. The combination of monthly reset, pattern of transfer, and volume-based consideration in this specific transaction leads to this deviation from the norm.

However, if MM were to estimate the variable consideration and transaction price initially, ASC 606-10-32-8 allows for two methods: either the expected value method or the most likely amount method. The most likely amount method is generally used when there is a binary outcome and one outcome is more likely than the other. Because that does not apply in MM’s case, the firm would apply the expected value method. This method estimates the variable consideration by considering all possible outcomes on a probability-weighted basis. We use the probability of various transaction volumes to determine the expected value of the contract. For example, there is a 2 percent probability of only processing 500,000 transactions in a given month. The fee for the 500,000 transactions would be as follows:

Using this methodology, we can calculate the expected monthly revenue for each forecasted level of processed transactions and create a probability-weighted expected amount for the variable transaction price:

The total transaction price for the three-year contract is estimated to be $10,854,000. As illustrated below, this amount is not used to determine revenue recognition in this specific case. Certain companies with contracts similar to this case study may be able to forego the transaction price estimation process altogether. However, there are certain complicating factors discussed in the “Other Industry Considerations” section that may require companies to estimate the transaction price for volume-based tiered pricing structures as illustrated above.

Step Four: Allocate the Transaction Price

The contract includes just one performance obligation, a series of distinct days over the three-year contract term wherein MM is obligated to stand ready to process customer transactions. By default, the entire transaction price would be entirely allocated to the single performance obligation. However, ASC 606-10-32-39 allows MM to allocate variable consideration to “one or more, but not all, distinct goods or services promised in a series of distinct goods or services.” To allocate variable consideration to a distinct day in the series, MM must ensure that two criteria are met, per ASC 606-10-32-40:

The first criterion is that “The terms of a variable payment relate specifically to the entity’s efforts to… transfer the distinct good or service (or to a specific outcome from … transferring the distinct good or service).” The variable consideration is dependent on the number of transactions processed per day. The terms of the variable payment, in this case, relate specifically to MM’s effort to transfer each distinct daily stand-ready service, meeting the first criterion.
The second criterion is that such allocation of variable consideration “is consistent with the allocation objective” when considering all other performance obligations and payment terms. ASC 606-10-32-28 defines the allocation objective as “allocat[ing] the transaction price to each performance obligation (or distinct good or service) in an amount that depicts the amount of consideration to which the entity expects to be entitled in exchange for transferring the promised goods or services to the customer.” Because the terms of the variable payment are based on transactions processed and the contract contains only this single performance obligation and related payment terms, the second criterion is met.

A similar example regarding variable consideration for hotel management services found in ASC 606-10-55-157B through 55-157E supports this conclusion. In this example, the hotel management company receives 1 percent of the hotel revenue each month as variable consideration for its daily management service. Paragraph 55-157E explains that the allocation objective is met when the variable consideration is allocated to specific days of service based on the activities performed during each of those days:

“…The entity considers whether the variable consideration may be allocated to one or more, but not all, of the distinct days of service in the series…The entity evaluates the criteria in paragraph 606-10-32-40 and determines that the terms of the variable consideration relate specifically to the entity’s efforts to transfer each distinct daily service and that allocation of the variable consideration earned based on the activities performed by the entity each day to the distinct day in which those activities are performed is consistent with the overall allocation objective…”

MM may allocate variable consideration to each specific day in the series based on the number of PB transactions processed each day. However, the first transaction processed on the first day of the month should lead to the same or nearly the same recognized revenue as the one millionth transaction processed later in the month to best meet the allocation objective. Under a tiered pricing structure, this may not ordinarily be the result. To correct this improper allocation, MM considers the number of transactions processed during the month and the amount of consideration it will invoice PB per the contractual payment terms. An average, or blended, rate is calculated by dividing the total consideration by the total number of transactions. On July 31, 20X1, for example, MM recorded that 1,800,000 transactions had been processed during the month of July, and MM was entitled to $275,000 of transaction processing fees as calculated below:

If the total consideration is $275,000 for processing 1.8 million transactions, the blended rate for the month of July is $275,000 / 1,800,000 = $0.15278 per transaction. The variable consideration is then allocated to each day according to the number of transactions processed each day at the blended rate. The aggregate allocated revenue for the 31 distinct stand ready service days during the month of July is $275,000 using the blended rate; operationally, it is important to note that using the blended rate for the monthly reset period will always yield the same result as the invoiced amount. The same allocation method can be applied for every month of the contract.

Step Five: Recognize Revenue

MM will recognize revenue over time as their obligation to stand ready to process transactions is performed. Per ASC 606-10-55-4, MM may recognize revenue over time because their customer, PB, “simultaneously receives and consumes the benefits provided by the entity’s performance as the entity performs.” When recognizing revenue over time, MM must use either the output or input method and select a measure that, according to ASC 606-10-55-17, “faithfully depict[s] the entity’s performance toward complete satisfaction of the performance obligation.”

The output method with time as a measure of progress best depicts the transfer of services from MM to PB. Using time as a measure does not imply recognizing revenue on a straight line basis over the contract term. Instead, as each time period of stand ready service is performed, the amount of variable consideration allocated to that time period may be recognized. Over the course of July 20X1, $275,000 of revenue is recognized according to the allocation of variable consideration to each day. If the contract included fixed fees, these would be recognized ratably over the contract term.

However, a practical expedient is available under ASC 606-10-55-18, which states that “if an entity has a right to consideration from a customer in an amount that corresponds directly with the value to the customer of the entity’s performance completed to date … the entity may recognize revenue in the amount to which the entity has a right to invoice.” When MM bills PB for the transaction processing fees, MM has a right to that consideration; this also represents the value to PB of MM’s performance completed to date.

Ultimately, MM recognizes revenue each month in the amount they invoice PB. As is shown above, the full application of the standard using an estimated transaction price, daily allocation, blended rates, and the allocation objective results in the same revenue recognition as the right-to-invoice practical expedient because of the monthly reset provision in the contract. Operationally, MM will likely apply the practical expedient and recognize revenue as they bill PB each month.

During the first month of the contract, July 20X1, MM processes 1,800,000 transactions for PB’s customers. On July 31, 20X1, MM invoices PB for $275,000 according to the tiered pricing structure, calculated above, and recognizes revenue of that amount. In August, MM processes 1,818,000 transactions; MM both invoices PB and recognizes revenue for $277,520 on August 31, 20X1. In September, MM processes 1,836,180 transactions; MM both invoices PB and recognizes revenue for $280,065 on September 30, 20X1. This pattern continues monthly for the duration of the contract term.

Transaction Summary

Amounts invoiced by MM represent their right to consideration for services rendered to PB. These amounts can be recognized as revenue as invoiced over the contract term. The following table summarizes the number of transactions processed and the corresponding invoice amount and revenue recognized for each month of the contract term.

The total revenue recognized over the contract term is $11,683,374.

Other Industry Considerations

Period Alignment

Most FinTech and SaaS companies that use similar tiered pricing structures in their contracts are sure to align the end of the billing, reset, and reporting periods. However, some companies structure contracts differently. For example, suppose MM’s billing periods end and the monthly reset occurs on the 14^th of each month. For the billing and reset period of December 15, 20X1 through January 14, 20X1, with the end of a financial reporting period being December 31, 20X1, MM would have two options and would need to consider materiality in its assessment of whether the allocation objective is met. The first option would be to estimate the total number of transactions processed during the billing period and calculate a blended rate for the billing period. MM would recognize revenue on December 31, 20X1, using the actual number of transactions processed between December 15 and 31 at the estimated blended rate. The second option applies the practical expedient: MM would use the number of transactions processed between December 15 and 31, calculate the actual processing fees that MM has a right to invoice using the tiered pricing structure, and recognize revenue for that amount. The difference between the two options could be immaterial on a financial statement level.

Infrequent Tier Reset

The industry standard is a monthly reset for the tiered pricing structure, but some SaaS companies reset the tiered pricing annually or forego a reset altogether. In these cases, the same blended rate process is followed as outlined in the case above, but the right-to-invoice practical expedient likely cannot be used because the allocation objective would not be met. If MM used a yearly reset for their tiered pricing, the company would need to estimate both the total transaction processing volume over the entire contract period and the associated processing fees to determine an estimated blended rate. If MM had quarterly financial reporting periods with an annual tier reset, MM would apply the annual estimated blended rate to all the transactions processed during the quarter, recognizing that amount as revenue. At the end of each reporting period, MM would be required to reassess its estimates of the inputs to the calculated blended rate for the remainder of the contract, per ASC 606-10-32-14: “At the end of each reporting period, an entity shall update the estimated transaction price (including updating its assessment of whether an estimate of variable consideration is constrained) to represent faithfully the circumstances present at the end of the reporting period and the changes in circumstances during the reporting period.” The accounting for annual resets of the tiered pricing model becomes much more complex and requires significantly more estimates and judgments, resulting in decreased accuracy and increased time and costs. Because of the operational challenges associated with annual resets, many companies previously using an annual reset period may consider transitioning to quarterly or monthly reset periods in their tiered pricing structures.

Multiple Performance Obligations

FinTech companies often offer more services than simply transaction processing, and some FinTech and SaaS companies use a combination of tiered pricing, recurring subscription fees, one-time implementation fees, and other payment terms in their contracts. More complex contracts may involve multiple performance obligations and various methods of allocating the fixed and variable consideration. Some companies may have difficulty showing that they meet the allocation objective when attempting to allocate variable consideration specifically to one or more, but not all distinct goods or services in complex contracts. They may have to determine the standalone selling price (SSP) of each performance obligation, compare that to the allocated portion of the transaction price for each performance obligation, and justify any inconsistencies in the relative discount from SSP to the allocated portion of the transaction price. This may prove especially difficult when variable consideration and complex, long-term estimates are involved.

Comparison to ASC 605

Under ASC 605, MM’s relatively straightforward contract would result in the same revenue recognition under ASC 606, though built upon differing technical bases. However, accounting can change under the different standards when contracts become more complex, including multiple performance obligations, fixed and variable consideration for a single performance obligation, one time fees, and recurring payments.

Resources Consulted

ASC 606
FASB TRG Memo 39: "Application of the Series Provision and Allocating Variable Consideration." 13 July 2015.
FASB TRG Memo 40: "Practical Expedient for Measuring Progress toward Complete Satisfaction of a Performance Obligation." 13 July 2015.
FASB TRG Memo 48: "Customer Options for Additional Goods and Services." 9 November 2015.