Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
.png)
The Monetization Stack (the set of technical components that carry a deal from quote to cash) is useful to model as seven layers, laid out in the order the pipeline actually runs. The deal is constructed at the front (Layer 1: CPQ). The runtime then governs, measures, and prices usage (Layers 2 through 4: entitlements, metering, rating). (see Figure 8)
The finance layers invoice it, recognize the revenue, and post it to the system of record (Layers 5 through 7: billing, revenue recognition, ERP). Other practitioners draw the boundaries differently, and, as the next section argues, the weight is distributed very differently for a self-serve product than for an enterprise one. But these seven capture the work, and every one of them is under significant stress in the AI era. Figure 8. The Monetization Stack - the seven technical layers that carry a deal from quote to cash, in the order the pipeline runs.
This is the front of the pipe: the system where a deal is constructed before it is sold. Sales selects the products, applies the pricing rules and discounts, and generates the quote and the order form. It is what produces the bespoke contracts the rest of the stack then has to honor: the committed spend, the included allowance, the discounted overage rate that applies only to one model. In the per-seat world, CPQ's job ended at the signed document. The contract was countersigned, the terms were handed to billing, and CPQ never had to talk to the product.
In the agentic world it does. The terms CPQ produces (committed usage, included tokens, model-specific restrictions) are precisely the entitlements the runtime has to enforce in real time. A commitment that lives only in a signed PDF is not yet enforceable; for it to bind, CPQ's output has to flow downstream into the entitlement layer, so that when a customer's agent reaches for a model the contract did not include, the system can act on it. That connection, between a system sales owns and a runtime engineering owns, did not exist in the per-seat world, and it is one of the most demanding seams in the stack.
This is the system that answers the question: "Is this user allowed to do X?"
In the per-seat world, entitlements were binary. You either had access to a feature or you did not, based on your tier. In the agentic world, entitlements are quantitative and tiered. You might be entitled to ten thousand agent tasks per month, five hundred thousand tokens per day, the larger context window but not the most expensive model, or five concurrent agent sessions rather than fifty.
These entitlements need to be checked in near real time, sometimes mid-inference, to prevent cost overruns. A customer whose agent is mid-task when their credit balance reaches zero poses a decision the older entitlement model was never designed to make: halt the task and discard the work in progress, or let it complete and absorb the cost?
In the per-seat world, metering was trivial: you counted logins or active users. In the agentic world, you need to meter input tokens versus output tokens, reasoning tokens versus generation tokens, tool calls versus model calls, agent sessions by duration and complexity, and the external API invocations the agent makes on the customer's behalf.
This requires a high-throughput, idempotent event ingestion pipeline that can handle duplicates and late-arriving data without dropping billable events or double-counting them. Accuracy here is a first-order requirement: at scale, a two percent discrepancy between metered and actual usage corresponds to hundreds of thousands of dollars a year, so the pipeline has to be precise as well as fast.
This is the system that applies pricing rules to metered usage to calculate billable amounts.
In the per-seat world, rating was multiplication. In the agentic world, rating involves tiered rates (the first thousand agent tasks cost fifty cents each, the next five thousand cost thirty), volume discounts (spend over ten thousand dollars per month and the rate drops fifteen percent), time-of-day pricing (peak versus off-peak compute), customer-specific negotiated rates, and credit burndown calculations that track how much of a prepaid commitment the customer has consumed.
The complexity is not in any individual calculation. It is in the combination of all of them, applied in real time to a stream of usage events that may arrive out of order. Consider a single enterprise deal: "commit to fifty thousand dollars a year, receive one million tokens included, then pay overage at a discounted rate, but only on the Pro model." Rating has to compute that correctly every cycle, alongside every other customer's terms, which is why this logic cannot live hard-coded in the application backend.
This is the system that generates invoices, processes payments, handles disputes, and manages collections.
In the per-seat world, billing was a calendar event: generate the invoice on the first of the month, collect payment on the fifteenth. In the agentic world, billing may need to happen in real time (for prepaid credit models), in arrears (for consumption models), or on a hybrid schedule (monthly subscription plus quarterly usage true-up).
There is also a translation problem hiding in this layer. Billing systems speak in invoice line items; metering systems speak in events. Something has to aggregate "1,402,302 tokens consumed between September 1 and September 30" into a single line that reads "Overage: $42.06." And the invoice itself has to show the customer not just what they owe but what they consumed, broken down by usage type, so the charge can be understood and verified.
This is the system that determines when revenue can be recognized under accounting standards like ASC 606.
In the per-seat world, revenue recognition was straightforward: you recognized the subscription ratably over the contract period. In the agentic world it is significantly more complex: usage-based revenue is recognized as the usage occurs, prepaid credits may need to be recognized as they are consumed or as they expire, and hybrid models require allocating the transaction price across multiple performance obligations.
Finance teams that were built to handle SaaS revenue recognition are discovering that agentic revenue requires a fundamentally different accounting treatment, and that the system where it all has to land, the last layer of the stack, was not designed for it either.
This is the back of the pipe: the enterprise resource planning system (NetSuite, SAP, Oracle) that serves as the system of record for the general ledger, accounts receivable, and financial reporting. It is where recognized revenue lands and where ASC 606 compliance is ultimately reported to auditors and the board. In the per-seat world, the interface to the ERP was simple because the revenue was simple: a subscription recognized ratably is a clean, predictable entry posted on a schedule. In the agentic world, billing has to feed the ERP a stream of event-driven revenue: usage recognized as it occurs, prepaid credits drawn down and expired, transaction prices split across multiple performance obligations. The ERP was built to recognize subscriptions, not events, and bridging that gap (without breaking the close, the audit trail, or the controls finance depends on) is where the back of the pipe strains.
Join companies like Zoom, DocuSign, and Twilio using our systematic pricing approach to increase revenue by 12-40% year-over-year.