Why GaaS Valuations Can't Use SaaS Revenue Multiples

Table of Contents

• The Multiple Everyone Reaches For
• What a SaaS Multiple Secretly Assumes
• Where GaaS Breaks Each Assumption
• The Revenue Quality Problem
• Margin Is the Whole Ballgame Now
• What to Anchor On Instead
• A Worked Example: Two Companies, Same ARR
• Insights Most People Overlook
• References

The Multiple Everyone Reaches For

When a board deck needs a valuation number fast, the reflex is automatic. Take ARR, multiply by whatever comparable software companies trade at, and call it a range. That habit is baked into a decade of muscle memory. Public SaaS has spent years training investors to think in revenue multiples because, for a pure software business, revenue was a remarkably clean proxy for value. Costs barely moved when you added a customer, so revenue and gross profit tracked each other closely. The multiple worked because the thing it ignored, cost of goods sold, was almost a rounding error.

Agentic AI-as-a-Service quietly demolishes that convenience. A GaaS company sells the output of agents that run on someone else's expensive inference infrastructure. When a customer uses the product more, the vendor's bill goes up in near-lockstep. Revenue still looks like software revenue on the income statement, but underneath it behaves more like a managed service or even a logistics business: every unit of output has a real, recurring, variable cost attached. Apply a 12x SaaS multiple to that and you are valuing a company as if its revenue were almost pure margin. It isn't.

This is not a minor adjustment. It is a category error, and it is the single most common mistake in how early GaaS businesses get priced.

What a SaaS Multiple Secretly Assumes

A revenue multiple is never really about revenue. It is a compressed shorthand for three deeper beliefs about the business. To see why GaaS breaks the model, you have to unpack what the SaaS multiple is actually pricing.

First, it assumes high and stable gross margin, typically 75% to 85%. A revenue multiple is implicitly a gross-profit multiple where the conversion rate from revenue to gross profit is high and consistent. When Bessemer and others built the canonical SaaS benchmarks, they could lean on revenue precisely because margin was a near-constant. The classic framework here is the Bessemer Cloud Index and the "good, better, best" SaaS metrics, which assume software-grade margins as table stakes.

Second, it assumes durable, recurring revenue. The "R" in ARR means a customer who paid last year is overwhelmingly likely to pay again, and the default state is renewal. Churn is the exception you measure, not the baseline you fear.

Third, it assumes negligible marginal cost to serve. The next API call, the next seat, the next workflow run costs the vendor essentially nothing incremental. That is what justifies paying for revenue years out, because most of that future revenue drops to the bottom line.

Strip any one of those assumptions and the multiple loses its meaning. GaaS strips all three at once.

Where GaaS Breaks Each Assumption

Marginal cost is no longer near zero

This is the foundational break. In SaaS, serving one more unit of usage costs fractions of a cent. In GaaS, serving one more completed task means real inference spend, model calls, often several of them, sometimes across multiple vendors, plus retries when the agent stumbles. The cost of goods sold is no longer hosting and support; it is compute, and compute scales with usage. We've covered this dynamic in depth in the discussion of when compute becomes your COGS and what lessons GaaS should steal from cloud providers who learned it first.

The practical consequence: a GaaS company at 45% gross margin and a SaaS company at 80% gross margin can report identical revenue and identical growth, yet the SaaS company produces nearly twice the gross profit per dollar of revenue. A revenue multiple treats them as equals. Gross profit says they are nothing alike.

"Recurring" is doing a lot of work

Most GaaS revenue is consumption, not subscription. A customer doesn't churn in the SaaS sense, they just run fewer tasks. Usage can fall 40% quarter over quarter while the logo stays "active," which means the revenue base is far softer than an ARR figure implies. This is exactly why churn is often invisible in GaaS until it's catastrophic: there's no cancellation event to trip your alarms. The revenue simply evaporates one workflow at a time.

Forecastability collapses

SaaS ARR is contractual and smooth, which is why it earns a forward multiple. GaaS revenue is lumpy, seasonal, and tied to how much work customers happen to push through the agents in a given month. Per-task pricing makes forecasting nearly impossible compared to seat-based SaaS, and uncertain future revenue is worth less per dollar than certain future revenue. The market pays a premium for predictability, and GaaS, in its current form, can't offer it.

The Revenue Quality Problem

Here's the part that the headline ARR number actively hides: not all GaaS revenue is created equal, and the multiple can't see the difference.

Consider two revenue streams of the same size. One comes from a vendor that runs agents on its own fine-tuned open-weight models with aggressive caching, holding 65% gross margin. The other comes from a vendor that pays through to frontier-model APIs for every call and holds 25%. On a revenue-multiple basis, both might get tagged at the same valuation. But the first company keeps 65 cents of every dollar to reinvest, and the second keeps 25. Over a few years of compounding, the gap in enterprise value should be enormous, and a revenue multiple papers right over it.

This is why a16z and other thoughtful investors have started arguing that AI businesses should be valued on gross profit, not revenue, because the variable cost structure makes the revenue line a misleading headline. Two GaaS companies with identical ARR can have wildly different economic engines, and only the margin tells you which one is real.

The blunt version: in SaaS, revenue was a fair proxy for value. In GaaS, revenue is a starting point you immediately have to deflate by a margin you can't assume.

Margin Is the Whole Ballgame Now

If you internalize one shift, make it this: in GaaS, gross margin is not a footnote, it is the headline metric that determines what multiple, if any revenue multiple at all, is defensible.

A SaaS company holds margin almost passively. A GaaS company holds margin only through active, ongoing engineering work, caching, smart model routing, prompt compression, capping autonomy where it doesn't pay, choosing open-weight models where quality allows. We get into these levers in caching, memory, and the quiet levers of agent gross margin. The point for valuation is that margin in GaaS is earned and defended rather than given, which makes it both more variable and more revealing about the quality of the team.

Margin is also volatile in a way SaaS margin never was. Inference prices move. Model providers reprice. An agent that worked at three model calls per task starts needing seven as you handle harder cases. None of that touches a SaaS gross margin, but all of it hammers a GaaS one. McKinsey's work on the economics of generative AI underscores how much of the value, and the cost, sits in the inference layer rather than the software wrapper. A valuation that ignores this volatility is mispricing the risk, not just the level.

There is one nuance worth flagging. Falling token prices don't automatically rescue margin, because cheaper tokens tend to get spent on more reasoning, more retries, and more ambitious agents. The cost floor keeps moving, but so does what customers expect the agent to do. Valuing on today's margin without modeling that treadmill is its own trap.

What to Anchor On Instead

So if the revenue multiple is the wrong tool, what's the right one? A more honest GaaS valuation rests on three pillars, in roughly this order of importance.

Gross-profit multiples, not revenue multiples. Value the gross profit, revenue minus inference and infrastructure COGS, and apply a multiple to that. This single change neutralizes most of the distortion, because it forces the margin difference between two companies to show up directly in the valuation. A 25%-margin agent business and a 65%-margin one will no longer be priced as twins.

Revenue durability, not revenue level. Ask how much of the consumption base would survive a bad quarter. Cohort retention by use case, the human-intervention rate as a leading churn signal, and net revenue retention on usage all tell you whether the revenue is sticky or fragile. Durable, expanding usage deserves a premium; lumpy, declining usage deserves a discount, regardless of the current run rate.

Unit economics that improve with scale. The best GaaS businesses show margin expanding as volume grows, caching hit rates climb, reserved compute gets cheaper, routing gets smarter. That's a fundamentally different and more valuable trajectory than a business whose margin is flat or compressing as it grows. A unit-economics teardown, the kind done for a coding agent at scale, reveals this curve in a way no top-line number can.

The throughline: stop pricing the revenue, start pricing the profit and its durability.

A Worked Example: Two Companies, Same ARR

Make it concrete. Two GaaS companies each report $10M ARR, both growing 100% year over year.

Company A runs a support agent on open-weight models with a 70% cache-hit rate and reserved compute. Gross margin: 68%. Gross profit: $6.8M. Net revenue retention: 130%, because customers route more ticket volume through the agent over time. Apply, say, a 10x multiple to that gross profit and you're near $68M, and you'd argue for more given the expansion.

Company B runs a similar-looking agent but passes every call through to frontier APIs, eats heavy retries, and caps nothing. Gross margin: 22%. Gross profit: $2.2M. Net revenue retention: 85%, because usage quietly declines as customers hit cost ceilings. The same 10x on gross profit lands at $22M, and the declining durability argues for a discount, not a premium.

Same ARR. Same growth rate. Same headline. Roughly a 3-4x difference in defensible value, and a naive revenue multiple would have priced them identically. That gap is the entire argument of this article, expressed in one table you could build in a spreadsheet.

Insights Most People Overlook

A SaaS multiple on a GaaS company doesn't just overvalue it, it misallocates capital toward the wrong behavior. If the market rewards revenue regardless of margin, founders are incentivized to chase usage at any cost, including negative-margin usage. The valuation method becomes a behavior-shaping force. Pricing on gross profit instead quietly redirects the whole company toward the things that actually compound value.

The "we'll fix margin later with cheaper models" story is more dangerous in valuation than in operations. Operators can genuinely improve margin over time. But baking that future improvement into today's multiple double-counts it, you're paying now for a margin gain that hasn't happened and may be eaten by rising agent ambition. Healthy practice is to value the margin you have, and treat the improvement path as upside, not as the base case.

GaaS may eventually deserve a higher multiple than SaaS on the right revenue, but only on gross profit. Because the best agent businesses deliver outcomes, not tools, a dollar of durable, high-margin agent gross profit can be stickier and more defensible than a dollar of SaaS revenue, since it's tied to work the customer can't easily reabsorb. The correction here isn't "GaaS is worth less." It's "GaaS is worth what its profit is worth, which the revenue multiple was never measuring."

Per-outcome pricing can rehabilitate the multiple, partially. When a vendor charges per verified outcome rather than per task, revenue and value re-couple somewhat, because price is set against delivered value rather than raw consumption. It doesn't restore SaaS-grade margins, but it does make the revenue line more meaningful again. The catch is whether you can actually measure the outcome, which is its own unresolved problem in the category.

The public comps don't exist yet, which is itself a signal. There is no clean public GaaS peer set to anchor a multiple, so most "comps" being used are SaaS companies with an AI feature bolted on, not pure agent businesses bearing full inference COGS. Borrowing those multiples imports the exact margin assumption that doesn't hold. Until a credible cohort of pure-play GaaS companies trades publicly, any revenue multiple is borrowed from a different species.

References

• Bessemer Venture Partners, Scaling to $100 Million (Cloud/SaaS Benchmarks)
• a16z, The Cost of Compute and the Economics of AI Businesses
• McKinsey & Company, The Economic Potential of Generative AI