Technology Spotlight — Accounting for Outcome-Based Pricing in an Agentic AI Software Product (June 4, 2026)

Accounting for Outcome-Based Pricing in an Agentic AI Software Product

The Bottom Line

Agentic artificial intelligence (AI) refers to AI systems that combine language understanding with goal-directed reasoning to interpret context, plan multistep workflows, and take autonomous actions by connecting to external tools and data. Entities are increasingly embedding AI agents into software as a service (SaaS) offerings or selling stand-alone agentic AI SaaS applications. Because traditional per-seat or flat-fee pricing models may not adequately reflect the value delivered, some vendors may adopt outcome-based pricing, charging customers only when the agent successfully completes a defined task or achieves a contractually specified result (e.g., the resolution of a customer service ticket, processing a specified volume of data). This pricing structure introduces questions about how to determine the timing of revenue recognition under ASC 606.1
A key accounting judgment related to determining timing of revenue recognition in an agentic AI SaaS arrangement is whether the nature of the entity’s promise is (1) a stand-ready obligation to provide continuous access to the agent (i.e., making the agent available to process customer requests throughout the contractual term, with revenue typically recognized over time by using a time-based measure of progress) or (2) an obligation to deliver a specified quantity of successful outcomes (with revenue typically recognized as those outcomes occur by using an output method).
If an entity’s agentic AI SaaS arrangement qualifies as a series of distinct services under ASC 606-10-25-14(b), the entity may be able to apply either the variable consideration allocation exception (ASC 606-10-32-40) to recognize variable outcome-based fees as successful outcomes occur or, depending on the payment terms of the contract, the invoice practical expedient (ASC 606-10-55-18). However, to apply these exceptions, an entity must carefully evaluate whether the contract terms meet the specific criteria in the guidance.
Two additional issues may arise in agentic AI SaaS arrangements: (1) whether predeployment implementation activities transfer a good or service to the customer and (2) whether a vendor’s rights to use customer data for model improvement constitute noncash consideration under ASC 606.

Beyond the Bottom Line

This Technology Spotlight highlights considerations related to accounting for revenue from SaaS offerings with agentic agents.

Background

AI agents have evolved beyond generative artificial intelligence (GenAI) chatbots and apps, combining language understanding with goal-directed reasoning to interpret context, plan multistep workflows, and take action by connecting to external tools and data with minimal human interaction. While GenAI chatbots largely focus on generating content or answering questions within a single interaction, AI agents are designed to operate in multiple tasks and systems, retaining relevant context, applying task-specific logic, and coordinating steps in which extensive human oversight would otherwise be required. For example, an AI agent that supports customer service can maintain relevant customer context for various channels, interpret policies, and execute next steps (e.g., create a case, initiate a refund workflow, update account details) and is not limited to responding within a single chat session. More broadly, agents can orchestrate workflows (e.g., planning, forecasting, or program execution) that are often difficult to complete reliably through a single large language model (LLM) prompt. Figure 1 places agentic AI within the broader AI landscape and clarifies its relationship to AI, machine learning (ML), deep learning (DL), and GenAI.

Figure 1

Connecting the Dots

Think of AI as the broad umbrella: technology that enables computers to perform tasks that typically require human intelligence. ML is one approach to AI in which systems learn patterns from data rather than relying solely on explicitly coded rules. DL is a subset of ML that uses neural networks and often requires larger datasets and more computing power to learn complex representations. GenAI is a subset of DL that can create new content, such as text, images, or summaries, on the basis of patterns learned from training data. Agentic AI goes a step further by adding the ability to plan and act: it can break a goal into steps, use tools to execute those steps, and maintain context (often via memory) to track progress and adapt as conditions change. That action orientation is what makes AI agents useful for end-to-end work, not just single-turn responses.

AI agents can coordinate work in different ways depending on the complexity of the objective. In a single-agent system, one LLM-driven agent receives the request, plans an approach, uses tools as needed, and returns the result. Such a system is often effective for well-bounded tasks such as research, summarization, or validation.

In a multiagent system, multiple agents collaborate when the work benefits from specialization or parallelization. A common design includes a manager (orchestrator) agent that decomposes the request into smaller tasks and assigns them to specialist agents, each equipped with distinct tools and responsibilities. Shared memory helps the system remain aligned by retaining context, tracking progress, and supporting coordinated handoffs as new information emerges. This distinction matters because multiagent systems are designed to tackle complexity that a single agent may not handle reliably on its own. When implemented well, such systems can accelerate workflows, reduce bottlenecks, and enable new forms of human-AI collaboration, particularly when work must be decomposed, executed in parallel, and validated before completion. For example, in an incident-management workflow, one agent can classify and prioritize incoming tickets, another can enrich and route them, another can recommend or apply fixes, and a final agent can verify resolution and close the ticket. The primary measure of value is not the number of steps executed; it is the accurate resolution of outcome incidents with minimal human intervention. Figure 2 illustrates single-agent and multiagent patterns side by side.

Figure 2

Pricing Agentic AI

How the use of AI agents is priced and paid for may significantly affect both SaaS users and vendors. When software was mostly delivered through an on-premise license, customers often purchased a right to a perpetual license and paid for postcontract customer support. The transition to SaaS, driven by the adoption of the cloud, shifted many software vendors from an on-premise software license model to a SaaS model in which their offerings were delivered to customers through the cloud via subscriptions. Today, several different models may be used to price SaaS arrangements, including pricing based on successful outcomes, charges based on the number of users or seats, usage-based pricing tied to actual consumption, and hybrid approaches that combine these elements. As AI agents enter more widespread adoption and use, these traditional pricing models may not adequately reflect the value exchange between provider and consumer.

Outcome-Based Pricing

Outcome-based pricing is based on the actual results that AI agents produce. In practice, arrangements may use a single outcome-based pricing approach or a hybrid structure that combines multiple approaches. For example, a vendor may use one or more of the following approaches (not all-inclusive) to price its AI agent:

Per-successful-outcome pricing — Payment is based on each discrete successful outcome the AI agent achieves (for example, each resolved customer-service request, processed transaction, or prevented error).
Performance-tier pricing — Payment varies depending on the AI agent’s aggregate performance level over a defined period. Higher success rates, measured as the percentage of eligible tasks successfully completed, result in higher payments, while lower success rates result in reduced or no payments.
Fixed-fee pricing with performance adjustments — The customer pays a base fee but receives refunds, credits, or fee reductions if the AI agent’s performance falls below contractually defined thresholds, or the vendor earns additional fees if performance exceeds defined targets.
Prepaid successful-outcome pricing — The customer prepays for a specified number of successful-outcome credits or units, and each credit is consumed only when the AI agent successfully completes a defined task or achieves a qualifying outcome. Amounts prepaid for successful outcomes may be nonrefundable (“use it or lose it”) or refundable.

In each case, including hybrid arrangements, payment is tied in whole or in part to achieving contractually defined “successful” outcomes rather than simply providing access to the AI agent or counting usage attempts. The key characteristic of outcome-based pricing is that unsuccessful attempts, incomplete actions, or results that do not meet the contractual success criteria typically do not trigger payment or may not reduce the customer’s prepaid entitlements.

Implementation Services

Entities that sell a cloud-based or hosted software solution (e.g., a SaaS arrangement) often include implementation services. These services are performed either (1) at the outset of the customer arrangement or (2) during the SaaS term (in many cases because of added modules or features of the SaaS solution). Depending on the facts and circumstances of the arrangement, an entity may need to use judgment to determine whether the implementation services represent (1) activities that do not transfer a good or service to the customer, (2) a promise that is not distinct from the SaaS, or (3) a distinct performance obligation. The Q&As below provide interpretive guidance intended to help entities address certain challenges associated with applying the revenue model in ASC 606 to agentic AI SaaS arrangements that include variable consideration.

Interpretive Guidance

Q&A 1 — Determining Whether Implementation Activities in an Agentic AI SaaS Arrangement Are a Promised Good or Service

In agentic AI SaaS arrangements, the vendor may perform predeployment activities to prepare the hosted service for use by a particular customer. Those activities may include ingesting or processing customer-specific data, tuning model parameters, configuring workflows and decision rules, testing tool orchestration, and validating guardrails and performance thresholds before the service goes live.

ASC 606-10-25-17 states the following about the identification of promised goods or services in an arrangement:

Promised goods or services do not include activities that an entity must undertake to fulfill a contract unless those activities transfer a good or service to a customer. For example, a services provider may need to perform various administrative tasks to set up a contract. The performance of those tasks does not transfer a service to the customer as the tasks are performed. Therefore, those setup activities are not promised goods or services in the contract with the customer.

In addition, ASC 606-10-55-53 states the following:

An entity may charge a nonrefundable fee in part as compensation for costs incurred in setting up a contract (or other administrative tasks as described in paragraph 606-10-25-17). If those setup activities do not satisfy a performance obligation, the entity should disregard those activities (and related costs) when measuring progress in accordance with paragraph 606-10-55-21. That is because the costs of setup activities do not depict the transfer of services to the customer. The entity should assess whether costs incurred in setting up a contract have resulted in an asset that should be recognized in accordance with paragraph 340-40-25-5.

Question

Are predeployment training activities a promised good or service in the contract?

Answer

The entity’s analysis of whether predeployment training activities are a promised service is based on whether the customer obtains control of the implementation services as they are performed. In the determination of whether the customer obtains such control, we believe that it may be helpful for the entity to consider the following:

Whose assets are being enhanced, improved, or customized by those activities. If the implementation activities are performed on the entity’s internal infrastructure and applications (i.e., “behind the firewall”), the activities most likely do not transfer a good or service to the customer and the entity therefore would not consider the services in identifying performance obligations. This would be the case even if the customer will benefit from the implementation activities. Because the activities are performed on the entity’s assets, the entity retains control of any benefits those activities confer. By contrast, if the implementation activities are performed on the customer’s infrastructure and applications, the activities may represent the transfer of a promised good or service to the customer. Paragraph BC129 of ASU 2014-09 2 discusses “situations in which an entity’s performance creates or enhances an asset that a customer clearly controls as the asset is created or enhanced.” It states, in part, the following:
In those cases, because the customer controls any work in process, the customer is obtaining the benefits of the goods or services that the entity is providing . . . . For example, in the case of a construction contract in which the entity is building on the customer’s land, the customer generally controls any work in process arising from the entity’s performance.
Whether the services are provided directly to the customer (i.e., the services are simultaneously received and consumed by the customer; another entity would not need to substantially reperform the entity’s performance to date). Paragraph BC125 of ASU 2014-09 states, in part:
In many typical “service” contracts, the entity’s performance creates an asset only momentarily because that asset is simultaneously received and consumed by the customer. In those cases, the simultaneous receipt and consumption of the asset that has been created means that the customer obtains control of the entity’s output as the entity performs . . . . For example, consider an entity that promises to process transactions on behalf of a customer. The customer simultaneously receives and consumes a benefit as each transaction is processed.

Example 1

Entity A provides an agentic AI SaaS platform that autonomously drafts, routes, and executes customer-support actions (e.g., refund issuance within preset limits, order reroutes, escalation triggers). Entity A enters a two-year noncancelable SaaS arrangement with Customer C that provides continuous access to the platform once it is live.

As part of the arrangement, C pays an up-front, non-refundable “agent training and readiness” fee of $250,000. Before the platform goes live, A will receive a copy of C’s historical support tickets and policy documents and performs offline model tuning and simulation in A’s controlled environment (i.e., behind A’s firewall) to improve the agent’s intent classification, tool-selection logic, and guardrail performance (i.e., neither C nor a third party can perform the offline model tuning through access to the SaaS). The contract with C limits A’s rights to the customer’s data to providing the contracted agentic AI SaaS platform, and A cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract with C. In addition:

Customer C cannot access or use the agentic AI SaaS until A completes the readiness activities and turns on production access.
Customer C receives no code or on-premise software license to the agentic AI SaaS platform.
Customer C can only benefit from training through the hosted service during the agentic AI SaaS term.

Question

Are the predeployment training activities a promised good or service in the contract?

Answer

No.

The predeployment training is an internal activity A must undertake to fulfill its promise to provide the hosted agentic AI SaaS, and because it is performed on A’s assets behind the firewall (with no transfer of control of a good or service to C as performed), it is akin to a setup activity and does not represent a promised good or service. Entity A would separately evaluate whether any related costs create an asset under ASC 340-40.

Q&A 2 — Determining Whether a License to Use Customer Data Represents Noncash Consideration

Agentic AI vendors may negotiate with customers to receive a license to customer data because real-world data is valuable for training and improving agentic AI models. While AI vendors can purchase data from third-party data brokers or use publicly available datasets, customer data may provide more specific examples, edge cases, and feedback that improve agent performance across the vendor’s entire customer base.

Question

Are rights to customer data noncash consideration from the vendor’s customer?

Answer

It depends.

Agentic AI vendors will need to evaluate whether the right to customer data is noncash consideration from their customers. ASC 606-10-32-21 requires an entity to measure the fair value of noncash consideration at contract inception. In terms of the sequence of steps used to determine the fair value of noncash consideration, ASC 606-10-32-21 and 32-22 require an entity to first look to measure the estimated fair value of the noncash consideration and then consider the stand-alone selling price of the goods or services promised to the customer only when the entity is unable to reasonably estimate the fair value of the noncash consideration.

In making this determination, an entity should consider whether the contract restricts the vendor from using customer data beyond the limited purpose of providing the contracted service to that specific customer (because of ownership, confidentiality, privacy, and competitive concerns) or whether the vendor has the right to use the data to develop model improvements and deploy those improvements in serving other customers.

If the vendor has limited rights to use the data to perform the contracted service, the data most likely does not represent noncash consideration because the customer has not provided the vendor with a separate asset or right of value in exchange for the vendor’s services. Rather, the data is provided only so that the agentic AI vendor can perform under the service contract, and the customer is making its own asset available for the vendor to be able to deliver its service back to the customer. Moreover, even if a separate asset were determined to exist, the vendor’s limited rights to use the data would suggest that the asset is not distinct from the services being provided.

By contrast, if the vendor obtains broader rights to use the data (e.g., through an explicit license grant), that fact alone does not mean that data rights represent noncash consideration. Instead, an entity should determine whether rights are (1) capable of being distinct and separately identifiable from the promised services in accordance with ASC 606-10-25-19 and (2) sufficient to give rise to a recognizable asset under GAAP. Although the data rights may be capable of being distinct in some cases (e.g., if the vendor routinely purchases similar data in stand-alone transactions), it is often more challenging to assess whether those rights are separately identifiable from the service being delivered in the context of the contract. Further, even if the rights were determined to be distinct, they would not represent noncash consideration if they do not result in a recognizable asset under GAAP. For example, if the right to use the data would be expensed as incurred because it will be used in research and development activities and has no alternative future use, the vendor would not have obtained an asset and therefore would not have received noncash consideration. Accordingly, the analysis should focus on whether the customer has transferred rights that are distinct from the service being provided and, if so, whether those rights give rise to a recognizable asset. See the Data Acquisition Costs section in Deloitte’s October 7, 2024, Technology Spotlight for further discussion of situations in which acquired data give rise to a recognizable asset. An entity must use significant judgment when assessing whether data provided by a customer constitute a form of noncash consideration.

Changing Lanes

At its March 12, 2026, agenda committee meeting, the EITF voted to add to its agenda a project on consideration payable to a customer; the Task Force plans to discuss this issue at a future EITF meeting. Although the scope of the EITF’s future deliberations, as well as any resulting conclusions, remains uncertain, vendors may find the Task Force’s thinking on consideration payable to a customer useful in evaluating whether data rights received from a customer are distinct from the services the vendor provides.

Example 2

Entity C, an agentic AI SaaS vendor, enters into a contract to provide automated refund-request processing services to a customer. Under the contract, C will deploy an AI agent that reviews customer refund requests, evaluates whether the requests meet the customer’s refund-policy criteria, and either approves or denies the requests.

To perform the contracted services, the customer provides C with access to its refund-request data (including request content, metadata, and outcome labels) during the contract term. However, under the contract, C’s rights to use the data are limited to providing the contracted services to that customer. Entity C is not permitted to use the customer’s data to train or improve its models for general use, deploy model improvements derived from that data in serving other customers, sell or license the data, or otherwise use the data for any purpose other than performing under the contract. In addition, C must return or destroy the data at the end of the contract term in accordance with the customer’s instructions.

Although C uses the data in performing the services, the customer has not granted C a separate license or other substantive right to use the data beyond what is necessary for C to fulfill its obligations under the contract. Rather, the customer is making its data available so that C can provide the contracted services.

Entity C concludes that the customer data do not represent noncash consideration because the data rights are not distinct from the revenue arrangement. Entity C’s rights to use the data are limited to performing the contracted service for the customer and do not provide C with a separate asset in exchange for its services. Rather, the customer is making its own data available only so that C can perform under the service contract. Moreover, even if the arrangement were viewed as conveying some right to use the data, that right would not be distinct from the services being provided. Accordingly, the customer data do not represent noncash consideration from the customer.

Q&A 3 — Determining Whether an Agentic AI SaaS Arrangement Represents a Stand-Ready Obligation or an Obligation to Provide a Specified Amount of Successful Outcomes

In assessing the appropriate revenue recognition model for an agentic AI SaaS arrangement, an entity must first determine the nature of its promise to provide services. In some arrangements, the entity may price an agentic AI SaaS arrangement on the basis of expected successful outcomes, but it may not always be clear whether the nature of the promise is (1) an obligation to provide a specified amount of successful outcomes (e.g., a promise to provide 5,000 successful outcomes) or (2) a stand-ready obligation to provide the agentic AI SaaS arrangement when the customer needs it (e.g., a promise to make the agentic AI SaaS available throughout a specified term to process transactions remitted during the period).

Question

What factors should an entity consider when determining the nature of its promise in an agentic AI SaaS arrangement?

Answer

The factors an entity should consider when determining the nature of its promise in an agentic AI SaaS arrangement are the same factors that an entity would evaluate when assessing whether a traditional SaaS arrangement represents a stand-ready obligation or an obligation to provide a specified amount of services. The figure below includes indicators that an entity should consider when performing this assessment. Indicators are not individually determinative, and entities will need to exercise judgment.

Figure 3

When defining the nature of the promise, entities should consider historical judgments and conclusions regarding existing offerings to ensure similar promises are consistent.

Example 3

Entity B contracts with an e-commerce customer to provide an agentic AI customer service chatbot (the “AI agent”) that autonomously resolves customer refund requests. The key terms of the contract are as follows:

Entity B will deliver 250,000 fully resolved refund cases by using AI (i.e., without human escalation).
Each successful resolution reduces the remaining number of cases the customer is entitled to receive.
The contract stipulates that the customer may roll over unused balances into a future period. Once the 250,000 successful outcomes are delivered, the customer’s right to additional AI-resolved cases ends, and the customer must make a separate purchasing decision (e.g., new purchase order [PO] or addendum) to acquire additional successful outcomes.
Entity B has no enforceable obligation to provide services beyond the 250,000 successful outcomes unless and until the customer executes that additional purchase.
Entity B also sells the service separately on a successful-outcome-only (pay-as-you-go) price-per-case basis for incremental volumes.
The contract states that B may “use customer data to improve the service,” and B will tune the model over the contract term to improve the AI agent’s success rate. The contract with the customer limits B’s rights to the customer’s data to providing the contracted service, and B cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract.

The contract is priced as follows:

Up-front payment of $5 million for 250,000 successful outcomes (i.e., $20 per outcome).
The customer’s prepaid balance is reduced only by successful outcomes (the purchase bundle represents payment for successful outcomes), and unsuccessful attempts do not count toward the bundle.

A refund case is a “fully resolved refund case using AI” only when, as defined in the contract:

The AI agent completes the workflow end to end without human escalation (e.g., verifies eligibility, applies policies, triggers a refund or credit, and sends customer confirmation).
The case meets defined completion and quality criteria defined in the contract.

The nature of B’s promise is an obligation to provide a specified amount of successful outcome (250,000) that satisfies the over-time criterion in ASC 606-10-25-27(a). This conclusion is supported by the following:

The customer has the right to roll over unused volume into a future period.
Each successful outcome diminishes the customer’s remaining rights.
The customer’s right to use the service terminates upon reaching the specified volume.
Upon reaching the specified volume, the customer must make a separate purchasing decision, and B has no enforceable obligation to provide additional services in the absence of that decision.
Entity B separately sells the service on a successful-outcome-only price-per-unit basis.
The customer simultaneously receives and consumes the benefits (i.e., successful outcomes) provided by the service as it is performed.

In addition, the ongoing training of the agentic AI on a when-and-if-available basis is an internal activity that B performs to fulfill its promise to deliver successful AI-resolved outcomes and does not represent a separate promised service.

The $20 per successful case fee is earned only when B transfers a complete successful outcome to the customer. If the contractual success criteria are not met, the customer has not received the completed service for which the fee is charged and must complete the remaining work through manual intervention or other processes. Because the promise is a specified quantity of outcomes, B would recognize revenue when the services are provided by using an output method on the basis of successful outcomes delivered (e.g., $20 per successful case).

If the customer is not expected to use all specified volume and unused volume does not remain available (or otherwise meet the criteria for breakage), B would consider whether breakage is applicable. For further discussion, see Section 8.8 of Deloitte’s Roadmap Revenue Recognition.

Q&A 4 — Applying the Series Guidance to Agentic AI SaaS

Under ASC 606-10-25-14(b), a performance obligation is considered a series of distinct goods or services if such goods or services “are substantially the same and . . . have the same pattern of transfer to the customer.” To help entities make that determination, ASC 606-10-25-15 states:

A series of distinct goods or services has the same pattern of transfer to the customer if both of the following criteria are met:

Each distinct good or service in the series that the entity promises to transfer to the customer would meet the criteria in paragraph 606-10-25-27 to be a performance obligation satisfied over time.
In accordance with paragraphs 606-10-25-31 through 25-32, the same method would be used to measure the entity’s progress toward complete satisfaction of the performance obligation to transfer each distinct good or service in the series to the customer.

Question

Does an Agentic AI SaaS meet the criteria to be considered a series?

Answer

If the nature of the promise is a stand-ready obligation, the nature of the promise is to stand ready to provide ongoing access to the service, and each day represents a distinct day of service provided to the customer. The blue squares in the timeline below represent the nature of the promise, which is to provide the same service each day (access) over the contractual term.

On the other hand, if the nature of the promise is to provide a specified amount of successful outcomes, the nature of the promise is not to provide ongoing access but, instead, to provide a specified amount of successful outcomes. The green squares in the timeline below illustrate that the service is delivered only as each successful outcome occurs. Some days may have more successful outcomes, and other days may have no successful outcomes.

The decision tree below illustrates how the nature of the promised goods or services affects whether the series guidance applies when the promised good or service is satisfied over time:

When a revenue contract includes a series of goods or services that are each distinct in the arrangement, substantially the same, and satisfied over time by using the same measure of progress, ASC 606 requires an entity to bundle these distinct promises into a single performance obligation, called a “series,” rather than viewing the arrangement as having multiple performance obligations. This evaluation is important because it will affect how the entity identifies the performance obligation (i.e., whether the arrangement is viewed as having one or multiple performance obligations). Further, as discussed in Q&A 7, if the agentic AI SaaS arrangement includes variable consideration, an entity will need to consider how to allocate the variable consideration to each distinct service within the series.

Q&A 5 — Measuring Progress Toward Complete Satisfaction of the Performance Obligation

Once an entity has determined the nature of the promise to the customer, the entity must determine how to appropriately recognize revenue.

Question

How should an entity measure the progress toward the complete satisfaction of an agentic AI SaaS arrangement?

Answer

It depends on whether the nature of the promise represents a stand-ready obligation or an obligation to provide a specified amount of successful outcomes.

To select an appropriate measure of progress, an entity needs to use judgment on the basis of the arrangement’s particular facts and circumstances. In a typical stand-ready agentic AI SaaS arrangement, the entity promises to make the agentic AI SaaS available to its customer throughout the contractual period. In many of these arrangements, the entity may reasonably conclude that it is standing ready to provide the customer with access to the agentic AI SaaS when and if the customer needs it; the customer therefore benefits from the promise of standing ready evenly throughout the contract period. As a result, it would generally be appropriate to apply a time-based measure of progress over the period during which the customer has rights to use the SaaS. However, in other instances, the nature of an entity’s promise may be to provide a specified quantity of successful outcomes; in such cases, a measure of progress based on outcomes (i.e., an output method) may more faithfully depict the pattern of transfer than a time-elapsed method.

Q&A 6 — Applying the Invoice Practical Expedient to Stand-Ready Agentic AI SaaS Arrangements With Outcome-Based Variable Consideration

Agentic AI SaaS arrangements may be structured with pricing that is tied to successful outcomes (e.g., per resolved case, per completed transaction, or per prevented error). This pricing structure matters under ASC 606 because variable consideration generally requires estimation and application of the constraint, which can be operationally complex and may introduce volatility.

ASC 606-10-55-18 provides the following practical expedient, which can be applied to performance obligations that are satisfied over time:

As a practical expedient, 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 (for example, a service contract in which an entity bills a fixed amount for each hour of service provided), the entity may recognize revenue in the amount to which the entity has a right to invoice.

Commonly referred to as the “invoice practical expedient,” this approach allows an entity to recognize revenue in the amount of consideration that the entity has the right to invoice if such an amount corresponds directly to the value transferred to the customer. That is, the invoice practical expedient cannot be applied in all circumstances because the amount that an entity has the right to invoice does not always correspond to the value of the entity’s performance to date. For example, if the customer was required to make a significant up-front payment that was not associated with the satisfaction of a separate performance obligation (i.e., the up-front payment was allocated to the SaaS performance obligation), the entity’s right to invoice may not correspond directly to the value of the entity’s performance to date. Therefore, the entity should demonstrate its ability to apply the invoice practical expedient to performance obligations satisfied over time. In addition, because the use of the invoice practical expedient must faithfully depict the entity’s measure of progress toward completion, the expedient can be applied only to performance obligations satisfied over time (not at a point in time).

Question

Can an entity apply the invoice practical expedient to an agentic AI SaaS arrangement with a variable pricing structure based on successful outcomes?

Answer

It depends.

If the agentic AI SaaS arrangement is transferred to the customer over time and (1) has a pricing structure that is solely variable on the basis of successful outcomes, (2) is priced at a fixed rate per outcome, and (3) gives the entity the right to invoice the customer for its outcomes as they occur, the entity might be able to apply the invoice practical expedient. In such cases, the amount of revenue that the entity has the right to invoice may reflect the value the customer has obtained from the agentic AI SaaS during the period because it is a fixed rate based on the volume of successful outcomes. Accordingly, an entity with this type of arrangement is not required to estimate the amount of variable consideration to which it would be entitled at contract inception and instead can recognize revenue as the successful outcomes occur (provided that it also has the right to invoice).

However, use of the “invoice practical expedient” would most likely not be appropriate when (1) there are fixed fees (in addition to the outcome-based fees), (2) there are substantive minimum requirements, (3) the outcome price varies during the contract period, or (4) up-front or back-end fees are charged. In those circumstances, it may be challenging to demonstrate that the amount the entity has the right to invoice corresponds to the value the customer has received to date.

Q&A 7 — Applying the Variable Consideration Allocation Exception to Agentic AI SaaS Arrangements With a Stand-Ready Promise and Outcome-Based Variable Consideration

An entity that cannot apply the invoice practical expedient should evaluate whether it meets the variable consideration allocation exception if the series guidance applies, as discussed in Q&A 4.

Generally, ASC 606 requires an entity to allocate the transaction price to each performance obligation on a relative stand-alone selling price basis. However, the guidance provides an exception to the general allocation principle that applies specifically to variable consideration (the “variable consideration allocation exception”). Specifically, ASC 606-10-32-39(b) states that variable consideration may be attributable to “[o]ne or more, but not all, distinct goods or services promised in a series of distinct goods or services that forms part of a single performance obligation.” In addition, ASC 606-10-32-40 states the following:

An entity shall allocate a variable amount (and subsequent changes to that amount) entirely to a performance obligation or to a distinct good or service that forms part of a single performance obligation in accordance with paragraph 606-10-25-14(b) if both of the following criteria are met:

The terms of a variable payment relate specifically to the entity’s efforts to satisfy the performance obligation or transfer the distinct good or service (or to a specific outcome from satisfying the performance obligation or transferring the distinct good or service).
Allocating the variable amount of consideration entirely to the performance obligation or the distinct good or service is consistent with the allocation objective in paragraph 606-10-32-28 when considering all of the performance obligations and payment terms in the contract.

Question

If an entity elects not to apply the invoice practical expedient or is precluded from applying this expedient to a stand-ready agentic AI SaaS arrangement, may it apply the variable consideration allocation exception to outcome-based fees?

Answer

It depends.

Because a stand-ready agentic AI SaaS arrangement would typically be a series of distinct services that represent a single performance obligation, an entity that does not apply the invoice practical expedient would apply the variable consideration allocation exception if the conditions in ASC 606-10-32-40 are met.

Criterion (a): Whether the Variable Payment Is Specifically Related to a Distinct Service or Outcome

An entity that receives variable consideration on the basis of usage or outcomes would typically meet the first condition in ASC 606-10-32-40(a) if the variable payment is associated with a specific outcome occurring in a distinct period (e.g., each day or month the SaaS is provided) and the contract includes clear, objective, and measurable criteria related to determining when that successful outcome has occurred. For outcome-based pricing, the contract must define what constitutes a “successful outcome” with sufficient specificity to allow both parties to determine when the entity has satisfied its performance obligation and earned the right to consideration. For example, the contract may specify that an outcome is successful only when (1) the AI agent completes the workflow end to end without human intervention, (2) the result meets defined quality or accuracy standards, (3) the output is validated through an agreed-upon method, or (4) the outcome is not reversed or challenged within a specified window. Without clear contractual success criteria, the variable payment may not be specifically related to an outcome under ASC 606-10-32-40(a).

Criterion (b): Whether the Variable Consideration Is Allocated to the Distinct Period in a Manner Consistent With the Allocation Objective

However, an entity must carefully evaluate its pricing structure to determine whether allocating variable consideration to a distinct service period (e.g., each day or month in which SaaS is provided) is consistent with the allocation objective in ASC 606-10-32-28. The allocation objective is to allocate the transaction price to each performance obligation (or distinct service within a series) in an amount that depicts the consideration to which the entity expects to be entitled in exchange for transferring the promised goods or services to the customer.

Factors that may indicate that the allocation objective is met include:

The variable consideration is priced at a consistent rate per successful outcome throughout the contract term, and that rate represents the stand-alone selling price.
The variable consideration resets each period (e.g., monthly success-rate tiers that apply only to that month’s outcomes) and does not depend on cumulative performance across multiple periods.
Successful outcomes in one period do not affect the pricing of outcomes in another period (no volume-based tiering, no cumulative thresholds, no cross-period true-ups).
The pricing for each agentic AI agent reflects its stand-alone value and is not set on the basis of expected usage of other agents or services in the arrangement.
Success criteria are not defined in a manner that makes it impracticable to determine in a given period whether and when the outcome has been achieved.
The customer receives no benefit from an unsuccessful outcome (e.g., if the AI agent is unsuccessful, the customer will spend substantially the same amount of time as it would have spent if the AI agent had not been used).

If the variable consideration allocation exception does not apply, the entity must estimate at inception the total variable consideration for the contract (subject to the constraint in ASC 606-10-32-11) and generally recognize it over time by using a time-based measure of progress, updating the estimate in each reporting period.

In all the examples below, it is assumed that the customer receives no benefit from an unsuccessful outcome (e.g., if the AI agent is unsuccessful, the customer will spend substantially the same amount of time as it would have spent if the AI agent had not been used).

Example 4

Entity A sells an agentic AI SaaS platform that continuously monitors a retailer’s Web site for fraudulent activity and can autonomously block suspicious actions. The key terms of the contract are as follows:

The revenue contract provides the retailer with continuous access (24/7) to the platform over a one-year term.
The contract does not include a specified volume of interventions (the retailer has unlimited monitoring and blocking throughout the contractual term).
Fraud attempts (and therefore interventions) are driven primarily by external threat activity rather than deliberate procurement actions by the retailer.
The contract states that A may “use customer data to improve the service,” and A will tune the model over the contract term to improve the platform’s success rate. The contract with the customer limits A’s rights to the customer’s data to provide the contracted service, and A cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract.

The contract is priced as follows:

$1 million annual access fee (fixed, regardless of usage).
$3 per successful autonomous intervention (each time the AI independently detects and blocks a fraudulent attempt), billed in arrears. The retailer pays only for interventions that meet the contractual definition of “successful.”

An intervention is “successful” only when all of the following conditions are met, as defined in the contract:

The platform autonomously executes preventive action (e.g., blocks a login, prevents checkout, holds an order) without human review or override.
The action is validated as fraud-preventing on the basis of an agreed-upon method under the contract.

The nature of A’s promise is a stand-ready obligation to provide access to the platform over the contract term, which meets the over-time criterion in ASC 606-10-25-27(a) and is treated as a series of distinct service periods. This conclusion is supported by the following:

The contract does not include any specified volume of usage (unlimited access).
Entity A must stand ready to provide the service over the entire contractual period regardless of whether usage increases.
The retailer’s right to remaining service is affected only by time, not by the number of interventions performed.
Usage is driven primarily by downstream or third-party activity, not procurement decisions.
The customer simultaneously receives and consumes the benefits (i.e., ongoing access) provided by the service as it is performed.

In addition, the ongoing “training” of the platform based on the retailer’s data is an internal activity that A performs to fulfill its stand-ready promise to provide continuously improved fraud-monitoring and blocking capabilities.

Entity A would recognize the fixed access fee over time by using a time-based measure of progress. Entity A would not apply the invoice practical expedient in ASC 606-10-55-18 because the consideration includes a fixed annual access fee and therefore does not directly correspond solely to the value of services transferred in each period.

The outcome-based fees are earned only when A transfers a complete successful outcome to the customer in the period. If the contractual success criteria are not met, the customer has not received the completed service for which the variable fee is charged and must complete the remaining work through manual intervention or other processes. The $3 per successful autonomous intervention is outcome-based variable consideration priced at a fixed rate per successful outcome, and the variable consideration allocation exception is applied because the fee is specifically related to the number of successful interventions occurring in the period, which is an outcome from A that satisfies its performance obligation, and allocating the success fee to that period meets the allocation objective. Accordingly, A is not required to estimate success-based fees at contract inception and instead recognizes revenue as successful interventions occur (i.e., when the contractual “successful” criteria are satisfied).

Example 5

Entity C contracts with an e-commerce customer to provide an agentic AI customer service chatbot (the “AI agent”). The key terms of the contract are as follows:

The contract is a 12-month term.
The contract provides the customer with continuous access to submit refund requests for automated handling throughout the term and does not include any specified volume of requests, attempts, or successful resolutions (the customer has “unlimited access”).
Entity C is required to stand ready to provide the service throughout each month of the term, regardless of how many requests are submitted.
The customer’s right to remaining service is affected only by the passage of time (continued access each month), not by volumes processed.
Usage volume is driven primarily by the submission of refund requests by the customer’s end customers rather than deliberate procurement actions.
The contract states that C may “use customer data to improve the service,” and C will tune the model over the contract term to improve the AI agent’s success rate. The contract with the customer limits C’s rights to the customer’s data to provide the contracted service, and C cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract.

The contract is priced on a monthly payment scale that resets monthly. The fee is based on the percentage of successful outcomes achieved during that month and applies only to that month’s service period as follows:

If the AI agent’s monthly resolution success rate is above 80 percent or more, pay $18,000.
If between 70 percent and 79 percent, pay $15,000.
If between 60 percent and 69 percent, pay $12,000.
If below 60 percent, pay $0.

The monthly resolution success rate is calculated, as defined in the contract, as follows:

Numerator (successful outcomes) — Eligible refund requests completed end to end by the AI agent without human escalation, meeting completion and quality criteria.
Denominator (eligible requests) — Refund requests submitted during the month that meet predefined eligibility criteria for automation, excluding contractually defined out-of-scope items (e.g., fraud investigations, regulatory exceptions, missing required data, or other defined exclusions).

If there are no AI agent customer service requests during the period, C will not have a right to any consideration.

The nature of C’s promise is a stand-ready obligation to provide access to the platform over the contract term, which meets the over-time criterion in ASC 606-10-25-27(a) and is treated as a series of distinct service periods. This conclusion is supported by the following:

The contract does not include any specified volumes of usage (unlimited access).
Entity C is required to stand ready to provide the service over the entire contractual period, regardless of usage volume.
The customer’s right to remaining service is affected only by time, not by consumption of a finite amount of usage.
Usage is driven primarily by downstream third parties (C’s customer’s submitted refund requests), not procurement actions.
Variable monthly payments do not affect the customer’s access rights; rather, they affect only how much is paid for that month.
The customer simultaneously receives and consumes the benefits (i.e., ongoing access) provided by the service as it is performed.

In addition, the ongoing training of the agentic AI on a when-and-if-available basis is an internal activity that C performs to fulfill its stand-ready promise to provide continuously improved automated refund-handling capabilities; it is not a separate promised service.

Entity C would recognize revenue for the stand-ready service over time by using a time-based measure of progress. The outcome-based fees are earned only when C transfers a percentage of successful outcomes for each month. If the contractual success criteria are not met, the customer has not received the completed service for which the variable fee is charged and must complete the remaining work through manual intervention or other processes.

Because the consideration is determined solely by each month’s success-rate result, depicts the consideration expected for outcomes provided, resets monthly, and applies only to that month’s service period, C applies the variable consideration allocation exception and allocates the variable consideration to the distinct monthly service period to which it is related. Accordingly, C recognizes revenue when the month’s outcome metric is determined and criteria are satisfied.

Example 6

Assume the same facts as in Example 5, except that the success rate does not reset monthly but instead is calculated on the basis of the AI agent’s overall success rate for the entire 12-month term (i.e., total successful outcomes for the year as a percentage of total eligible requests for the year). The nature of Entity C’s promise remains a stand-ready performance obligation over the 12-month term. However, because the fee is determined on the basis of the aggregate success rate for the entire term, the variable consideration is not specifically attributable to a distinct month within the series of distinct service periods.

Accordingly, the variable consideration allocation exception is not applied, and C estimates the total variable consideration (subject to the constraint) for the 12-month term and recognizes it over time by using a time-based measure of progress. Entity C would update its estimate of variable consideration in each reporting period.

Example 7

Entity D sells an agentic AI finance operations platform that processes invoices end to end, including controls and enterprise resource planning (ERP) posting. The platform includes multiple agents that operate as part of the workflow, such as:

Invoice ingestion agent (captures invoice data from e-mail, PDF, or electronic data interchange and creates the invoice record).
Three-way match agent (matches invoice to PO and receives document within configured tolerances).
Fraud and controls agent (runs control checks, including duplicate detection and policy or vendor flags, and applies holds or blocks when needed).
Posting agent (posts to ERP and initiates payment workflow in accordance with the delegated authority matrix).

The key terms of the contract are as follows:

The contract provides continuous access (24/7) to the platform and all agents over a one-year term.
The contract does not include a specified volume of invoices.
Volume is driven by purchasing activity and vendor billing patterns rather than deliberate procurement actions.
The contract states that D may “use customer data to improve the service,” and D will tune the model over the contract term to improve the platform’s success rate. The contract with the customer limits Entity C’s rights to the customer’s data to provide the contracted service, and C cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract.

The contract is priced as follows:

$600,000 annual access fee (fixed, regardless of usage).
Outcome-based fees, billed in arrears, payable only when the contractual definition of “successful” is met:
- $1.25 per invoice processed straight through (STP) (posted with no human intervention).
- $1 per duplicate payment prevented (verified duplicate identified and blocked so no payment is made).

A “successful” outcome is achieved only when (1) the invoice is posted correctly to the ERP (ERP document ID and required field validations), (2) approvals follow the delegated authority matrix (workflow audit trail, no overrides), and (3) controls pass and the transaction is not reversed for cause within an agreed-upon window. This outcome occurs when the invoice ingestion agent, three-way match agent, and posting agent are successful.

For duplicate prevention, “successful” requires the fraud and controls agent to log, hold, or block action and demonstrate that no payment occurred, with the prevention not overturned within the agreed-upon window.

The nature of D’s promise is a stand-ready obligation to provide access to the platform over the contract term, which meets the over-time criterion in ASC 606-10-25-27(a) and is treated as a series of distinct service periods. This conclusion is supported by the following:

The contract does not include any specified volume of usage (unlimited access).
Entity D must stand ready to provide processing capability throughout the contractual period, regardless of actual volumes.
The customer’s right to remaining service is affected primarily by time, not by the number of invoices processed or outcomes achieved.
Volumes are driven primarily by downstream purchasing or vendor billing activity rather than the customer’s making discrete procurement decisions for each invoice.
The customer simultaneously receives and consumes the benefits (i.e., ongoing access) provided by the service as it is performed.
The ongoing training of the agentic AI on a when-and-if-available basis is an internal activity D performs to fulfill its stand-ready promise to provide continuously improved invoice-processing and control capabilities and therefore is not a separate promised service.
Entity D would recognize the fixed access fee over time by using a time-based measure of progress. The $1.25 per STP invoice and $1 per verified duplicate payment prevented are outcome-based variable consideration priced at fixed rates per successful outcome. The outcome-based fees are earned only when D transfers a complete successful outcome to the customer in the period. If the contractual success criteria are not met, the customer has not received the completed service for which the variable fee is charged and must complete the remaining work through manual intervention or other processes.

Entity D applies the variable consideration allocation exception because the fees are specifically related to the successful outcomes in the period (which is an outcome from A’s satisfaction of its performance obligation) and allocating the fees to that distinct period meets the allocation objective. Accordingly, D is not required to estimate the outcome-based fees at contract inception and instead recognizes revenue as successful outcomes occur (i.e., when the contractual “successful” criteria are met).

Example 8

Entity F sells a modular agentic AI SaaS platform that comprises four independent AI agents (Agents A–D). Each agent is independent of the others, can be deployed on a stand-alone basis, and has its own contractual definition of a “successful outcome.” The customer enters into a 12-month contract. At contract inception, Agents A–D are provisioned and available to all authorized users (including engineers) throughout the term; no separate order form, addendum, PO, or click-through is required to access any agent. Users may toggle which agents are deployed during a given month for operational purposes. This toggle does not change contractual entitlements or create additional enforceable rights or obligations, and agents may be turned on/off without any coterminous commitment. The contract does not specify any minimum or maximum volume of activity.

The contract states that F may “use customer data to improve the service,” and F will tune the model over the contract term to improve the platform’s success rate. The contract with the customer limits F’s rights to the customer’s data to provide the contracted service, and F cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract.

The contract is priced as follows (billed monthly in arrears):

The customer is charged only for successful outcomes achieved by agents that are deployed in the applicable month.
Pricing is fixed per successful outcome for each agent:
- Agent A: $4.00 per successful outcome.
- Agent B: $7.50 per successful outcome.
- Agent C: $2.25 per successful outcome.
- Agent D: $12.00 per successful outcome.

Entity F sells Agents A–D on a stand-alone basis to other customers at the same per-successful outcome rates. In addition, there are no tiered pricing, credit, rebate, retroactive true-up, or other pricing features that would cause consideration paid for one agent to depend on the outcome of another agent.

A “successful outcome” is defined separately for each agent in the contract and is achieved only when the agent’s agent-specific criteria are met.

The nature of F’s promise is a stand-ready obligation that is a series of distinct periods for the following reasons:

The customer has the right to access and deploy the agents on a discretionary basis and the company has made the agents available to the customer to deploy throughout the contract term.
The contract does not include any specified volumes of usage (unlimited access).
Entity F is required to stand ready to provide access to the agents over the entire contractual period regardless of usage volume.
The customer’s right to remaining service is affected only by time, not by consumption of a finite amount of usage.
Usage is driven primarily by downstream users within the organization (engineers that are deploying agents), not procurement actions.
Variable monthly payments do not affect the customer’s right to access; rather, they affect only how much is paid for that month for usage of the agents.

In addition, the per-agent, per-successful-outcome fees are variable consideration priced at fixed rates per qualifying outcome that represent their stand-alone selling price and are specifically related to the distinct monthly service period in which the outcomes occur. Entity F therefore applies the variable consideration allocation exception and recognizes revenue as successful outcomes occur (i.e., when the contract’s definition of success is satisfied for the applicable agent), without estimating total variable consideration at contract inception. The ongoing training of the agentic AI on a when-and-if-available basis is an internal activity F performs to fulfill its stand-ready promise to provide continuously improved agent capabilities and therefore is not a separate promised service.

Note that the variable consideration allocation exception applies only if the per successful-outcome consideration is specifically related to the relevant agent (or the distinct monthly service period) and allocating it on that basis is consistent with the allocation objective. If the per outcome rate for one agent is set or discounted on the basis of the expected purchase or use of other agents (i.e., bundled or cross subsidized pricing in such a way that consideration for Agent A is, in substance, partially compensation for Agent D), the entity may not be able to apply the variable consideration allocation exception and may need to estimate variable consideration.

Example 9

Entity G sells a modular agentic AI SaaS platform that comprises a core hosted platform and four independent AI agents (Agents A–D). Each agent is independent of the others, can be deployed on a stand-alone basis, and is priced separately.

The customer enters into a 12-month contract that includes (1) a platform subscription and (2) Agent A. The platform subscription provides access to the hosted environment and core platform functionality (e.g., admin, security, monitoring, support) for a fixed fee of $10,000 per month. On day 1, the customer also purchases Agent A for a 12-month term for a fixed fee of $120,000, plus usage-based fees of $0.08 per run billed monthly in arrears on the basis of actual usage. The contract does not specify any minimum or maximum volume of activity for Agent A.

The contract states that G may “use customer data to improve the service,” and G will tune the model over the contract term to improve the service’s performance. The contract with the customer limits G’s rights to the customer’s data to provide the contracted service, and G cannot sell, license, disclose, or otherwise use the customer data except to perform services under the contract.

The contract also grants the customer the right (but not the obligation) to purchase additional agents in the future (Agents B–D). The customer is not required to purchase any additional agents, and no penalties apply if the customer does not purchase them. Each additional agent may be purchased only through a separate PO that specifies the agent purchased, a 12-month term beginning on the PO effective date, and agent-specific pricing as follows:

Agent B: fixed fee of $75,000 plus $0.05 per run.
Agent C: fixed fee of $200,000 plus $0.12 per run.
Agent D: fixed fee of $40,000 plus $0.03 per run.

The customer’s rights to purchase Agents B–D are options and do not create enforceable rights and obligations for those agents unless and until a separate PO is executed. Accordingly, expected purchases of Agents B–D are not variable consideration in the day 1 contract. When the customer executes a PO for an additional agent, F accounts for that PO as a separate contract (or as a contract modification treated as a separate contract) because it adds a distinct agent with its own stated consideration. Entity G would also need to evaluate the contract for a material right.

Contacts

If you have questions about this publication, please contact the following Deloitte industry professionals:

	Aaron Shaw U.S. Technology Industry Professional Practice Director Audit & Assurance Partner Deloitte & Touche LLP +1 202 220 2122 aashaw@deloitte.com		Chris Chiriatti Audit & Assurance Managing Director Deloitte & Touche LLP +1 203 761 3039 cchiriatti@deloitte.com
	Mark Strassler Audit & Assurance Managing Director Deloitte & Touche LLP +1 415 783 6120 mstrassler@deloitte.com		Kristin Bauer Audit & Assurance Partner Deloitte & Touche LLP +1 312 486 3877 kbauer@deloitte.com
	Dan Le U.S. Audit & Assurance Technology Sector Lead Partner Deloitte & Touche LLP +1 206 716 6015 dle@deloitte.com		Jean-Denis Ncho Oguie U.S. Audit & Assurance TMT Industry Leader Partner Deloitte & Touche LLP +1 415 783 6600 jnchooguie@deloitte.com
	Radwan Edlbi Audit & Assurance Partner Deloitte & Touche LLP +1 415 783 6676 mhedlbi@deloitte.com		Ky Kano Audit & Assurance Partner Deloitte & Touche LLP +1 808 543 0746 kykano@deloitte.com
	Joe Catsavas Audit & Assurance Senior Manager Deloitte & Touche LLP +1 510 775 3164 jcatsavas@deloitte.com		Marissa Lee Audit & Assurance Senior Manager Deloitte & Touche LLP +1 415 783 7678 marissalee@deloitte.com
	Jessica Lievanos Audit & Assurance Senior Manager Deloitte & Touche LLP +1 714 436 7283 jlievanos@deloitte.com

Footnotes

For titles of FASB Accounting Standards Codification (ASC) references, see Deloitte’s “Titles of Topics and Subtopics in the FASB Accounting Standards Codification.”

FASB Accounting Standards Update (ASU) No. 2014-09, Revenue From Contracts With Customers (Topic 606).