LOSS OF DATA INTEGRITY; DELIBERATE REPLACEMENT OF DATA: THE CASE OF THE LOST AUDIT TRAIL

by Elbert L. Menees and Jerome V. Bennett

Jerome V. Bennett is Dean of the School of Business and Economics and a Professor of Business Administration, and Elbert L. Menees is a Professor of Business Adminstration at the University of South Carolina at Spartanburgg

Integrity of the data is a fundamental requirement of an accounting system. Yet, in many accounting software packages now in use by small and medium sized firms, there is no inherent guarantee that integrity is assured. And the vendors of this software neither alert purchasers to this problem nor seem inclined to remove the problem.

Many commercial accounting software packages allow stored data to be manipulated in a way that can seriously jeopardize the integrity of the data. The phenomenon might be called "data replacement," and the danger it represents is rarely explained in the software documentation. Unwary users can lose the audit trail to an account balance, making error recovery exceedingly difficult. This phenomenon is a serious control problem, but the risk can be avoided if all system options are clearly understood and employed by owners and operators.

The purpose of the audit trail is to allow verification of the balance in an account by tracing from the current balance through each and every transaction posted to the account back to a previously validated balance (or vice versa). This capability is fundamental to the auditing process. The data entry/posting process is called "data aggregation." Most accounting systems create a log of all transactions for the very purpose of creating an audit trail.

But some accounting systems allow direct access to account balances, bypassing the transaction posting/audit trail activities, through data replacement. When one can simply and directly replace one account balance with a different value, integrity is then lost.

Integrity or Fraud

Accounting systems' integrity is as vulnerable as the joint probability of finding inadequate systems design coupled with the inclination to commit fraud. Designers of accounting systems for PC-based use must understand and respond to this vulnerability. As described by Charles Legrand (1986), controls are essential, must be intact, and must operate continuously if integrity is to be maintained. Systems design must not place excessive trust in the honesty of individuals. Access codes and passwords should not be optional, even in simple systems. Every access to the general ledger accounts should be logged to insure trace-back ability to deter fraud. Overrides should not be allowed to remove or replace entries, balances, or transactions.

In spite of the admonitions ten years ago of  Legrand and others, software not meeting those specifications is widely available and without any "hazardous to your financial health" warnings.

The inclination to commit fraud is pervasive. Fraud has been found in for-profits and not-for-profits, large firms and small firms, manufacturing and service and retail. An article by Thomas G. Calderon and Brian P. Green (1994) summarized 114 reports of fraud reported in The Internal Auditor from 1986 to 1990, as follows:

The software problem which is the focus of this article is a tailor-made invitation to fraud in the very categories of highest incidence as reported by Calderon. While any purchaser of software which has the described features is at risk, the risk is much greater in small firms because:

• Owner/managers have greater access.
• Internal audit does not exist.
• Fewer employees are available to facilitate separation of functions.
• A higher level of trust exists because people know each other well.

"A Disaster Just Waiting to Happen," by Gerry Ross (1988), fits all too well in the discussion to follow. Ross warned of the danger that computerization posed with the loss of audit trails and management's total relying on software to do what management believed it to be doing. His description of "low probability, high consequence" events corresponds to the situation in which this article is addressed: the opportunity to replace data in accounts with no audit trail evidence being produced. Instead of the preferred data aggregation, data replacement is allowed.

Data Aggregation

The concept of data aggregation refers to a programming instruction that permits a number to be altered by adding or subtracting (aggregating) another number to the existing number. The programming instruction

LET A = A + B

for example, would result in the number B being added to the existing number A and the resulting sum (A + B) substituted in data storage for the old number A.

The old number A ceases to exist in the system, but normally A remains recoverable. The number B, which represents the amount by which the old A was altered to form new A, is saved in the system. This happens, in part, because the program step that aggregates B with A is different from the program step that collects and validates B.

With B saved within the system, recoverability is assured, and the old value of A can be reported easily at any time. Aggregation transactions, in short, provide an automatic audit trail.

Data Replacement

The term data replacement refers to a programming instruction that simply permits one number to be replaced in data storage by another number. For example, the programming statement:

LET A = B

would result in the number A being replaced in data storage by the number B. The old number A ceases to exist in the system when the replacement occurs. A not only ceases to exist, it ceases to be recoverable because the system neither computes nor logs the amount by which A differs from B. Recoverability would be possible only when the amount by which a new number differs from an old number is saved within the system.

Design of System

Both data replacement and data aggregation have their place in the design of every accounting system. The problem is that some software packages do not prohibit unwitting users from crossing the two concepts, giving the dangerous capability of "aggregate replacement" : the ability to continue replacing a number intended only to be aggregated after start-up.

Software packages allow aggregate replacement for the convenience of users. One illustration demonstrates the potential for serious dysfunction. Exhibit A presents selected options from the starting, daily processing and monthly closing menus for a real software package product for general ledger accounting.

To create a chart of accounts, Option 1 on the "startup menu" is used. Then, Option 5 enables the operator to enter a set of beginning balances. This option prompts the operator to enter a beginning balance for every account in the chart. It is clearly a start-up event and clearly a data replacement operation, since the balances entered will replace the zero-balance condition initially existing. A computer-based audit trail is not required for this step; Option 6 lists the account balances entered. Option 7 permits correction of a value entered in error.

Thereafter, the "daily processing" menu is designed for recording transactions. Option 1 on the daily menu enables a system operator to add new transactions (debits and credits) to a monthly transaction file. These are data aggregation transactions. They are entered, edited and retained in the system until the monthly close, at which time they are aggregated with beginning balances to create ending balances, then saved to auxiliary storage for recovery and audit trail purposes. This posting operation is a central function of the system and creates the information from which all general ledger reports are derived. The computer-based audit trail thus created is essential to data integrity.

System Design Deficiency

The system as written has a deficiency: after account initial balances are entered and listed, Option 7 of the startup menu remains operational; it is the source of concern. Its design purpose is to enable the system operator to select an individual account and replace an existing initial balance with a new balance. This capability has only one legitimate use: to enable an operator to change an initial balance entered incorrectly during start-up. This capability during start-up is convenient and not potentially damaging at that time; it is normally part of a universe of similar options called "file maintenance," which is included to make data correction easy for operators. The problem is that the software does not prevent executing this same data replacement operation subsequent to start-up.

Imagine, for example, that the accountant discovers the cash account balance in the computer to be in error when reconciled with the bank statement. Further, assume that this discrepancy is traced to a data error in the previous period, in which the amount of a payable was recorded incorrectly. How will the operator correct this error? The proper procedure is to use Option 1 on the daily menu to post an adjusting entry during the current period, thereby preserving the audit trail. An accountant unwilling to make data entry errors a matter of record may elect to use Option 7 on the starting menu and simply replace the existing cash account balance and payable account balance with new balances.

If the accountant uses Option 7, not only is the audi trail lost, but the potential for even greater damage is created when a careless operator does faulty off-line arithmetic and replaces existing incorrect balances with new incorrect balances. It is not difficult to image a situation where further attempts to correct the problem in this manner results in a hopelessly entangled general ledger.

Obviously, data aggregation is the preferred way to alter stored numbers that require recoverability, and conversely, data replacement should be avoided in those situations.

Avoiding Risky Options

How can concerned software owners avoid this type of entrapment if the installed software contains these risky options? Owners can eliminate unwanted options from menus, in some cases, or simply prohibit the use of risky options.

What would be the implications, for example, of not allowing Option 7 from the startup menu in the first place? An operator would be required to correct a start-up account balance error by posting an adjusting transaction through Option 1 on the daily menu. The transaction would be handled as a reversal of the incorrect entry and a correct (debit or credit) entry and become part of the audit trail.

By the same token, a convincing argument can be advanced for also eliminating Option 5 from the startup menu. This option, intended to be used only during start-up, could actually be used at any time to replace all existing balances, more potentially damaging from a control standpoint than Option 7. While this misuse might be prevented by installing a control within the program to prohibit replacement of balances after start-up, the initial account balances, as well as the corrections, could all be entered as aggregation transactions through Option 1 on the daily menu. This provides a useful and appropriate audit trail, and results in a "tight" system: a system with no hidden pitfalls to confuse and confound an unwary suer.

Conclusion

Most firms are very conscious of the need to include adequate data entry controls in packaged software. Software developers, on the other hand, feel they have to offer user-friendly products to the market, and this often means providing as many system options as possible, even some that can be misused. The hazards of these options are not revealed to users, which means that owners and users must be vigilant. Only software which allows users to control, that is prohibit, use of options such as those described should be purchased.

REFERENCES

Calderon, Thomas G. and Brian P. Green, "Internal Fraud Leaves Its Mark," National Public Accountant (August 1994), pp. 17-19, 36-38.

Legrand, Charles H., "Discouraging Fraud Through System Design," The Internal Auditor (April 1986), pp. 28-35.

Ross, Gerry, "A Disaster Just Waiting to Happen," CA Magazine (August 1988), pp. 28-32.

EXHIBIT A

Menu Choices - Selected Options