Outcome-based AI pricing needs a decision ledger

Outcome pricing turns a product claim into an accounting rule. The moment a vendor bills for a resolution, a recovered dollar, or a completed workflow, both sides need to know which event counts, what evidence supports it, and when human work or another system deserves the credit. The pricing model is only as defensible as the decision ledger underneath it.

The market is moving in that direction. Salesforce has announced pay-per-resolution pricing for Agentforce Help Agent, while its broader Agentforce pricing includes consumption and action-based structures. Microsoft has introduced trace replay and agent ROI capabilities that connect execution traces with task completion, time saved, and cost efficiency. These products differ, but the signal is shared: buyers want the bill to move closer to work completed and value created.

That is good pressure. It also exposes an unsolved part of the contract. A status change is easy to count. Attribution is the harder question. If an agent proposed the right action, a human rewrote it, another system executed it, and the customer record later moved to resolved, how much of that outcome belongs on the AI invoice?

Event counting is not attribution

Event counting observes a final state. A ticket closed. A candidate advanced. A renewal completed. A payment posted. Those events can be authoritative and still say nothing about which participant produced them. The state may have changed because of the agent, because of a human, because of an existing automation, or because the customer took an action independently.

Outcome-based pricing AI therefore needs a contractual attribution rule rather than a broad claim of causality. The rule defines the contribution the product must make before an event becomes billable. In a customer service workflow, the parties might agree that a resolution counts only when the agent completed the approved path, no human materially rewrote the work, the authoritative service system recorded the resolved state, and the case stayed closed through an agreed validation window.

The exact rule will vary. The need for one will not. Without it, the vendor sees a resolved field and the buyer sees a mixed process. Both can be looking at the same database row and disagree honestly about what it means.

This is why the price should follow the proof. The outcome metric must be defined before the billing period, and the evidence for each event has to survive review after the invoice arrives. A monthly dashboard is useful for totals. It is not enough to settle a disputed line item.

What belongs in the decision ledger

The decision ledger begins before the agent acts. It records the baseline state the parties agreed to measure from. That may be the open service case, the pending workflow, the unreviewed proposal, or another state in a customer-owned system of record. The baseline needs a timestamp, a stable identifier, and an authoritative source.

Next comes the proposed action. The system states what it wants to do, which records it read, and what evidence supports the proposal. If the proposal changes during review, the ledger preserves the original and the edited version. This matters because a human who corrects the substance of the work made a different contribution from a human who merely approved it.

The approval event identifies the person with authority to proceed. A regulated workflow may require a second signer. Approval is not a generic click. It is a recorded choice to approve, edit, or decline a specific proposal on specific evidence. Digital labor needs that approval gate before execution, and outcome billing needs the same event so finance can distinguish agent work from human rescue.

Execution then records the command sent to the system of record and the response returned. A proposal that never executed cannot produce a billable outcome. An API call that failed halfway through should remain visible as a failed attempt, not disappear behind a final status that someone else repaired.

The outcome record comes from the source the contract names as authoritative. Vendor telemetry can explain what the AI system did. It should not be the sole authority for whether the customer's business outcome occurred. The final field is the finance rule: the pre-agreed logic that turns the full record into billable, excluded, shared, pending, or disputed.

Together, those fields create a Decision Trace that can answer two questions from the same evidence. Operations can ask why the action happened. Finance can ask why the event appeared on the invoice. The trace becomes billing infrastructure because it connects the unit of work to the unit of price.

Human edits change the billable unit

Human involvement does not automatically disqualify an outcome. Many enterprise workflows should require approval. The meaningful distinction is whether the human authorized the agent's work or materially performed the work the vendor is charging for.

If a reviewer checks the evidence and approves the proposed action unchanged, the agent may have completed the contracted unit while the human supplied governance. If the reviewer replaces the reasoning, corrects the underlying record, or rewrites the execution payload, the ledger should capture that intervention. The contract can then exclude the event, share credit, or apply a different rate.

This distinction protects both sides. The buyer avoids paying full outcome price for work its employees had to reconstruct. The vendor receives credit when its system did the substantive work even though policy required a human signature. A blanket rule such as any human touch voids the outcome would punish good governance. A rule that ignores edits would charge for human labor. The ledger makes a more precise contract possible.

Declines matter too. A proposed workflow that a human rejects should remain in the record with the reason. It is not billable execution, but it is valuable product evidence. Repeated declines reveal a model, context, or permission problem. That pattern should feed evaluation and product improvement without being relabeled as successful work.

Shared outcomes need precedence rules

Enterprise work crosses systems. One agent may classify an incoming request, another may extract records, an existing workflow may calculate a field, and a human may make the final judgment. Every component can point to the same resolved event. If each vendor bills from the final state alone, one outcome can appear on several invoices.

The contract needs precedence rules before that happens. It may assign the outcome to the system that completed the final approved action. It may define smaller billable units for each stage. It may allow shared attribution when contributions are independently verifiable. The correct design depends on the process. The wrong design is to let every tool claim the same terminal event.

Stable identifiers make those rules enforceable. The case, proposal, approval, execution, and result need to refer to one another across systems. Timestamps help establish sequence. Source records establish authority. Human edits establish contribution. Without that chain, finance receives several plausible stories and no common record to compare them against.

The decision ledger should also preserve exclusions: duplicate events, reopened cases, failed execution, customer cancellation, policy exceptions, and outcomes outside the agreed measurement window. An outcome price earns trust when the exclusions are as inspectable as the successes.

How the trace becomes invoice evidence

The invoice should be an aggregation of validated traces. A buyer reviewing the total can open a sample, follow the proposal through approval and execution, see the authoritative result, and inspect the finance rule that classified it. A disputed item can be moved out of the payable set without erasing the operational record.

This connects observability to procurement. Microsoft is right that traces can explain how an outcome was produced and that ROI should connect running cost with business value. The next step is contractual: preserve the trace fields and classification rules in a form the customer's finance team can query, export, and reconcile.

A queryable trace also prevents the vendor from becoming the accountant of record for its own performance. The vendor can calculate the invoice, but the source events and approval history remain available to the buyer. Finance can reproduce the classification against customer-owned systems rather than accept a number that only the seller can generate.

This is the operational extension of a proposal arriving pre-priced. Before action, the system shows the cost of acting and declining to act. After action, the same chain records what executed and what result followed. The proposal supports the decision. The trace supports the invoice.

Put attribution in the contract

The product demo should show more than the happy path. Ask the vendor to open a completed outcome, an edited proposal, a declined action, a failed execution, and a disputed billing event. If those records do not connect, the pricing model is ahead of the product.

The contract should name the billable unit, the authoritative system of record, the baseline rule, the validation window, the treatment of human edits, the treatment of shared outcomes, the exclusion set, the dispute process, and the buyer's export rights. It should also state what happens to the ledger at exit. An outcome price built on evidence should leave the evidence with the customer.

Salesforce's pay-per-resolution move is a useful market marker because it puts vendor success closer to customer success. Microsoft's trace-to-ROI work is another because it treats execution evidence and business value as one operating loop. Buyers should welcome both directions and demand the architecture that lets the pricing survive finance review.

Pricing exposes the product underneath it. Seat pricing needs identity. Consumption pricing needs a meter. Outcome pricing needs a decision ledger. If an outcome cannot survive a trace query, it should not survive onto the invoice.

Sources

Salesforce announces pay-per-resolution pricing

Microsoft Foundry: from observability to ROI for AI agents

Salesforce Agentforce pricing

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.