You Can't Bill for an Outcome You Can't Prove
Software pricing is moving off the seat. Pure per-seat plans are now a minority, and hybrid structures carrying usage or outcome components are the common form. The constraint nobody priced in: an outcome you cannot independently verify is not billable. Outcome pricing is a provenance problem wearing a finance costume.
What actually changed
The 2026 surveys disagree on magnitude and agree on direction. Kyle Poyar's State of B2B Monetization survey of 230 companies puts hybrid — a base fee plus a variable usage or outcome component — at 37%, the single most common structure, up from 25% a year earlier. A Cruxy survey of 300 SaaS CEOs in April found 97% intending to retire seat-based pricing within two years. IDC forecasts that 70% of software vendors will have moved off pure per-seat by 2028. Estimates of how much pure per-seat is left range from the mid-teens down to single digits depending on who is counting and what they count.
The stated cause is agents: when one autonomous workflow absorbs the work of a dozen license-holders, seat count stops tracking value delivered, and a vendor priced on seats watches its revenue fall as its product gets better. That is a real mechanism and it explains the direction of travel.
It does not explain why so few vendors have landed on outcome pricing itself. Almost everyone announcing a move off seats has landed on hybrid instead — a seat floor with per-resolution or per-transaction upside. Hybrid is not a philosophy. It is where you stop when the pure version won't survive procurement.
The three conditions
Outcome pricing works when three things are simultaneously true, and it collapses into a dispute when any one of them isn't:
The outcome is technically verifiable inside your own system. Not inferrable, not proxied by a satisfaction click — recorded, as an event, at the moment it happened.
The outcome is cleanly attributable to your product rather than to the five other things that also touched the workflow that week.
Both parties agreed what counts as success before the contract was signed — and the definition is legible enough that neither side can relitigate it at renewal.
Read those again and notice what they are. None of them is a pricing question. All three are questions about instrumentation: what your system records, how precisely it attributes, and whether the record is intelligible to someone who wasn't there. The pricing model is downstream of the data model. Vendors are discovering this in the order that hurts most — they sell the outcome, then go looking for the evidence.
The billing question and the audit question are the same question, asked by different departments.
Verifiable to whom
There is a weaker and a stronger version of "verifiable," and the gap between them is where the disputes live.
The weak version: your system produces a number and the customer takes your word for it. This is most usage billing today. It works while the relationship is good and fails the first time the number is large and surprising, because the customer's only recourse is to doubt you in general rather than check you in particular.
The strong version: your system produces a record the customer can check without trusting you — an append-only log, exportable line items, timestamps fixed at the moment of the event rather than asserted afterward. The counterparty doesn't have to believe your integrity. They have to believe arithmetic. It costs more to build, it is the only version that holds when money is attached, and it is the same architecture auditors and regulators ask for. Build it once, serve three masters.
What this looks like in shipped systems
We build the strong version by default, for reasons that have nothing to do with pricing.
LeoLog is the clearest case because verification is the product. Each entry is hashed with SHA-256 and encrypted on the device before anything leaves it, then anchored on-chain — Base for fast confirmation, Bitcoin via OpenTimestamps for durable finality. The content never touches the chain; only the fingerprint does. Every anchored entry exports a Certificate of Existence and a proof bundle that anyone can check at verify.leolog.io with no LeoLog account, and which would still check out if LeoLog didn't exist. That last property is the whole point: a record whose credibility does not depend on the continued goodwill of the company that issued it.
LeafIQ makes the same move in an industry where the billable event is physical. Routes, orders, deliveries, and AR live on one data model, so the delivery that gets invoiced is the same delivery the compliance trail describes — not a reconciliation between a driver's texts and an accounting system. LegiOS carries each obligation with its citation, jurisdiction, effective date, and deadline, which is what makes the calendar re-derivable rather than hand-maintained when a date moves — an argument we made in last week's post. In Casebound, a matter cannot open without a cleared conflicts check, an AI draft from the Lexwright engine cannot reach a client without a recorded attorney disposition, and every mutation is audited — including from an admin account.
And MagenticOS is where the agent version of this problem gets worked out directly: if an autonomous system is going to be trusted with actions, the actions need receipts, which is the argument in Agent Actions Need Receipts. An agent that reports success without emitting a checkable artifact of what it did is unbillable for exactly the same reason it is unauditable.
None of these products bills on outcomes today, and this post is not an announcement that they will. The observation is narrower and more useful: the record you would need in order to bill on outcomes is the record you already need for the audit. If you have built the second, the first is a pricing decision. If you haven't, it is a rebuild.
The test
For any system you are building or buying, ask one question: can a party who does not trust us verify this claim from the artifacts we produce? Not "can we produce a report." Not "do we log it." Can a skeptical counterparty — a customer disputing an invoice, an auditor sampling a quarter, a regulator asking what you knew and when — reconstruct the claim without your help.
If the answer is no, you do not have an outcome you can price. You have an assertion you can make, which is a different asset with a different shelf life. The same discipline shows up outside software: the reason a research process is worth following is that its rules were fixed before the trade, not narrated after it, which is the standing argument on the MacroSavant Substack.
The move off the seat is being reported as a pricing story. It is really the moment the industry discovers that it has been selling things it never instrumented. Systems that captured the work, proved it, and kept the proof checkable get to participate. Systems that captured a login count get to keep charging for logins. That distinction is the whole of what we mean by an operating system for an industry.
We publish here as we learn. Subscribe by RSS, or write to hello@mutagenic.io.