Cash received is not revenue earned
Patrick reads his classic Bits About Money essay explaining why revenue recognition in software is more complicated than most engineers, founders, and financial reporters think.
Presenting Sponsors: Mercury & Granola
Complex Systems is presented by Mercury—radically better banking for founders. Mercury offers the best wire experience anywhere: fast, reliable, and free for domestic U.S. wires, so you can stay focused on growing your business. Apply online in minutes at mercury.com.
If meetings consistently leave you with hazy action items and lost context, Granola handles the transcription so you can actually participate and gives you searchable notes afterward. Try it free at granola.ai/complexsystems with code COMPLEXSYSTEMS
Timestamps:
(00:00) Intro
(00:56) Accounting for SaaS and swords
(03:22) Why revenue recognition matters
(05:49) Revenue recognition in SaaS
(09:54) Revenue recognition in virtual goods
(12:52) Accounting for potions
(13:24) Accounting for swords
(14:56) Sponsors: Mercury | Granola
(18:34) Accounting for swords (cont’d)
(20:49) Game mechanics as accounting optimizations
(22:10) So about that goblin
(23:25) Back to the real world
(25:00) How this applies to AI labs
(32:48) Wrap
Transcript
Hideho, everyone. My name is Patrick McKenzie, better known as patio11 on the internet. As has been abundantly discussed recently, the AI labs are some of the fastest growing companies in the history of capitalism, both in terms of revenue and also in terms of their capital needs. Frequently during boom times, games are played with revenue.
Some genre-savvy nonspecialists have raised questions about whether games are being played today. Spoiler: probably not. But to understand why, you probably need to understand what revenue means in software in more detail than, say, the typical financial reporter does. And so I'd like to read you a classic Bits about Money essay about software revenue recognition, and then expand on this in the AI lab context.
And so, "Accounting for SaaS and Swords," originally published on March 18th, 2022, in Bits about Money.
Accounting for SaaS and swords
One classic misunderstanding by engineers is that data can be compared reliably by computers. On the one hand, this is a foundation on which our civilization now rests. On the other hand, human society doesn't evaluate data—bits—like computers do. Bits have history to them, provenance, moral character, intent, and other epiphenomena which are not directly inspectable. Matthew Skala called this the colour of bits, in a seminal essay that remains one of the Internet's best meditations on the topic.
Intellectual property lawyers, as one example, frequently concern themselves with discerning the colour of bits and then pronouncing whether a program operating on those bits is behaving legally. (Computer scientists, on the other hand, believe that answering whether a program will behave legally is formally undecidable.)
As an aside, this is a consequence of the diagonalization proof, which you'll learn if you take CS classes. The diagonalization proof basically says that for any interesting property about a computer program, you can't say definitively whether that property holds about the computer program. This is counterintuitive to people because they think, well, I can do reasoning about computer programs all the time. My life requires me to do that. And computer scientists will say yes, but mathematically you can't. You're fooling yourself into believing that you're reasoning about a computer program. And then people who make money writing computer programs, who all went through a degree to get into computer science departments–or rather, their job as an engineer as a result of getting the degree in computer science–will say, well, it's slightly more complicated than either side believes here.
Money is also widely believed to be fungible. A dollar is a dollar and a yen is a yen. On the one hand, this is a foundation on which our civilization now rests. On the other hand, human society doesn't evaluate money like math does. Money also has colour.
A salary payment is coloured differently than a gift, even if they're the same amount paid by the same person the same way into the same bank account. Some dollars were re-coloured by implication recently, without those dollars ever being touched or named or even intended to be acted upon.
Accountants frequently concern themselves with tracking the colour of money, because business managers, owners, and tax agencies care a great deal about this question.
Which brings us to a question which sounds deceptively easy: if a customer pays a business money, does that money have the colour of "revenue?"
Why revenue recognition matters
If you were paying attention, you've probably guessed that the answer is "Money paid from a customer to a business is sometimes revenue." In the general case it is undecidable, but it is nonetheless extremely important that businesses quickly come to a defensible conclusion about how much revenue they earned in, for example, the current month.
The process by which a business discerns that some money has the colour of revenue is called revenue recognition. The exact details depend on your jurisdiction, accounting standards, and a myriad of factors, but broadly the accounting profession has three tests.
Money is revenue when:
- The amount to be collected is known exactly.
- The thing the business is being paid for has been performed; the customer has either taken delivery of the product or received the service completely.
- The business has reasonable confidence that the money will actually be collected.
Why do we do this to ourselves, when we could simply count money as it is received? Because accounting is designed to perceive the world as it actually exists.
A business which has performed all their obligations to a creditworthy customer should certainly expect to receive money; they a re in a better position than before they performed their obligations. If society did not agree they had received revenue, they would both be allowed to do some incredible tax gamesmanship by delaying receipt of payments until convenient for them, and also they would experience artificial distortions in their apparent health caused by, for example, the banking calendar or implementation quirks of their payment processors.
As an aside, one thing that many small business owners will be familiar with is that the IRS–or, for example, the National Tax Agency in Japan–might ask you to elect to be a cash-based business or an accrual-based business for your bookkeeping. The difference between the two is relatively simple. In a cash-based business, you recognize revenue and expenses as you pay cash for them, or more typically as money moves in and out of your bank accounts and credit cards and similar. In an accrual-based business, you do somewhat more sophisticated revenue recognition, like recognizing insurance policies rateably over the term of the insurance policy as an expense, or recognizing the contracts that you have with counterparties for software delivery rateably over the term of the software contract, as we'll discuss in a few moments.
And so this is one of the first things that surprises people when they start learning about revenue recognition: that you can recognize revenue in the absence of having actually received money. Totally normal. Many businesses do it every day of the year.
Revenue recognition in SaaS
In a past life, I founded several software-as-a-service (SaaS) companies. They were much smaller than the publicly traded giants who were thrown into a tizzy by IFRS 15, an accounting standards update which tried to better align how we performed math about contracts with their economic impact in the actual world. But even though the businesses were small, revenue recognition still came up.
A fun example: many SaaS companies operate against a non-revenue metric called, to the great disgust of accountants, monthly recurring revenue (MRR). MRR is the number SaaS entrepreneurs selling on the low-touch model live and die by.
As an aside, SaaS is broadly sold on one of two models. The low-touch model, where you have a website, customers show up to the website, they might get a free trial, and then they choose to pay for the service via, most typically, a credit card. Then the high-touch model, where you have teams upon teams of sales representatives who are either taking calls from customers or going out into the world to recruit, most typically, business customers to buy your service. Businesses that are run on the high-touch model care about ARR–annually recurring revenue–because they will generally have their contracts be annual. Businesses that sell in a low-touch model generally have contracts that are monthly by default, and those contracts are often, in the low-touch model, not really contracts worthy of the name. It's "click here to say yes" to something, whereas there are actually bespoke contracts being negotiated in many enterprise deals. If you care greatly about the difference between low-touch and high-touch software sales, I wrote a guide on it for Stripe a few years back. I will link it in the show notes.
SaaS companies that sell month-to-month services also frequently offer annual plans, generally trading the knowledge that the customer won't churn for a year and the upfront use of cash for a discount. And then they tie themselves into knots trying to build dashboards which track MRR but adjust for the impact of a 12-month plan sold for the price of 10 months. Almost nobody gets this right.
Frequently seen bugs include adding all 10 months of the pricing into MRR (will overstate it by a lot since the user will, by definition, not pay you next month), adding a full-priced subscription worth of MRR despite the 2 free months, or having MRR dip during the last two months of the year despite there being no change in the customer relationship.
Accounting says "We have a simple solution for this. You should recognize revenue for all your plans, monthly or annual, on a daily basis over the lifetime of the period the customer is committed to using you. If you want to predict how much money you'll make next month, you're almost past what accounting can do for you, but to a first approximation try multiplying your last day's revenue by the number of days in the next month."
So what happens to the money which is received but not recognized as revenue? It gets a different colour: deferred revenue. Accounting says deferred revenue is a liability; it is something you owe society, which you will repay by either servicing your customers as agreed or returning their money.
Who cares about what the balance sheet says? Acquirers, for one. SaaS companies are largely valued based on revenue multiples. (At the smaller end of the scale, technically seller discretionary earnings multiples.) Both of the businesses I sold were sold based effectively on a negotiated multiple of the SDE.
When I sold my SaaS business which had a mix of monthly and annual contracts, the buyer sensibly didn't want to pay similar prices for differently coloured dollars. The MRR would almost certainly (net of churn) recur next month, but the annual contracts had (on average) about six months left before the buyer would get paid, and they'd be responsible for performance of those contracts immediately. They'd still have to keep the servers running, pay the CS staff, etc. And so that revenue was valued lower. (This surprises public markets SaaS investors and frequently VCs, because after a certain scale annual contracts are more valuable than monthly contracts all else equal.)
Once upon a time, I worked for Stripe, which has a Revenue Recognition product that helps do the heavy lifting of prorating subscriptions over their lifetimes. (As always, this is my own space and these are my own opinions.) This has exposed me to an even geekier accounting question: how do you recognize revenue for sale of imaginary goods?
Revenue recognition in virtual goods
Computer games are one of my hobbies. Mobile games are one of my vices. In particular, recently -- well, recently back in 2022 -- I have been playing a "merge" game. Merge games take resource management games, a genre which can be wonderfully intellectually satisfying explorations of complex systems with an undercurrent of Chinese techno-optimism like Dyson Sphere Program, take out all the intellectual content, and replace it with a Skinner box to drive monetization.
Which is easy to write when I'm sitting at my computer, just like I can easily write that Coca-Cola has no nutritional value, harms health by default, and is terrible for teeth. But sometimes I find myself hankering for that sweet effervescent siren. And sometimes a game like Merge Adventure Puzzle Master hooks me on allowing me to brainlessly click my way through appealing fantasy art.
Which is why I have this screenshot of an in-app offer handy. I will verbally describe the screenshot for you. Imagine you're looking at a goblin offering to build a bank for 1,000 gems. The bank will produce 10 gems a day forever. Gems are the game's premium currency and available for a variety of price points, including 1,500 gems for ~$10.
Now here is a fascinating question: how do you recognize revenue for selling a perpetual bond with a 1% daily coupon denominated in a virtual currency?
To answer it, let's take a brief detour through the fascinating world of virtual goods revenue recognition [PDF by PwC]. It's gloriously geeky.
Merge Master, like many mobile games, sells a premium currency (gem) for real money. You might naturally think "OK, so when you give them money and they give you gems, you're even. That payment is revenue within a second after they credit you the gems." That's a reasonable first guess. It is the first guess of every engineer who has ever considered this question, including myself. So if you had it, you were in excellent company in being totally wrong.
It is wrong because accounting tracks the world as it actually exists, and in that world, I'm not paying Merge Master for gems. I don't want gems. I want the things gems let me get access to in the game I trust Merge Master will continue making available to me. A necessary implicit part of our bargain is "You're going to be around in a minute so that I can trade in my imaginary gems for imaginary swords to kill the imaginary dragon, right?"
And so virtual goods accounting for goods bifurcates around the question of whether the goods have a necessary services component in them. If you sell someone e.g. a downloadable e-book, you can recognize the revenue about as quickly as you can if you sell them a real book at a bookstore. (Immediately, modulo their right to return it, which you'll book a reserve against based on your prior data about... sorry for that digression. I just love this stuff.)
If you sell someone a virtual good with an embedded service element, there are broadly two treatments based on whether the virtual good is consumable or durable. I like to think of this as potions and swords.
Accounting for potions
This is fairly easy. If you sell someone a potion, revenue is recognized when they drink the potion. Or use their speed boost. Or skip the progress gate to get to the next dungeon. The fiction doesn't matter. Reality matters, and the economic reality of the situation is that performance has happened after the temporary thing you've promised is delivered. (Technically speaking you do have to recognize the revenue over time if your potions last long enough to be close to monthly SaaS contracts, but practically speaking most are over within a day and most accounting systems lose precision below that.)
Accounting for swords
If you trade gems for swords then you can rateably recognize the purchase price of the gems when you satisfy your obligation by giving the player a new sword.
Hah, just kidding. That would be way too easy.
You actually need to recognize the prorated cost of the gems exchanged for the sword over the economically useful life of the imaginary sword. "Economically useful life" is a concept with a lot of prior art on it in accounting. You are obligated to, and accountants can point to substantial work on, estimating the economically useful life of factories, cruise ships, CNC machines, bunk beds, Bitcoin miners, dairy cattle, and almost everything else that depreciates.
But there is not a huge amount of prior art on imaginary swords. So you get to pick one of two methods.
The first, by far less commonly used, is to put your head together with very expensive accounting professionals and rigorously answer the question "What events in reality, in the universe we actually live in, would cause the owner of this imaginary sword to believe it had no or de minimis future value to them?" And perhaps that conversation would involve questions like power creep, game balance changes, declining player preference for swords now that you're offering a sale on imaginary nuclear weapons, etc.
Nobody has time for that conversation or the truly gargantuan amount of implementation engineering required to enforce the decision it comes up with, so they largely use door #2: the economically useful life of a virtual good is by nature upper bounded by the economically useful life of a player's relationship with our game, so use that instead.
You are required to use your existing data to make a reasonable estimate of how long either the particular player or, failing that, the hypothetical spherical frictionless average player will continue to play the game after the purchase. Then you recognize the price of the sword rateably over that time period.
This causes many virtual goods companies to have bookings (player purchases) diverge sharply from revenue. That depresses the value of their companies, in the real world, and those companies then spend substantial amounts of professional labor taking their frustration out on imaginary swords.
As an aside, the difference between the revenue that you as the business owner think you have and the revenue the market credits you with–due to, among other things, accounting standards–is a real difference in the world that some business owners rail against for quite some time. So, taking a brief detour from imaginary swords for the moment: GoDaddy, back in the day, was a closely held company and looked at going public on a number of occasions. GoDaddy had this issue where they would sell services over rather long time periods–five years, ten years–because they were largely selling domain names to customers, and would tell customers to renew the domain for many years at a time. And they would book this enormous deferred revenue liability for their customers.
What the GoDaddy CEO said in many interviews and investor presentations is: "Look, since we're not going out of business, and since the cost of serving domain names is essentially the same whether we're serving a million of them versus a hundred million of them, you should really treat this as a cash-and-carry business. So all of the money that comes in this year is our revenue, regardless of this massive balance sheet item that says deferred revenue." What sophisticated investors looking at GoDaddy said was, "Well, no. You do have to still keep running the business. And so from my perspective, it looks like GoDaddy is incredibly levered. You've got so much debt on the books. The debt isn't to a bank or to a private credit fund–it's just to your customers. But oh goodness, is there a lot of debt. And since that debt must get satisfied before US equity holders get the residual value of the company, we are not willing to extend equity investment at the valuation you think you're worth."
Game mechanics as accounting optimizations
If you're familiar with gacha games like Genshin Impact, you have probably seen game systems which require sacrificing multiple copies of a character or item to get a new, slightly better version of the same character or item.
Some people cynically believe this exploits the player's inability to understand how exponential math works. "Eight levels of upgrades, each burning two imaginary swords, requires buying 256 swords, not 16 swords. If Sword of Awesomeness was honest about its price, no one would actually choose to buy it!" There is some amount of truth to this.
But again, if you sell someone a Sword of Awesomeness for value, you have to recognize the revenue rateably over the future economic life of the Sword of Awesomeness. If on the other hand you tell someone to burn two Swords of Slightly Less Awesome to get their Sword of Awesomeness, at least one (and maybe two, depending on your accountant's opinion) of the Swords of Slightly Less Awesome has no future useful economic life.
Which means you can recognize the revenue immediately. Which means that your large, perhaps publicly traded video game company is worth more, no longer weighed down by the unearned revenue liability that was the existence of the now-burnt Sword of Slightly Less Awesome.
And that is why accounting standards have destroyed more imaginary swords than all the rust monsters in all the prime material planes combined.
So about that goblin
Alright, let's return to the goblin banker with the improbably underpriced 1% daily yield non-resellable perpetuity bonds.
Is the "bank" a sword or potion? Sword, clearly.
Do you have to somehow account for the liability implied by the bond? No, you do not, because the bond is a fiction and accounting is concerned with reality. Accountants working on a production of the Merchant of Venice don't recognize revenue during Shylock's soliloquies; their gaze is on the audience, not the stage, and the audience has been satisfied once the play is over. (I will note that, unfortunately, many depictions of Shylock and many depictions of goblins share some baggage, in a fashion which many of you already noticed.)
The economic substance of the goblin transaction is not "I will give you an infinite amount of future value in return for a current payment." The economic substance is "If you pre-pay us now, we will give you a variable discount on your future purchases of in-game items for the duration you choose to play this game."
And thus the answer is, somewhat boringly, that you recognize revenue for the goblin bank rateably over the course of the player's predicted future lifetime (again, unless you do substantial professional services work to establish that the 10 gems per day is no longer valuable to the player).
Back to the real world
Why does any of this matter? One reason is that systems which operate with money often grow in scope over time, as they have to become increasingly aware of the colour of money. Revenue recognition is just a single example. Some money is KYC-rich and some money is KYC-blind. The risk ratings of money would fill an entire spectrum of colour.
This is important both for consumers of systems which operate on money (i.e. everyone) and for people who build and adopt those systems. It is crucially important, on a local level, that you pick systems which can actually perceive the colours which you have reason to care about.
On a societal level, the more colour there is in the world and the more people have to care about it, the greater incentive there is to buy systems which manage money rather than attempting to build them. If your model of money is "It's just numbers, math operates trivially on numbers, let's just build a spreadsheet or otherwise simple system and call it a day", then money problems often look easy. This is extremely deceptive, and as you grow to perceive more colours around you, you will often come to regret that the spreadsheet has colour vision deficiency. This frequently results in you having to update it, sometimes for very large piles of greenbacks.
This is an interesting thing for policymakers, who can invent new colours and frequently do, to keep in mind. Every additional colour introduced to the world is a vote that there be fewer systems better architected to perceive it. That sometimes exists in direct tension with other policy goals, such as e.g. promoting competition, discouraging centralization or correlated failures, and similar.
How this applies to AI labs
And now, as promised, the applicability of this to AI labs.
AI labs sell a variety of products under a variety of service models. But let's take API access for the moment. Broadly speaking, when they sell in a low-touch fashion–so to individual retail customers–you show up at the AI lab, you predeposit money often via credit card or similar, and the company gives you a balance which they track internally or using a system such as Metronome, which I believe is now owned by Stripe, which is my previous employer.
I should make a disclaimer here. One, most of the AI labs use Stripe under the hood for things. You can read more about that relationship in Stripe's annual letters. I'm not using any internal information to make the following representations and Stripe has not endorsed what I say in my personal spaces necessarily.
Two, as the economic center of gravity in Silicon Valley moves towards all things AI and LLM, you should assume that every technologist, myself included, is sort of synthetically long AI labs, even if they don't directly hold the equity of AI labs. And so I am not aware of directly holding any equity in the AI labs, but my interests are aligned with theirs in a way. And so if you care about that, you should discount what I say appropriately, but I'd rather think I'm right here.
So you have a balance. That balance is deferred revenue or a contractual liability, depending on exactly what lingo your accountants want to use. As you consume tokens, the service delivery is basically over about as soon as the API call comes back with the inference. And I would bet that there are very, very fun conversations within AI labs on things like, okay, in the case where there are multiple API calls or a thinking model or similar which takes multiple turns, is the service complete at the point where we consume the tokens, or is it complete at the point when the API gives a useful result back to the user? Is it complete when the user reads that result?
Regardless, I think rounded to: as soon as the token is consumed, the revenue is recognizable. So this is much less complicated than revenue recognition typically is for SaaS companies.
However, that model is not the only way that AI software is sold. Another model AI software is sold on is the sort of all-in-one subscription to some of the premium plans for labs–their core chat services or their increasingly core services in, say, programming–and those are essentially the classic SaaS story. However, they're the classic SaaS story in that you can pay a certain amount of money for a month, and the business will recognize the revenue rateably over the course of the month. With an asterisk, which is that some users of those products are not paying a fixed price for usage over the month, but they're paying a metered billing model, which is more similar to the thing that we've just discussed with respect to using their API billing directly.
Now, there are additional wrinkles on this, and this is stuff that lifts the souls of people who work in revenue recognition, because the actual contractual terms on enterprise deals get very complicated very quickly. So one way that you can typically structure deals in enterprise software–which works for all parties–is to say there is something that we're metering here, which kind of proxies for the amount of value that you are getting out of the software. We would like the price of the software to go up as you get more value out of it. So we're going to use that metered item to price the contract.
However, there are various parties here, even at lower levels than the companies–like, for example, the sales representatives who don't want to say, "Well yeah, I sold them an unknown amount of tokens over the course of the next year." There are some parties that need visibility for budgeting purposes, and there are other parties that need visibility for, for example, calculating their commission purposes. So you might say, okay, indicatively, the price of a million tokens is a certain amount that we're establishing via contract for these models and see this pricing list. Indicatively, we think that the contract is going to run you about this much money in the next year, and maybe we even make that a hard commit.
But what will often happen is the amount of money you spend depends on your actual usage over the next year. However, you get these lovely prices, which are a discount to the publicly available prices for a million tokens or for a seat license, for similar software. You have to agree to what's called a minimum commit.
A minimum commit simply means that if in a given period–a month, a quarter, or similar–your actual usage of the software would bring in less than a particular dollar amount, your invoice gets grossed up to that dollar amount.
So how do you do revenue recognition in the case of a minimum commit? Well, ask your accountant rather than yours truly. But what you can do is configure your accounting software to recognize the revenue of the minimum commit rateably over the course of the minimum commitment period. And then as you get in the actuals over that actual period, you only recognize the revenue from the actuals to the extent it exceeds the minimum commit, and possibly you have some reconciliation process running on either a daily basis or a monthly close basis to make sure that you true up the actuals versus the minimum commits. There are other treatments, and I'm sure your accountants would love to discuss them with you. But that is just one of many potential contractual terms that you can have with a software contract.
There are other terms, and they get fascinatingly complicated. For example, software-as-a-service is generally more similar to a service than a product, but there are a variety of deployment topologies for this one. One deployment topology is where you are giving essentially the software that you have made–whether it's a "SaaS appliance," which is typically an installable version of the SaaS that is typically accessed over the open internet, or say just the weights of an AI company to your customer to run on premises. And in that case, there are elements of that transaction that look more like a service, and there are elements of that transaction that look more like a product. And the accounting for them can be slightly different. But that ends up being quite facts-dependent. And so this is why accountants will continue making money, even in a world where an LLM can answer a lot of relatively easy questions about accounting.
By the way, tax time is coming up, and if you have not run your draft tax return against an LLM, I strongly advise doing so. It picked up thousands of dollars for me with mere minutes of work, and I've received word from a number of people after I tweeted this out that they should probably do the same. Anyone with a reasonably complex return, or even a relatively straightforward return for working professionals, should run it against an LLM and just say, "Hey, what do you notice about this before I sign it?" I tweeted that and there are multiple people who have already told me that it saved them between thousands and, in one case, rather substantially more than thousands of dollars, despite having very professional, well-paid professionals looking after their tax returns. So my suggestion to you: run your return past an LLM before you sign it. The worst thing that happens is you burn some tokens. The best thing that happens is you get to have a more complete and accurate return to Uncle Sam, and it'll hopefully have a smaller number on the bottom of it.
Anyhow, that's all for this week, and thank you very much for listening to Complex Systems. I'll see you next week.
