By Tom Zauli, SOFTRAX
The pandemic brought about rapid growth in the subscription economy, and UBS analysts predict it will grow to $1.5 trillion by 2025. One group that had pre-pandemic awareness of the importance of recurring revenue and how to manage it was CFOs. A 2019 CFO Research / Salesforce survey found that more than half (53 percent) of respondents said that at least 40 percent of their organizations’ revenues were sold via subscription or usage-based models (or “recurring.”)
Recurring revenue was on their radar at that time due to the stable nature of the revenue stream and the ability to optimize how they monetized their relationship with their clients. Post-pandemic subscription models have become more popular than ever, right when the accounting processes underlying them have increased in complexity, notably through the introduction of ASC 606 / IFRS 15. Essentially, what had been back-office problems in complex accounting are now also front-office considerations given the many customer touchpoints with subscriptions. CFOs are left with compliance mandates, customer pressure, and old ERP systems that are not up-to-speed with the current operations. The key to success in the subscription economy lies in finding and maintaining agility, and this checklist offers five good places to start:
Point 1: The fundamental tenant – “Where there is doubt, there is no doubt”
It is an old saying, but in these simple words lies the secret to financial transformation and digitization. When revenue accounting is complex, more time may be spent in enforcing controls, reconciliations, and other tasks around the core accounting, than the accounting itself. According to Rob Banham of PWC, at least 30% of a finance team function is spent in reconciliations alone. Why? Because there is doubt regarding the accuracy of the accounting. Particularly now, with a retreat to spreadsheets, there are more human touches, each of which has the potential to inject error. Controls on top of controls exist to ensure accuracy. These processes bring inertia and diminish agility. In the case of revenue accounting, the goal should be to change the paradigm so that accounting errors cannot be injected, i.e., to completely remove doubt.
Point 2: Processing architecture considerations
In past decades, a level of automation and agility could be achieved through on-premises install of ERP systems such as Oracle or SAP. These systems are wide in functionality, but not deep. Gaps in functionality are often filled via software customizations to preserve automation and agility. Future business changes are accommodated by yet another customization.
There is significant cost with these customizations. First, they create dependence on an IT team, whether internal or external, to write and maintain the customizations. Second, they create vendor and version lock-in causing tremendous cost of ownership. Upgrades are painful as customizations must be brought forward and retested. Because companies cannot easily upgrade to latest versions, defects already found and fixed in core software must be found and fixed via customization. This entails additional test effort against these customizations that are not tested by the vendor as part of their core QA process creating a highly inefficient process. This leads to stability issues because customizations are tested and used by one company, unlike core vendor software which gains stability via broad automated regression and use by hundreds or even thousands of companies. Because the solutions are installed on-premises, the companies themselves were responsible for security, backups, and other administrative aspects of the software.
Despite the extraordinary costs involved, the approach worked… until you had a business change. This is the problem many companies find themselves in as they attempt to move applications to the cloud and embrace subscription bill models.
A newer deployment model is single tenant cloud. A single tenant deploy means moving the application off on-premises servers to run either in a public data center or one owned by the software provider. It gets the application out of the client data center. It does provide significant benefit. Monitoring, backup, disaster recovery, and security are all handled by the cloud provider, who should be expert in each. It does not change the operational model of the software. The software still runs on a dedicated server. For this reason, like an on-premises install, customizations can and do occur and carry the same increase in TCO, partially due to the vendor and version lock-in that still exists as customizations are deployed. Additional problems exist. It is not easy to support a continuous release process in a single-tenant cloud, which means an impact to agility. Single-tenant clouds do not have the advantage of compute power on demand, impacting how the solution handles volume and potentially also increasing TCO.
The world is moving to the multi-tenant form of cloud and for good reason. It is unfortunate that both single tenant and multi-tenant cloud are referred to as just Cloud. The multi-tenant cloud processing architecture is quite different than both the on-premises and single tenant cloud models (which are like each other as stated). In a multi-tenant cloud deploy, all application instances deployed are the same. Cloud providers such as Amazon with their Elastic Compute Cloud, Microsoft with their Azure Cloud, and Google with its Cloud have become expert in making simple the provisioning and even load balancing and auto-scaling of compute power against spikes in load. They enable elastic compute where hardware can automatically be provisioned against peak loads and immediately de-provisioned when spikes pass. This offers tremendous improvements in price per compute. Multi-tenant cloud transitions monitoring, backup, disaster recovery, and security to the cloud provider just as in the single-tenant case.
There is one seeming downside. Customization is either hard or impossible. This would appear to impact agility. It is a false downside. Good multi-tenant cloud software is devoid of customization. Through this, a high percentage of the business logic is covered via the automated regression test performed by the vendor. Multi-cloud infrastructures retain agility because they enable a continuous release process where new versions are pushed to all users in automated, incremental updates. As out-of-the-box software, it stabilizes rapidly as new versions are simultaneously deployed to many users. If the vendor is open to a needed change, it can be developed, tested, and pushed to the cloud as supported product in a small amount of time. At the time of this writing, multi-tenant cloud has emerged as the clear preference for nearly all companies in terms of processing architecture.
Point 3: Deciding between a platform vs component strategy
With multi-tenant cloud the winner in terms of processing architecture, the next decision is whether to solve the revenue accounting problem via a single system or by leveraging ERP as a backbone and augmenting with other solutions. The question has always existed, but the equation changes in the era of multi-tenant cloud. In the past, it was more likely a single platform would suffice given that any gaps could be solved through customization, albeit at a cost. This is less the case with multi-tenant cloud deploys where it is less likely a single system will suffice absent the freedom to customize.
Companies with simple revenue accounting should lean toward deployment of a single, multi-tenant cloud platform to avoid data and integration issues that would otherwise add complications. There is one significant caveat. The chosen platform must support the points below, and particularly those related to removal of doubt in the process.
Where there is complexity, it is difficult to find a single platform that will meet the need. Today, even the platform vendors themselves have created separate offerings to assist in revenue accounting. In this scenario, augmenting with either a dedicated revenue accounting system or a set of point solutions may be necessary. An advantage of the approach is you are no longer dependent on a single vendor. You also gain the ability to place and replace components as the business changes without the disruption of a full platform rip and replace. Many companies with complex revenue accounting are choosing to select a simple, less expensive, ERP system to serve as a core backbone knowing they will require other applications to augment it.
Point 4: Evaluate functional components – prepare for the unknown tomorrow
All businesses change over time. In an environment where customization is not an option, or at least not recommended, you can get stuck. Even if you find functionality that meets your need of today, will it handle the regulatory and business change of tomorrow? This is exactly the problem many companies find themselves in now. They are transitioning back-office applications to the cloud at exactly the time when complexity is increasing, and business models are changing. The result? Without the ability to customize, functionality moves back to spreadsheets at an alarming rate. For this reason, it is critical to select applications that are deep in functionality, flexible, and robust. Whether a single system or multiple components, you must achieve confidence they will handle, not only today’s most complex requirements, but those of tomorrow as well.
Point 5: Evaluate functional components – plan for post-processing requirements
Evaluations often neglect the automated processing of change events. These could include processing of credits, pause events, cancelations, contract modifications, or any other change event impacting the revenue accounting process. If change events occur with any frequency, it is critical these events are handled out-of-the-box. Each of these actions impacts the contract for services and the revenue considerations, so change events should be central to your planning strategy.
By putting these five elements into your subscription billing plan, you are allowing for the agility that is needed to support the front office as well as the back-office, including revenue recognition, compliance measures, and ever-changing customer preferences.
Tom Zauli is the general manager and senior vice president for SOFTRAX, a provider of revenue management systems. Zauli background includes working with start-up software companies, including SES, HyPerformix, Parasoft, rPath and iTKO. Prior to that, Zauli worked as an Electrical Engineer for GE Aerospace, Martin Marietta, and Lockheed Martin. He holds a Masters of Engineering and Bachelors of Science in Electrical Engineering from Rensselaer Polytechnic Institute. In addition, Zauli holds US Patents related to techniques for automating the data collection and filtration processes supporting simulation models of complex, n-tier information systems.