Public companies must meet various regulatory requirements for financial controls and accounting. The primary requirement in place is a set of rules known as Sarbanes-Oxley, and often abbreviated as “SOX”. These rules were developed in the wake of the Enron type scandals to require publicly held companies to standardize the way they recorded, maintained, and reported the various values that describe the health of the business. While many businesses bristle at the requirements and the costs they create in implementing them, they do generally meet a good test for common sense. Even privately held organizations may want to implement all or part of the SOX requirements to increase confidence in the numbers.
The systems which record, maintain, and report these values are necessarily part of the SOX process. You may have a diligent team of accountants, but if the ERP system they use is not compliant with the latest rules, or has faulty calculations or reporting formats, you will find yourself out of compliance with SOX. Because of this, there two places in particular where SOX is affected by, or affects software development projects.
The first is the obvious fact that software in a company usually interacts with data. It may be the system that manages the receivables, takes orders, tracks shipment costs, or handles payroll, but in some way it allows data to be collected and edited. It may not even be the last system of record, and the one the final report is generated from, but it may collect that data that feeds that system. In this case our concern is twofold:
- The system collects data, and therefore may be massaging it. Think the movie “Office Space”, where three not so ambitious young developers decided to take the fractions of the pennies off of each transaction, and skim it to an account in their name. They ended up with a huge amount of money, and the company books were wrong. In this scenario we are concerned with the code that manages data, and what it is doing. Your process and audit controls should be looking at database procedures, front end user interface code, scheduled jobs, data integration points, etc. for erroneous or malicious code.
- The second area of concern is anybody that has access to the raw data or production code. This may be a database administrator that can directly edit data in production systems, etc. This type of access is often needed, and almost impossible to deny, so trust is required. But verification, in the form of audit control of transactions should be implemented and reviewed by somebody outside the IT department.
The second place we are concerned with is the inherent value of software, specifically software that is being developed. If your company creates software, for internal use or sale to third parties, and in some way assesses a value to that asset, then it should be tracked and managed as an asset. This means that development cycles should be closely monitored and be able to show the real value and progress of development. In a top down work plan for a software project, the value of the software project is equal to the percentage complete of the overall project. This is not an exact record, but can be used for assessment purposes. In other words, if your project is estimated at $100,000, and your team is ½ complete, then the current value is $50,000. That does not mean you can sell it for $50,000 but the book value can be used. For value-up software projects, the assessed value is equal to whatever has been completed to that point. If you do not have an accurate way to assess that value, or are not sure where you are in the project lifecycle, then you may have an inadequate project control and reporting process in place. And that ultimately affects the values reported to shareholders and regulatory agencies.