Introduction
The #subscriptioneconomy is a growing domain in terms of revenue and customer-adds. As a result, many businesses are considering moving towards subscription models or have already onboarded in “as-a-service” offerings. At face value, subscription seem logical and comprehensive. You define a customer-based agreement for a period, ensure you deliver accordingly and off you go.
That does not count for the financial considerations a subscription business must decide upon. Operating a subscription business model open a new compliance chapter. A key component of financial compliance is adhering to IFRS 15 or ASC 606. The main aim of IFRS 15/ASC 606 is to recognize revenue for transfer of goods/services promised to customers in an amount reflecting the expected consideration in return for those goods or services. This can also work in reverse when doing the same with your suppliers, resulting into cost recognition models.
In this document bluefort would like to lay out the different considerations a business must decide upon in terms of developing a highly automated financial system for subscription models.
1.1 Purpose
The purpose of this document is to structure different approaches to managing subscription based financial transactions and how they can be addressed in Microsoft Dynamics 365 Finance and Supply Chain management with bluefort’s LISA BusinessPro. We will address the different types of financial subscription models, how they produce transactions to the general ledger as well as configuration aspects that need to be considered.
1.2 Audience
- Financial consultants at Microsoft Dynamics 365 partners;
- Financial managers or controllers at end-users of Microsoft Dynamics 365 Finance and Supply Chain Management;
- CFO’s.
1.3 References
| Title | URL |
| IFRS 15 definition | https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/ |
| ACS 605 and 606 | https://asc.fasb.org/1943274/2147479442 |
| Why subscription management is important? | https://www.houseofcontrol.com/blog/why-is-subscription-management-important |
| Revenue and expense deferrals in Subscription billing | https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/sb-deferrals |
| Revenue recognition links from the bluefort eLearning portal. | https://learn.bluefort.eu/knowledge-base/working-with-billing-posting-profile-schedules-to-recognise-revenue/ https://learn.bluefort.eu/knowledge-base/working-with-revenue-recognition-products-to-recognise-revenue/ https://learn.bluefort.eu/knowledge-base/understanding-the-subscription-data-model-for-revenue-recognition-journals/ https://learn.bluefort.eu/knowledge-base/working-with-revenue-and-expense-deferrals-to-recognise-revenue/ |
Requirements
The requirement of running a sound subscription-based financial transaction model is foundationally based on IFRS 15 or ASC 606. Albeit the standards are slightly different, the objective is to manage revenue coming in from agreements over a period. In essence a subscription can be broken down into the following timelines buckets:
- Subscription contract duration
- Subscription billing cycles
- Revenue deferral and recognition cycles
- Subscription delivery cycles
A subscription agreement can be sold for a 3-year contract duration, with a yearly billing cycle and a monthly recognition cycle whilst delivering goods or services weekly. When mapping the standard accounting principles on the above subscription models, it is important to observe the following guidelines:
- Identity the subscription agreement with customers
This step defines the actual contract, it’s terms and conditions and the duration as well as the customer details. It often also specifies payment method and billing frequencies.
- Identify the performance obligations set forth in the contract
Once a customer signs a subscription agreement, the detail of each performance obligation must be specified. This is translated to the subscription products that are defined on the contract.
- Determination of the subscription transaction prices
For each subscription product a transaction price per period must be clearly define. For example, a price per month for using software or a product that defines 100 hours of defined services per month against the monthly transaction price.
- Allocation of the subscription transaction prices to the corresponding performance obligation
On a subscription agreement the subscription products details map towards the value it offers and captures the price per term or period.
- Revenue recognition postings when performance obligations are met
Periodically, for example during financial period closing, the revenue that may be recognized must be posted from a deferral account to the actual revenue account capturing that the performance obligations are provided.
Revenue recognition posting models
Subscription business models are not a one-size-fits all approach. There are various ways of running subscriptions financial models. In this chapter we will review different models and how they lead to different revenue recognition configurations.
Future dated revenue allocation model
This model is setup for subscription models that are not changing a lot over time and stay the same in terms of performance obligations. The concept is to determine a model per billing cycle or for the full subscription duration. The model works based on the transaction price per performance obligation and the duration determined.
The revenue recognition and deferral flows (excluding VAT or Sales tax) are illustrated below and automatically processed upon running the billing cycle:
Figure 2 Basic future date processing
Based on the duration of the billing cycle or contract duration, the basic future dated model processes all GL entries at one go, reducing the administrative burden on the financial team.
The downside is that this model requires posting future dated transactions which is in some case not aligned with all accountancy standards.
Financial period dated revenue allocation model
The model for basic financial period date revenue allocations works in principle in the same manner as the future dated model. The exception is that in this model the financial transactions for revenue recognition are posted during the financial period closing process.
Figure 3 Posting revenue recognition during financial close
Modelling revenue deferrals and recognition
When you deploy a subscription revenue model, and agreement duration is longer than at least one financial period, several modelling considerations must be reviewed.
| Model consideration | Description | Business requirement |
| Multi-element allocation | Split revenue entries into percentual elements to capture revenue per product, department, or another set of financial dimensions. | In many scenarios subscription revenue allocation requires a multi-element allocation so that different financial dimensions or general ledger accounts get a revenue split from the subscription revenue that is being processed. Let’s review a real-world example: A SaaS subscription has been sold for 12,000.00 USD for a yearly subscription plan. The revenue generated covered revenue for the support team, the maintenance team as well as the cloud hosting team. Therefore, the revenue must be allocated to each team’s financial dimension or revenue account using a percentage-based revenue split. |
| Indexation and price changes | When prices change over time due to a pricing update or indexation, this needs to be reflected in the ledger entries for deferrals and recognition after billing has completed. | Since subscription agreements can last multi-year, many companies run a price change or indexation policy in their terms and agreements. This usually covers inflation or market price changes. When updating prices on existing agreements, the line-item price can be changed, or an index increase the price. Once the next invoice for renewal is created the revenue deferrals and recognition must be processed with the new amounts. |
| Manage contract changes like, up- and downgrades | It is common practice to drive up- and cross selling efforts on subscriptions. However, subscription must reflect the right dates and pro-rata amounts. | When you add or remove quantities or lines on a subscription agreement, revenue deferrals and recognition must post those values accordingly. Let’s review a real-world example: A SaaS company sell an add-on to an existing plan. The plans’ renewal date is 10/10/2023. The date of selling the add-on is 10/01/2023. This means that the add-on is priced pro rata from 10/01/2023 till 10/10/2023 and revenue is deferred and recognized accordingly. |
| Early cancellation | When a subscription agreement terminated prior to contract end date, it is possible to create a credit note and remove the remaining subscription duration. | In this case the subscription is cancelled early, and we want to credit the remaining duration. A credit can be created resulting in a revenue correction which also updates the revenue deferrals and recognition. |
Four ways of managing revenue deferrals and recognition in LISA BusinessPro and Microsoft Dynamics 365 Finance
In this chapter we will review the different options for revenue deferral and recognition processing using bluefort’s LISA BusinessPro for Microsoft Dynamics 365 Finance & Supply Chain Management.
Based on the functional capabilities we can deploy four ways of running financial deferral and recognition processes:
- Accrual scheme’s
- Revenue recognition add-on’s
- Revenue deferrals in Subscription billing
- Revenue recognition module
Introduction
Each method has its own advantages and disadvantages. The above methods can work aside of each other based on the billing posting profile framework in LISA BusinessPro, except for the revenue deferrals in subscription billing. This option will require exclusion of the revenue recognition module.
Let’s review each method’s high-level options:
Use accrual schemes if you have relatively low changes (such as up- and downgrades, price fluctuations) in your subscriptions and your accounting team can work with future dated postings. The postings are always triggered by the billing process.
Use revenue deferrals in subscription billing when you would require monthly postings of revenue recognition based on the subscription sales orders and credit notes processed in that period. Revenue deferrals and recognition can be posted separate from the billing events. However detailed revenue allocations are not supported in this method.
Use the revenue recognition module when you would require monthly postings of revenue recognition based on the subscription sales orders and credit notes processed in that period. Revenue deferrals and recognition can be posted separate from the billing events. However detailed revenue allocations are not supported in this method.
Use revenue recognition add-on’s if you want to specify more details in how the revenue must be deferred and recognized. Revenue recognition add-on’s create actions using HARP BusinessPro and revenue recognition can be processed on its own and does not depend on the billing process.
Revenue deferral and recognition application model in LISA Business Pro
The core mode for allocating and processing revenue deferrals and recognition in LISA is based on the following mechanism:
The accrual method
Using the accrual method for revenue deferral and recognition is based on the features in the General Ledger for Microsoft Dynamics 365 Finance and Operations. The billing posting profile needs to be configured to setup the accrual method:
By setting the flag to yes on “Post accrual scheme” it becomes possible to setup a sales accrual (and a purchase accrual) to process the revenue deferral and recognition. Create the core accrual scheme and connect it to the billing posting profile.
It is possible to automatically setup the right billing posting profile based on the subscription duration using the option “automatic billing posting profiles”:
Using this capability, you can create billing posting profiles for the most common contract durations (like quarterly, bi-annual, or yearly) and automatically assign the right profile with the right accrual scheme setup. When using accrual scheme as the method for revenue deferral and recognition, it is required to setup a billing posting profile and accrual scheme for each foreseeable subscription contract duration.
Other options are to determine the percentage to defer and recognize, so that you can allocate partial revenue and post a percentage of revenue straight to the profit and loss upon billing. It is also possible determine the amounts to defer or recognize by day or monthly determination.
The revenue schedule method
The revenue schedule is based on the module revenue recognition. It is important to state that Microsoft has planned to deprecate this module in the very near future.
Following the setup in the billing posting profile, set the flag “use revenue schedules” to yes, and select the revenue schedule you would like to link to the billing posting profile.
From there onwards it becomes possible to utilize the revenue recognition module. More information about this standard method can be found here https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/revenue-recognition-overview.
The revenue schedule method is triggered by the subscription billing action and executes on posting.
The deferral and recognition method
This method has become available early 2022 and is part of the standard subscription billing module. Using the billing posting profile the capability can be used by switching on Revenue and Expense deferrals to yes in the correlating radio options.
Based on the processing in HARP sales orders are created for billing and these orders will be captured into deferral schedules.
Figure 7 Deferral schedule triggered by billing event
After the creation of the deferral schedule, the functional is standard for Dynamics 365 Finance. Find more details about this method here: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/sb-deferrals
The revenue recognition item add-on method
To use this method, the configuration does not start from the billing posting profile but from the creation of new products in the release products area:
Figure 8 Setting up revenue recognition add-on products
The revenue recognition product is linked to all products that require this add-on. It is possible to have multiple revenue recognition add-ons so the revenue can be split into various details before it is posted to the general ledger.
This method will trigger each subscription line with a revenue recognition add-on to create a child line item of the type “revenue recognition”. When running HARP BusinessPro, it will create a revenue recognition posting action with can be posted at any point in time, even unrelated to the billing action.
Figure 9 Revenue recognition actions
This means that you can disconnect the billing event from the revenue deferral and recognition event and have maximum control over revenue recognition.
Other considerations
When configuring revenue recognition, the following considerations:
Duration
Revenue recognition can follow different durations. The main consideration is to either follow a billing cycle or the full contract duration, depending on the terms and conditions.
When recognizing revenue for a full contract duration, the recommended method is the revenue recognition add-on process. In this case the revenue is determined on the total duration setup in the renewal options. When the billing cycle is the duration for revenue recognition all method can be applied. This method is the most used way to defer and recognize revenue.
Total amount to defer and recognize
The total performance obligation requires a business to determine the amount to defer and recognize. It can either be the full amount of revenue or a percentage of the revenue. Using the billing posting profiles you can setup a percentage of revenue to defer and recognize. This will trigger to post only the percentage of revenue you have configured.
Figure 10 Percentage to defer and recognize
Kindly note that this option is only possible when using the accrual method.
Perpetual licensing and maintenance subscriptions
When your business sells and operates perpetual sales and maintenance plans, then it is highly likely that you only need to defer revenue and recognize it for the maintenance subscription. In this case you can configure maintenance plans and assign recognition only to the subscription part, excluding the directly recognized revenue from the perpetual sale. The main setup is to choose a billing posting profile for the maintenance revenue.
Discounts
When you apply discounts to subscriptions plans it is possible to defer and recognize revenue for the discount amount as well. This triggers a separate posting to general ledger accounts and dimensions for the discounted amounts. The base configuration requires you to determine main accounts and financial dimensions and then setup these discount segments in the billing posting profile.
Revenue deferral and recognition amounts per financial period
Revenue deferrals and recognition are posted in financial periods. The amount of revenue to be processed can differ based on the following configurations:
- Posting in beginning of a period
- Posting in the middle of a period
- Posting in the end of a period
Based on the chosen configuration the transactions will be posted accordingly.
When determining the amount, it is possible to configure the following options:
- Evenly
- Number of days
When selecting evenly, the total amount will be the same for each period. When selecting number of days, it will determine the amount based on the pro-rata number of days in the period. This will fluctuate the amount based on each period length.
Allocation by percentage per financial period
Revenue deferrals and recognition can be based on pre-defined schedules that use an allocation percentage per period. Based on this accounting principle it is possible to define a revenue deferral scheme to subscription agreements and post the split revenue deferrals accordingly.
Automatic assignment for renewals
Revenue deferrals and recognition can be treated different when a subscription agreement renews. Upon renewal contracts can renew to itself or it is possible to renew to a pre-configured auto renewal schema.
This capability means that we can assign an auto renewal configuration that attaches an updated billing profile on a subscription line based on the above setup. Therefore, the renewal can update the duration of lines and the consequent revenue deferrals and recognition processing. An example is to move a 1-year agreement to a 3-year agreement on renewal.