Intercom went from 3x ARR to 36x ARR in two years by changing how it charged for outcomes. Here is what that means for every CFO managing a software stack, and every finance leader whose rev rec infrastructure was built for a different era. – Jagan Reddy, CEO, RightRev · June 2026
Something significant happened in enterprise software last month. Salesforce acquired Intercom (rebranded as Fin) for $3.6 billion. Adyen paid $335 million for Orb. Salesforce separately acquired m3ter for an estimated $150 million. MGI Research flagged ten major deals in the billing and monetization space in a single newsletter edition.
These are not isolated transactions. They are a market sending a signal, loudly, about where enterprise value is moving. And that signal has direct consequences for how you manage revenue: how you recognize it, report it, and defend it under audit or in a due diligence room.
The Intercom story: From zombiecorn to $3.6B: what the multiple actually says
By late 2023, Intercom was at roughly $250 million ARR and essentially flat. Analysts put a potential acquisition value around $800 million, a 3x ARR multiple. Decent, but not a great outcome for a company that had raised at a $1.3 billion unicorn valuation.
Then they made a decision most SaaS companies are too cautious to make. They built Fin, their AI customer service agent, and charged $0.99 per resolved customer issue; a shift from per seat, per license, to per provable outcome delivered.
$1M to $100M ARR
Fin’s AI agent revenue in roughly two years, growing at 350% year-over-year at the time of Salesforce’s $3.6B acquisition
The headline acquisition multiple looks like 9x ARR against $400 million in total revenue. That understates what Salesforce was actually buying. Fin’s $400 million is split: $300 million in legacy SaaS, $100 million in AI agent (outcome-based) revenue. Salesforce was paying up for the $100 million. The AI product likely commanded something closer to 27 to 36x ARR.
How the multiple breaks down:
| Legacy SaaS ARR | ~2-3x |
| AI Agent ARR | 27-36x |
| Blended headline | ~9x |
The lesson here is about what markets pay for when revenue is tied to provable customer outcomes and growing fast, compared to revenue that measures access to a tool. The multiple follows the clarity of the value delivered.
Usage-based pricing has been building for a decade. The finance infrastructure has not.
Snowflake went public in 2020 on a pure consumption model, charging by compute credit and storage rather than by seat. Their own filings describe the model precisely: revenue is recognized based on platform consumption, which is inherently variable at customers’ discretion and the amount recognized in a given period is used as a direct signal of customer satisfaction and the value derived from the platform. That is a compelling commercial story. It is also a genuinely hard revenue recognition problem. We break down how Snowflake manages usage-based revenue recognition in a recent webinar here.
Cockroach Labs built a similar consumption architecture for distributed SQL, charging based on compute nodes consumed over time, with cloud-hosted serverless options priced on actual usage. The commercial logic is sound. Customers pay for what they use, and as their workloads grow, so does the contract value. But that variable consideration has to be estimated, constrained, and trued up each period under ASC 606 and doing that accurately across thousands of customers at different consumption tiers is not a spreadsheet exercise.
Snowflake
Consumption-based revenue recognized as customers use compute, storage, and data transfer. Revenue in any period is variable by customer discretion, with rollover and overage mechanics that require daily predictive modeling from historical usage patterns to produce accurate forecasts.
Cockroach Labs
Usage-linked fees based on nodes consumed and duration, with serverless options on pure pay-as-you-go. Variable consideration that has to be re-estimated each period, with tiered pricing creating additional allocation complexity across multi-element arrangements.
Fin (formerly Intercom)
$0.99 per resolved customer issue, with performance guarantees, usage alerts at 50/75/90% of budget, and hard caps that automatically disable the product. Each of those mechanics creates a distinct revenue recognition question under ASC 606 and IFRS 15.
Three different companies. Three different consumption models. The same underlying challenge: the revenue recognition infrastructure most finance teams have was designed for a world where you booked a contract and recognized it ratably. That world is receding fast.
Five things that break when you shift to usage or outcome-based models
The shift from seat-based to usage-based to outcome-based pricing is typically driven by product and commercial teams. The complexity lands squarely in finance.
- Revenue timing: Usage-based revenue accrues unevenly. It spikes, it dips, it depends on customer behavior. Your close process has to match that variability in real time, period after period.
- Contract modifications: When a customer hits a cap, adds a tier, or renegotiates mid-period, ASC 606 requires a full reassessment of performance obligations. Most teams handle this manually.
- Forecasting accuracy: RevOps can no longer project revenue from license counts. Forecasting outcomes requires consumption data at a granularity that seat-based billing systems were never designed to produce.
- Audit defensibility: How do you prove a resolution to an auditor? How do you document that an implicit close (a user who did not respond in 24 hours) constitutes a delivered performance obligation under ASC 606?
- Multi-element allocation: Most AI-native contracts bundle a platform fee, a usage component, and a performance guarantee. Standalone selling price allocation across each element has to be defensible, documented, and applied consistently at scale.
Those numbers are about what happens when the revenue recognition infrastructure cannot keep pace with the commercial model the company is running. A Fin-style outcome-based contract, with variable consumption, performance guarantees, hard caps, and automatic product disablement, is a meaningfully different object than a fixed-term SaaS license.
What the acquisition wave is telling you
The acquisitions of Orb, m3ter, and Fin represent incumbents like Salesforce and Adyen recognizing a gap in their infrastructure. Metering. Rating. Usage-based billing. Outcome tracking. Both companies chose to spend hundreds of millions rather than build these capabilities internally.
Salesforce will likely use m3ter internally, and MGI Research estimates the internal value of that usage could exceed $100 million per year. Snowflake built their entire financial reporting model around consumption data, refreshed daily, pulling from contracts through to metering through to forecasting. Most companies do not have that infrastructure, and the M&A market is telling you that building it matters.
Revenue that is tied to provable customer outcomes, growing fast, and recognized cleanly commands a different multiple than revenue that measures access. The valuation follows the clarity. – Jagan Reddy, CEO, RightRev · June 2026
What this opens up for finance teams with the right infrastructure
- Valuation upside: Outcome-based revenue with provable, clean metrics commands dramatically higher multiples. The Fin example is a preview of where acquirers and public market investors are heading.
- Pricing velocity: Finance teams with infrastructure that handles new models ship new pricing in weeks. Every quarter a new pricing model sits in a queue is a quarter of lost monetization.
- M&A readiness: Clean, auditable revenue recognition under complex pricing models removes a top trigger for purchase price reductions in due diligence. It becomes a deal closer, not a liability.
- Competitive positioning: Customers are moving to AI-native contracts. Finance infrastructure determines whether sales can actually make the offer and close it without creating a rev rec problem on the back end.
The missing layer is now visible
RightRev was built for hybrid bundles, outcome-based AI contracts, mid-period modifications, and multi-entity revenue share. The complexity ceiling of legacy systems is our starting point.
The shift toward usage-based and outcome-based pricing is accelerating because AI is generating genuinely measurable outcomes at scale for the first time. When a software product can prove it resolved 76% of your customer service volume, outcome-based pricing is a contractual reality you have to recognize correctly, report accurately, and defend in an audit.
The question for finance leaders right now is direct: can your revenue recognition infrastructure keep up with the commercial model your company needs to run? If the pricing team can imagine a model faster than finance can close on it, you are paying a finance tax on every pricing decision you make.
The Fin acquisition happened because Intercom built an outcome that was measurable, provable, and growing at 350%, with the infrastructure to run that model at scale. The valuation followed the clarity.
Outcome-based pricing is already here. The question is whether your finance stack can see it clearly enough to defend it in an M&A room, an audit, or a board presentation.
Want to see how we can help? Request a demo today.
