Implementing the Deloitte ASC 606 Guidance for Outcome-Based AI Pricing

The arrival of formal guidance from a major accounting firm on outcome-based AI pricing signals that the model is now mainstream enough to have established rules. Translating the judgments in this guidance into auditable practice however reveals a significant gap that most existing billing systems were not designed to address.

From theory to practice in AI revenue recognition

The release of Deloitte's June 4, 2026 Technology Spotlight, "Accounting for Outcome-Based Pricing in an Agentic AI Software Product" provides a legitimate accounting framework for outcome-based pricing under ASC 606. For finance leaders, this document is a critical step forward. It offers a structured way to think about revenue recognition in a world where value is measured by results not seats.

This article serves as a practical implementation guide. We will translate the accounting judgments in the Deloitte guidance into concrete system requirements. The core challenge is that most billing systems cannot produce the specific evidence this guidance assumes you have. This post is for informational purposes. You must finalize your revenue recognition policies with your own accountants and auditors.

Know the nature of your promise

A central judgment in the Deloitte guidance, discussed in its Q&A 3, is determining the nature of your service promise. Are you providing a "stand-ready" obligation to make a service available over a term or are you promising a "specified quantity" of successful outcomes? The answer is set by your contract terms, but an auditor will want to see systemic evidence consistent with the promise you claim. The following table summarizes the indicators from Deloitte's Figure 3.

The evidence your system must produce depends on which promise you make. A stand-ready promise with per-outcome fees billed in arrears is evidenced by the outcome records themselves: the service was available all term and each fee traces to a confirmed outcome in a distinct period. A specified-quantity promise adds a second burden. You must also track a decrementing entitlement balance, block service at exhaustion and record the new purchase order that extends it. That is one reason many vendors structure contracts as stand-ready access with per-outcome fees, the pattern Deloitte's Examples 4, 7 and 8 analyze. It is the lighter promise to evidence and the simpler one to account for.

System requirement: your records must match your promise type. Stand-ready access with per-outcome fees needs complete outcome records. Fixed quantities also need entitlement tracking.

Translating contractual success into executable logic

Defining a successful outcome is the foundation of outcome-based billing. Deloitte's Q&A 7, criterion (a) requires that the criteria for success be "clear, objective, and measurable". For auditable revenue recognition per successful outcome at scale, prose definitions in a contract are insufficient. They are open to interpretation and difficult to verify consistently across thousands or millions of transactions. This gap between legal language and operational reality creates significant audit risk.

The system requirement is clear. Your billing platform must translate contractual language into machine-executable rules. For example, at witn, we define success using a condition tree that evaluates a stream of event data. This tree can apply operators like "event seen" or "count thresholds" to determine if a specific outcome has been achieved. This turns a subjective definition into a deterministic calculation. You can find more detail on how to determine what counts as a resolution in practice.

Immutability is just as important for auditability. The system must snapshot the exact contract conditions onto each outcome at the moment the outcome is created. This ensures that subsequent contract edits can never retroactively alter the basis for revenue that has already been recognized. The system must prove not just that an outcome was successful but that it was successful under the specific rules in effect when it was opened.

System requirement: your billing system must convert contractual success criteria into executable, machine-evaluated logic and snapshot the rules applied to every outcome.

Gating revenue recognition with a settlement period

Defining success is one part of the equation. Knowing when to recognize the revenue is another. The Deloitte guidance in Q&A 7 introduces the concept of a reversal window, where an outcome is only considered final if it is "not reversed or challenged within a specified window". This directly impacts the timing of revenue recognition. Your billing infrastructure must enforce a formal settlement period to comply with this principle.

This is not a manual process. The system must manage this automatically. In witn, an outcome that meets its initial success criteria enters a provisional "PENDING" state. It only transitions to a "CONFIRMED" state after a configurable settlement window passes without any contrary events. If a new, relevant event occurs, such as a customer dispute or a data correction, the settlement window must reset. This system-enforced delay provides the auditable evidence needed to satisfy the ASC 606 constraint on variable consideration. It proves that a significant reversal is no longer probable. Our discussion on revenue recognition for outcome-based AI billing explores this policy choice further.

System requirement: your billing system must enforce a configurable settlement window that gates revenue recognition until an outcome is final.

Aligning invoicing with revenue recognition expedients

Your pricing structure has a direct impact on the complexity of your revenue recognition. The Deloitte guidance highlights two powerful simplifying tools: the "invoice practical expedient" (ASC 606-10-55-18) and the "variable consideration allocation exception" (ASC 606-10-32-40). As discussed in Q&A 5 and Q&A 6, these expedients are most accessible when you use straightforward pricing models.

Deloitte's Examples 4, 7 and 8 all rely on a simple structure: a fixed rate per outcome, billed in arrears. This is not a coincidence. This model allows revenue to be recognized in the amount you have the right to invoice, avoiding complex estimations and allocations. The system requirement that emerges is that your billing system must be able to generate invoices where each line item corresponds to a single, confirmed outcome at a fixed price. This means only invoicing for outcomes that have passed their settlement window.

The key insight here is that fixed per-outcome rates are not a limitation. They are a strategic choice that makes outcome-based pricing auditable and defensible. Your system must enforce this discipline by applying a simple rate card to confirmed outcomes, not to pending ones.

System requirement: your billing system must generate invoices from confirmed outcomes at a fixed rate per unit.

Building an immutable audit trail for every charge

Ultimately, your process will be tested during an audit. The auditor's core question for any invoiced charge will be simple: "Show me when the success criteria were met and when the settlement window closed". Answering this question requires more than a spreadsheet. It demands an append-only, immutable log of all events and system-driven status transitions. This is the foundation of an auditable billing system.

This audit trail must contain several key components. First is an immutable history of all input events that influence an outcome. Second is a persisted record of the outcome's state transitions, for example from PENDING to CONFIRMED, with timestamps. Third is an archived record of the specific contract version and success criteria applied to that outcome. This is not about re-deriving state from logs after the fact. The system must persist the state of each outcome as it was determined. This provides irrefutable, point-in-time evidence that revenue was recognized correctly and in accordance with your stated policy.

System requirement: your billing system must maintain an immutable, append-only log of events, state transitions and applied contract rules for every outcome.

Issues handled outside the billing system

It is also important to understand what your billing system is not responsible for. The Deloitte guidance addresses implementation services and customer data as noncash consideration in Q&A 1 and Q&A 2. These are primarily contract and legal questions, not billing system requirements. Your system does not determine if setup activities are a distinct performance obligation. The practical takeaway from the guidance, particularly Example 2, is that contractually limiting data rights to service delivery for a specific customer is a legal drafting issue, not a billing configuration.

Pricing structures that complicate compliance

While simple pricing models are easier to manage, some businesses may choose more complex structures. The Deloitte guidance identifies several that require more careful handling. For instance, Example 6 shows how using cumulative success-rate tiers across periods can cause you to lose the variable consideration allocation exception. Similarly, Example 4, which uses a hybrid of a fixed fee plus outcomes, loses the invoice practical expedient. The message is clear: simpler, more direct pricing structures lead to simpler, more defensible revenue recognition. Complex models increase audit risk by requiring more extensive estimation and justification.

A checklist for your billing infrastructure

To implement the Deloitte guidance effectively, your billing infrastructure must provide specific, auditable evidence. As you evaluate your systems, ensure they can meet these five core requirements.

1. Promise evidence: can the system show, for every charge, that it is consistent with the promise you made, whether stand-ready or specified quantity?
2. Executable criteria: can the system translate contractual success criteria into machine-evaluated logic?
3. Settlement windows: does the system gate revenue recognition with a configurable settlement period?
4. Fixed-rate invoicing: does the system support invoicing at a fixed rate per confirmed outcome?
5. Immutable audit log: does the system maintain an append-only log of events, state transitions and applied contract rules for every outcome?