Recognizing the Intangible
Looking at the current legislation on intangible asset (e.g., software) capitalization and the specification of the legislation by various institutes (e.g., IDW, DRSC), it becomes clear that this topic is difficult for IT to examine only casually. For this reason, the topic is often handed over to IT controlling and implementation takes place without management-level coordination between the CIO and the CFO. The result is a model for software capitalization that is often associated with disadvantages for IT. However, in times of increasing digitization dynamics and simultaneously rising cost pressure, IT must understand and actively master the concepts of software capitalization in order to meet various stakeholders‘ expectations. This article aims to highlight the tension between IT and its stakeholders with reference to software capitalization, as well as to present possible solutions that enable IT to exchange information with its stakeholders on an equal footing.
Considerations when Activating Software
When balancing software, applicable accounting standard (primarily HGB, IFRS, and US GAAP) regulations must be observed. The German Commercial Code (HGB) and the International Financial Reporting Standards (IFRS) are of particular importance for companies based in Germany and operating globally. The following section deals with the basic principles of accounting for software in accordance with HGB and IFRS.
According to the German Commercial Code (HGB), corporations‘ annual financial statements must give a true and fair view of their net assets, financial situation, and operation results in accordance with generally accepted accounting principles. The International Financial Reporting Standards (IFRS) require the application of the true and fair view principle, according to which financial statements must present a true and fair view of a company‘s net assets, financial situation, and operation results, as well as its cash flow.
In addition, both the German Commercial Code (HGB) and IFRS stipulate the „accrual principle.“ Accordingly, the financial effects of transactions, events, and circumstances are to be recorded in the period in which they occurred and not in the period in which the payments were made.
Combining these two principles makes it clear that software acquisition or development expenses are to be included in the balance sheet in accordance with relevant accounting and depreciated across their operating life.
However, a crucial difference exists between the two accounting standards of the German Commercial Code (HGB) and IFRS in the treatment of internally generated intangible assets: the obligation to capitalize under IFRS and the option to capitalize under HGB (see Figure 1).
Obligation to capitalize intangible assets under IFRS
IFRS accounting entities are required to capitalize internally-generated intangible assets. As the ability to capitalize internally-generated intangible assets is difficult to assess, special rules must be applied to the assessment. The criteria of technical feasibility, realistic usability, intended completion, future economic benefits, and a reliable valuation of software must be met on a cumulative basis. A resulting requirement for the reliable assessment of feasibility and economic benefit is the separation of research and development.
To assess capitalizable costs, the development process must be separated into research and development (IAS 38.53). Expenses for research cannot be capitalized in this context. If an organization cannot clearly separate research from development, the related expenses must be treated as if they had been incurred only in the research phase (IAS 38.53).
Assuming classic software development according to the waterfall model, the two phases of research and development can be separated. In agile methods such as Scrum, the separation is often not simply possible through the phases of a project.
Option to capitalize intangible assets under the German Commercial Code (HGB)
Since the German Accounting Law Modernization Act (Bilanzmodernisierungsgesetz), German Commercial Code (HGB) accounting entities have an option to capitalize internally-generated intangible assets as part of fixed assets. This option means that the reporting organization can decide whether to capitalize expenses for internally-generated software that is to remain in the organization (fixed assets), as long as they meet the capitalization requirements under HGB. If they exercise the capitalization option, they must also do it in subsequent periods. In formulating the capitalization option and the associated requirements, the legislator referred to the capitalization requirement under IFRS in many areas.
Under the HGB, the two research and development phases must also be clearly separated from each other. Due to the parallels in legislation between IFRS and HGB, the more concrete formulation of the criteria according to IFRS is often used in practice.
Software Capitalization as an Accounting Policy Instrument
If software is capitalized as an intangible asset, the necessary acquisition or development cost is not recognized in the profit or loss statement, but rather capitalized in the balance sheet. The fixed assets on the assets side of the balance sheet increase by the capitalized amount. Depreciation of the asset over its operating life reduces the capitalized amount by the depreciation. The depreciation is recognized in the profit and loss statement in the corresponding period.
Thus, software capitalization leads to a better external presentation, due to the increase in the company‘s assets and to a shift of expenses from the acquisition period to the periods of use.
Organizations therefore use the options and discretionary powers the law allows to influence their external presentation and their results under commercial law. In principle, organizations can pursue two accounting strategies: 1) capitalize as little as possible, and 2) capitalize as much as possible. If a company wants to show as many assets as possible in its balance sheet, it will try to capitalize as many expenses as possible for the implementation and development of software. Capitalizing expenses and the subsequent depreciation during the operating life also leads to an expense shift into the future.
The capitalization option granted under commercial law offers little room for accounting policy. Due to the different uses of the capitalization option, this balance sheet item is excluded from the comparison of different organizations in order to enable an objective comparison. It should also be noted that deferred tax liabilities must be recognized as a result of the difference between the tax balance sheet and the commercial balance sheet, and that the company preparing the balance sheet is prohibited from making distributions. The administrative expense associated with exercising the capitalization option under commercial law does not generally justify the advantages. In addition, when exercising the option, the reporting company presumably cannot refrain from exercising it in subsequent periods without good reason (= capitalization trap).
IFRS accountants, on the other hand, are required to capitalize internally-generated intangible assets if research and development can be clearly separated. Even though some companies refrain from capitalizing internally-generated intangible assets on the grounds that „separation from R&D is not possible“ due to agile development and working methods, intangible asset capitalization is common in some industries. Especially in organizations where intangible assets are the main component of fixed assets, capitalization is extensive, which is often the case in the financial and service sectors. For these companies, the proportion of intangible assets on the balance sheet reflects innovation.
Leading the Dialogue: Interests and Challenges in Software Capitalization
Chief Financial Officer: P&L as an essential basis for decision-making in a dynamic environment
The CFO has a significant interest in understanding the different IT projects‘ impact on the financial key figures. In case of strategic projects, the project‘s impact on the organization‘s P&L is therefore used as a key business factor in the decision-making process. In addition, it is in the CFO‘s interest to strive to realize a consciously-chosen accounting strategy by deciding for or against software capitalization.
However, IT is characterized by an especially high level of dynamic, which is reflected in the project business in particular. Projects are unique. Requirements for ongoing projects are revised as the level of knowledge increases. In addition, necessary and available resources change rapidly, and the methods and tools used are versatile. In reality, these dynamics are difficult to plan and control; thus, in the initial stages of decision-making, their impact on the profit and loss statement is limited. During the course of the project, for example, specifications may have to be made to the software due to regulatory requirements, or the project may be reorganized so that capitalization guidelines can no longer be met. In a worst-case scenario, the initial decision to capitalize software may have to be revised.
However, the CFO‘s expectations described at the beginning of this chapter are understandable, as the CFO must manage and be responsible for the company‘s business development as much as possible. However, two challenges can interfere with fulfilling this expectation. Firstly, the focus on the P&L is associated with the risk that expenses are not managed and reduced as those expenses arise. Secondly, decisions for and against projects could be made predominantly based on P&L impact rather than need or value creation. The aspect of non-calculable dynamics is also often neglected, especially with regard to resource planning.
For the implementation of IT projects, internal capacities must be built up and enabled at an early stage. Once internal IT resources have been built up, the associated personnel expenses are difficult to control. Activating these personnel expenses merely leads to postponing personnel expenses in subsequent periods. Therefore, it is important to agree at an early stage—and at eye level with the entire management—which strategic capacities are to be built up in IT. Once the capacities have been built up, they must be deployed in the best possible way, irrespective of the P&L impact.
Decisions for or against projects must be made on the basis of different decision-relevant information so that IT’s value contribution is maximized. Therefore, in addition to the P&L impact, the expected benefit, the availability of resources, the necessity (e.g., regulatory projects), and the risk of success must be considered when making a decision for or against a project.
Financial accounting and auditors: auditing compliance requirements in the light of incomplete information
Another group of stakeholders includes the controlling department, the financial accounting department, and the auditors, who determine the annual financial statements‘ correctness. All of these stakeholders are interested in the correct depiction of the software capitalization facts in the company‘s books. On the one hand, the requirements for software capitalization—such as documentation and the principle of continuity—must be met. On the other hand, clear guidelines and criteria must ensure that facts do not have to be corrected retrospectively, as this practice can lead to a distorted and unplanned effect on the profit and loss statement.
To ensure that controlling, financial accounting and auditors‘ expectations can be met, an early exchange with these stakeholders is essential. Especially when defining a capitalization guideline and the concept for recording the selected options and applied discretionary powers, the reality of IT must be taken into account. IT is not a production environment in which the research and development phases can be strictly separated and manufacturing costs can be calculated on the basis of production orders and time reports.
The challenge in terms of meeting the above expectations is primarily to avoid administrative overhead. Identifying research and development expenses should be as simple as possible. Our experience shows that identifying development expenses through selection boxes in employee time reports is susceptible to mistakes and requires very detailed recording, due to the way IT works. This usually does not happen in reality. Time-consuming, manual rechecking and corrections are the consequence. The requirements for complete documentation can often only be met to a limited extent with the existing tool landscape. In practice, Excel or Word-based toolkits are often used to record, merge, and evaluate relevant data. It should be noted that this option is error-prone, the documents quickly become outdated, and an enormous amount of manual effort is expended on evaluation and analysis.
With reference to the requirements of the stakeholder auditors, controlling, and financial accounting, the complexity for IT is therefore to mutually work out a concept for software capitalization based on the current collaboration model and tools that complies with the estimate and evaluation criteria as well as provides complete documentation. Somehow this feat must be accomplished without requiring enormous administrative IT efforts. Otherwise, the administrative effort associated with software capitalization does not justify the expected added value.
The joint business and IT responsibility for capitalization of software
Business is another internal IT stakeholder. It must be involved in designing the capitalization guidelines and also implementing the criteria for estimate and evaluation. In particular, business can best make the assessment of whether an intangible asset that is associated with sustainable economic benefits is being generated. In addition, they must review defined estimate criteria at regular intervals (for example, as part of the rolling forecast process). This review identifies effects on P&L at an early stage and avoids special depreciation.
The business usually implements IT projects with a large share of personnel resources. Depending on the accounting strategy selected, the business may be interested in capitalizing these expenses. Even without capitalization, increasing personnel expenses are justified by the fact that the business is contributing its capacities to IT projects. However, the business often expects that the responsibility for the capitalization‘s correctness lies with IT, which is responsible for the projects as a whole. Similar to IT, however, the business should also control its personnel expenses as they arise. This control is only possible if both areas coordinate the planned projects and the capacities required for them on an equal footing and monitor them regularly. The accounting treatment of the expenses can be neglected in this step.
The major challenge facing CIOs is therefore reconciling the previously described areas of tension with the reality of IT in order to make the software capitalization process and the associated requirements and activities as lean as possible for IT (see Figure 2). With its holistic approach to IT management and integrative solution concepts, Bee360 offers a wide range of options to provide IT with the best possible support for software capitalization.
Bee360 Enables Lean Software Capitalization with Unimpaired IT Management.
First of all, a decision has to be made as to whether IT projects that lead to the creation of an intangible asset should be capitalized or not. As a basis for this decision, Bee360 uses the project’s planned expenses in the system for its entire term. Thus, among other things, the depreciation incurred can be simulated on the basis of the planning across the operating life and adjusted in the event of changes to the planning by means of a renewed simulation. Consequently, precise statements can be made about the effect of software capitalization on the company‘s P&L, which supports the decision for or against a project from the CFO‘s point of view. However, decisions for or against a project based on the P&L impact must not influence the actual management of IT at the level of expenses and resources.
Once the decision to capitalize software has been made, a well-defined concept must be created that meets the requirements for software capitalization. As previously mentioned, it is necessary for IT to be in close contact with the business in order to explicitly define the requirements. As a central tool for managing, controlling, and documenting projects, Bee360 enables both areas to work together efficiently in one system on a uniform data basis and to develop a concept for software capitalization. In doing so, Bee360 not only makes comprehensible concepts and decisions available in a central tool for all parties involved, but also offers the possibility of integrating documentation outside of Bee360 (for example, in Confluence or Jira) by means of integrative solution approaches. Extensive documentation ensures that decisions are made in an understandable manner and that future issues can also be evaluated using the same approach to software capitalization (continuity principle).
When developing a concept for software capitalization, it is also important to reflect the requirement to separate the research and development phases. Numerous options exist for this requirement in practice (see Gartner G00341471). One option that Bee360 enables is the structuring of a project into sub-projects for easy identification, evaluation, and documentation of parts that can be capitalized. Consequently, a lean documentation of the expenses incurred is also possible because the time reporting to sub-projects makes it possible to immediately identify which parts of the project’s personnel costs can be assigned to the development phase and can therefore be capitalized.
In order to regularly review capitalization decisions, it is necessary to compare the planned expenses with the Actual incurred expenses. Here, too, a close exchange between IT and business is important. Bee360 facilitates this collaboration by providing full transparency of all decision-relevant information in a central tool at any time. Within the framework of rolling forecast, it is thus possible to question at certain intervals whether capitalization decisions still make sense and should be implemented. For example, if efforts in the development phase turn out to be much higher than planned, which leads to high depreciation in later periods when capitalized, the IT budget would be affected more than originally assumed. Bee360 identifies such changes at an early stage in the course of rolling forecasts, coordinates them with the business, and guarantees timely corrective action.
Effectively Manage the IT Challenges of Software Capitalization with Bee360!
Bee360’s full transparency of data and the effect of software capitalization makes it possible to meet the stakeholders‘ requirements. At the same time, this transparency also creates a holistic view of the planned and ongoing projects within the organization, detached from the topic of software capitalization. This approach clearly shows which business processes are to be supported by the project, how the project fits into the corporate strategy, and to what extent the project creates value in the organization. It is essential that existing steering systems are not impaired by software capitalization and that IT’s administrative effort is kept as minimal as possible. A clear distinction must be made between the stakeholders‘ requirements and the way IT works and manages. On the one hand, Bee360 enables lean documentation and makes the impact of software capitalization on the organization‘s P&L visible. Stakeholders are thus provided with the information they need to steer the organization. However, IT is still managed at the spend and resource level and must remain unaffected by stakeholder requirements. Bee360 therefore offers IT leaders the ideal opportunity to focus on helping shape business processes sustainably within the organization and participate in projects that create long-term added value.