The Standard Financial Model v3 Revenue Model

The specific documentation below refers to v3 versions of the Standard Financial Model. Refer to the v4 documentation at The Default Revenue Model. Contact me anytime for detailed and specific support.

The Standard Model is built as a modular model that seperates the financial core – financial statements, operating costs, hiring plan, cap table, valuation, and actuals reporting – from the growth and revenue projections, allowing you to change or replace the default revenue model built into the Standard Model.

More about this under Bring Your Own Model ›

But the default revenue model built into the Standard Model is designed to handle a wide variety of growth and revenue models, in an effort to make it as simple as possible for users to model their businesses. Most users of the Standard Model choose to use the default revenue model because it can reduce the time to create a growth and revenue forecast down to minutes.

Here's an overview of how its components work, and how it can be used to model a few common business types. This is a fairly in-depth post to explain technically how the structure works, but if you're only interested in how to use it to model your type of business, skip to the key usage examples below, each of which has a explainer and video on how to use the model for each business type.

Worksheets #

• Get Started - Revenue Model. This contains the key assumptions for the revenue model sheet, and instructions on what each section does. Additional assumptions are input directly on the Revenue Model sheet in the appropriate sections.
• Revenue Model. The default revenue model itself. The Revenue Model sheet contains some assumptions in various sections, in-line where one would expect to see them, and almost all assumptions can be edited on a per-month basis even if the structure on the Get Started - Revenue Model sheet only covers an initial input, or if the algorithim that creates the per-month changes don't quite fit how you want to model each individual month. Same as everything in the model, everything is calculated monthly, then summed into quarters and years, for up to five years.

Key Usage Examples #

The default revenue model in the Standard Model can be used for a wide variety of businesses; below are explainers about how to use the default structure to model the below types of businesses, simply by using the inputs in the model (no structural changes required).

Here are examples of the types of businesses it can model:

• SaaS, for consumer and SMB SaaS where online acquisitions and/or partnerships is a major element of growth
• Enterprise SaaS, for mid-market and enterprise SaaS businesses where B2B sales is a major component of growth
• Ecommerce, for ecommerce, retail, and other non-recurring revenue type businesses that sell direct to consumers or indirectly through other channels
• Retail, for ecommerce, retail, and other non-recurring revenue type businesses that sell direct to consumers or indirectly through other channels
• Subscriptions, for any subscription revenue business, including subscription ecommerce
• Hardware, for hardware companies with a mix of one-time hardware purchases and subscription software sales. For just hardware purchases, consult the ecommerce model.
• Apps & Games, for apps with free users, subscriptions and/or one-time purchases, including many iOS and Android apps and games
• Marketplaces, for marketplace businesses where the business facilitates transactions and takes a share of the transactions as revenues
• Advertising, for advertising-based businesses based on CPM, CPC, sponsorships, and others, including media businesses that combine advertising and ecommerce

Core Structure #

The default revenue model has a number of prebuilt features and options that are organized around a 10 core goals:

1. Easy to change terminologies and labels. A user-defined set of labels for what's acquired, what names to use for the conversions, and for what the revenue streams should be called, which change all the labeling throughout the model. That means you don't have to change a bunch of terms throughout the model to get it to fit whether you have users, or customers, or clients, or subscribers, or purchasers, or accounts: change it in one place and the terms change everywhere.
2. Multiple growth methods. Includes paid, organic, and sales (as well as a manual input), which sum into the total acquisitions for that 1 user base.
3. Flexible conversion funnel. The conversion funnel models 1 user base, meaning one set of leads, users, customers, etc. that are used for both potential revenue streams.
4. Up to 2 different revenue streams. The conversion funnel allows you to model two separate usage situations or revenue streams. By "usage situation", I mean that the conversion step doesn't have to model revenues - it could model free users, or trial customers, or add to carts, or an intermediate metric that doesn't earn revenue directly but is important to model (and it can model costs to support the usage, even if no revenues are earned from them).
5. Model revenue streams based on multiple conversion steps. The first conversion step converts from the acquisitions, and the second conversion step can convert from the acquisitions or from the first conversion step. This is important because it allows you to create revenue streams that are independent or build on each other; it can handle two different products sold to the same set of potential users, or allow you to model subscriptions and transactions sold to potential customers (for example, a subscription commerce company that allows people to also buy one-off), a one-time purchase followed by a recurring subscription (say a hardware product that is purchased, and then people optionally sign up for a SaaS software add-on), or a media company with a set of free users with advertising and paid users without advertising, and many other combinations of mixed revenue models.
6. Model recurring and non-recurring revenue using the same basic structure. Each conversion funnel of which can be subscription-based (recurring usage or revenues, for example SaaS, subscription, monthly, annual, advertising ARPU, etc.) or a transaction (a one-time usage or transaction that can recur at intervals greater than 1 month, such as ecommerce, retail commerce, etc.)
7. Cost of goods sold (COGS). If applicable. This is done with an input for overall COGS (per conversion step, % of revenue or per conversion), but can be expanded to show multiple line-items for COGS if desired.
8. Optional ability to model marketplace businesses. Each conversion step can reflect a marketplace or not. The difference is that if the marketplace feature is used, the model will calculate gross value of transactions (or subscriptions) on the marketplace and then the revenues that the company earns from it; if the marketplace feature is not used, the model will calculate the gross revenues earned from each steam and allow you to optionally pay affiliate or revenue-sharing fees from those gross revenues.
9. Optional Inventory forecasting. If applicable, inventory purchases are calculated separately for each conversion step based on inputs around purchasing behaviour, desired stock levels, and payment schedules, and the model handles purchases, cash, inventory and work-in-progress valuations automatically.
10. Prebuilt Analytics. Full analytics around customer acquisition cost (CAC), long term value (LTV), LTV / CAC, marginal recurring revenue (MRR, if applicable), and more. Financial statements are only a start to understanding the financial performance of a company. The structure includes standardized metrics reporting that reports new, cumulative, active and other acquisition and usage-based metrics if applicable.

The default revenue model is built structurally to minimize the visual impact of the different options, as selecting different options about the structure will change labels and calculations throughout the sheet. For example, the lines in the revenues buildup will look different depending on whether either (or both) revenue streams are using the marketplace option, as the options will change the organization of the section and the calculations.

What if my situation doesn't match the default structure? #

• Want a simpler revenue forecast? This happens: sometimes you don't have a very complicated revenue model, and don't want to use all the calculations and features in the default revenue model because it's bit bloated for your usecase. Two options: create your own simple revenue model on a new sheet and feed it into the model through Modelhooks, or use the Starter Financial Model, which does not have the default revenue model built into it but does have the same costs, financial statements, summaries, and key reports.
• Need to model more than 1 user base? Meaning, you want to model revenue streams that come from two different sets of users? One way is to duplicate the two worksheets (Get Started - Revenue Model and Revenue Model) to create 1 set of revenue model calculations for each user base, and then feed the new revenues into Modelhooks. Another is to split up the acquisitions section and use it to model different user bases, and then change the conversion steps so they draw from different user bases in the acquisitions section (this method covers only 2 user bases, no more).
• Need to model more revenue streams? One way is to create a new set of revenue calculations on any sheet - the Revenue Model sheet or your own new sheet - and then add the new revenue streams into Modelhooks, which will minimize the integration process. Another way is to simply build a custom revenue model for your different revenue streams and use Modelhooks to feed the revenues (and metrics, if applicable) into the model.
• Need to model something completely different that the default revenue model can't handle? Use the Bring Your Own Model approach.

Questions about these, contact me ›

Key Components #

Here are the key components of the Revenue Model sheet.

• Funnel Definitions
• Metrics
• Acquisitions
• Conversion Step #1
• Conversion Step #2
• Revenues
• COGS
• Optional: Inventory
• Optional: Analysis
• Optional: Marketplace
• Optional: Advertising

Funnel Definitions #

The funnel definitions are a critical component, as they set the terminology that's used throughout the revenue model for the acquisitions, conversions, and revenues, and setting them up correctly is the first part to utilizing the conversion funnel in the best way possible for your business.

The default revenue model's structure works like this:

• Acquisitions
• Conversion #1
• Conversion #2
• Revenue Event #1
• Revenue Event #2

The acquisitions section models how you acquire the potential users/customers/clients/etc, i.e. website sessions, email subscribers, partnerships, etc. The acquisitions do not have a direct revenue component, but they form the base of the growth model, since both conversion #1 and conversions #2's growth are related to the growth of the acquisitions.

Conversion #1 is a conversion step, modeling how the acquisitions convert to users/customers/clients/etc. It's easiest to think about this as a revenue stream, but it need not earn revenues: you could use this to model free users, trial users, or other usage situations where you do not earn revenues (but might incur costs).

Conversion #2 is a second conversion step, and works the same as conversion #1, except for one additional variable: conversion #2 can convert from the acquisitions or conversion #1. What does that mean? You can use conversion #1 and #2 to model two different products or revenue streams, both being marketed to the same set of potential customers (acquisitions). Or you could use conversion #2 to market conversion #2 to conversion #1's users/clients/customers/etc.

Here's a few common usage scenarios, with the terms meaning acquisitions - conversion #1 - conversion #2;

• Website sessions - free accounts - paid accounts, whereby the paid accounts convert from the free accounts (for example, SaaS business with freemium model)
• Website sessions - subscriptions - one-time orders, whereby the one-time orders convert from the website sessions (for example, modeling an ecommerce business that has a subscription product and a la carte orders)
• Website sessions - purchase - subscription, whereby there is a one-time sale followed by a portion of those purchasers signing up for a subscription
• Leads - trials - customers, for enterprise-style sales where trials can convert to customers
• Partners - accounts - users, for an enterprise-style sales where you sign up partners to get access to potential users, create accounts, and then a portion of them become users

You can also not use both conversion steps and just use one of the conversion steps, using 0s to zero out the assumptions for that conversion step and hiding all the calcs, if you do not need it. It's a simple way to use the structure with a minimum amount of editing or changes to the structure.

Revenue Event #1 is what earns the revenue from conversion step #1. You could define a user for conversion step #1, and then define what earns that revenue as the revenue event: subscription, order, purchase, etc. It's an input that helps set the terminology and also allows for added flexibility if there are multiple revenue events per user/customer/client per month. Sometimes there is duplicity in the terms, in which case you can use the inputs but hide some of the calculations, but most often it helps provide additional clarity around growth and revenues.

Revenue Event #2 is the same as revenue event #1, except it applies to conversion step #2.

In short, there's a tremendous amount of flexibility built into the funnel. The key usage situations section above have more details and videos on how to use it for a few key business models. I personally think it's easier to use this than it sounds, and once you set this up in your model you'll never change it: but knowing how you can use the fundamental options is pretty important. If you ever want to run your setup by me, contact me anytime.

Metrics #

The metrics section is at the very top of the sheet, but it's purely for reporting. For each of the applicable funnel steps above, the metrics section reports:

• New per period
• Cumulative at end of period (total over time or at end of period, if applicable)
• Cost per Acquisition (also known as CAC), during period
• Cost per Acquisition, average to date
• Long Term Value (LTV), calculated from assumptions
• Long Term Value, observed in model to date
• LTV / CAC

This section is used to provide operational performance data outside of the financial reports, and is used on the Summary and Key Reports sheet. Many users customize their Summary sheet to select the metrics they want to show, and it's easy to update the Summary using the metrics caclulated here.

Acquisitions #

The background behind the acquisitions section is covered in the Funnel section above, but the acquisitions section models growth using three different methods:

• Paid
• Organic
• Sales

Paid is treated as one acquisition channel to represent the sum of all paid channels (Facebook ads, Google ads, etc.). For paid, the model allows you to input the actual expenditure on paid advertising and marketing, and change it over time, and also input the percentage of net revenue spent on advertising. The model takes the maximum of those two expenditures as the expenditures in the model. The rationale for the % of net revenue is that it allows you to create a "flywheel", whereby increasing revenues get turned into increasing spend on acquisitions, tying the investment into paid acqusitions into a function of revenue growth.

The last assumption under paid is for the assumed Cost per Acquisition (CPA) for the acquisitions, and this can change over time (increase, decrease, decrease to a floor, increase to a ceiling, etc.).

Organic is treated as one acquisition channel for all organic growth channels. The assumptions allow you to set the number of acquisitions in the first month, and then change it over time (grow, decrease). Under organic, you can also set the viral coefficient (K factor) for viral acquisitions.

Sales helps you model the acquisitions from sales people and partnerships. The number of sales people hired is calculated from the hiring plan on the Costs sheet, and the acquisitions from sales is calculated from the number of fully ramped sales people multipled by the number of acqusitions each sales person can create each month.

It's also possible to use the sales model to model the acquisition of partners, and then the number of potential acquisitions coming from those partnerships. It's an extra level to the growth model that's important for many enterprise or partnership-driven growth strategies.

And there is also a manual input to add in any spikes, irregular acquisitions, or just manual input of acquistions if you wish to not use the other channels.

The last important step in setting up Acquisitions is that you have a choice on how each source of acquisitions - paid, organic, viral, sales - drives to each conversion step. You can choose on the Get Started - Revenue Model sheet ^[1] in the dropdown whether to drive each source of acquisitions to converstion step #1, conversion step #2, or both. This sets how the funnel works back on the Get Started - Revenue Model sheet.

Conversion Step #1 #

Each conversion step can be considered as a usage situation or a revenue stream, as each conversion step has its own set of calculations around user/customer/client/etc. behaviour, revenues, and costs.

Both conversion steps can model either subscription (recurring) revenue models OR transaction (non-recurring) revenue models, selected in the dropdown on the Get Started - Revenue Model sheet, and can be a marketplace business or not (again, selected in a dropdown on the Get Started - Revenue Model sheet).

The conversion step models the behavior of the user/customer/client/etc., by calculating the new, repeat, churn, and other metrics, and then calculates the revenue events occuring

The key inputs for each conversion step on the Get Started - Revenue Model sheet and the Revenue Model Sheet, and cover:

• Conversion Rate % from New Acquisitions, the conversion rate from acquisitions in that period to conversion step #1
• Conversion Rate % from Existing Acquisitions, the conversion rate from acquisitions prior to the current period that have not previously converted
• Months lag to conversion, in case conversion happens months after the initial acquisition
• Contract length (subscription) OR # of months between repeat conversions, to define the time period to evaluate retention OR repeat conversion
• Number of Months paid upfront (subscription). The input should always be "1" if this is a transaction business, but for subscription business it provides additional flexibility to define the payment schedule separately from the contract length. I.e., you can define a 12 month contract that pays monthly, a 36 month contract that pays for 12 months every 12 months, a monthly contract that pays monthly, a 12 month contract where they pay quarterly, etc.
• Churn % from New Users/Customers/Clients/etc., the churn rate to use for the first repeat / retention time period
• Churn % from Repeat Users/Customers/Clients/etc., the churn rate to use for all repeat / retention time periods after the first repeat / retention cycle
• Number of Revenue events per User/Customer/Client, to allow you to set multiple revenue events per user/customer/client. This could apply if someone places multiple orders a month, or has multiple subscriptions per customer, or a customer paying for multiple seats, etc.

Conversion Step #2 #

Conversion step #2 works exactly the same as conversion step #1, but for one additional variable: conversion #2 can convert from the acquisitions or conversion #1. The usecases are described in the Funnel section above, and the flow is determined by how you allocate the acquisition sources on the Revenue Model sheet.

Revenues #

The revenues section use the results from each of the conversion steps to calculate revenues based on the inputs on the Get Started - Revenue Model and the Revenue Model sheets. As described in the Funnel section, the definitions of the conversion step are important because they will define how the revenues are calculated: the model changes the descriptions and the calculations in this section based on whether it is a subscription or transaction revenue model and whether it is a marketplace business or not.

The inputs on the Get Started - Revenue Model sheet are:

• Revenue per revenue event #1 and revenue event #2, per month
• Cost of Goods Sold per revenue event #1 and revenue event #2
• The length of a contract (subscription) OR how many months between repeat revenue events

The inputs on the Revenue Model cover:

• Revenue per revenue event #1 and revenue event #2, for new and repeat events, per month, allowing you to change this over time
• Cost of Goods Sold per revenue event #1 and revenue event #2, allowing you to change this over time
• Affiliate or Channel Costs OR Marktplace Take Rate.
• % of New Conversion #1 with Discount (optional), if you give discounts to aid acquisitions and conversions of new users/customers/clients (for example, first month free, $10 off first order, etc.)
• % of New Conversion #2 with Discount (optional), same as above but applying to converion #2
• Average Discount (optional), average discount to
• Chargebacks and Refunds (optional), as a % of net revenues, modeled as a contra revenue
• Shipping Revenue and Cost per Revenue Event #1 (optional), if you need to account for shipping or delivery revenue and costs, on a per-revenue event level
• Shipping Revenue and Cost per Revenue Event #2 (optional), same as above for revenue event #1

A couple key notes:

• The revenue (and COGS) inputs are per-month. If you want to model an annual contract, then you would want to use the monthly rate and input 12 as the length of the contract; this works if it is paid monthly or paid annually, using the additional inputs in the conversion step described above.
• The revenue numbers are also per-seat, per the unit defined as the revenue event in the conversion funnel. If you have an enterprise business, this revenue input will be the per-seat license, and you can input the number of seats in the conversion step inputs (if you are pricing that way).
• Just like the user/customer/client/etc. calculations in the conversion step, the revenue calculations are done at the level of revenues for new, existing, and repeat users/customers/clients, so you can directly see where the revenues are coming from (new v. repeat/retained users/customers/clients). You have the ability to define a different average rate for new and repeat revenue events; note this repeat revenue assumption is used for all future repeat events, and this structure does not allow for defining a continually increasing revenue for a specific monthly cohort of acquisitions. That takes a more detailed cohort approach to acquisitions, if you need that simply contact me.

Cost of Goods Sold #

This is done with an input for overall COGS per conversion step, input as a monthly COGS cost. This can be expanded to show multiple line-items for COGS if desired.

As a note, cost of goods sold can also be input on the Costs sheet, and the total of the COGS from the Revenue Model and Costs are used in the financial summaries.

Optional: Inventory #

The inventory section is optional, but it is prebuilt to handle inventory calculations for one or both conversion steps if you need to calculate inventories. The calculations forecast inventory purchases based on four questions:

• How many months of future sales are desired in Inventory?
• How many months does it take from placing purchase order to ready to sell?
• What % of cost of product are paid when purchase order placed?
• What are your Days Account Payable on the remaining cost of product?

The model uses forecasted sales, the desired minimum stock levels, and the lag time from purchase order to being available for sale to forecast when to place purchase orders for inventories, and then uses the payment inputs to calculate when the purchase orders are paid for. From that, the model calculates inventory levels, inventory purchases, work in progress, and all the related balance sheet accounts.

Important to note that this calculates the overall stock level based on orders/purchases/etc., whatever you defined the revenue event as in the Funnel section above. If you need to calculate per-item/per-SKU inventories, then use the Ecommerce Model ›

Optional: Analysis #

In the Analysis section, the model calculates a number of operational metrics that can be used to understand the business better beyond the financial statements. The metrics cover:

• Long Term Value (LTV), calculated in three ways, showing the difference in LTV if the business is a subscription, transaction, or marketplace revenue model, calculated for each conversion step separately and then combined
• Bookings, Billings, and Deferred Revenues, for subscription businesses
• Marginal recurring revenue (MRR), for subscription businesses

Optional: Marketplace #

As explained in the Funnel and Conversion Steps above, each conversion step can be used to model a marketplace, and the model automatically changes the labels, the inputs, and the calculations so that it will calculate the gross value of transactions (or subscriptions) on the marketplace and then the revenues that the company earns from it (rather than using the inputs to just calculate gross revenues).

That is built into the default structure of the model: but that only covers the demand side of the marketplace. This optional section covers the supply side of the marketplace, to calculate the other side of a two-sided marketplace, and calculate how merchants/suppliers/etc are acquired (and churned and retained) and combines that to calculate marketplace liquidity. Optionally, the inputs also allow you to earn revenues from the supply side (on top of the revenues earned from the marketplace take rate), through per-month fees paid by the merchants and per-listing fees.

More details at How to model a marketplace business using the Standard Model ›

Optional: Advertising #

The advertising section aids with setting the revenues for the inputs, but does not directly link into the inputs. The sequence of calculations calculate the average usage and the monetization of that usage to calculate the Average Revenue per User/Customer/etc. (ARPU), which can then be used as the revenue input for the conversion step that you are using to model your advertising revenue stream.

The inputs are:

• Unique visits per month, per User/Customer/etc.
• Pageviews per unique visit, per User/Customer/etc.
• % of Pageviews with advertisements
• Number of advertisements per page
• Sellthrough %, meaning the % of the impressions that are sold
• % of Ads sold as CPC (Cost per Click), which is used with the % of Ads sold as CPM (Cost per thousand impressions) to help you analyze the mix of two different pricing methods
• CPC
• Click rate, which is used with CPC to calculate eCPM (effective CPM)
• CPM
• Ad server cost CPM

This calculates RPM (revenue per thousand pageviews, an advertising industry metric you can use for benchmarking) and ARPU (which you can use for benchmarking with other advertising-based businesses, and use as the input in the model.

More details at How to model an advertising-suppored business using the Standard Model ›