Embedded controls boost Sarbanes-Oxley compliance: companies are installing treasury systems that automate financial activities and embed controls, as well as audit trails. Such systems can help ensure compliance without extensive manual reviews.

All the angst and uncertainly created by the Sarbanes-Oxley Act has

given public corporations in the U.S. a powerful reason to consider using sophisticated software to automate much of their treasury operations and to embed controls, as well as clear audit trails, right in the software. Systems like these can go a long way toward assuring Sarbanes-Oxley compliance without extensive manual reviews and double-checking.

[ILLUSTRATION OMITTED]

For years, companies turned to treasury software primarily to automate manual processes and achieve operational efficiencies. For a couple of years, they upgraded to new treasury software to be Y2K-compliant. Now, they are doing it for the additional reason of improving and verifying the financial controls required by Sarbanes-Oxley.

In fact, many public companies are significantly redesigning their financial operations around the new standards. If they need another reminder of how serious these issues are, they need only glance at daily newspapers, which are full of stories about the criminal trials of once-respected CEOs and CFOs who failed to uphold the standards now embodied in Sarbanes-Oxley.

Treasury Impact

Three sections of the act have direct impact on treasury operations:

* Section 303, which requires the CEO and CFO to sign off personally on all required financial statements and disclosures, attesting that the statements are complete and accurate and comply with all relevant regulations and accounting standards. They are personally liable for willful violations of the requirements of this section. That responsibility and liability cannot be delegated or outsourced.

* Section 404 adds to the required financial disclosures a written assurance that management has designed and tested adequate financial controls, that it regularly measures the effectiveness of those controls and that they are working. A management pledge is not enough: The controls must be audited by the company's outside auditor, meaning that a whole new, expensive component of the audit process has been created by Sarbanes-Oxley.

* Section 409 requires companies to disclose promptly any material changes in financial condition or operations that occur between reporting periods.

The emphasis is firmly on control. Companies that were the subject of recent scandals were out of control. Such surprises and large losses should not be allowed to happen, so Sarbanes-Oxley places a high duty on management to tighten controls in their enterprises.

Spreadsheet Shortcomings 

Until recently, even some large, sophisticated companies did fairly well by exploiting the power of inexpensive spreadsheets, downloading bank statements and reports and data from their enterprise resource planning (ERP) or accounting systems into various spreadsheets that could perform specific tasks, then uploading processed data back into internal systems, primarily the accounting system.

However, spreadsheets alone don't cut it in the Sarbanes-Oxley world. They require too much manual processing, which allows room for accidental mistakes or even the deliberate manipulation of data that ultimately affects the content of financial statements. There's little tolerance for human error today.

Moreover, while spreadsheets can be effective work tools, they're not reliable at maintaining a record of what was done. They permit people to make changes without an adequate record of what was changed, and use formulas that could be mismatched. Even when spreadsheets are stored, they provide mere snapshots of pieces of a complex financial reality. Each snapshot might offer a different picture of the financial reality, based on what selected data the spread-sheet contains and how it displays that data.

They're not up to Sarbanes-Oxley standards. What's now required is a systematic solution in which standards, controls and a prescribed work process are built into the system.

Workflow Controls

Software is just software, of course, so people still must set parameters and oversee the way controls are programmed and how well they are working. Treasury systems provide the tools that people can use to embed the controls that are right for their company and their treasury operations.

Good financial controls involve segregation of duties. For decades, companies have recognized that when large amounts of money are involved, making a payment must be broken up into two, three or four distinct steps; the same person should not be able to perform each of those steps.

A system of good controls carefully defines each person's duties. Systems features are then employed to ensure that each person has access to all the information and processes needed to perform those duties, and deny access to information and processes not needed to do the job.

Defined User Access

Advanced systems offer extensive tools to enforce segregation of duties and each user's defined role. A new employee starts with the authority and tools to do nothing. As that person begins his or her job, a "super-user" function in the software, controlled by a system administrator, grants that employee a key to certain portions of certain databases, so he or she can get the information needed, but only what is needed.

This new employee also gets authority to perform certain tasks--as many or as few as the job requires. For example, he or she might be able to view certain files on a read-only basis, while others with more authority might be allowed to both read and write to that file.

Some treasury systems allow the employee to see from a frame bar just what he or she is authorized to do--the icons he or she can use are bright, while those where access is denied are shaded out. As job duties expand, more icons can be turned on for that particular user by the administrator.

For certain access or at certain companies, dual approval may be required before a user can be granted new access or powers. When a person is promoted or given expanded duties, a supervisor can report this to the administrator who authorizes access. The new access or powers may not become effective until approved by a second administrator, such as the treasurer.

Effective Walls

For corporations with multiple subsidiaries, access can be restricted to selected business units or departments. That corporation still can enjoy the power and efficiency of a common database or data warehouse, but it can be combined with strong walls that assure segregation of duties and control who can do what. Those who need to see the big picture can do so.

Those who need to see the activity of just one entity can be restricted to that information. Static or reference data can be completely restricted by various characteristics--legal entity, business unit, payment addresses, accounts, etc.

Reports can be similarly controlled. Anyone with appropriate user clearance can view and run a public report, but only the owner--the user who created it--can issue, delete or edit a private report. For further security and control, password standards can be set as high as the company chooses. Minimum password length and maximum password time duration can be enforced. A combination of alpha, numeric and punctuation characters can be required. Of course, security standards must be enforced if they are to be effective.

Deal Workflow

Treasuries involved in the buying and selling of investment, debt and derivative instruments need a secure, controlled workflow. Each deal transaction involves a lifecycle with a sequence of stages, and different instruments have different lifecycles. That lifecycle is likely to involve initiation, acceptance or rejection, authorization, confirmation, counter-confirmation, rollovers, options (exercised or not) and more.

Each transaction must be initiated, confirmed, booked, held and accounted for properly. Then each transaction must be retired when instruments mature, expire or are sold, and the accounting record must be closed out.

Since terms of a deal may be changed, there needs to be the flexibility to make those changes without the ability to fudge the record or cross lines of segregation and authority. Risk limits can also be embedded in the software, capping the risk a user can incur with any one dealer, counterparty or country.

The particular history of each deal also must be recorded. For this record, a treasury system should include fields for action description, user, time and comment. These fields should allow for the user only to print and not edit the information. Typically, anyone touching the deal can record comments in the comment field.

Deal workflow also needs to be scalable to accommodate both large- and small-volume treasury operations. Deal tickets and confirmation letters should be generated within the system automatically at the time a deal is authorized or accepted.

Since deals can involve a lot of money, segregation of duties is particularly important. Typically, one set of actions is handled by a "front office," another by a "back office" and sometimes a third set by a "middle office." A front-office operative might initiate and accept deals, while a back-office operative might authorize or reject them, as well as confirm them. While these separate "offices" are conceptual, not literal, the language reflects the strong segregation of duties.

The same basic workflow used for deals can be replicated for payments: The user who initiates a payment cannot release or validate it, and the statistical data associated with that payment can be locked in an indelible record.

Audit Trails

The audit trail keeps a record in the system of every relevant financial event--whatever is entered, deleted or modified, including:

* the type of action taken;

* what was added, deleted or changed;

* the date and time of the activity;

* the legal or accounting entity or sub-entity involved in the change;

* the previous and new value resulting from the addition, deletion or change; and

* a notation as to whether the audit trail was enabled or disabled for that event.

Audit values are stored in the database and can be viewed and reported at levels and time periods defined for particular users.

Treasury systems should automatically compare bank ledger balances with balances in the software using a book-balance check report. If there is a discrepancy, the system can refuse to import the bank balance until the discrepancy is resolved.

Risks are reduced and controls improved every time existing data can be reused instead of reentered. Sophisticated treasury systems use features like accounting system interfaces, target-balancing and deal-mirroring to see that original data flows to wherever it is needed instead of being re-keyed from one system into another.

No matter where your company is in the process of implementing Sarbanes-Oxley compliance controls, there will always be room for improvement. Embedding controls into automated financial systems will significantly improve compliance issues and make the audit process far less onerous. The answers are in the electronic data, with audit trails to prove what was done. Executives can attest to the financials with far more assurance that the stories these figures tell are, in fact, the truth and not a fiscal sleight of hand.

John Alarcon is General Manager for treasury services provider XRT North America. He can be reached at 610.290.0300 or [e-mail].

RELATED ARTICLE: takeaways

* More companies are turning to software-based treasury systems that automate financial processes and embed controls, as well as create audit trails.

* Spreadsheet-based systems are arguably inadequate in a control environment, since spreadsheets involve re-keying and are subject to errors and manipulation.

* Many treasury systems are user-defined, and specify each person's duties; they allow access only to the information those users need to do their jobs.

* Sophisticated treasury systems use features like accounting system interfaces, target-balancing and deal-mirroring to see that original data flows to where it is needed.