A major SaaS implementation can warrant the same investment governance as a traditional capital project, including business case, executive approval and portfolio oversight, even where most of the spend is accounted for as operating expense. That makes it a live example of strategic operational expenditure: material, non-routine investment supporting strategic objectives without necessarily creating a capital asset. Accounting classification and investment governance are different questions, and this article treats them separately.

Traditional software was acquired via perpetual license or developed internally. New systems are now being acquired under a ‘subscription’ license or fully hosted Software-as-a-Service (SaaS) agreement. In both cases, the investment of internal labor and external consulting fees to design and configure SaaS projects is significant. The challenge for financial controllers is how to budget effectively for these large Information Technology projects: should they be budgeted and accounted for as Capital Expenditure (CapEx) or Operating Expenditure (OpEx)?

Whilst the accounting treatment of a SaaS agreement will be impacted by the contractual form of the agreement, the substance of most SaaS projects is to establish a technology platform that delivers ongoing benefits. Thus, in an economic sense, , many major SaaS projects are investment-like in nature.

Material SaaS projects should therefore be approved through an appropriate investment governance process and justified on a comparable basis to purchased or bespoke development. The appropriate cost to consider is both the up-front implementation services cost and the net present value of subscription fees over the planning horizon.

This blog will help you understand your SaaS projects, the accounting implications, and how to prepare a successful business case submission for a SaaS solution.

Is SaaS CapEx or OpEx?

For accounting purposes, SaaS is usually OpEx: a standard subscription buys access to software the supplier controls, so it is a service contract rather than an asset. For governance purposes, a major SaaS implementation is an investment decision and should be treated like one. Those are two different questions, and treating them as one is where most SaaS budgeting goes wrong.

On the accounting question, a standard SaaS arrangement gives the customer access to software the supplier controls, so it is generally a service contract rather than an intangible asset. IFRIC addressed this in 2019 and the position still stands. The accounting treatment of SaaS costs depends on the reporting framework. IFRS/AASB and US GAAP do not apply identical rules to implementation costs, so there is no single CapEx-versus-OpEx rule that can be applied globally. The treatment of a particular arrangement should be assessed under the accounting standards applicable to the organization.

On the governance question the answer is independent of all that. A ten million dollar transformation program is a major investment decision whether its costs sit in subscription expense, implementation expense, prepayments or capitalized intangibles, which may include a mixture of these treatments. Treating it as routine OpEx because the invoice says so pushes a material, long-lived commitment outside the process that scrutinizes every other investment of the same size. That is the failure this article is about.

Why are Software Providers Encouraging SaaS?

Because supporting one current version is far cheaper than supporting dozens. Software developers such as SAP and Microsoft are aggressively transitioning their solution delivery models from on-premises perpetual licensing to cloud subscriptions primarily to reduce the cost and accelerate the pace of solution delivery. There are many environmental dependencies when deploying on-premise solutions that require on-going administration including hardware platforms, operating system versions, database management systems, and third-party software components.

As software ages and the underlying environments evolve, the number of supported versions and application landscapes increases geometrically. This limits SaaS vendor validation and support capacity, leading to slower and less ambitious version releases.

By contrast, with true multi-tenancy cloud-hosted SaaS projects, the software manufacturer has greater control over much of the application and hosting stack. Of course, user access mechanisms rely on a compatible browser and any integrations still require careful API management, but all the other typical dependencies can be controlled. With only one version to support, software vendors can rebalance their team towards innovation and competitive differentiation, and more agile delivery cycles.

EBOOK: Advanced Capital Budgeting Strategies

Learn strategies to optimize capital budgeting
and improve financial decisions.

EBOOK: Advanced Capital Budgeting Strategies

Learn strategies to optimize capital budgeting and improve financial decisions.

What’s Included in a SaaS Agreement?

A SaaS agreement typically covers access to the software, hosting, maintenance, updates and support, priced as a recurring subscription. What it usually excludes is configuration, integration, data migration and training, which remain the customer’s cost. The benefits to you the customer of SaaS projects and SaaS solutions are plentiful. By acquiring software-as-a-service, your technical landscape complexity, responsibilities, and costs can be greatly reduced. You no longer have to cross-check the dependencies of any business application when considering your hardware and platform upgrades. You no longer have to retain support expertise in niche technology layers. SaaS can significantly reduce your responsibility for infrastructure provisioning, platform maintenance, scalability and software updates. You nevertheless retain responsibility for areas including data governance, identity and access, configuration, integrations, change management and vendor oversight.

With modern SaaS projects you get all the benefits of the best-of-breed functionality provided without the burden of infrastructure provisioning, installation or platform support , though configuration, integration, data migration, training and change management remain yours, as the next section sets out.

Investment Costs of SaaS Projects

Whilst SaaS solutions provide a wealth of functionality ready to be instantly adopted, in practice some degree of configuration is required. Classifications need to reflect your industry requirements. Workflow processes need to be tailored to your organizational responsibilities. Integrations need to be implemented to your other core systems. There are data migration costs in transitioning into a new solution. There is the cost of decommissioning legacy environments whilst preserving audit trails. Users will still need some degree of change management and training. Thus, whether you are transitioning from a legacy solution or digitally transforming for the first time, some significant implementation costs can be expected.

Is SaaS a Lease?

Usually not. SaaS agreements can resemble leases because they may involve recurring payments and multi-year commitments, but resemblance is not the test. A SaaS arrangement is not normally a lease simply because it is committed for several years. Under IFRS 16, an arrangement contains a lease only where the customer has the right to control the use of an identified asset for a period of time, including the right to obtain substantially all the economic benefits from it and to direct its use. In a typical SaaS arrangement the supplier controls the application software, including how it is operated, updated and hosted, so the customer receives a service rather than a software lease.

Some software arrangements may nevertheless convey control of software or contain a software lease. The assessment depends on the contractual rights provided, rather than on the length of the agreement or on whether the fees are described as OpEx.

Does Your SaaS Confer Controllable IP?

In most cases, no. For SaaS implementation or customization expenditure to qualify as an intangible asset under IAS 38, it must result in an identifiable resource that the entity controls and meet the applicable recognition criteria. Legal ownership is not always required, but control is. Under IAS 38, expenditure on training users does not qualify as an asset even where future benefits are anticipated, and is expensed as incurred. Thus, training is likely to be incurred regularly.

Once-off expenditure incurred on customized integration to existing systems could qualify as an asset where the organization controls the resulting asset. In-between scenarios such as the tailoring of Workflows to accommodate the delegation of authority limits and responsible managers will be harder to assess. The degree of customization alone does not determine whether expenditure can be capitalized. The key question under IAS 38 is whether the work creates an identifiable resource that the customer controls. Configuration or customization of supplier-controlled SaaS software will often not create a separate intangible asset, although separately identifiable code or integrations controlled by the customer may qualify where the IAS 38 recognition criteria are met.

Are Software Licenses CapEx or OpEx?

Under IFRS and AASB, a software license that gives the customer control of identifiable software will generally be accounted for as an intangible asset and, where it has a finite useful life, amortized over that life. By contrast, a typical SaaS subscription gives the customer a right to access supplier-controlled software over the contract term and is accounted for as a service. The distinction therefore depends on the rights and control conveyed by the agreement, rather than simply on whether the license is perpetual or subscription-based.

The complications are contractual, not a matter of contract length. Whether a license bundled with implementation work splits into expensed and capitalisable components, and how a vendor-hosted on-premise license is treated, both turn on the specific rights the agreement confers and on your reporting framework. Contract duration on its own decides nothing.

Governance requirements can be established independently of the eventual accounting classification, while the accounting treatment should be assessed against the final contractual rights and applicable reporting framework. A license renewal worth more than your CapEx approval threshold warrants the same evaluation whichever line it lands on.

Implications of CapEx or OpEx for SaaS Projects

Accounting Implications of SaaS Projects

Under IFRS and AASB, SaaS expenditure can have several treatments. Subscription fees for access to supplier-controlled software are generally recognized as an expense over the service period. Configuration and customization costs may be expensed as the services are received, recognized over the SaaS contract term where those services are not distinct from the SaaS service, or initially recorded as a prepayment where paid in advance. Where expenditure creates a qualifying intangible asset controlled by the customer, it may instead be capitalized and subsequently amortized over its useful life.

Economic Implications of SaaS Projects

From a net present value perspective, the timing of the tax deduction matters: a deduction deferred to future periods is worth less than one taken now. That timing is set by tax law, not by the accounting treatment. In Australia the ATO is explicit that accounting classification is not determinative of the tax character of expenditure, so the deduction profile has to be established separately rather than inferred from whether the cost was capitalized.

Funding Source

The accounting classification does not necessarily determine how the investment is funded or governed. Organizations may fund SaaS costs through operating, transformation or capital-related budgets depending on internal policy. Material SaaS programs such as an ERP or CRM platform replacement, for instance, can still be evaluated and governed alongside major capital investments even where much of their expenditure is accounted for as OpEx. That makes OpEx budgeting a capital planning problem rather than a cost center one.

Developing a Business Case for your SaaS Projects

SaaS solutions are currently the most generic form of digital enablement and transformation. However, there is still some lingering resistance to the adoption of a SaaS solution in organizations that have a strong tradition of ‘owning’ their capital base. As it is likely that your SaaS investment proposal will need to be progressed through your Capex management system and approval processes, the underlying concerns of management need to be explicitly addressed.

Software Planning Horizon

The reality is that your software application has a limited useful life and requires repeated re-investment to benefit from rapid technological advances, such as in artificial intelligence. Additionally, the skills required to support and enhance a unique SaaS application or legacy technologies rapidly dissipate. Indeed, the more bespoke the software application, the greater the liability to maintain the solution. Consequently, software commonly has a shorter economic life than other capital assets. There is no five-year rule: IAS 38 requires an asset’s accounting useful life to be assessed on the circumstances of the particular asset. The business-case planning horizon should separately reflect the expected commercial life and decision context. With such short planning horizons, and such rapidly evolving technology, the argument for acquisition as opposed to simple adoption is extremely hard to make.

Identify Business Benefits

Like any investment, a SaaS solution needs to have clearly articulated business benefits. Software is needed for all the typical investment reasons: to achieve sustenance, savings, growth, compliance, environmental or strategic goals. Organizations running SAP, for example, are increasingly being incentivized to transition to cloud ERP offerings such as SAP S/4HANA Cloud, as SAP themselves pivot from an on-premises to a cloud vendor.

Organizations that have long operated internal authentication, operating system and productivity apps from Microsoft are seeing the savings from adoption of Microsoft 365 and other cloud services. Salesforce.com is now one of many SaaS-based CRM solutions to help organizations grow. A new breed of compliance and environmental management solutions are now on the market to address the unique challenges being presented to organizations as they look to meet their net-zero and sustainability goals.

What Is The Urgency for SaaS Projects?

More often than not the timing is set by the vendor rather than by you. Sometimes the urgency for a SaaS solution is dictated by the current provider ending support of legacy software versions, which greatly increases the risk of not doing anything. The urgency for transition to SaaS is also being dictated by resourcing unavailability for legacy solutions. The strategic value of software, however, is increasingly motivating a new platform to address competitive demands.

Organizations may find it difficult to achieve the equivalent speed of innovation and depth of capability from bespoke software that they can realize from adopting broadly supported platforms, where the cost of platform development and support is shared by all participants, and with each organization still able to differentiate their processes through their unique configurations.

Have You Considered the Risks of SaaS Projects?

The main ones are data security, vendor dependence and loss of internal capability. At the top of everyone’s mind is data security including confidentiality and accessibility. This is a valid concern. Nonetheless, a SaaS vendor is specialized in the provision and management of online software services. They have dedicated resources and platforms for ensuring that services remain secured and available. Indeed, any one organization would be unlikely to be able to offer the degree of governance and resilience of tier-1 SaaS company. When compared to the risks of internal platform and software version installation, administration, and support coverage, the inherent risk of a SaaS solution may indeed be lower than for internal deployment.

Is Your SaaS Solution Strategically Aligned?

It is aligned if it frees investment for the areas that actually differentiate you, and misaligned if it consumes that investment. Ultimately, an organization needs to fulfill its strategic vision. The weight of investment will need to be in areas that support its unique differentiators. These may be in its people, products, or market positioning. For most organizations, this is unlikely to be in the operation of its underlying enterprise resource planning systems. So, where cost can be saved, and resilience gained through migration to best-of-breed SaaS solutions, more money can be invested in areas that will truly underpin an organization’s long-term success.

Monitoring CapEx and OpEx for SaaS Projects

All significant projects including SaaS software implementations are intended to deliver long-term benefits and are thus investment-like in nature. They are strategic investments in economic terms, whatever their accounting classification. They consume substantial human and financial resources and need a robust business case to prioritize their inclusion in the project portfolio. Approval of these projects should be provided by senior management based on endorsement by IT, Finance, Procurement, and other impacted areas. All related costs should be budgeted and closely monitored.

Depending on the applicable reporting framework and the terms of the arrangement, some installation costs and software components may be capitalized, while others are expensed or recognized over the service period. However, irrespective of the accounting treatment, the budgeting, approval, execution and monitoring of the project is most related to your other significant capital projects and should be governed with comparable rigor.

Modern CapEx management systems such as Stratex Online will support the inclusion and effective monitoring of both CapEx and OpEx components of SaaS projects from a substantive and economic perspective to ensure your capital investments are optimized, no matter the form of software licensing adopted. Where SaaS spend stays on the standard OpEx route, strategic OpEx governance explains how to screen significant commitments before they are made.