A shopper's guide to accounting software: fifteen leading high-end packages for PCs are examined.

The computerization of accounting has done more than streamline the work of CPAs by eliminating post binders, columnar sheets and those quaint posting machines. It also has changed significant aspects of accountants' work fundamentally. For example, in precomputer days CPAs were instrumental in designing accounting systems for each client and then implementing them by hand. In the process, accountants made sure the systems included adequate audit trails, controls and reports, among other things.

That was then. Today, the most popular accounting tools are off-the-shelf, shrink-wrapped products. While most allow some customization, their basic design is locked into the esoteric code of computer programming. As a result, today's CPAs, rather than being able to adapt an accounting system to a specific use, must themselves adapt to it. Thus the accountant's role has changed--from that of system designer to system selector and adapter.

CPAs who are asked to recommend an accounting package for a client or an employer must be sure it meets the business's unique needs. That's not easy. While many of the 200 or so products in the marketplace today are adequate accounting tools, rarely does any one package fit a client's needs perfectly. So, even before investing the time to analyze a package in depth, accountants must set their priorities and then search for the software that appears to provide the best fit. However, we have found that appearances, or claims about the ability to perform certain functions, can be deceiving.

At best, CPAs must compromise on software functions. Accordingly, this article, which examines 15 popular accounting software packages, probes not only the packages themselves but also how the various software functions affect the way today's accountants select and work with software.

MAKING THE SELECTION

We focused on high-end microcomputer accounting software designed for small to midsized organizations. Our selection was based on these criteria:

* Price. We reviewed programs that cost between $400 and $1,000 per module in the fall of 1993, when the review process started; since then, although some prices have risen above the $1,000 level, we retained those products in the review (see the sidebar on page 59.)

* Operating system. We chose only DOS packages because they make up the largest segment of the accounting software market. However, in the sidebar "Migration Paths: Planning for the Unknown," page 40, we alert readers about available Unix or Windows versions. We didn't include Unixonly software because it's usually somewhat more sophisticated and expensive than DOS software; as a result, fewer businesses use it. Windows software was excluded because in our view and that of many accounting firms, accounting often is a mission-critical application and the current Windows version, 3.1, has not proven sufficiently stable to support such applications. That may change with the new Windows version, Windows 95, Microsoft plans to introduce this year.

* Customers. We selected widely used and marketed software that is designed for a variety of industries rather than for only a specific industry. We focused on horizontal packages because most CPA firms find they can support only two to three programs--thus, they tend to select packages that are adaptable to a variety of clients rather than those that are highly specialized or industry-specific.

* Multiuser support. Even though an initial installation may be on a single microcomputer, we consider multiuser support essential for a growing business.

AREAS OF FOCUS

Accounting packages have many attributes worthy of review--so many, in fact, that no one article could cover the subject adequately. For example, ease of learning is important to the installer and new user. Efficiency of operation also is important, especially for data entry. But since there are no objective standards for such attributes, we focused on accounting considerations only, leaving it to the user to make those personal judgments.

We chose audit trails, internal controls and reporting for study because they are the primary concerns of accountants in both public practice and in industry. Audit trails represented by journals and ledgers are the essence of any accounting system, adequate controls allow users to rely on the integrity of that system and reliable reports are the primary purpose for any accounting program.

An adequate audit trail and sufficient internal controls permit auditors to form supportable opinions on financial reports. Controllers are responsible for implementation and maintenance of all three attributes. It is in those three areas where computerized accounting is most vulnerable--after all, the move from hand-kept and mechanized accounting systems to electronically based systems has changed drastically the physical form of audit trails, the nature of required internal controls and the potential for much more in-depth financial reporting.

Many accounting packages contain 10 or more modules covering a variety of activities, such as sales, manufacturing and bank reconciliation. To keep the size of the study manageable and maintain comparability between products, we included only the general ledger module plus those necessary for the sales, inventory and purchasing cycles. Because accounting activities differ from module to module in different packages, specific modules examined varied from vendor to vendor.

WHAT'S IN A NAME

In researching accounting packages, CPAs must deal with many daunting obstacles, but what may be the most frustrating is understanding software publishers' jargon. Many of the packages use terminology incorrectly and inconsistently to describe accounting functions. For example, one software package uses the word posting when what is meant is journalizing. The title detail report is used on one package to describe a journal while it refers to a ledger in another package. When CPAs examine potential accounting software packages, these inconsistencies are more than just a minor linguistic oversight--they become a serious barrier to selecting a product.

Another problem: In a significant number of cases, vendors claim features for their products that clearly aren't present. And in other cases, vendors say their products lack capabilities we discovered they possess. For example, one vendor reported it could not provide an aging schedule by invoices, two said they do not use data type checks that permit entry of only integer data in dollar value fields and one claimed it could not produce a report showing gross profit by inventory item. In each of these cases, the product was able to do the job. Part of the problem stems from misunderstandings over terminology. In this article we have used standard accounting terminology to describe functions even when a vendor labels a product's functions differently.

I. AUDIT TRAIL

TRACKING THE ELUSIVE TRANSACTION

All 15 packages claim to provide complete audit trails. We soon discovered that those claims were exaggerated.

Some background first: A complete audit trail has two dimensions, as shown in the adjacent illustration. An accountant must be able to trace a transaction from its document origin through a journal (a chronological listing of transactions) and a ledger to any ensuing reports or output documents. And this trail must be bidirectional; that is, the accountant must be able to trace information from the output documents and reports back through the ledger and journal to originating documents. Moreover, for a complete audit trail, references must be distinct enough to permit a trace directly to an item rather than require a random search of either journal or ledger data. Such random searches constitute gaps, which are, in fact, defects in the audit trail.

In addition, for an audit trail to be effective, it must permit an accountant, using ledgers, to track all changes in the account balance from the end of one period to the end of each subsequent period. And the ledgers must include customer, supplier and inventory ledgers as well as the general ledger. As CPAs know, to constitute a complete ledger, accounts must show three elements: a beginning balance, all transactions affecting that account for the period and an ending balance. The two crucial accounting records are journals and ledgers. Since all of the packages studied are designed around hard copy output, we looked closely at the nature of these printouts and under what conditions they can be produced.

We discovered that the quality of audit trails varies and several packages have clear deficiencies. In some systems transactions are followed easily, but in others the audit trail requires considerable effort. And in some there are clear breaks in the trail, making it difficult to trace the flow of specific items.

[CHART OMITTED]

A JOURNAL BY ANY OTHER NAME

A journal, as every CPA knows, is a chronological listing of transactions. Unfortunately, some accounting packages consider listings of transactions in account-number order to be journals. However, for a document to be considered a journal in this review we required that data in a printout be in chronological order. While all the packages we reviewed could generate journals, how they did so became an issue.

Journals can be printed in four ways: (1) by user-specified beginning and ending dates, (2) by transaction entry session, (3) by posting batch and (4) by reporting period, such as a month. That raises these questions:

* Can a journal printout be obtained to scan for errors before posting so corrections can be made to the journal, thereby avoiding the need to correct entries?

* Can a single, complete journal printout covering an entire reporting period be obtained?

Scanning printouts after each transaction entry session usually is the best way to obtain a proof listing. But as exhibit 1 (column B), below, shows, only 8 of the 15 packages support this option. Eleven provide printouts by a range of dates (column A), thereby permitting corrections before posting. Only one--RealWorld--makes no provision for proof lists (column E) since printout cannot be obtained prior to posting.

[TABULAR DATA OMITTED]

All of the packages except Macola Accounting and Open Systems Accounting Software provide for printing journals by reporting period (column D). If journals can be printed only by transaction entry session, the operator must accumulate and combine printouts manually for all entry sessions to have a journal for an entire reporting period. This also is true of printouts based on posting batch, unless there is only one posting batch per reporting period--an unlikely scenario except perhaps for the general ledger.

So the issue becomes not whether a journal can be produced, but how reliably it can be obtained and how useful it is as an audit trail. Macola and Open Systems, for example, force a printing at posting and simultaneously erase the journal file (column F). While obtaining and retaining a good printout is critical, it's not a good idea to rely solely on the printed product: Printers can fail and data can be lost when the information is printed to a file or a network print spooler. Even if a good printout is obtained but later lost, accountants must rely on a backup made immediately before posting--a risky proposition at best. In our view, the best system would retain the journal file for an extended period and permit printing at any time before and for some time after posting, which is what most of the packages do.

We discovered other shortcomings. For example, due to delays in receiving information from remote locations, transactions may not be journalized in chronological order. In these cases the accounting system may be programmed to assign a sequential identifying number to each transaction. All but three products assign such numbers (column G). But curiously, while AccountMate Premiere and Solomon IV assign such numbers, they do not provide for a printout of the journal according to these assigned numbers (column H). Thus, only 10 of the 15 both assign transaction numbers and support printouts.

If accountants want to be able to trace backward through the system, it's essential that they be able to place an identifier of the source document in journal entries. While all the packages provide such a capability, again there are wrinkles. A desirable feature of such systems is the ability to locate journal entries and view entries on screen by entering the source document ID--putting less reliance on paper output; all but four packages do this (column K).

While journals can be produced by the packages reviewed here, they cannot be generated with just a few keystrokes; instead, they are treated as just one of many printout possibilities and are not even necessarily called journals. Often one must select certain options manually at print time to obtain one.

LEDGER DOMAIN

Can these packages produce ledgers? Accounting ledgers have specific characteristics:

* All accounts in an application, such as the general ledger, are printed in a single report.

* Each account in the printout contains a beginning balance plus all transactions affecting that account during the period (in date order) and an ending balance.

As shown in exhibit 2 (column A), below, all the packages have adequate general ledgers--although they often are misnamed and the formats sometimes are unconventional and therefore difficult to follow initially.

[TABULAR DATA OMITTED]

The real problems surfaced when we examined the so-called subsidiary ledgers. Although most of the software vendors claimed to have these ledgers, we had great difficulty locating them in the software. After many phone calls to the software publishers and two supplementary questionnaires, here is what we discovered: In the best case, customer, vendor and inventory ledgers usually are considered to be three of many possible reports and are obtained only by selecting the proper combination of options at print time. Thus, to obtain a ledger, users must select a report--not called a ledger--and select the characteristics from a long menu of options that will create a ledger printout.

A few packages lack even that; they produce a report that only lists transactions in account-number order with no beginning or ending balances. Others have transactions for the period and ending balances; to obtain the beginning balance the user must look on the prior-month printout for its ending balance or calculate it by working backward through each account.

Most of the receivables ledgers were generated through an aging report option. We divided receivables accounting methods into balance forward and open item. A true balance-forward system combines all open items at the end of an accounting period and carries a single balance forward to the new period. In contrast, an open-item system carries forward to the current month the detail of all unmatched items from prior months.

Vendor responses to our supplementary questionnaires indicated that several did not understand the difference between the two systems. AccountMate, for example, provided us with a single account printout to accommodate both balance-forward and open-item systems. From their responses we were unable to determine the software's capability and we had to run tests to reach a conclusion.

Vendor responses

     Beginning                  Ending    Our

     balance     Transactions   balance   evaluation

1.   Yes         Yes            Yes       Yes
2.   No          Yes            Yes       Partial
3.   No          Yes            No        No
4.   No          No             Yes       No
5.   No          No             No        No

Some systems described by the vendors as balance forward do not meet our definition. Solomon, for example, instead of carrying a single balance forward, carries all unpaid items forward and applies payments to the oldest. However, statements are printed on a true balance-forward basis, showing only a single amount carried forward each period.

Exhibit 3, at right, shows the vendor responses to the following question in our supplementary questionnaire: Can your package produce a listing by account that shows (1) a beginning balance of the account, (2) all transactions for the period in date order and (3) an ending balance of the account? They provided this information for balance-forward receivables, open-item receivables and payables and inventory (both in units and in dollars). They were told the beginning balance for open-item receivables and payables "may be represented by several items (invoices, etc.) carried forward from prior periods."

[TABULAR DATA OMITTED]

To substantiate their yes answers, we asked the vendors to provide a printout illustrating the capability--being quite specific as to its contents. At that point we performed our own evaluations by running sample data provided with the programs. We then summarized the vendors' responses for beginning balances, transactions and ending balances and determined the extent to which a ledger exists. For example, vendors who answered yes to each question clearly provided a ledger. The following table provides our evaluation of the five responses:

For those who may question why we believe category 2 (no, yes, yes) is incomplete--since it's possible to work backward to the beginning balance--consider this: That calculated figure is only what the beginning balance should be--not necessarily what it is. Only by looking back at the prior printout is it possible to be sure no transactions are missing. Category 3 (no, yes, no) is simply the journal file sorted into account-number order and cannot be tied directly to the output reports.

Our conclusions about subsidiary ledgers are shown in exhibit 2 (columns B-F). We were distressed at the results. Libra Accounting, Macola and SBT Accounting Systems Pro Series have no subsidiary ledgers for either receivables, payables or inventory. Only M[center dot]A[center dot]S 90 Evolution/2 and Platinum Series Accounting have ledgers for all--but even for them, it is necessary to search for and effectively design them from the menus provided.

As in receivables, payables ledgers often were obtainable as an option in the aging of payables. In our view, this use of the aging programs in receivables and payables to produce both ledgers and aging reports did justice to neither. CYMA PAS+ was the only package with menu options that allowed users to print journals and ledgers without having to go through complex steps.

DOLLARS AND UNITS

We believe inventory ledger accouts should show both units and dollar values. However, we found that inventory ledgers were the rarest breed of all. As shown in exhibit 2 (columns E and F), only six of the packages supported either kind of ledger, units or dollars. Surprisingly, Open Systems had neither receivables nor payables ledgers, but it did have both units and dollar inventories.

Note that information often can be found in various reports that, if properly combined, would constitute a ledger. For example, in one package it's possible to ferret out the information constituting a ledger by using the ending trial balance of inventory for the prior year, the receipts listing of the current period, the issuances listing for the current period and the ending trial balance. We resorted to this ponderous procedure in our search for an audit trail in some of the packages--a process we recommend only when all else fails.

Some of the vendors noted that while the software did not produce the journals and ledgers we desired, their report writer could produce it. Since these packages are supposedly accounting systems, we believe they should produce a "set of books"--journals and ledgers--without any programming by the purchasers.

These deficiencies in basic accounting records suggest that developers of accounting programs often believe an accounting system is sufficient as long as management reports can be culled from processed transactions.

BLIND TRACKING

While a conventional audit trail requires the existence of at least a journal and a ledger, obviously more is needed--such as references tying together originating documents, journals, ledgers and reports. In all instances we found that when journals and ledgers existed, the forward trail from documents to reports was good. However, the trail from things such as ledgers and transaction listings to documents often was deficient. In these cases it was not possible to trace directly from ledger entries to journal transactions.

With a hand-kept system, the source of ledger account transactions is denoted by a reference to a page number of an identified journal. In computerized systems, journal page numbers don't exist except on printing. Thus, there needs to be some other way to reference data.

Data posted to the ledger accounts always should include the transaction date, source journal, a unique transaction identifier, the transaction amount and perhaps a batch number. With the journal identifier and unique transaction identifier it's possible to trace directly to the source journal entry. Without a journal identifier, it may not be possible to determine the source journal from the nature of the transaction. If neither a journal identifier nor a unique transaction number exists, then one must search among the various journals for a transaction using only the date, customer/vendor ID and transaction amount. Practically speaking, when there are hundreds of transactions a day, the audit trail will look more like an overgrown jungle.

Some transactions provide automatic referencing information. Sales invoice numbers usually are posted to receivables and check payment numbers to payables along with the dollar amounts, providing a convenient way to trace back to the originating journal. But no such automatic referencing information is available with collections on account or purchases of merchandise. Purchase order numbers aren't useful, since purchases are recorded when consummated rather than when initiated.

Exhibit 4, below, shows references in various reports (some of them are ledgers) for tracing back to supporting journal entries. Some of these so-called ledgers are only full or partial transaction listings by account number. Most of the general ledger references are adequate for tracing. As expected, invoice numbers generally are available in customer accounts permitting traces directly to the sales journal entry.

However, there are no natural references for tracing from customer accounts to the cash receipts journal and, not surprisingly, problems abound. The only reliable reference data would be a sequential transaction number or a deposit number. The date might suffice if there is only one deposit a day. While some references listed are merely ambiguous, others clearly are inadequate; the customer number is insufficient because one would have to scan an entire month's deposits to match the customer number and an amount. The customer check number could be found only by searching the cash receipts journal randomly. Tracing from the vendor (accounts payable) ledger to the purchases journal is just as difficult. The voucher number (probably a sequential number assigned to purchase transactions) permits one to proceed directly to the transaction in the purchases journal. Using the date would restrict the search considerably. But searches using the vendor name, vendor invoice number, purchase order or the amount would only be random.

These searches are required because of gaps in the audit trail. Very small businesses with small volumes and no or few multiple customer or supplier transactions of the same amount on the same date would have no difficulty tracing from ledger to journal. But these packages are designed for considerably larger businesses; thus, the deficiencies are serious.

The best audit trails are provided by ABS Accounting System and CYMA. Although not reflected in the table, an examination of CYMA software found that in every journal the computer assigns a sequential number uniquely identifying that transaction. That number is posted to the ledger, providing a consistent and clear audit trail in every module. Thus, tracing is easy and direct. Open Systems and SBT have excellent audit trails in all but accounts payable.

Other packages depend on the uniqueness of transaction datevendor-amount combinations to provide a basis for journal entry searches. Thus, depending on the number and nature of a company's transactions, the ledger reference information provided makes tracing backward from ledger entries to journals either tedious or nearly impossible.

The structure of accounting software, compared with hand-kept records, raises another audit trail problem. One must be concerned not only with the clarity of audit trails between module journals and ledgers but also with transaction transfers from modules such as accounts payable to the general ledger module. Such transfers may be summaries of transaction data or detailed transactions transferred to the general ledger. Exhibit 5 (column A), this page, shows that ABS transfers the data in detail and all the other packages give the user an option. While some accountants prefer transferring all details, others prefer summary information, which permits them to scan the general ledger accounts easily for unusual transactions. Moreover, if all detail is transferred, the size of the typical general ledger account may increase from a few monthly entries to thousands, nearly doubling the required disk storage space.

[TABULAR DATA OMITTED]

The information transferred may be entered into the general ledger module journals or posted directly from other modules to general ledger accounts. If detail data are transferred to the general journal from other modules and then posted to the ledger, the transaction data will have been stored four times: in the original journal and ledger and in the general journal and ledger. We believe these are two compelling reasons to prefer summary rather than detail transfers. In either case, one should be able to trace data easily from the originating module to the receiving module and vice-versa. All packages have adequate audit trails for this information.

COUNTING MORE THAN MONEY

Audit trails are important for nonmonetary data also. Numerous ledger account changes involve other than dollar amounts: New customer accounts are created; changes are made in addresses, phone numbers, key personnel, credit limits, etc. Accounting programs can be designed easily to provide activity logs (journals) containing all changes to such accounts for auditor and management review. Moreover, systems providing user identifications can report on the identity of the operator making the change.

Exhibit 6, page 48, shows that only ABS, CYMA and RealWorld provide such an audit trail for general ledger, receivables, payables and inventory. Of these, only the RealWorld log contains the ID of the person making changes. Five additional packages--Macola, M[center dot]A[center dot]S 90, Open Systems, Platinum and Solomon--have logs in at least one of the four modules (columns A-D), with M[center dot]A[center dot]S 90, Platinum and RealWorld including user ID (column E). We believe the inclusion of such a log in 8 of the 15 packages indicates a significant awareness of the need for audit trails for nonfinancial information in ledger accounts. The inconsistent implementation is especially regrettable given this recognition.

[TABULAR DATA OMITTED]

MINDING SECURITY

It's relatively easy to make manual books secure: Just lock them in a safe place. But providing access control for computerized books takes some planning. The conventional way is to use password access controls to limit access to various accounting functions. However, while some personal computer password systems are nearly useless, others are relatively effective.

There are two types of systems built into accounting software: task passwords and user passwords. Task passwords are assigned to various activities by the system's security administrator and shared by all users performing those activities. In contrast, user passwords are assigned to each user, and each is given access to appropriate activities. Task password systems are marginally acceptable only if activities are not shared. But they are less than desirable because users must remember a password for each assigned activity and, as a practical matter, users are likely to write the passwords in an easy-to-see place--defeating the purpose. As shown in exhibit 7 (column A), this page, only two use task password systems.

[TABULAR DATA OMITTED]

The longer a password, the harder it is to crack. All the packages provide for several password characters except CYMA, which is limited to three. However, none requires a password of sufficient length to be really effective.

Most of the software packages permit the use of any keyboard symbol, but CYMA is limited to alpha uppercase characters and Great Plains Accounting and Solomon are limited to alphanumeric characters (column C).

For extra security--and a welcome audit trail--two of the packages (AccountMate and SBT) provide a log of user accesses (column B); the log stores the password used and the times access was gained. In general, Infinity Power and CYMA trailed with program password systems (column A), with CYMA limited to three uppercase alpha characters.

Program access controls prevent operators from modifying the accounting program itself. Only products that are created with programming languages requiring a compilation of programmer-developed code can do this. COBOL and C are compiler languages, for example, while most BASIC programs are interpreters, which can be modified easily by anyone with access to the programs and a rudimentary knowledge of the language. All but M[center dot]A[center dot]S 90 and Open Systems have such high-level security (column E).

Data access controls also are a concern, especially when files are stored in American Standard Code for Information Interchange (ASCII) format, which makes the data easily readable by anyone. On the plus side, ASCII formatting makes it easy to export data to spreadsheets and word processors; however, programs now have filters that facilitate exporting and importing of data, so the ASCII plus is no longer significant.

If security is a major issue, the only alternative is to use encryption. None of the packages uses standard encryption algorithms to secure data (column G), and both CYMA and RealWorld store data in ASCII format. Thus, while effective password systems in the accounting packages may prevent unauthorized use of the programs, data files may be read and changed from outside the accounting programs unless the accounting programs encrypt the data.

The most effective security systems are integrated with the computer's operating system and control access to program files, data files and hardware. Those users who want to have the most effective security should investigate such system-level security products rather than relying on package-level security.

II. EXAMINING CONTROLS

DATA ENTRY CONTROLS

Although there are numerous data entry controls, three field-level and two batch controls were selected to represent these packages' general ability to filter erroneous data entered. Those selected are

Field checks.

* Code check and account title display ascertains whether an account number entered in a journal actually exists and, if it does, displays the related title on the screen.

* Check digits control uses the account number itself to determine its own accuracy by invoking an algorithm. A code check assures only that such an account exists by comparing input with a list of valid numbers. Because the check digit is calculated based on input data, it is more likely to identify keying errors. Check digits are used widely to validate credit card and checking account numbers.

* Data type check ensures only numerals are accepted in the amount field.

Batch checks.

* Batch totals control directs the journal program to accumulate the total dollar amount entered in a batch of transactions; that total is compared with an adding machine tape of source document values so errors can be corrected before posting. Packages featuring real-time posting usually don't include this control.

* Hash totals control enables the program to accumulate account numbers, other critical numerical fields or both and compare the totals with adding machine tapes obtained independently.

Exhibit 8, pages 12--13, shows that all the packages reviewed use code and data type checks, but none uses check digits (columns A-C). This omission is particularly regrettable, especially in inventory modules, where many items have lengthy part identifiers and the checking procedure would be especially worthwhile.

[TABULAR DATA OMITTED]

All except M[centerdot]A[centerdot]S 90 and Real-World support batch totals (dollar amounts), but none supports hash totals (columns D and E). Curiously, ABS, AccPac Plus, Account-Mate, Infinity, Platinum and Solomon support batch totals (exhibit 8, column D) but don't permit journal printouts by transaction entry session (exhibit 1, column B), which means accountants using these programs can determine that errors occurred but cannot obtain a printout to correct them before posting. Of the above programs that don't support transaction session printouts, all except Account-Mate and Solomon permit journal printouts by date (exhibit 1, column A), which at least would provide some clues to the location of an error.

By omitting both check digits and hash totals controls, these accounting packages are grossly deficient in validating account identifiers. The benefit of using both check digits and hash totals is testified to by their widespread use by large businesses.

PROCESSING CONTROLS

Processing controls are designed to ensure accounting tasks are performed in proper order. In manual systems, they either don't exist or are informal checklists. Such controls are highly desirable in computerized systems because the operator cannot view computer records as processing occurs. Consequently, it's easy to perform tasks in the wrong sequence, resulting in incorrect reports or an incomplete audit trail. Thus, the software should enforce a proper processing order.

Accounting software generally has tried to replicate manual systems, in which proper task sequencing is assumed. As a result, we anticipated that these controls would be relatively rare. Rather than exhaustively considering all correct operations sequences, we focused on four basic ones to suggest the general development level. For the general ledger, we posed these questions:

* Can financial statements be printed when there are unposted transactions?

* Can the books be closed when financial statements have not been printed?

* Can the books be closed when journals and ledgers have not been printed?

And for accounts receivable, we asked

* Can the accounting records for the period be closed when journals and ledgers have not been printed?

Exhibit 8 (column F) shows that none of the packages prevent financial statement printing when unposted transactions exist, although four provide a warning. Only AccPac requires that financial statements be printed before closing, although CYMA provides a warning if a closing is attempted before printing (column G). Four provide an audit trail by requiring that journals and ledgers be printed before closing; CYMA and SBT provide a warning (column H).

Note that these controls are designed to ensure reliable output and an adequate audit trail. One could object to our criticism by suggesting that access to electronic media would be adequate--paper output is not required. But we believe these packages are not designed for paperless reporting; rather, they emphasize the importance of hard copy output and some even require journal printing as posting occurs.

An even greater absence of control was found in receivables modules. AccPac alone required journals and ledgers be printed before closing; four gave warnings (column J).

Documentation accompanying all of the accounting packages gave the proper order of software operations. In a single-user environment, check sheets can control the operation sequence, but these packages generally are directed toward multiuser environments, with many opportunities for error.

Only 2 of the 15 packages consistently guide the user in performing accounting tasks in the proper order (columns F-J). AccPac prohibits incorrect operation, while CYMA provides warnings. With so many packages having no processing controls, it seems that most accounting software developers are unaware of this need.

OUTPUT CONTROLS

While there are many output controls, we selected two basic concerns to illuminate their overall efficacy level: Ability to determine when printing occurred and to control the distribution of all printouts.

One manual output control is to scan printouts visually for reasonableness. On finding errors, the user should be able to make additional entries, post them and print new statements. But for that to work well, the user must be able to distinguish easily between earlier and later printouts. Controls that provide this capability are date/time stamps on the printouts, sequence numbers appearing on the output or both.

All of the packages provide a date stamp, but MICA IV Accounting Software and Solomon lack time stamps (columns K and L). Only ABS and RealWorld have sequence stamps (column M). Thus, in most packages one can determine the order in which multiple balance sheets have been printed.

A print sequence number also facilitates tracking output distribution. Only ABS and RealWorld make it possible to control the distribution of what may be sensitive data. However, a sequence number indicates only that some printed output exists. A log of the sequence numbers, date and nature of the output is a more effective control; it is available only with RealWorld (column N).

III. REPORTING THE DATA

GETTING THE NEWS OUT

No matter how effective an accounting package is in all other respects, if it doesn't produce reports that enable management to plan and control operations, it's of little benefit. Many businesses have unique reporting needs and most certainly have unique general ledger accounts. Nevertheless, most reporting requirements are common, and exhibit 9, below, shows how each package fares in this regard.

[TABULAR DATA OMITTED]

All the packages provide excellent print medium choices: to screen, to a file and to printer for hard copy. Consequently, reports can be reviewed and printed immediately or stored for later hard copy output (columns A-C).

The order in which records appear in reports affects data's usefulness. For example, a listing of dollar sales of inventory items starting with the largest selling item to the smallest should be useful to any product manager. Yet only 4 of the 15 packages provide any such sequencing capability (column D).

The ability to do exception reporting also is highly desirable for all but the smallest companies. For example, an aging-of-all-customer-accounts report likely would not be useful because information is needed on only those customers requiring management attention. Comprehensive reports bury critical information in long printouts of largely superfluous data. Exception reporting requires the ability to select which records (customers, suppliers, etc.) to include. We examined reporting in receivables and payables modules and used that as a representation of what should be found in other modules.

The most fundamental level of exception reporting is the ability to select records based on an account's dollar value. If the software also can select accounts based on an invoice's due date, an aging can include only overdue customer accounts having a significant balance. A separate report can be run of very old balances of insignificant amounts--and they can be considered for writeoff. While such exception reporting has obvious benefits, only about half of the accounting packages permit such selection (column E).

In accounts receivable aging, selection of large balances permits exception reporting. However, in many situations the difference between actual and budget, rather than an absolute balance, is critical and only significant differences should be included in performance reports. This is especially desirable when reporting on sales by customer, by salesperson, by geographic area, etc. In the general ledger, expense performance reports (including only accounts with significant budgetary differences) would be included. But none of the software packages permits selection based on differences between actual and budget amounts (column F). Thus, exception reporting capabilities are rather deficient for all the packages.

A generalized report writer is highly desirable for flexible reporting. Such a tool can extract and combine data from all modules of an accounting package so that, for example, one might list all customers that buy products that originate with a particular supplier; the report would allow the user to evaluate the impact of discontinuing that supplier. The report would require data from the receivables, inventory and payables modules. As indicated in exhibit 9 (column G), six of the 15 packages include a generalized report writer.

GENERAL LEDGER REPORTING

All of the packages produce acceptable balance sheets and income statements, although clients may wish some modification. All also include either a generalized report writer or a general ledger report writer, permitting the design and modification of reports within the general ledger module. Nevertheless we believe that new users should be furnished examples of predesigned reports and therefore we evaluated the packages on this basis.

However, a significant reporting deficiency is the absence of cash flow statements. As indicated in exhibit 10 (column A), below, all of the vendors except ABS produce a report labeled a cash flow statement. However, only CYMA produced a cash flow statement that complied with the requirements of Financial Accounting Standards Board Statement no. 95, Statement of Cash Flows. With the exception of AccPac and Platinum, the remaining packages produced reports that contain a listing of net changes of all real accounts other than the cash account. The sum of all these net changes is the net change in the cash account. This amount is then added to the beginning cash balance to obtain the ending cash balance, which concludes the statement.

[TABULAR DATA OMITTED]

AccPac's statement falls somewhere between the old statement of changes in working capital and a cash flow statement. The most impressive presentation (other than CYMA's) is by Platinum, which produces a correct statement of changes in financial position-sources and application of funds. However there is no cash flow statement.

When we asked vendors about this omission, several evidenced no understanding of the nature, purpose or content of the cash flow statement; yet they promote their products as conforming to generally accepted accounting principles.

COMPARING DATA

Absolute values reflected in financial statements have little information content. The only way to turn such bare-bones data into useful information is to provide comparison data. Exhibit 10 (columns C-L) shows various ways in which current-period data can be compared with prior periods and budgeted amounts, whether percentage differences can be shown and whether vertical analysis of statements is possible. The tabulated answers refer to income statements only. As can be seen, most of the packages are excellent in this respect. However, CYMA is particularly weak, with spotty performances as well for Account-Mate, Infinity and Solomon.

FOCUS ON RATIOS

In addition, a good general ledger module should provide the most significant financial ratios. While business managers have their favorite ratios, we selected as a standard those used in Industry Norms and Key Business Ratios, published by Dun and Bradstreet Information Services. While every ratio need not be included in the ratio report, a significant number should be. Also, we didn't expect an exact duplication of ratios--only duplication of information content. For example, the ratio of sales to assets was considered equivalent to the ratio of assets to sales.

As shown by exhibit 11, below, excellent coverage is provided by Open Systems and Real World, while ABS, AccPac, Libra, MICA and Platinum provide no predesigned ratio report. While ratios can be produced by most of these packages, some programming is required by the user. The ratios most often omitted were

* Fixed assets to net worth, which indicates either over- or underinvestment in fixed assets.

* Assets to sales.

* Sales to net working capital.

* Accounts payable to sales.

[TABULAR DATA OMITTED]

RECEIVABLES REPORTING

Several reporting activities are considered critical to management; we selected as representative the six shown as column headings in exhibit 12 at right.

[TABULAR DATA OMITTED]

While all packages provide an aging-by-customer report (column A), column B shows that four don't permit aging by invoice. That means there's insufficient detail to discuss the account with the customer because invoice and payment data are lacking.

When evaluating a company's discount policy, reports showing discounts offered to customers compared with those actually taken suggest whether the policy is too restrictive or too generous. Only four provide any such information (column C), and the variety of formats in which they are provided is too great to describe here. We think this type of report is necessary if users wish to monitor the efficacy of their discount policy and its impact on cash flow.

Three packages provide no projected cash receipts report (column D) even though cash budgeting is one of the most critical planning tasks for financial management.

Sales management reports are adequate. Column F shows that four packages don't report on gross profit by customer although all packages provide a report showing sales by customer (column E). Since the additional programming and data storage required to accumulate and report on gross profit is minimal, it is disappointing that some packages omit this information.

ACCOUNTS PAYABLE REPORTING

Management activities considered essential in accounts payable and the supporting reports parallel those in receivables; they are listed as column headings in exhibit 13 on page 58.

All the payables modules provide an aging of payables (column A). There clearly is a greater appreciation of the need to manage cash on the purchasing cycle than on the sales cycle. Of the three packages without a receivables cash flow report, only one--Open Systems--lacks a payables cash flow report (column B). And in contrast to the receivables modules, where only four provide a discount report, as shown in exhibit 12 (column C), all except five--ABS, CYMA, Infinity, M*A*S 90 and Solomon--produce a discounts-lost report in payables (exhibit 13, column C).

[TABULAR DATA OMITTED]

A significant number of programs omit reports of late shipments or returns and allowances by vendor, with only AccPac, Great Plains and Macola providing both (columns D and E).

INVENTORY REPORTING

The critical management activities and reports supporting inventory reporting activities are listed as the column headings in exhibit 14 on page 58.

[TABULAR DATA OMITTED]

An order recommendation report ensures merchandise is ordered on a timely basis, while the excess inventory report calls attention to unwarranted accumulations. All but two packages provide a report listing inventory items that have fallen to a reorder point, usually considered to be lead time stock plus safety stock (column A). But 7 of the 15 packages fail to report on excess inventory units (column B). Thus many programs lack a significant inventory management tool.

While the order recommendation report is a natural exception report since it includes only items requiring management attention, the excess inventory report is not because it includes all excess inventory items whether or not the excess is significant. Since sales are random during an open order period, about half of the inventory items should be over the maximum stocking level when orders are received. Accordingly, few of the items listed in the excess inventory report will be significant enough to warrant management attention. AccPac is the only package to address this problem: It permits user entry of a minimum value so only excess inventory items above the chosen value are included in the report. Several modules of AccPac offered this ability to set minimum values permitting exception reporting.

While the order recommendations and excess inventory reports will suffice for day-to-day inventory management, some items will be out of stock or in such critically short supply that closer monitoring is necessary. The stock-available and on-order report that includes the expected order receipt dates addresses this need. As shown in column D, only about half of the packages support this need.

Periodically, management must ascertain which are the best and worst products. The turnover ratio shows product activity and may indicate obsolete items. A comparison of sales and gross profit by item for the current month and year-to-date with budget or prior-period amounts suggests products to be considered for either better sales efforts or deletion from the product line. Generally, these accounting packages produce an excellent way to conduct continuing reviews of a company's product line (column E-G).

THE BOTTOM LINE

From this analysis we conclude that in some important respects all of the packages have excellent capabilities. Some are significantly superior to others in audit trails, controls or reporting. But, as our analysis has shown, in some important respects all of the packages have significant deficiencies.

In selecting a package, an accountant must consider all of its plused and minuses--not just the ones we reviewed here. Consequently, a package that fared poorly in some respects in this analysis may be a best choice for a particular client. Similarly, a package that received high marks in this review may not be a good choice for another client. The bottom line is this: Selecting accounting software is not easy; there is no simple way to qualify a package for a client except by fully analyzing both the package and the client to be sure they are compatible.

The selection process is an imposing task. First, one must exhaustively research and inventory a business's accounting and reporting needs. Only then is it possible to begin the daunting task of selecting software to meet those needs. Software evaluation requires an examination of hundreds of features and ways in which those features are implemented--and there is no quick and easy way to accomplish this.

HOW THE STUDY WAS CONDUCTED

This project was more than a year in the making. It was initiated by the Journal of Accountancy and involved not only the two named authors but also about 80 students at the University of Texas at Arlington.

Fifteen software packages were selected for review and their vendors were invited to participate. They were asked to complete a detailed questionnaire on the products' capabilities. The vendors also provided copies of their software with demonstration data and full documentation so we could verify their responses. The programs were installed on the University of Texas accounting department's computer laboratory network, where the students--all accounting majors--divided into groups of five to examine each package using the same questionnaire submitted to vendors. Student groups critiqued four modules of each package (general ledger, receivables, payables and inventory) and then made a formal presentation of findings to the class.

When vendor and student information conflicted--and there were many instances of that--the authors examined the software and its documentation. In only a few cases were the conflicts a result of students' inexperience. On several occasions, it was determined that vendors approached the questionnaires somewhat casually, claiming features clearly not present.

When there were inconsistencies, the vendor was contacted and attempts made to clarify and resolve any differences. Often these differences were caused by misunderstandings in the use of accounting terminology.

In many cases the demonstration data included with the software packages did not clearly reveal software capabilities, making examination of features especially difficult. Compounding the problem was the fact that often illustrative printouts in the vendors' manuals were inconsistent from journal to ledger and from one report to another.

SKEPTICISM CONFIRMED

The presence of a capability in a particular module was taken to assume its presence in other appropriate modules. For example, certain input controls were assumed to exist in all modules based on their presence in a single one. Claims to features that it was not feasible for us to verify were accepted if they appeared reasonable (for example, how long journals can be maintained on disk). However, we were skeptical of some answers and, on inquiry, found many to be erroneous.

For example, one vendor supplied us with a single customer account printout that it said illustrated both balance-forward and open-item capabilities; but in our view it illustrated neither. In another case, on a follow-up questionnaire, a vendor decided that a yes response to a question was the best answer and wrote yes for every question even though some did not call for yes/no responses.

In cases where the vendor claimed a capability for its product and was either unwilling or unable to support the claim, we trusted our own findings.

While we cannot claim the study is error-free, we have made every effort to clarify responses with each vendor.

MIGRATION PATHS: PLANNING FOR THE UNKNOWN

The only constant in business is change, which is why managers of any growing enterprise always must factor into any software purchase the likelihood of a change in the hardware, the software or the operating system. Thus the ability to move existing data to an updated system--called a migration path--must be considered when buying application software. As a result, each of the responding companies was asked about the availability and planned availability of their software on more sophisticated operating systems than DOS. The exhibit below shows the responses.

Unix is one of the most mature and stable multiuser operating systems. The Unix versions of the accounting programs covered in this article often are identical or nearly identical to DOS versions; thus, retraining costs when migrating from a vendor's DOS product to a Unix product will be minimal. Rapidly growing companies or those with branch locations needing good communications support may wish to consider a Unix platform.

IBM's OS/2 also is a mature and stable windowing operating system, and clients needing a network environment--particularly those with existing IBM mini- or mainframe installations--may wish to consider it as an upgrade path.

Microsoft's Windows 3.1, while technically not an operating system (since it runs on top of DOS), must be treated as one because it runs Windows applications. While several of the software vendors have Windows accounting programs available and claim good sales, there are sufficient reports of Windows instability in networking environments to advise caution when choosing that platform for accounting applications. Program interruptions that are an inconvenience when running word processing or spreadsheets often precipitate a crisis when accounting is the application.

There are two additional Windows concerns:

* There is no assurance that Microsoft will continue shipping and supporting Windows 3.1 when its successor, Windows 95 (previously called Windows 4 and code-named Chicago), is released sometime later this year.

* The user interface has been revised significantly for the successor program, with reduced training required. Thus, there is some evidence it would be prudent to wait for the successor and related accounting software.

The much-delayed Windows 95 is a true operating system and certainly can be expected to mature into a stable and sophisticated product.

NT, also from Microsoft, has developed into a network server system and has limited market penetration. That may change when Windows 95 is launched.

Many companies will find that the present DOS/networking or multiuser DOS platforms (such as VM/386) will be adequate for their foreseeable growth and that they can confidently select accounting software without considering the availability on other operating systems.

[TABULAR DATA OMITTED]

FOR MORE INFORMATION

* ABS Accounting System American Business Systems, Inc. 315 Littleton Road Chelmsford, Massachusetts 01824 Phone: [phone] Fax: [phone]

* AccPac Plus Computer Associates International, Inc. One Computer Associates Plaza Islanda, New York 11788 Phone: [phone] Fax: [phone]

* AccountMate Premiere SourceMate Information Systems, Inc. 20 Sunnyside Avenue Mill Valley, California 94941 Phone: [phone] Fax: [phone]

* CYMA Professional Accounting Series Plus (PAS+) CYMA Systems, Inc. 1400 East Southern Avenue Tempe, Arizona 85282 Phone: [phone] Fax: [phone]

* Great Plains Accounting Great Plains Software 1701 South West 38th Street Fargo, North Dakota 58103 Phone: [phone] Fax: [phone]

* Infinity Power Data Pro Accounting Software, Inc. 5439 Beaumont Center Boulevard, Suite 1050 Tampa, Florida 33634 Phone: [phone] Fax: [phone]

* Libra Accounting Libra Corp. 1954 East 7000 South Salt Lake City, Utah 84121 Phone: [phone] Fax: [phone]

* Macola Accounting Macola Inc. 333 East Center Street Marion, Ohio 43302-4148 Phone: [phone] Fax: [phone]

* M*A*S 90 Evolution/2 State of the Art, Inc. 56 Technology Irvine, California 92718 Phone: [phone] Fax: [phone]

* MICA IV Accounting Software Micro Associates, Inc. 2349 Memorial Boulevard Port Arthur, Texas 77640 Phone: [phone] Fax: [phone]

* Open Systems Accounting Software Open Systems, Inc. 7626 Golden Triangle Drive Eden Prairie, Minnesota 55344 Phone: [phone] Fax: [phone]

* Platinum Series Accounting Platinum Software Corp. 195 Technology Drive Irvine, California 92718 Phone: [phone] Fax: [phone]

* RealWorld RealWorld Corp. 282 Loudon Road P.O. Box 2051 Concord, New Hampshire 03302 Phone: [phone] Fax: [phone]

* SBT Accounting Systems Pro Series SBT Corp. 1401 Los Gamos Drive San Rafael, California 94903 Phone: [phone] Fax: [phone]

* Solomon IV Solomon Software, Inc. 1218 Commerce Parkway P.O. Box 414 Findlay, Ohio 45840 Phone: [phone] Fax: [phone]