One meter can bill the customer and book the revenue.

The price became a measurement, and measurements need systems.

For twenty years the revenue number at a software company came from two stable things: a contract that said what the customer had bought, and a count of seats that changed a few times a year. Revenue accounting was hard in the way contracts are hard, full of judgement about performance obligations and standalone selling prices, but the inputs sat still while you thought about them. You could print the order form and reason about it.

That is changing quickly, and the numbers are no longer small. Deloitte’s 2026 technology predictions cite a Maxio survey finding that 83 percent of AI native software companies currently offer usage based pricing, and quote Gartner saying at least 40 percent of enterprise software spend will shift toward usage, agent or outcome based pricing by 2030. The same report makes an observation that sounds like product advice and is really an accounting warning: these models need agreed definitions of an agent, a task, a process, an interaction and an outcome, and system instrumentation and metering may have to become more advanced while data observability, billing and financial compliance become more real time.

Read that as a controller and the consequence is direct. If the price is a count of things that happened, then the thing producing the count has become a source document. It is usually a stream of events emitted by application code, designed by engineers for product analytics, shipped on a weekly cadence, with retention set by storage cost and a schema nobody thought of as permanent. None of that is a criticism of how it was built. It was built for a purpose, and it does that purpose well. The purpose has now quietly expanded.

The good news is that this is a solved problem on the accounting side. The guidance for variable consideration is fifteen years of thinking old, both standard setters have recently reviewed it and concluded it works, and the paragraphs that matter here are short and readable. The work that remains is engineering work with a clear specification, which is a far better position than waiting for a standard. What follows is the specification.

Two doors, and the contract decides which one you walk through.

On 4 June 2026 Deloitte published a Technology Spotlight dealing specifically with outcome based pricing in agentic software, and KPMG has a webcast on revenue for AI companies scheduled for 1 October 2026. Reading the Deloitte piece in full, the striking thing is how little new law there is in it. The analysis runs through paragraphs that have been in the standard since it was written. What has changed is how many contracts now land on them.

The first question is the nature of the promise. Either you are standing ready to provide access to a service throughout a term, which is satisfied over time because the customer simultaneously receives and consumes the benefit, or you are obliged to deliver a specified quantity of successful outcomes. The tells for the second are concrete: each success reduces a remaining entitlement, the customer’s right ends when the quantity is consumed, and getting more requires a fresh purchase order rather than simply continuing. Where usage is driven by downstream events, a customer’s own end customers submitting refund requests, or fraud attempts arriving from outside, the promise is almost always the stand ready one.

A stand ready hosted service is typically a series of distinct service periods under ASC 606-10-25-14(b) or IFRS 15 paragraph 22(b), which is the structural fact everything else rests on. Being a series is what makes it possible to say that a variable fee belongs to March rather than to the contract as a whole. Without the series, there is one undifferentiated performance obligation and the variable amount has nowhere specific to go.

The comparison worth sitting with is the last two rows against each other. Deloitte’s Example 5 has a monthly fee set by that month’s resolution success rate: 18,000 dollars above 80 percent, 15,000 dollars between 70 and 79, 12,000 dollars between 60 and 69, and nothing below 60. Because it resets each month and applies only to that month’s service, the variable amount is allocated to that month and recognised when the month’s metric is determined. Example 6 keeps every one of those facts and changes exactly one: the success rate is computed across the whole twelve month term instead of monthly. That single change means the fee is not attributable to any distinct month, so the exception falls away and the company must estimate total variable consideration at inception, apply the constraint, recognise it over time on a time based measure, and revisit the estimate every reporting period.

Same product. Same price. Same meter. Same customer experience. One clause in the order form separates reading a number off a system from running an estimation model four times a year and documenting it for an auditor. That is worth knowing at the point the clause is drafted, which is months before anyone in revenue accounting normally sees it.

One route is worth closing off explicitly, because it is the first place experienced revenue people reach. The sales based or usage based royalty treatment, where you recognise only as the usage occurs and never estimate anything, is genuinely simple and genuinely unavailable here. IFRS 15 paragraph 58 and paragraph B63 confine it to a royalty promised in exchange for a licence of intellectual property, and the US equivalent does the same. A hosted service is not a licence. The FASB’s post-implementation review of Topic 606 even records that the Board considered widening the exception beyond licensing when the standard was written and decided against it, because it would add complexity or delay revenue past the point goods and services transfer. The door is closed deliberately rather than by oversight.

A definition of success is a query over somebody’s audit trail.

The allocation exception has a first criterion that reads like boilerplate and is the whole game in practice. The payment terms must relate specifically to your effort to transfer that distinct service, or to a specific outcome from doing so. Deloitte’s reading of that for outcome pricing is blunt: the contract has to define a successful outcome with enough specificity that both parties can tell when the obligation has been satisfied and the right to consideration earned. Without clear contractual success criteria, the payment may not be specifically related to an outcome at all, and the exception is not available.

The clearest way to see what that demands is Deloitte’s Example 7, which happens to be an accounts payable agent. The arrangement carries a 600,000 dollar annual access fee, 1 dollar 25 per invoice processed straight through, and 1 dollar per duplicate payment prevented. A successful outcome is defined as an invoice posted correctly to the ERP with a document identifier and passing required field validations, approvals that followed the delegated authority matrix with a workflow audit trail and no overrides, and controls passing with the transaction not reversed for cause within an agreed window. Duplicate prevention requires the controls agent to have logged, held or blocked the payment, to demonstrate no payment occurred, and for the prevention not to be overturned inside the window.

Read that sentence as a specification and every clause is a condition something has to evaluate and store. A document identifier exists. A set of validations passed. An approval chain matched a matrix. No override was applied. A window elapsed without a reversal. The revenue for that line is the count of rows satisfying all of it. Which means the vendor’s revenue recognition depends on evidence produced inside the customer’s own system of record, and the vendor has to be able to show that evidence to its own auditor months later.

This cuts both ways, and the second direction is the more interesting one. If you are the buyer rather than the seller, an outcome priced contract is an invoice you cannot check unless the same evidence is available to you. Agreeing a success definition without agreeing how it will be evidenced, retained and recomputed is how a procurement win becomes a dispute in month seven. The asymmetry is worth fixing at signature, and the fix is a clause about evidence and retention rather than a clause about price.

There is a related trap in the denominator. A tiered or performance based fee turns on a success rate, and a rate needs both numbers. Deloitte’s Example 5 spells out the denominator carefully: eligible requests submitted in the month meeting predefined automation criteria, excluding contractually defined out of scope items such as fraud investigations, regulatory exceptions and missing required data. If your event pipeline only writes a row when something succeeds, which is a very common and entirely reasonable design choice for product telemetry, the denominator does not exist anywhere and the fee cannot be recomputed by anyone. That is a schema decision made years earlier with no accounting intent whatsoever, and it is the single most common way this goes wrong.

Build the event record once and let both jobs run off it.

The practical answer to all of this is a single well built record per outcome, serving billing and revenue at the same time, rather than a metering feed for invoicing and a separate reconstruction for the close. The fields that make that work are not exotic. Most of them are the things you would want anyway for a billing dispute, which is a useful argument to have ready when asking for engineering time.

-- One row per outcome. Append only: a reversal is a new row, never an edit.
create table outcome_event (
  event_id                uuid primary key,
  idempotency_key         text        not null,
  contract_id             text        not null,
  contract_version        int         not null,
  customer_id             text        not null,
  agent_or_sku            text        not null,

  occurred_at             timestamptz not null,   -- when the outcome happened
  recorded_at             timestamptz not null,   -- when we learned about it
  accounting_period       date        not null,   -- derived from occurred_at

  success_criteria_version int        not null,
  success_result          boolean     not null,   -- failures are stored too
  exclusion_reason        text,                   -- contractually out of scope
  evidence_ref            text,                   -- document id, workflow trail

  rate_applied            numeric(18,6),
  unit_amount             numeric(18,6),
  currency                char(3)     not null,

  reversal_of             uuid references outcome_event(event_id),
  reversal_reason         text,

  billing_status          text        not null default 'unbilled',
  revenue_status          text        not null default 'unrecognised',

  unique (idempotency_key)
);

-- The success rate a tiered fee turns on. It needs the denominator,
-- which only exists because failures were written down.
select accounting_period,
       contract_id,
       count(*) filter (where success_result)                  as successes,
       count(*) filter (where exclusion_reason is null)        as eligible,
       round(100.0 * count(*) filter (where success_result)
             / nullif(count(*) filter (where exclusion_reason is null), 0), 2)
                                                               as success_rate_pct
from   outcome_event
where  reversal_of is null
group  by accounting_period, contract_id;

-- The exception query to run before the close, not after it.
select 'no contract version'   as issue, event_id from outcome_event where contract_version is null
union all
select 'priced off contract',  event_id from outcome_event e
  where not exists (select 1 from contract_rate r
                    where r.contract_id = e.contract_id
                      and r.contract_version = e.contract_version
                      and r.rate = e.rate_applied)
union all
select 'landed in closed period', event_id from outcome_event e
  join period_status p on p.period = e.accounting_period
  where p.status = 'closed' and e.recorded_at > p.closed_at
union all
select 'reversal with no original', event_id from outcome_event e
  where e.reversal_of is not null
    and not exists (select 1 from outcome_event o where o.event_id = e.reversal_of)
union all
select 'success with no evidence', event_id from outcome_event
  where success_result and evidence_ref is null;

Two things in that shape deserve a note. The first is that failures are stored. It costs almost nothing and it is the difference between a success rate you can recompute and one you have to assert. The second is that reversals are appended rather than applied. Contracts in this space routinely make success conditional on the outcome not being overturned inside an agreed window, which means reversals are part of the normal path rather than an error case. An append only history lets you answer the question an auditor will eventually ask, which is not whether the number is right today but whether you can explain how it got there.

The occurred_at and recorded_at pair is the other piece worth insisting on early. They diverge routinely and the gap is exactly where cutoff problems live. An outcome that happened on the 30th and arrived on the 3rd belongs in the earlier period, and the only way to demonstrate that after the fact is to have stored both timestamps at the time. Measuring the size of that late tail each month turns your cutoff from an assumption into a policy you can describe.