For many developers, that is the perfect summation of how the Sarbanes-Oxley (SOX) Act has affected their daily lives. At first blush, the SOX Act looks like yet another set of checks and balances to ensure accurate financial reporting at public companies. As anyone who has worked in the financial department of a public company can attest, the SEC and FASB (Financial Accounting Standards Board) have been writing and rewriting the rules of the game for years. In this context, SOX is nothing new.

What makes SOX different is one small and very ambiguous section of the Act: section 404. The wonderful irony of this number (think the infamous HTTP 404 error) may be worth a snicker, but unfortunately, the wording and interpretation of this section of the Act have very deep implications for IT.

To paraphrase, section 404 says: "Management has to ensure appropriate internal controls of financial reporting." If you follow this statement down the financial reporting rabbit hole, sooner or later you find a software system that helps generate these reports. For many corporations, this system comes in the form of a big packaged application such as PeopleSoft, Oracle Financials, or SAP. Other organizations will have a homegrown package or some combination of packaged software and heavy customization.

In any case, SOX 404 has come to be interpreted as saying: IT must make sure there are appropriate internal controls in place when making any changes to any software system that plays a significant part in financial controls or reports. To fully understand the implications of this interpretation, one needs to examine both the concept of an internal control as well as what types of software systems are covered by this statement.

What Software Systems are Included?
So what does it mean to play a significant role in financial reporting? Unfortunately section 404 can be interpreted very broadly. Take, for example, the sources of data used in financial reports: employees (paychecks, benefits, and outstanding vacation time), orders (and all associated financial transactions), inventory (asset management), and physical plants (facilities costs). Any software system that helps manage one of those sources can arguably be included in the list of systems section 404 is concerned with.

Add to that all additional software systems related to finance's process for reporting (e.g. expense payouts, payables management, revenue booking and recognition). Activity in any of these source management and financial reporting systems rolls into the final numbers that appear in corporate profit and loss statements and balance sheets. It is easy to see why the broad wording in section 404 can start to feel like it covers almost any software system related to your core business.

What is an Internal Control?
So now that we have painted most of your software systems with a SOX bull's-eye, let's take a deeper look at the concept of an internal control. An internal control is really a check and balance system that ensures any change made to an application does not adversely effect your financial reports.

As it is likely you work on a software system related to financials, during the audit you may be required to produce proof of your internal development controls and how you can guarantee you follow them.

Let's take a simple example derived from a real experience. A developer needed a critical fix to the company's expense application. The developer found the fix he needed in a specific patch released by the vendor. After installing the patch and doing some quick testing, the expense application looked to be working just fine. The developer rolled the patch to production during the next scheduled downtime window. When the end of the month rolled around, everyone found their expense checks were not quite what they expected; they were all mysteriously a few dollars off. The developer did some research and discovered that the patch itself accidentally changed the database table holding expense information to use an integer column rather than a decimal column. All the data went into the user interface correctly but the data stored in the database was incorrect, thus the erroneous expense checks. At a large company, this glitch could add up to enough to cause a real problem in the balance sheet. An internal control would prevent such unforeseen changes.

One of the required activities related to SOX compliance is the SOX audit. This audit is performed by an external auditor, similar to the financial audit your company goes through on a yearly basis. The goal of the SOX audit is to validate the financial reporting processes (as opposed to the actual financial data which is still covered by the traditional audit). As it is likely you work on a software system related to financials, during the audit you may be required to produce proof of your internal development controls and how you can guarantee you follow them.

The time is ripe for automation. Two years ago, internal controls were a moving target; every auditor would tell you something different. Things have calmed down a bit now so a technology investment can have a pretty high probability of being accepted by the auditor.

For the balance of this article I'll talk about these best practice internal controls and how automating them in your development cycle will help you quickly produce the reports required during an audit.