Hey there,
If you’re at the deal desk right now, a revenue accountant, in rev ops - you might be thinking: We used to be able to hold the line.
Sales wanted to sell something new, experiment with usage, change the price, bundle two things together. We had a written accounting policy, a straight face to hold that line with.
That’s gone.
With AI, the technology keeps moving, so the line keeps moving. More capabilities. More modifications. More exceptions. More “just this once” arrangements have become the new normal as we fight to create the appearance of calm in our financial statements.
Product and strategy teams are scrambling just as hard. Nobody knows which functionality will be commoditized tomorrow. Everybody still has to look confident.
At our May Shareforum, I put a scenario in front of a room of enterprise accounting practitioners:
I see pricing shift weekly in my own AI subscriptions. One week a model is available and burns through usage four times faster than another. Another week, a limit resets unexpectedly and gifts you enough capacity to finish a project. Then capacity doubles to drive adoption of a new capability. The product changes. The unit changes. The price changes. Sometimes all three change inside the same contract term.
So let’s just admit it: nobody really knows how to sell AI.
I don't think this is a "you" problem. I think it's a "we" problem, rooted in a mismatch: the cost structure of the technology has changed, and the accounting we built around software let us enjoy smooth, predictable earnings for years.
The facts and circumstances keep changing. And we keep trying to make our old interpretations fit. When the price, the packaging, and the unit all keep moving - are we still following the economics, or just the mechanics?
Let me show you what I mean.
This newsletter is generously sponsored by HubiFi:
RSVP for The Reckoning – a free virtual summit for accounting and finance leaders. Build vs buy | AI vs reality | New monetization | The accountant’s career ceiling. Keynote: Chief Accounting Officer @ 1Password, Senad Mustafic. Panels featuring Higgsfield, Miro, eero, Lumera, Prenuvo & more. Earn up to 5 CPE credits.
SaaS's shift to usage-based selling, and how AI breaks the facade
Usage-based economics have been sitting underneath SaaS all along.
AWS, Google Cloud and Azure always charged for consumption. SaaS companies built applications on top of them and sold predictable, seat-based annual subscriptions, while their own infrastructure costs moved with customer usage underneath.
Companies closer to the infrastructure layer, like Snowflake, Twilio and Elastic, had a more direct link between customer usage and delivery cost from the start. Snowflake built its investor story around that difference. On its August 2022 earnings call, its CFO reminded analysts that “this is a consumption model, not a SaaS model,” and told another that he doesn’t look at billings “because we’re not a SaaS company” (Q2 FY2023 earnings call transcript).
“You only pay for what you use” was both a compelling pitch and a closer reflection of their economics.
The usage-based cost layers AI adds
Jensen Huang describes the AI stack as a five-layer cake: energy, chips, infrastructure, models, applications. Each layer's cost feeds the one above it.
Classic SaaS really only dealt with two of those layers: the application, and the cloud infrastructure under it. The infrastructure was already usage-priced. The application stayed seat-priced, under pressure to add a usage component when customers used more than the fixed price assumed.
AI adds three newly material, cost-intensive, usage-priced layers underneath: models, chips and energy. In contrast, traditional SaaS was what Huang calls “prerecorded” software: humans described an algorithm and computers executed it. AI generates intelligence in real time. In Huang’s words: “Every token produced is the result of electrons moving, heat being managed and energy being converted into computation.” Cost is incurred through the whole cake every time it runs.
That’s why prices won’t sit still. Every layer is repricing itself against the layer below it, and each one has its own tiers, commitments and discounts. A model that gets cheaper to run can make customers run far more of it. The price per unit falls while total consumption climbs.
Usage was already hard for SaaS. AI didn’t create that mismatch. It made it impossible to ignore.
We’re throwing spaghetti at the wall and calling it go-to-market strategy out of survival, all while the entire cost cake underneath it is built on usage. It’s no wonder pricing and packaging a multiyear contract feels impossible to hold steady right now.
Caveat: this describes how companies sell themselves in the market, not a confirmed statement of how any of them recognize revenue. But the gap between the two is the point. What a company sells and what a company recognizes get decided by two different teams, and nothing requires them to agree.
How straight-line revenue became comfortable and the margin we never recalculated
A short history of software, SaaS and revenue accounting
Here’s the part of this story about accounting, not technology.
For decades we carried a quiet assumption: software is high margin. Write the code once, sell it a thousand times. It was true, so we built our accounting standards and policies around it.
In the 1990s software shipped on a CD, and copy one thousand and one cost almost nothing. The guidance of that era, SOP 97-2 (later ASC 985-605), wasn’t worried about cost. It was worried about how easy it was to give software away, so it limited how much revenue you could take when the license shipped. It also required “vendor-specific objective evidence” (VSOE) of fair value for maintenance, which was deferred and recognized over the maintenance term.
In 2000, Salesforce turned the end of that model into theater. Its logo was a “No Software” sign, and it hired protestors to wave it outside a Siebel Systems conference. When it filed it’s S-1 in December 2003, it told investors customers would “incur less risk and lower upfront costs,” and its revenue policy fit in one sentence: recognized “monthly over the terms of their subscription agreements.” The pitch was a revolution. Because SaaS was “not software,” the software accounting rules no longer applied. Instead, SaaS was “access to a service”. Revenue recognition was ratable, straight-lined as the service was delivered.
Straight line gave markets what they loved: smooth, predictable, ratable revenue. Committed revenue meant stable returns, commission plans based on ARR, and consistent storytelling.
Software companies became SaaS companies, and software accountants became SaaS accountants, carrying the high-margin assumption into a model where it was no longer automatically true. Meanwhile, cloud costs from AWS, Google Cloud and Azure quietly grew into one of the largest costs of revenue for many SaaS companies.
How the new standard complicated usage-based fees
I was in the room, holding the tension.
In 2015, I was on the advisory side at KPMG, working with the four major card networks, Visa, Mastercard, Amex and Discover, on adopting the new revenue standard.
The main question we wrestled with: What was the appropriate pattern of recognition for transaction-based fees over long-term arrangements?
View A: Estimate the total contract value upfront, and recognize that estimate ratably over the service period (the lean at the time) or,
View B: Keep recognizing fees as transactions occur.
To me, View A felt insane. Theoretically correct, yet economically uncomfortable. Most SaaS contracts run one to three years. These relationships run for decades. Imagine forecasting how many times a card will be swiped over 30 years. The estimate would be wrong every month, every quarter, every year. Nobody could say what a downturn would do to it, or a pandemic, or a currency crisis, or how many times a card would get swiped in a world that won’t sit still.
The new revenue standard moved us from a risks-and-rewards model (ASC 605) to a transfer-of-control model (ASC 606). Legacy ASC 605 was focused on constraining upfront revenue. A contingent revenue cap limited what you could recognize on a delivered item to the amount you had the right to bill, so revenue could never get ahead of billing. Usage-based fees were generally recognized when they became fixed or determinable.
ASC 606 removed the cap and asked a different question: is this usage-based fee simply a pricing mechanism for a stand-ready performance obligation where control transfers over time? If so, estimate it as variable consideration, constrain it, and keep truing it up.
605, the old instinct: don’t recognize what you don’t know. 606, the new one: estimate it, recognize it according to the nature of the promise, and keep estimating.
But calling the estimate economically irresponsible wasn’t an acceptable answer at the time. So we worked within the words of the new standard which meant showing that allocating usage-based fees to the period in which they occurred met the variable consideration allocation exception (ASC 606-10-32-40), in a manner consistent with the allocation objective (ASC 606-10-32-28). That is, the amount allocated should depict what the entity expects to be entitled to for the services delivered in that period.
Plain English Translation: In order for a Company to recognize revenue for a usage-based fee in the month it’s used, the associated fee must represent the value the usage is worth for that month.
This would have been easy to prove if usage was priced at a consistent rate per transaction type throughout the term.
But in reality, that’s just not how the industry worked.
Payment processor transaction fees were never just one rate. There were hundreds of fee types, transaction fees, volume-based fees, debit, credit, late fees, fraud chargebacks, etc. Many fees had different pricing tiers that accumulated over different periods, with rates decreasing as transaction volumes grew. The industry norm: as volume grows, a mostly fixed cost spreads over more transactions, so rates fall. And if a big customer could get a better rate from another processor, it would, so each processor had to price to that reality to stay competitive.
So the real question was whether a declining rate could still meet the allocation objective.
Here’s what we argued, and I would argue it again. Consistent price and consistent economics are not the same thing. A rate that steps down with volume isn’t a front-loaded fee. Total fees still grew with volume even as the rate per transaction fell. The steps followed the cost structure and the market, and matched how the company priced similar customers. Every processor faced the same unknown future, and that risk was already in the price. When price moves the way the economics move, recognizing it as it’s earned still depicts what the service is worth to the customer. The standard-setters’ staff reached a similar place in TRG Agenda Paper 39 (July 2015): a changing price could meet the allocation objective if it is based on market terms, or if the changes are substantive and linked to changes in the cost to fulfil.
The industry landed on recognizing transaction fees as the transactions occurred. It took real nuance and a lot of cooperation, but it matched the business better than the theoretical answer did.
(A note for the technical accountants: this section covers only one of several judgments that usage-based revenue has to clear across the five-step model. I kept it to one and paraphrased some of our normal technicalities for readability and so the article could end. I’m always open to talking shop on the rest.)
Now put AI inside that frame
An AI usage contract will almost certainly have rates that change over its term. We are living it right now. Not because anyone is gaming revenue, but because cost to serve is moving: models get cheaper to run, limits reset, prices get repriced, and customers use more as it gets cheaper. Unit price falls and volume rises. That is the payments question again: a rate that moves because the economics move.
But this is harder than payments. Price is only the part we can see. The packaging and the unit move too.
A changing rate is the cleanest pure usage-based version. Your contract probably has a seat fee, a credit pack, an overage rate and a conversion right, and no market price curve behind any of them.
AI is consumed, not just accessed. With AI added to the cost model, the selling side is reacting, and what’s emerging isn’t pure seats or pure usage. It’s a fast push toward hybrid: a per-seat price with some usage-based pricing included, with overages for what goes beyond it. Are you selling agents? Outcomes? Model usage? Credits in a newly minted company currency? We went from selling something countable to a menu that keeps changing.
The product changes while the customer is using it, and the cost of serving them changes with the model, the workload, and the amount of intelligence being generated. The customer may not know how much they’ll consume until they discover what the technology can actually do. Neither does the vendor.
If a changing rate fails the allocation objective, nearly every honest AI usage contract is in trouble. If price that tracks economics meets it, as I argued for payments, the real question is evidence. What evidence would show a token’s price tracks what a company is entitled to or what it costs to serve? Answering that requires understanding the technology, and the technology keeps rewriting the economics as we speak.
(A second note for the technical accountants: I’m not sure it’s worth shaping usage billing into monthly invoices to reach the “as invoiced” practical expedient. That feels like forcing a billing mechanism to get an accounting conclusion, the opposite of what the new standard was trying to decouple. And the expedient still asks whether the invoiced amount corresponds with the value delivered, so a moving rate raises the same question.)
One company’s revenue is another company’s cost
So where would that evidence come from? It is slippery for a reason. Look at the map of this community.
The companies selling tokens buy compute from someone else, and they run their own finance on the same enterprise software they sell into. Your vendor is another company’s customer. Your customer is another company’s vendor. The evidence for your token’s price is someone else’s price list, which is someone else’s estimate.
It isn’t a supply chain. It’s a loop. Every company in it is trying to recognize revenue cleanly on one side and trace cost to product on the other, and each one’s mess lands on someone else’s books.
Where this leaves us
We spent years building accounting policies around software predictable enough to sell by the seat and recognize ratably.
So back to the question I started with: are we still following the economics, or just the mechanics?
In 2015 we followed the economics, and I’d make that argument again. A changing rate isn’t the problem. It’s what evidence is required to show that pricing is aligned with the economics.
As accountants, we’re always challenged to look at the economic substance. I think that means looking at the big picture: what’s happening to the vendor, the customer and everyone else in the loop, and making the next judgment from there.
I’m not ready to say we should stop estimating or that revenue shouldn’t be straight-lined. But look at what we’re doing: estimates that are stale by the next release, a contract modification for every new feature, exceptions that became the norm. Is the information getting better, or are we just getting better at documenting a number we know will move? Where is the standard still doing its job, and where are we stretching it to fit a technology it wasn’t written for?
We are all part of the same ecosystem, and a national office conclusion doesn’t stay inside one company. It sets precedent. What one firm decides about one fact pattern becomes the starting point for everyone else’s.
The mechanics will keep changing. Our job is to keep following the economics, and no one company can see the whole loop.
So let’s compare notes. Reply with the usage fact pattern that’s keeping you up, from whichever side of it you sit on, and let’s discuss at the next QTC ShareForum on Oct 23.
Thanks for being in the conversation.
Angela
What’s coming up
Wed Oct 14, New York (In person): AI in Finance Lab 4.5 CPE (Gaapsavvy × Coterie CFO, at Deloitte). I’ll be teaching AI foundations + hand on build time.
Wed Oct 14, virtual: The Reckoning, HubiFi’s free summit with CPE: Register HERE
Tue Oct 20, San Francisco: Women Leading the Next Era of Finance, a networking brunch hosted by Zuora: Register Here
Fri Oct 23 — next QTC ShareForum. Must be an industry practitioner member join here. (Calendar invite coming)
Wed Oct 28 San Francisco ( In person): AI in Finance Labs. 4.5 CPE Register here Oct 28 · Dec 2
This isn’t accounting advice. Facts and contracts differ, so document your analysis and check with your auditors.