SOX, SOA and Executive Behavior

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.