A guest article by Dr. Harald Riedel, tax advisor and certified public accountant, on accounting aspects of complex software systems, claimed useful lives, and a notable election right.
When implementing more complex software systems, such as ERP systems, significant additional expenses—in the form of planning costs, implementation costs, training costs, maintenance costs, data migration costs, etc.—are regularly incurred in addition to the “actual” expenses for the software itself. From both a commercial accounting and a tax perspective, this raises the question of whether such expenses should be recognized immediately as an expense or whether they should be capitalized and depreciated over their normal useful life. The following section will first outline the commercial accounting aspects of this topic and then turn to tax law.
Commercial Accounting Aspects
A business entity preparing financial statements must capitalize the assets acquired for its business in its (commercial) balance sheet and depreciate them over their expected useful life. The acquisition cost of an asset to be capitalized includes all expenses that can be individually allocated to the asset and that the business incurs to acquire the asset and bring it into an operational condition.
In practice, the statement issued by the Institute of Public Auditors in Germany (IDW), IDW RS HFA 11, plays a decisive role in the accounting treatment of software acquired for a consideration by the software user. When classifying software for accounting purposes, a distinction must first be made between firmware (e.g., BIOS), system software, and application software (a general term for all programs that perform the user’s data processing tasks). Within application software, a further distinction must be made between custom software—developed exclusively to meet the needs of a specific user—and standard software—designed for use by a wide range of users.
Acquisition or Production Transaction
For the aforementioned question—whether an expense is immediately deductible or an asset to be capitalized—it is essential to distinguish whether the software is acquired (acquisition transaction) or developed in-house (production transaction). If the software is acquired, it must be capitalized at its acquisition cost—including, among other things, the costs of bringing it into operational readiness—and depreciated over its useful life.
Under commercial law, a manufacturing transaction generally provides the option to either capitalize the costs and depreciate them over their useful life or recognize them immediately as an expense. For tax purposes, however, there is a prohibition on capitalizing costs in a manufacturing transaction; that is, the related expenses are immediately deductible.
The purchase of off-the-shelf software (such as SAP) is generally considered an acquisition transaction that must be capitalized. This remains the case even if the off-the-shelf software still needs to be adapted to the company’s operational requirements. However, if the software is modified to such an extent that a fundamental change to the standard software can be assumed—or the standard software is effectively “obliterated”—this constitutes the creation of a new asset: “custom software.” Whether a new asset is created is primarily determined by the nature of the software’s functions before and after implementation and customization.
In addition, to determine whether this new asset is “purchased” or “produced,” one must also consider who bears the production risk. As is already evident from this distinction, the assessment of software projects from a financial accounting perspective regularly depends on the circumstances of the individual case.
Expenses
Expenses for customizing the software—that is, parameterization and other measures to integrate the software into the specific operational environment, such as consulting fees related to the ramp-up of the programs, program and system tests, modification and integration of individual programs, programming or setup of interfaces, and installation of the software on the computers of the affected employees—must be capitalized as part of the acquisition cost if they serve to bring the software into operational readiness. It is irrelevant whether these measures occur immediately at the time of acquisition or at a later date. User training, on the other hand, is not attributable to bringing the software into operational readiness and therefore cannot be capitalized.
Conversely, expenses incurred prior to the acquisition of the software for activities aimed at identifying and evaluating procurement alternatives may not be capitalized. These include, in particular, expenses incurred prior to the software’s implementation in connection with general organizational consulting, the analysis and optimization of business processes, the development of preliminary concepts, etc.
Dr. Harald Riedel
Dr. Harald Riedel is a certified public accountant, tax advisor, and founding partner of PKF Riedel Appel Hornig GmbH, with more than 30 years of experience in auditing, tax consulting, and management consulting.
He specializes in auditing and advising manufacturing, retail, and service companies; designs tax models; performs business valuations; and advises on structural measures. Dr. Riedel is a member of the executive board of PKF Deutschland GmbH and a member of the Chamber of Tax Consultants and the Chamber of Public Accountants.
His practice focuses on:
- Restructuring/Conversions
- Acquisitions and divestitures
- Corporate tax law
- International tax law
- Contact person for small and medium-sized businesses
His key industry areas are:
- Automotive
- Fashion
- Service Companies
- Renewable Energy
Dr. Harald Riedel will be happy to assist you:
If the costs of the software project are to be capitalized, the next step is to estimate the depreciation period during which the software is expected to be usable (known as the useful life). In practice, the tax depreciation schedules provided by the tax authorities have generally been used for this purpose to date.
Tax Considerations
In the world of taxation, the treatment of software projects has been radically “redefined” by the tax authorities over the past two years. In several official announcements (so-called BMF letters), the tax authorities have stipulated that a standard useful life of one year may be applied to “business and application software.” In practice, this rule means that the full cost of acquiring the software in question can be claimed for tax purposes immediately in the year of acquisition. The tax authorities explicitly state that the taxpayer may deviate from this assumption. Thus, the taxpayer effectively has a right of choice, even though the tax authorities, in the same breath, strictly deny the existence of a tax-related right of choice and, according to their statements, assert that there is no immediate write-off, no new depreciation method, and no special form of depreciation in this context.
In the tax authorities’ view, business and user software in the above sense includes, among other things, not only standard applications but also applications tailored to individual users, such as ERP software, software for inventory management systems, or other application software for business administration or process control.
While the tax authorities provide a very detailed definition of eligible computer hardware, the explanations regarding eligible software are quite limited. Nor do they provide a clear definition of what they consider to be eligible (and what is not). Tax literature concludes from this that the scope of application with regard to eligible software is not subject to any significant restrictions—and should therefore be interpreted broadly.
At this point, one might criticize the tax authorities’ position. For example, to what extent does the software user have the option to assume a one-year useful life and, in effect, can still choose (in the tax authorities’ own words: “No objection will be raised …”) to claim the full amount of depreciation in the fiscal year of acquisition? One might also ask how realistic it is to assume that the purchased software has a useful life of only one year and is therefore used for only one year (after which new software is purchased the following year).
After all, especially with large and complex software projects—where implementation alone incurs enormous costs and, in some cases, takes longer than the potential useful life of one year—one must ask whether this can even remotely reflect the actual circumstances. Regardless, taxpayers can take particular delight in the fact that they are given the opportunity to implement (extreme) tax planning strategies. Depending on their tax burden requirements, they can opt for a long (more realistic) or a short useful life.
A Regulation on Shaky Ground
Reportedly, the background to this regulation by the tax authorities is that this de facto immediate write-off was negotiated during a video conference between the former Chancellor and the state premiers to stimulate the economy during the COVID-19 pandemic. The tax authorities were then left with the thankless task of providing a technical basis for this political decision.
Since this new interpretation by the tax authorities rests on relatively shaky legal ground and the courts are not bound by this administrative opinion, disputes with the tax authorities should be avoided at all costs. For example, one should simply comply with the tax authorities’ requirement that, when applying this “immediate write-off,” the software must still be included in the inventory list (asset register) without questioning the logic behind it too thoroughly. This is because courts are not bound by the tax authorities’ views, but rather by the law.
To conclude by reconnecting to the commercial balance sheet: Discrepancies between the commercial and tax balance sheets resulting from this issue must be accounted for by recognizing deferred tax items (typically liabilities) in the commercial balance sheet, which generally reduces the impact of these discrepancies on net income.
