Did you know that:
The process never ends
Bringing your systems into compliance with a new financial reporting law may be your biggest information-technology expenditure this decade. Some say implementing compliance with the Sarbanes-Oxley Act is a bigger project than Y2K bug fixes. “That might seem extreme,” says Kraig Haberer, director of financial product marketing at SAP. “But Y2K was a single task —this is a recurring one.”We’ve seen clients invest tens of thousands of hours to achieve minimal Sarbanes-Oxley compliance,” says Gregory Derderian, managing director of the World-Class Finance practice at consultancy BearingPoint.
Speed is a requisite
Under Sarbanes-Oxley, the allowed time to file quarterly reports will fall from 45 days now to 35 days in 2005; and annual reports will have to be filed within 60 days of the close of the year, rather than 75. Disclosures of “material events” and insider trades must be filed within two days.If you’re still dependent on older systems for some of your financial data—such as legacy Cobol-based transaction processing systems or terminal-based order entry systems—you may have to alter or replace that software to speed up the reporting process.If your integration between these systems depends on moving “flat-file” data in batches, or some other periodic data transfer, the data may not be transferred frequently enough to ensure that decision-support systems and financial reports are up-to-date and accurate. Monthly roll-ups of financial data may leave companies scrambling to meet quarterly report deadlines.Packaged enterprise-resource-planning systems such as SAP R/3 and Oracle 11i don’t depend on batch processing, so they’re less susceptible to these sorts of problems internally. But if your company’s not using such a system to capture transactions, the points where data is passed along can still spell trouble.
Not all data can be tamper-proof
That’s because there are so many information systems and corporate processes it’s virtually impossible to lock them all down. A typo on an order-entry screen or a small mistake in any of thousands of manual processes can create inaccuracies throughout the financial reporting process. Security of financial data also is generally dependent on trust in individuals. As demonstrated by the Autotote betting scandal (see “Inside Bet,” Baseline, Dec. 2002, p. 15), even the most secure business processes are vulnerable if a trusted individual wants to commit fraud.The best first step in preventing fraud is to keep access to systems that create or manage financial information separate from access to the places where data is stored. Also, users should only have access to data needed by the applications they’re permitted to use; only system administrators should maintain the underlying database.Information moved in batches also could be compromised while it’s waiting to be uploaded—or misread by the software that uploads it.
Rules have to be enforced
Section 404 of Sarbanes-Oxley requires executives to sign off not only on their companies’ financial statements, but also on the control processes that surround collection of the data behind them—down to the transaction level. You’ll need to audit and verify each step in a transaction, from order, to payment, to storage of data, to aggregation into financial reports.You’ll also need a way of monitoring each step—and to alert key people when something goes awry.Middleware such as Tibco Active Enterprise and IBM’s MQ series can enforce business rules and transform data without human intervention, using automatic messages. Such software as the SAP Audit Information System also can report exceptions and alert internal or external auditors when something is amiss.Tibco and IBM middleware also can generate alerts when rules on the size of transactions, for instance, are violated.
