Revenues

The Revenues sheet is the core revenue model in the Standard Financial Model, prebuilt to be applicable to a wide range of revenue models. This page details how the Revenues sheet is structured, but there is also additional documentation on how to use the Standard Model for specific types of businesses below:

• How to Model SaaS Businesses
• How to Model Ecommerce Businesses
• How to Model Marketplace Businesses
• How to model Services and Consulting Businesses
• How to Model Hardware Businesses

Key to using the prebuilt revenue model for different types of businesses is the Revenue Model assumption on Get Started. This section defines the prebuilt options available for the Revenues sheet.

Many businesses will modify the prebuilt revenue model or add in custom revenue streams; it is not necessary to change the assumptions on Get Started to do that.

How to use #

The prebuilt revenue model lives across two sheets:

• Get Started is where the most important inputs live, and is intended to be the primary place for user interation
• Forecast is where the calculations live, and is intended to be the place for more detailed assumptions and detailed insights into the business

The Standard Model uses a system of progressive inputs for the revenue model, meaning:

1. The primary inputs for the revenue model calculations on the Revenues sheet are on the Get Started sheet, for ease of input and focus on the core inputs
2. The full set of inputs for revenue calculations are on the Revenues sheet, linking back to the core inputs on Get Started and adding more detailed options for the revenue calculations on the Revenues sheet.

The revenue model can be completely modeled using just the Get Started inputs in the Revenue Assumptions section, but the Revenues sheet offers the opportunity for different behaviors, use of the drivers to change inputs over time, and purely custom additions to the calculations.

How it works #

At a high-level, the prebuilt structure models the growth of a metric, which then converts into a metric, then models retention (churn) of that metric, and then revenues and billings from that metric. What those metrics are called are inputs on Get Started. The prebuilt calculations will change depending on the selection of revenue model (e.g. recurring, ecommerce, marketplace, etc.), and the model allows you to use this to model overall growth and conversion into one or (optionally) two customer bases (e.g. customer personas, subscriber types, contract cycles, or pricing tiers). The Revenues sheet is linked into the Forecast sheet, which then uses the revenues calculations and carries it through the rest of the model, financial statements, summary, charts, and reporting.

Sidenote, my favorite bit on revenues and startups...

... and now that you want to forecast revenues, here's how to.

Revenue model selection and structure setups #

The Revenue Model options are:

• Recurring, for SaaS or subscription businesses. Model used to reflect businesses with recurring contract revenues, most usually saas or subscription businesses.the period for recurring can be defined above (e.g. annual, monthly, quarterly) by inputting the number of months in the contract cycle (1, 12, 4, respectively)
• Transaction business, such as ecommerce or physical commerce. This may be used to reflect one-time transactions, or to model transaction businesses with repeat customers, or hardware businesses, or hardware businesses with replacement cycles, and many more.
• Marketplace business, earning a portion of total transaction value. The key aspect to this is that you want to set the primary revenue metric to be gross transaction value per revenue metric, and then use the take-rate assumptions to calculate the revenues from that. It is not necessary to select this if the business happens to operate a marketplace but works via a transaction or recurring revenue model: the key is to use this selection to reflect how the revenue model works.
• Advertising, such as content business running advertisements. Used to define advertising-supported content businesses typically using CPM or CPC style ads. for all intents and purposes, same as a recurring business, just noting that we will define ARPU (average revenue per user) as the revenue metric.
• Financial services businesses that track account balances and earn revenues from them. This is used for businesses that have accounts, and have to forecast the growth (and repayment) of those accounts over time.
• Top down forecast based on market size. From a math perspective, this works the same as marketplace. To use, you would define the revenue metric as market size, ten use the percentage take rate input to reflect the percentage of the market (in currency terms) that you get.
• Not applicable. Used to zero out the prebuilt revenue calcs. This option merely turns off the revenue calcs, in case you want to turn off the prebuilt revenue model and build your own revenue logic (using the operational growth and retention calcs, or not, your choice.). You can also just zero out the inputs, but this provides another option on how to turn the prebuilt revenue model off.

The overall model setup, units input, and revenue model selection is detailed in the video below.

Modeling growth #

The first section of inputs on Get Started are for modeling growth. Here is how the inputs work.

First are the labels used throughout the model:

• Operational metric used to model growth. This is a label, the default is Growth Units but it should be changed for your specific business. Can input an operating metric like customers, or a growth metric like leads or website sessions, or a revenue metric like revenues or MRR, for example. No structural limitation to what term you should enter, input what is best for your business
• Revenue metric used to model revenues. This is a label, the default is Revenue Units but it should be changed for your specific business. Can input a revenue event like subscription, customer, order, contract, etc. You can also input the same as the above to use the first section to calculate a revenue forecast without using the logic around conversion rates
• Revenue model selection. This selects from the revenue model types prebuilt in the Revenue Model section below it (and explained above), to define the logic used in calculating revenues. The labels for the types can technically be changed, but that is rarely edited. You can also theoretically add more types, but you will also have to add in the supporting logic for any new types you add as well, and it would be easier to just build a custom revenue model for your specific usecase.

Next are the assumptions regarding growth and acquisition costs:

• New Growth Units in first month (date defined below). The growth inputs here model out how the first metric grows over time. this input is for the New in the first month, and this creates a growth curve of new growth units per period.
• … starting on what date. Input for the start date for the growth to begin. Regardless of what date you input, it will effectively assume a full month for the first month.
• … starting with an initial growth rate. Percentage growth rate for the first month
• … where the growth rate decreases X per month. Percentage change in growth rate for second, third, etc. month in the model. This creates a growth curve that changes over time. You can modify this in detail on the revenues sheet and create any growth curve you want. Note that by default this input is a negative on Revenues regardless of whether the number input on Get Started is a positive or negative (thus the -1 * ABS() formula on Revenues). This is because it was common for people to get the input wrong and accidentally model exponential growth with an increasing growth rate, creating revenue forecasts way out of rationality, and thus I changed this to correct a common user input error. Feel free to change on Revenues if you want to assume increasing growth rates.
• … adjusting seasonally. Select yes or no to use seasonality adjustments, as defined on Get Started
• ... with a viral coefficient (K) per period. Viral coefficient is a measure of virality in the product's usage or sharing, which is normally calculated as invites per user per period * conversion rate of those invites to new users. From a practical perspective the new growth rate assumptions above could be used to reflect viral growth, or you can use this to reflect some separate aspect of growth. By default the assumptions on the Revenues sheet will reflect a declining viral coefficient over time to reflect decreasing virality through product maturity, but you can alter this assumption on the Revenues sheet. More on modeling virality at Virality
• ... with virality based on Select Units. If using virality, this defines the basis for the virality, with the prebuilt options covering new current period, new previous period, or end previous period for the two different prebuilt growth bases in the Revenues sheet. Feel free to change the calculations on the Revenues sheet if you want to use a different base to fit your specific product characteristics. As a note, "end previous period" will use the number from the end of the previous period, "new current period" will use new that current period excluding the new from virality, which would create a circular calculation, or it will use the "new previous period" to remove the circulars created by conversion rates. The conversion rate used in the calculation excludes the optional conversion lag for simplicity reasons.
• ... calclating virality using on Select base. If using virality, see above
• Cost per Acquisition (CPA) per paid Growth Unit. Optional. Useful to model the acquisition costs of growth in leads, users, customers, etc. It's not exactly CAC (customer acquisition cost), it's the CPA for the first metric. CPA / % conversion rate = CAC. You can also model acquisition costs directly on the Forecast sheet, either as a replacement to this assumption or in addition to.
• … % acquired through paid acquisitions. Optional. The percentage of the acquisitions that come through paid channels, and thus are charged the cost per acquisition above
• Use Outbound Sales. Optional. If you select "'yes", then the model will use the prebuilt outbound sales section on the Revenues sheet as an additional growth channel. You can set the hiring schedule and growth per sales assumptions on the Revenues Sheet.

Written documention on this is coming, at the moment consult the video above, which covers how this section works in detail, and read the notes in the model itself for line-by-line instructions.

Modeling conversion and retention #

Next are the assumptions regarding conversion:

• Conversion rate per Growth Unit. This input is used to calculate conversion or adoption per Growth Units. This can function as a percentage conversion or a number adoption per growth unit, by changing the format from % to #. Meaning, the default setup assumes you convert some portion of the Growth Units to Revenue Units, but mathematically there is no reason why you cannot assume a conversion greater than 100%. For example, if you acquire an enterprise or partner, and that partner leads to 100 seats per partner, you can assume 100 here and change the format so it is clearer.
• … during the same period as acquisition. Change this input to create a timing lag in conversions; by default, "0" means that when you acquire the first metric, they convert to the second metric in the same period (month). If you type in "1", then it will convert to the second metric one month after the acquisition of the first metric. Common for businesses that have lags in the time to convert leads to customers, etc.
• … Select adjusting seasonality. Select yes or no to use seasonality adjustments, as defined on Get Started

Followed by the inputs regarding churn and retention:

• Revenue Units segments This splits the conversion in up to 2 different customer segments. Combined with the assumption below, this allows you to segment your conversions in up to two different customer/subscriber/revenue unit segments. Typical usecase is to segment to monthly and annual contacts, or to two different customer segments, or two different pricing tiers, with the need to set different churn and revenue assumptions.
• ... % of Growth Units converting to each segment Allows you to select two separate repeat or recurring churning / billing options, useful for annual / monthly billing or two separate repeat behaviours. By default the assumption is that after conversion, you then set what percentage of conversions go into these two segments, so most people would want these two inputs to add up to 100%. But you can also use this to assume a mixture of business models, and set conversions to two separate things, and use these inputs to model conversions to revenue units greater than 100%.
• % Churn Rate The percentage that repeat or churn at the end of the contract. The assumption below defines whether this is monthly, quarterly, annual, etc. churn. If you type "1" in the row below, you'll want to input a monthly churn rate here. If you type "12" below, you'll want to type in an annual churn here.
• ... every month, and every month For example, "1" = monthly churn, "12" = annual churn, "3" = quarterly churn. Adjust this to any number to set the contract length and the time for churn, and the label will adjust to reflect the contrac periods you input.
• Cost per Retention (CPA) per paid Revenue Unit. Optional. Useful to model the retention costs to reacquire or retain users, customers, etc. Like acquistion costs, this can also be modeled directly on the Forecast sheet.
• … % acquired through paid acquisitions. Optional. The percentage of the retentions or reacquisitions that come through paid channels, and thus are charged the cost per retention above.

Modeling recurring and transaction revenues #

Last are the inputs regarding revenues and cash:

• Revenue Units at the end of Jan 2025 The growth section defines how growth works, this input is for the starting point on customers. Why the difference? The growth inputs reflect the growth in new units (e.g. customers, clients, subscribers, etc.) rather than overall growth, because using cohorts for different retention curves makes it impossible (practically) to assume an overall growth assumption. So the growth setion defines the growth in new units, and by default the model starts with zero units (e.g. customers, clients, subscribers, etc.) in the first month. This lets you define it differently if you want, only for the first month in the model.
• Average Revenue per Revenue Unit per period The name of the revenue metric to use in the model, feel free to overwrite the formula in the input cell. Doesn't impact any logic, just used so that you can be clear in defining the revenues in the model.
• … billed every month This defines the billing period. If you bill (i.e. collect revenues) the same month as when revenues are recognized, input "1". If you bill for months in advance, enter in the number of months billed at a time. usually this is "1" (monthly billing), "3", (quarterly billing), or "12" (annual billing). This input is key for businesses with deferred revenues, where billings are in advance of recognizing the revenues.
• ... billed in full. Optional. This defines how the contract is billed, using a % at the start of the contract, and the remainder at the end of the contract. for example, for a 3 months contract where it's input to bill for 3 months, the input % would be billed on month 1, and 1 - the input percentage would be billed on month 3 (month of end of the contract). 100% just means it's all billed upfront. Most users should not change the default.
• ... % of average revenue per revenue unit per period as revenue. Optional. Used for businesses that earn a takerate or transaction value. This assumption covers a percentage of transaction value, or percentage of account balances. Most users should not change the default.
• ... $ per revenue unit as revenue. Optional. Used for businesses that earn a take based on volume (per transaction, usually). This assumption is the take per metric, not take per transaction, so if you have a structure where you take .1 per transaction, you want to assume here the take per transaction * the number of transactions (per, per period).

Linkage to forecast sheet and MRR, ARR reporting #

Here's how the revenues calculations link into the Forecast sheet, including the MRR and ARR reporting on the Revenues sheet.

Common Modifications #

The prebuilt revenue model is highly customizable, there are a couple common modifications:

• Adding extra growth channels. By default there are 1 growth channel, which can reflect a mix of total organic and paid acquisitions. Additional growth channels can be added on Forecast, using whatever custom logic you want to use, and then summed into the total that is used for the conversion calculations.
• Adding additional conversion steps. To add additional conversion steps, we just edit the calculations on Forecast - and often add in the inputs into Get Started, for a consistent user experience - to capture additional conversions, to whatever level of detail is useful for the business.
• Adding additional revenue streams. The model allows you to use the prebuilt drivers in the Revenues section to quickly model any revenues that are based off an operating metric calculated in the revenue model, simply by selecting that metric in the drivers, and then assuming the $ per metric that applies (i.e. # of subscribers from the prebuilt section, and then assume an average monthly revenue for that specific line).
• Adding in custom revenue models. You can also build in any new revenue source based on any business logic you want, simply by pulling your model or sheets into the workbook, and linking the revenues, billings, and optionally the operating metrics into the Forecast sheet in the top Forecast section.

Questions, support, or customization help, contact me.