Reagan-Era Software Accounting Rules Prepped for Modern Refresh

The tools and apps inside a modern tractor do more than help farmers plow their fields; they also test soil quality, measure ground temperature, and even direct self-driving machines to spray fertilizer.

The development of this cutting-edge software moves fast—but not for accounting. The methods by which farm equipment manufacturers and other software makers account for their expenses date back decades.

“The accounting pronouncements and standards really haven’t kept up with the times or the way our IT counterparts do software development,” said Lara Long, chief accounting officer for Agco Corp., the Atlanta-based maker of Massey Ferguson tractors, Fendt combine harvesters, and other agricultural equipment.

US accounting standard-setters want to change that. The Financial Accounting Standards Board is plotting to bring accounting rules made in the 80s and 90s into the era of smartphones, apps, and artificial intelligence to make the rules better reflect the fast-moving research that fuels modern software development.

The goal: bring separate and sometimes conflicting bits of software accounting guidance into one central place in the US accounting rulebook, draw clearer lines on the types of costs that need to be recorded on company balance sheets, and require new disclosures so investors and analysts can better understand how the costs of buying or developing software hits corporate profits.

“The current accounting model for software costs has reached its expiration date,” said Jonathan Nus, managing director with advisory firm Alvarez & Marsal. “It’s probably several years beyond that.”

Impact Across Industries

Software accounting isn’t an issue just for tech companies. Computer programs are ingrained into every facet of most business operations—from back-office enterprise resource planning, to finance automation and customer-facing applications. Any change in the accounting for software expenses would be felt across many different industries.

“Every company investing in or building out their digital capabilities should be closely monitoring or tracking this project,” Nus said.

Two main accounting rules cover how to report software costs, with the line drawn based on whether a company plans to sell the software to the public or to use it in house. Determining which rules to follow is important because it can result in significantly different financial reporting outcomes.

Under 1985’s Subtopic 985-20, Software—Costs of Software to be Sold, Leased, or Marketed, expenses to make software that a company plans to sell to the public get reported in the period in which they occur, until the software achieves “technological feasibility.” Once the software is ready for release, the costs get capitalized, or recorded on the balance sheet, with the asset’s value steadily decreasing—amortized—over the product’s useful life. Few costs actually get capitalized, though, FASB research shows.

Costs for software to be used internally follow rules outlined in Subtopic 350-40, Intangibles—Goodwill and Other—Internal-Use Software, which require companies to capitalize costs incurred depending on the nature of the costs and the stage of the project. Generally, costs get expensed as incurred during the preliminary planning and the post-implementation stages, but get capitalized during the application development stage. The 1998 accounting standard requires significant judgment, FASB research shows.

There are many gray areas. A company may develop something to use in house but wants to sell it to the public and make money down the line, for example.

“That’s where it’s a struggle,” Long said. “What if you have a situation where it crosses over the line?”

Waterfall vs. Agile

The judgment calls are further complicated by the way the decades-old rules fail to account for how quickly software development now moves. The rules were written at a time when software was made using the waterfall method—deliberate phases of a project that happen in a linear fashion. Companies now make software under the “agile” approach, with different people and teams working simultaneously, sometimes in sprints of days or weeks that may or may not result in software that can be put to use.

Software technicians may say the app they’re developing is constantly being updated and therefore never fully done. This leads to few or no costs ever getting captalized, or recorded on the balance sheet. In contrast, other companies could have special teams taking 10 to 12 weeks to work on an app that has a set end point. Those companies could end up capitalizing more costs.

The contrast results in disparate hits or boosts to earnings, making it difficult for investors to compare how companies in the same industry are performing.

It’s further complicated when traditional manufacturing companies acquire technology companies to boost their software offerings and the companies account for their software expenses differently.

“It’s starting to muck up the works,” Long said.

Nitty Gritty

FASB accountants are working behind the scenes to come up with one set of accounting rules that covers the costs companies incur in purchasing, internally developing, or modifying software. The guidance would be delivered in a single spot in US GAAP so companies wouldn’t have to flip back and forth between the two current sets of rules.

Frustrated investors and analysts have told FASB that software costs are often difficult to find in corporate financial statements. Some companies record expenses in the income statement under generic categories like “cost of goods sold” or “property, plant, and equipment,” while others provide detailed footnote disclosures about which types of software costs are recorded on their balance sheets. The disparity between companies makes it difficult to figure out the dollars spent on software development.

Under the early-stage plan, companies would capitalize all direct software development costs from the point at which it is probable that a software project will be completed and the software will be used to perform the function intended.

In theory, this sounds simple. In practice, there will be questions.

“In software, it’s complicated,” said Sandra Heuer, partner at Grant Thornton LLP. “When is it ‘probable’ a software developer is going to complete a project, and I know it’s going to work and I can sell it? It sounds easy, but when you start to think about the application and how people might view ‘probable,’ it may not be as consistent.”