The Sarbanes-Oxley Act holds executives personally responsible for accurate and timely financial reporting
Introduction
“Can I trust our data enough to risk my neck?” That’s what CEOs and CFOs of small, medium and large companies are asking themselves these days. Unfortunately, they probably don’t.
The new Sarbanes-Oxley Act (also known as SOX) holds top executives personally responsible for the accuracy and timeliness of the financial data they report.
Before SOX, integrating and cleansing enterprise data was not high on the list of IT priorities. Now, CIOs and IT managers are on the spot to provide trustworthy data.
Data can be untrustworthy for many reasons. One is that data resides in various databases. All enterprises have data in at least two — and typically three or more — applications: ERP, payroll,
manufacturing, home-grown, distribution, point of sale, transportation, healthcare, insurance, or other systems.
Progressive organizations have built data warehouses or data marts. But many of the same problems persist. Independent data marts will each have their own extract process and transformation rules.
This leads to multiple versions of the truth-untrustworthy data that cannot be relied on for financial reporting.
Even centralized data warehouses or data marts can have problems if the underlying data extracts are undocumented, incomplete or not audited. There may be a single version of the truth, but it may
be wrong.
This white paper explores:
- the three key requirements of the Sarbanes-Oxley Act (SOX)
- typical data problems
Publisher’s Note: The complete white paper includes how Coglin Mill’s RODIN ensures trustworthy data for SOX reporting.
Three key requirements of the Sarbanes-Oxley Act
Companies face some real challenges in complying with three key sections of the Sarbanes-Oxley Act.
- Section 302: Financial Reports
- Standards for tracking and reporting
- CEOs & CFOs personally responsible for accuracy of financial statements
- Personal penalties from fines to jail
Implementing defined standards is not easy. Who, what, where and when must be addressed. Tracking and reporting defined standards is also challenging. Manual processes are error prone and time
consuming.
- Section 404: Internal Controls
- Assess internal controls
- Report on internal controls
- Assess effectiveness of controls and procedures
To create an internal control report, management must first identify all of the data sources used in financial reporting and then determine the validations and audit processes (if any) associated
with the extraction of data from each of these. This is difficult to do when there’s no central place for data, rules and documentation. When there are only manual processes, it is next to
impossible to assess the effectiveness of controls and procedures. Not only are these hard to document, but also to apply. The operator must follow procedures, report on exceptions and basically
“get it right” every time.
- Section 409: Real-time Disclosure
- Disclose information on material changes in financial condition on “rapid and current” basis
Acquisitions, divestitures and reorganizations make it difficult to reflect current and historical financials accurately and in a timely manner. Missing, unreliable or incomplete data caused by
these business upheavals will ultimately affect internal forecasts. This will lead either to failure to report changes in financial condition or even to erroneous reports. Therefore, collection and
aggregation of data from multiple divisions and business units must not only be reliable, but also must be done immediately, rather than over weeks or months.
For more details on the Sarbanes-Oxley Act, visit www.aicpa.org (American Institute of Certified Public Accountants) or www.fei.org (Financial Executives Institute).
SOX challenges facing IT Managers
The additional burden of the Sarbanes-Oxley financial reporting requirements is a critical business issue today. IT and financial teams are expected to produce more information in less time, and
top management must sign off on the accuracy.
Manual or query-based extract and consolidation processes carry a high overhead and are prone to error. Costs increase while productivity decreases.
Gaining secure access to data in various transaction systems is a problem every business faces. Data in transaction systems is spread out and formatted for transactions, not for easy access or
reporting.
Data that has not been transformed and consolidated leaves room for multiple interpretations and inconsistent business rules, which leads to multiple answers to the same question, and potentially,
non-compliance due to wrong information
Many organizations want to be able to audit, trace and scan transactions for anomalies while providing secure access to relevant data across various levels of the organization.
Without a repository of detailed and cleansed data, corporate reporting tools (whether based on SQL queries or predefined OLAP data cubes) can only provide half of the solution.
The inability to automatically identify, set aside and audit errors in transaction data increases costs exponentially as workers try to hand-code and manually search through programs for this
information.
Enterprises need to have employees spend less time gathering data and more time analyzing the data.
Typical data problems
There are many reasons why data can be untrustworthy.
One reason is that data resides in various databases. All organizations have data in at least two and typically three or more types of applications: ERP, payroll, manufacturing, home-grown,
distribution, point of sale, transportation, healthcare, insurance, or other systems.
Each application will have its own way of storing data within the database. Even worse, as more and more companies rely on heterogeneous platforms for different applications, the data may be stored
in incompatible databases.
Consider dates, for example. Many applications, such as JD Edwards, have a different or unique way of handling dates. Most legacy applications simply use numeric fields, rather than true date
fields, and store the data in one of several different formats (e.g., yyyymmdd, cyymmdd, mmddyyyy, etc.). If you have three different applications with three different date types, you automatically
have a data integrity problem.
Since most basic query tools cannot efficiently handle these disparate date formats, programmers end up writing programs and create staging tables to integrate the data. Over time, as more and more
extracts are created, those staging tables become a nightmare to manage.
Of course, the problem extends far beyond dates. Many pieces of information are common across applications, but will be stored differently. This mandates some form of conversion or transformation
and each programmer will do things differently. Different rules will be applied, different levels of exception reporting and error handling will be implemented (if at all). Documentation probably
won’t exist. This situation was already a nightmare to manage before SOX. Now it is completely unacceptable.
Organizational changes exacerbate data reliability problems. For example, let’s say the NE sales region (01) is split into two separate regions (01 and 09). Then let’s say the sales manager is
creating a sales forecast and wants a report on customer XYZ’s history over the last 3 years. The customer is now in region 09, but two years of history was in 01. How do you automatically
reconcile those numbers and ensure that you correctly report on XYZ without duplicating sales figures? If duplicated sales eventually end up in a financial report, you have a SOX compliance
problem. Where is it documented that the split occurred and how the history was handled? How are you going to prove that there was a control in place to correctly change reporting based on this
split?
Progressive organizations have addressed some or all of these issues by building data warehouses or data marts. While this is the correct approach, if not done correctly many of the same problems
will persist. If independent data marts are implemented, each will have its own extract process and transformation rules. This will undoubtedly lead to multiple versions of the truth-untrustworthy
data that cannot be relied on for financial reporting.
Even centralized data warehouses or data marts can have problems if the underlying data extracts are undocumented, incomplete or not audited. There may be a single version of the truth, but it may
be wrong.
The entire white paper from Coglin Mill – Developer of Rodin Data Asset Management can be found at http://www.coglinmill.com/homepage.nsf/webpages/SOX.
