Capitalizing software is difficult but rewarding for any company.

It's a process that allows accountants to present business finances more accurately, but it can be a complicated and challenging task to pull off.

It's very easy for an accounting department to miss projects that should be capitalized. Software engineers may start developing a project without notifying accountants, and by the time accountants are aware of the project, it may be too late to capitalize expenses.

But even when accountants know about capitalizable projects, it’s a complex, manual process that leaves lots of room for error. Fortunately, capitalizing software expenses doesn't have to be difficult. In this article, you'll learn:

• The rules of software capitalization
• How software is capitalized today
• An easier way to capitalize software expenses with automation

1. Types of arrangements. Software as a service (SaaS) includes a wide range of arrangements providing web-based delivery of applications managed by a third-party vendor. Platform as a service (PaaS) involves a third party providing a framework for a team of software developers to create and manage customized applications. Infrastructure as a service (IaaS) involves a third.
2. The final update is expected to tell businesses to look at the guidance in FASB ASC 350-40, Intangibles — Goodwill and Other — Internal-Use Software, to determine which implementation costs in a cloud computing arrangement that is considered a service contract can be capitalized as an asset. The EITF agreed that costs for employee training.

Armed with this knowledge, you and your business will never struggle with missed software projects and inaccurate data during the accounting process again.

For a new capex software that is being implemented (such as a new website, mobile app, CRM, accounting system, etc), what are the accounting rules for what project costs can be capitalized? There are generally several components to these projects, including an initial assessment before the project begins, the project work (design & build.

What is software capitalization?

In accounting, software capitalization is the process of recognizing in-house software as fixed assets. Accountants accomplish this by recording software costs on the balance sheet as capital expenses. Then, accountants can amortize these costs over time.

The ultimate purpose of capitalizing is to delay fully realizing an expense. If a company incurs expensive software costs, the company’s income will appear abnormally low during that period. However, if the accounting team can capitalize the software, the company can distribute the software’s cost over several years.

Essentially, it will look like the company is paying off the software as the business uses it over time. This provides a more accurate assessment of company finances, both to the business and to outside investors.

As long as the in-house software meets eligibility requirements, businesses may capitalize the following:

• Computer software developed for internal use
• Hosting arrangements obtained for internal use, e.g. using a Software as a Service (SaaS) vendor
• Website development costs

Some examples of software developed or acquired for internal purposes include:

• Project management systems
• Collaboration software
• Software for on-boarding
• Reporting or ticketing systems

Following GAAP and IFRS

Software capitalization is a powerful tool for company finances. However, there are strict guidelines and practices for capitalizing expenses, and it’s in a business’s best interest to keep these standards.

In particular, accountants should follow either the Generally Accepted Accounting Principles (GAAP) or The International Financial Reporting Standards (IFRS). Pre IPO and public software companies need robust tracking to be compliant with GAAP accounting standards ASC 350 and/or ASC 985.

These standards and principles provide consistency in a company’s financial statements and in financial reporting across multiple companies. This allows investors to analyze company finances with more fairness and transparency.

GAAP is the accounting protocol issued by the Financial Accounting Standards Board (FASB). It includes the best practices and authoritative standards adopted by the U.S. Securities and Exchange Commission and is used across the United States. You can access FASB’s Accounting Standards Codification online (requires registration fee).

Outside of the United States, businesses follow the International Financial Reporting Standards (IFRS). IFRS is issued by the International Accounting Standards Board (IASB). You can access IFRS’s standards online too (requires registration fee).

Fortunately, FASB and IASB are working together to converge their respective standards. Currently there are differences between GAAP and IFRS, but this article will focus on adhering to GAAP when capitalizing software.

When software is eligible for capitalization

A company can capitalize software if it’s designed for company use and there are no plans to market it.

The Financial Accounting Standards Board summarizes these two requirements in ASC 350-40. In order to classify software as in-house, it must meet the following characteristics:

1. The software is acquired, internally developed, or modified solely to meet the entity’s internal needs.
2. During the software’s development or modification, no substantive plan exists or is being developed to market the software externally.

A company may conduct a market feasibility study on the software and still meet the requirements.

Accountants can determine a new project’s eligibility by answering the following questions:

1. Has management committed to funding the project?
2. Is it likely the project will be completed?
3. Is it likely the software will be used for its intended purpose?

If the answer to all of these questions is “yes” then accounting should plan to capitalize the in-house software.

Please note that the rules for capitalizing any company property still apply to software. For example, the software must be expected to benefit the business for longer than one tax year to qualify as a fixed asset.

Which costs should be capitalized

The easiest way to capitalize all the appropriate costs is to first identify three stages in the software’s life: the preliminary stage, the development stage, and the post-implementation stage.

By identifying when these stages begin and end, you can be confident you’re capitalizing all the appropriate costs.

Stage 1: Preliminary

In this stage, your company is still just planning to use in-house software. Do not capitalize any costs in this stage.

Costs in this stage include company time spent on:

• Considering developing an in-house software vs. using a third-party software
• Determining the system requirements for the software
• Deciding who will work on the project and for how long

Stage 2: Development

During the software development stage, some costs should be capitalized, and some costs should not be.

The following development costs should be capitalized:

• Costs of materials and services in developing or obtaining the software (for both internal and external resources)
• Payroll and bonuses for employees who worked on the project
• Interest costs on loaned money used to develop the software

The following development costs shouldnot be capitalized:

• Overhead costs
• Costs for data conversion
• Training costs

If your business is using a Software as a Service vendor, FASB revised ASC 350-40 to provide guidance on capitalizing software in a cloud computing arrangement that is a service contract.

However, FASB summarized their position by instructing accountants to follow the same policies used to capitalize software that was developed in-house. (This rule is effective for businesses beginning in 2020).

Stage 3: Post-implementation

At this stage, the software is up and running for the entire company. You do not capitalize any costs in this stage, including:

• Operating costs
• Repair and maintenance costs
• Fixing bugs or minor issues

In short, you do not capitalize costs in the preliminary or post-implementation stage. In between the two, during the development stage, you capitalize the materials and services it took to develop the software.

There is one exception to this rule, however. If your business performs a significant upgrade to the software post-implementation, you can capitalize the costs for the upgrade. Accountants can determine if the upgrade is significant by answering the following questions:

1. Does the upgrade add functions that the software previously couldn’t perform?
2. Do the engineers classify the upgrade as significant?
3. Can you easily distinguish upgrade costs from maintenance and minor enhancement costs?

If the upgrade is eligible for capitalization, you can capitalize the same costs mentioned in the development stage.

When amortization begins

Amortization begins at the start of the post-implementation stage.

Amortization for capitalized software does not begin with testing or trial runs. Instead, amortization begins once the software is placed in service throughout the company and can perform its intended function.

In the case of a hosting arrangement, capitalized expenses are amortized over the term of the agreement.

When estimating the useful life of software, consider that technology becomes outdated quickly. In some cases, an appropriate useful life expectancy can be as low as 3 to 5 years.

How software capitalization is currently done

Today, accountants usually capitalize software manually. Here’s what the process typically looks like:

First, accountants ask product managers and engineering managers to fill out data on new projects that may be eligible for capitalization. This data is manually entered into a spreadsheet, Google Sheet, or Airtable.

The product manager and engineering manager then fill in information by estimating how much time each worker spent on different projects during the most recent period.

Accountants then ask the payroll team to provide compensation and salary data for all impacted employees. Then accountants multiply the time spent on the project by the payroll numbers.

The product of this calculation is the total value of the capitalized software in that period. Once accountants acquire this number, they move this amount from the operating expenses line on the income statement to the capital expenditures line on the balance sheet.

Disadvantages to Manual Software Capitalization

The current manual approach is a necessity for many businesses, but it opens up unnecessary opportunities for error, waste, and frustration for accountants and managers. Here are some of the pitfalls of capitalizing software expenditures manually.

1. Manually capitalizing is tedious and time-consuming

Entering information into a spreadsheet is monotonous and eats up company time. In some cases, managers have to spend valuable time just finding the correct information before they can begin entering the data.

2. Manually capitalizing is inaccurate

When entering a lot of data into a spreadsheet, there will invariably be errors. Managers roughly estimate the time employees spent on projects. Sometimes they simply forget which employees worked on which projects and for how long.

Additionally, typos are common and it’s easy to enter information in the wrong field. When you put these factors together, you end up with inaccurate results.

3. Manually capitalizing means missed projects

Sometimes engineers do not communicate to accounting that they started new projects. In some cases, significant time passes before the accounting team is aware of a capitalizable project.

In short, capitalizing software manually is difficult and unreliable. Fortunately, there will be another option in the future.

How software capitalization will be done in the future

In the future, with GitBloom, accountants will be able to capitalize software programmatically. This solves many of the common problems that companies face when capitalizing software costs.

With GitBloom CapEx software, accountants will be able to manage the software capitalization process automatically. Here are just a few of the powerful features that accountants will have access to with GitBloom.

1. Detect new projects in the preliminary stage

Engineering managers and product managers often start new projects without communicating with the accounting department. Now, whenever software developers create a new microservice, file, or module, Gitbloom will automatically notify accountants.

This can spur accountants to chat with engineering managers and product managers to determine whether or not the new project is eligible for capitalization. Accountants receive these notifications in real-time, ensuring that accounting departments never miss a new capitalizable project again.

2. Detect when a project is in the development stage

GitBloom plugs into your company’s signals, metrics, or logging systems and detects when engineers start developing the software. This means accounting immediately knows when workers begin developing a project and who in the engineering department is in charge.

3. Measure where engineers spend their time

Accountants can determine which engineer has worked on which project by inspecting lines of code. GitBloom records pull requests, commits, and pushes for every service, file, and module. All of this can be done in real-time.

This allows accountants to measure how long each engineer has spent on each project. Then, accounting can discuss measurements with an engineering manager or product manager to determine where to allocate engineering time.

4. Calculate the software value

Ifrs Capitalization Of Software Projects For Dummies

GitBloom pulls measurement data from your company’s Git repository. This includes:

• Assembla
• AWS
• Azure DevOps (TFS)
• Beanstalk
• Bitbucket
• GitHub and GitHub Enterprise
• GitLab
• Google Cloud, and more

GitBloom can also pull salary data from your company’s payroll system, including programs like Workday, Gusto, BambooHR, and more

By combining the repository and payroll data, GitBloom can estimate the value of capitalization. Accounting teams can then make adjustments based on other input to arrive at the final value of software capitalization in a given period.

Accountants can then pull and share a report of all this information with auditors to corroborate how they arrived at the capitalization value.

Automation is the future of software capitalization

In the future, accounting and finance functions will be automated with software solutions like GitBloom. Finances will be easily auditable and fully trackable. With GitBloom, accountants will be able to...

• Never miss a project eligible for capitalization
• Track where and when workers contributed to software development
• Easily pull data on work time and salary
• Accurately calculate the value of capitalization

Increase productivity, simplify your workload, and help your business succeed with an easier way to capitalize software.

Date recorded:

Background

The Committee received a submission asking about the customer’s accounting in cloud computing arrangements (e.g. Software as a Service (SaaS) arrangements). The submitter asks how the customer applies IFRS Standards in accounting for fees paid to the supplier to access the supplier’s application software running on the supplier’s cloud infrastructure. In such arrangements the capability provided by the supplier (the cloud service provider) to the customer is to access the supplier’s application software running on the supplier’s cloud infrastructure. The cloud infrastructure is a collection of hardware and software including network, servers, operating systems, storage, and individual software capabilities. The customer generally does not take possession of the software. Instead, it accesses the software on an as-needed basis over the internet or via a dedicated line. The customer does not manage or control the underlying cloud infrastructure with the possible exception of customer-specific software configuration settings. Contracts are often for an initial non-cancellable period (for example, two years), with options within the contracts for the customer to extend them.

In the absence of specific requirement in IFRS Standards, the submitter asks about the accounting treatment and the staff has analysed the appropriate treatment by considering (a) whether the rights to access software are within the scope of IAS 38 or IFRS 16 Leases from the customer’s perspective; (b) whether or not SaaS arrangements create an intangible asset for the customer; and (c) if the customer has an intangible asset, how should the customer measure that intangible asset and any liability related to its acquisition.

Ifrs Capitalization Of Software Projects

Staff analysis

With regard to (a) above, the submitter asks for clarity as to the distinction between ‘rights held by a lessee under licensing agreements’ and ‘leases of intangible assets’ referred to in IFRS 16:3(e) and 4 respectively. The submitter also says some think the scope exclusion in IFRS 16:3(e) applies only to the licensing agreements specified in that paragraph, and not to licensing agreements for software. The staff consider the explanation of a 'license' in IFRS 15 Revenue from Contracts with Customers (IFRS 15:B52) and conclude all leases of software would result in rights being held by a lessee under licensing arrangement and hence such rights are within the scope of IAS 38 but not IFRS 16. With regard to (b) above, the submitter questions how to assess the control element from the ‘underlying resource’ in IAS 38:13 (i.e. the customer’s right to access the supplier’s software or the application software itself?). The entity has to assess whether it has the power to obtain the future economic benefits flowing from that right and to restrict the access of others to those benefits. The staff conclude that it depends on the particular terms and conditions of the SaaS arrangements (such as whether the customer has a right to possess a copy of the application software and the level of configurations specified by the customer) and judgement is required. If the customer does not control the right to assess the supplier's software, the customer accounts for the arrangement as a service contract. The staff think in most SaaS arrangements the customer will not have an intangible asset for the right to access the supplier’s software.

With regard to (c) above, the concerns of the submitter are the measurement questions in the aspects of allocation of payments to different components of the arrangement and the variable payments. There is lack of specific requirements in IAS 38 and the staff consider the customer could look to other IFRS Standards (such as IFRS 16 that provides requirements on allocating the consideration in a contract to different components). Regarding the accounting for variable payments, the Committee has previously discussed the same issue and concluded at its March 2016 meeting that the matter is too broad to address and decided not to add this matter to its agenda and issued an agenda decision to that effect. Accordingly, the staff consider the Committee should not opine upon the measurement of the intangible asset and any related liability for SaaS arrangements.

Staff recommendation

The staff consider that the requirements in existing IFRS Standards provide an adequate basis for the customer to account for rights to access the supplier’s application software in SaaS arrangements. The staff recommend the Committee does not add this matter to its standard-setting agenda but instead publishes an agenda decision that clarifies the following matters: (a) an entity reads IFRS 16:3(e) to cover all software licensing agreements and, thus, that an entity account for all rights to access or use software applying IAS 38, not IFRS 16; (b) ‘underlying resource’ in IAS 38:13 refers to the asset that an entity would recognise as an intangible asset; (c) whether the customer controls the right of access depends on the particular terms and conditions of the arrangement. However, simply having a right to access the supplier’s application software would not be sufficient to indicate that the customer controls a resource at contract inception that meets the definition of an intangible asset.

Discussion

Most of the Committee members agreed with the staff analysis in respect of classification of the rights to access software as intangible assets under IAS 38 rather than a lease under IFRS 16, although one of the Committee members pointed out that he cannot see why intellectual property for a software is different from that for a film.

Before starting the discussion, the staff clarified that the issue is when the customer can actually control the intangible asset, since the customer only obtains the rights to access the software but not the software itself. A Committee member is asking if there is actually a two-step approach, i.e. if the customer does not control the software, it has to consider whether or not it controls the rights to access the software. For SaaS arrangements, the only place one can use the software is on the vendor's cloud. If there is significant configuration, the software is probably regarded as an asset that the customer controls, just like the situation that the software is downloaded onto the customer's computer and the customer can run it independently. The Committee discussed different indicators of control but there is diversity in views among Committee members. For example, a Committee member considered customisation may not be a key indicator of control because the supplier can license it to others even though the supplier provided a highly customized software; another Committee member suggested that exclusivity of the software (i.e. ability to prohibit other customers from using the software) should also be a factor to consider but there are some dissenting views that this is not a key factor.

A Committee member asked about how US GAAP deals with this issue. In response to that, another Committee member pointed out that it depends on whether the customer has the ability to take the software to its own server symmetric to the vendor transferring control of a product. If no, that arrangement is regarded as a service contract.

Since there were different views among the Committee members, the Chair suggested the staff to prepare an updated proposed wording for the tentative Agenda Decision and that the Committee could discuss the issue again on the second day of the meeting.

Ifrs Capitalization Of Software Projects For Beginners

In the Day 2 meeting the staff said that because in most SaaS arrangements the customer has no control over the software they had updated the draft by removing the term 'take possession of the software' and inserting 'right to access the control of the software.' Some Committee members insisted that analysis of whether the customer has the ability to restrict others from using the software should be added. Others said that they should expand the scope of IFRS 16 and IAS 38. The Chair has stated it is likely that no standard-setting will be done for the matter. There were a lot of debates over the 'right to access the software' among Committee members.

Decision

The Chair suggested that the Committee needed more time on the proposed wording and will come back to this next time. Accordingly, no decisions or conclusions were reached.