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.)

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 e.g. a 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:

1. The amount to be collected is known exactly.
2. 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.
3. 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 are 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 e.g. the banking calendar or implementation quirks of their payment processors.

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.

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.)

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.)

I work 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 swords?

Revenue recognition in virtual goods

Computer games are one of my hobbies. Mobile games are one of my vices. In particular, recently 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, 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-game offer handy:

(For the benefit of readers who might not see the above image, it is 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, I 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 with in a day and most accounting systems lose precision below that.)

Accounting for swords: If you trade gems for swords then you can ratably 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 ratably 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.

Game mechanics as accounting optimizations

If you’re familiar with gatcha 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 ratably 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 ratably 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 less 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.