SOX, SOA and Executive Behavior

By Marcia Gulesian

(Back to article)

A primary goal of the Sarbanes-Oxley Act (SOX) — the most comprehensive legislation ever in the field of corporate governance — is to improve the quality of financial reporting and thus increase investor confidence in financial markets.

This means SOX compliance is not a one-time effort or a one-year project, it is an ongoing process requiring extensive investment.

In the past few years, a number of promising software packages have come on the market to help with compliance efforts at public companies. Despite the hype that some of these programs “do it all” or are out-of-the-box SOX compliant, the reality is somewhat different.


SOX packages have the potential to actually make things more complex and less agile if they are not designed for simple integration with your existing data and applications. Fortunately, SOA has the potential to streamline integration of SOX packages with other applications.

Being new to the market, many of these SOX packages have built-in SOA features. The challenge is to match these new SOX packages with SOA integration points in the firm’s pre-existing architecture.

Meeting this challenge creates a new area of software application development for internal use.

Material financial consequences — namely, the affects on net profit, cash flow, and taxes that are tied to the costs of this development — can depend on which approach to software development is chosen by the CIO or CTO and how recognition of the resulting software development expenditures are timed by the CFO.

As part of this process, many firms elect to invest in their own development of software applications. Today, this software development represents an increasingly significant portion of businesses economic activities.

The bottom line? Differences in management philosophy and judgment can have a significant impact on both earnings and operating cash flow. Put another way, management’s behavior can be driven by the financial consequences of how it goes about complying with SOX.

To flesh out the subject of “how,” the Accounting Guidelines section at the end of this article contains a summary of the steps taken in the preparation of financial statements and their financial consequences, for readers not already familiar with these matters. (These guidelines are specific to software applications developed solely for internal use.)

There are differences in the way companies interpret “technological feasibility” (part of the first stage in the software development cycle discussed in the Accounting Guidelines section below) as well as carry out their software development processes.

These differences show up in the rate at which companies capitalize software development costs and the impact that capitalized software development costs have on the firms financial statements.

Capitalization of software costs boosts current reported earnings whereas expensing has the opposite affect.

Compliance-related costs may be either capitalized (i.e., amortized over future tax periods) or expensed (i.e., deducted from revenues this year). The objective of the capitalization process is to match the cost invested in the asset with the benefits derived.

IT Behavior

Management must make an important judgment concerning technological feasibility of its software projects. This decision affects at what point the company will begin to capitalize its software development costs, if at all.

While the relevant accounting guideline may seem clear to those not familiar with software development processes, there is a great deal of discretion and flexibility in capitalization practices, yielding similar discretion over pretax earnings.

Consider the following: If a company wishes to capitalize, it draws up a detailed program design quickly. If it wants to expense lots of development costs, it simply holds off writing a detailed program design.

In addition to management’s judgment concerning technological feasibility, different software development methodologies can result in far different capitalization rates.

For example, a company that uses a highly structured software development process such as CMMI might capitalize more of its software development costs than would a company using rapid prototyping techniques such as Agile.

This is because structured development approaches often separate product requirements and program design from program development, whereas coding and design often occur simultaneously with newer development techniques such as rapid prototyping.

Under the former scenario all of the software development costs are eligible for capitalization. None or much less of it is eligible for capitalization under the latter scenario.

Accounting Guidelines

Firms follow Financial Accounting Standards Board (FASB) guidelines when accounting for the costs of computer software developed (or obtained) for internal use.

First, they consider the following two characteristics to classify software as internal use software:

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

    There are three stages identified in the development of qualifying software:

  • Preliminary project phase: conceptual formulation of alternatives, evaluation of alternatives, and final selection of an alternative after the establishment of its technological feasibility.
  • Application development stage: design of chosen alternative, including software configuration and interfaces, coding, installation of computer hardware, and testing.
  • Post-implementation/operation phase: training and application maintenance activities.

    Costs associated with the preliminary project and post-implementation/operation phases are expensed as incurred. Costs (internal and external) associated with the application development stage are capitalized.

    Capitalization of costs begins when the preliminary phase is complete and management has implicitly or explicitly committed to funding a software project with the intent it will be completed to perform the planned functions.

    Capitalization ceases no later than the time when substantial testing is complete and the software is ready for its intended purpose or rendered in service.

    Capitalization intensity (capitalized development costs/sum of capitalized and expensed development costs) is a proxy measure for the success rate of software projects.

    This ratio is of interest to senior management because it provides an evaluation of a project (or portfolio of projects) that’s somewhat independent of the report provided by its project management office.

    It may be somewhat heretical to point out that even a good-faith collaboration between IT management and it’s financial counterpart can undermine the very compliance they’re charted to automate.

    This thought is even more apropos of software that’s developed for sale. In this latter case, the guidelines are different from those outlined in the previous section and can produce even more variable results … but this is a subject for another discussion.

    Marcia Gulesian has served as software developer, project manager, CTO, and CIO over an 18-year career. She is author of well more than 100 feature articles on IT, its economics and its management, many of which appear on CIO Update.