Printer Friendly

Guide to accounting software: the pluses and minuses of nine leading mid-price-range products.

The switch by most CPAs from DOS to the Windows environment occurred so quickly that our most recent review of the leading DOS-based accounting software, published only three years ago (JofA, Feb.95, page 37), was essentially obsolete a year after it appeared. This article, analyzing the current Windows-based mid-price-range products, updates the subject. But considering how quickly the Windows technology continues to advance, we can't guarantee how long before even this report will become outdated.

While some DOS accounting products continue to sell at a modest pace, most developers either are no longer updating their DOS products and milking them for as long as they sell or are abandoning them. Development efforts now focus on the Windows platform; in fact, as an indication of how fast Windows technology is moving, Microsoft NT, not Windows 95, is becoming the platform of choice for accounting programs. While many recently developed products will run on both Windows 95 and NT, few developers are making what amounts to programming compromises to achieve this dual flexibility. The developers have recognized that NT, more so than Windows 95, has the reliability needed for an application as mission-critical as accounting.

THE KEY FUNCTIONS

For this analysis, we decided to investigate the same key accounting functions assessed in our earlier research--audit trails, controls and reporting. For more on how we handled this review, see the sidebar, "How We Conducted This Analysis". Our investigations revealed that some of the new Windows packages did more than their DOS counterparts, but in at least one case--MICA--the developers simply converted the old DOS product into a Windows version with little functional improvement. As a result, although reviewed in our earlier study, MICA was dropped from this round; so, if readers are interested in our review of MICA, we suggest checking the 1995 article.

In the few years since the earlier review, some vendors have repositioned their products in the marketplace. CYMA, for example, offers a totally redesigned 32-bit product that runs on both Windows 95 and NT, but the vendor has cut the price sharply, to below its previous nearest competitors, and, as such, moved it into a lower-price category and out of the range of this review; for that reason, we omitted it from this article. Also, the maker of a product that technically ranked very high in the earlier study--ABS Accounting--says its Windows version is still under development and is not yet available for testing. In another case, we eliminated Platinum Software's product--Platinum for Windows--because, despite repeated efforts, the vendor failed to respond to our inquiries.

In the end, we selected nine Windows-based accounting packages to include in the study. Details on how to contact each vendor and the prices of their products appear in panels.

POSTING METHODS

As you know, there are two software methods for posting transactions: in real time or in batch. Certain controls discussed in this article are useful only with batch posting. We believe batch posting is the most effective posting method in most cases, and we're pleased to report it is the dominant method used by the packages we reviewed.

Although some accountants believe real-time posting is more desirable so all records are up-to-date, we question that thinking. With few exceptions, batch posting is sufficiently timely for most management reporting. Moreover, unless transactions are captured on a real-time basis, real-time posting can't produce current information: It's only as timely as the timeliness of the journalization. We do recognize that under some circumstances real-time data are essential; in such cases, both real-time data capture and real-time posting are necessary. This is especially true when accepting orders in real time (such as for airline reservations); then, inventory must be current. And of course, by its very nature, batch posting is more efficient; also, it results in fewer posting errors.

Most often, the inventory module and, less frequently, receivables (where credit limits are monitored) need real-time data. Rarely, if ever, will accounts payable and payroll require real-time posting. General ledger generally can be run on a batch-posting basis in any environment.

As shown in exhibit 1, below, only Great Plains Dynamics and Visual Accounting give users the choice of batch or real-time posting in all modules. All the products support batch posting in the general ledger and all except Impact Encore and SBT Pro support it in accounts receivable and accounts payable. In inventory, all support real-time posting. As might be expected, updates from other modules to general ledger (column 5 of the exhibit) match the posting options in the general ledger module (column 1).
Exhibit 1: Posting Methods Used by Accounting Software

 For the general For accounts
 ledger: Is the receivable: Is the
Accounting posting of journals posting of journals
software to ledgers in batch to ledgers in batch
product or in real time? or in real time?

ACCPAC Batch Batch

Great Plains Batch or Batch or
Dynamics real time real time

Impact Encore Batch Real time

MAS 90 Batch Batch

Progression Batch Batch

SBT Pro Batch Real time

Solomon Batch Batch

Traverse Batch Batch

Visual Batch or Batch or
Accounting real time real time

 For accounts For inventory:
 payable: Is the Is the posting of
Accounting posting of journals journals to ledgers
software to ledgers in batch in batch or in
product or in real time? real time?

ACCPAC Batch Real time

Great Plains Batch or Batch or
Dynamics real time real time

Impact Encore Real time Real time

MAS 90 Batch Real time

Progression Batch Real time

SBT Pro Real time Real time

Solomon Batch Real time

Traverse Batch Real time

Visual Bach or Batch or
Accounting real time real time

 For transfer to
 the general ledger
Accounting module from other
software modules: Is posting
product in batch or real time?

ACCPAC Batch

Great Plains Batch or
Dynamics real time

Impact Encore Batch

MAS 90 Batch

Progression Batch

SBT Pro Batch

Solomon Batch

Traverse Batch

Visual Batch or
Accounting real time


AUDIT TRAILS

Accounting software should be able to provide an audit trail--that is, a way to trace a transaction from its origin to the financial statements and vice-versa. Moreover, the software should permit users to trace from the beginning balance of each account to the ending balance and vice-versa.

Exhibit 2, describes the transaction (journals) available in each package. While all of the choices would be convenient, only the listing by reporting period is really important. All the packages except Great Plains Dynamics and MAS 90 provide satisfactory journals. Note that MAS 90 prints journals only for the general ledger module.
Exhibit 2: Journal Audit Trails for Accounting Software
 Journal Printing
 By By
Accounting user- Transaction By By
Software specified entry batch reporting
product date? session? posted? period

ACCPAC Yes Yes Yes Yes

Great Plains No No Yes No
Dynamics

Impact No Yes Yes Yes
Encore

MAS 90 General General General General
 legder ledger ledger ledger
 module module module module
 only only only only

Progression Yes Yes Yes Yes

SBT Pro Yes Yes Yes Yes

Solomon Yes Yes Yes Yes

Traverse No Yes Yes Yes

Visual Yes Yes Yes Yes
Accounting
 Is journal
 How Does the printing in
 long are system assigned
Accounting Prior journals assign transaction
Software to retained transaction number
product posting? on disk? numbers? order?

ACCPAC Yes For Yes Yes
 multiple
 years

Great Plains Yes For Yes Yes
Dynamics multiple
 years

Impact Yes For Yes Yes
Encore multiple
 years

MAS 90 General For Yes Yes
 ledger multiple
 module years
 only

Progression Yes For Yes Yes
 multiple
 years

SBT Pro Yes For Yes Yes
 multiple
 years

Solomon Yes For Yes Yes
 multiple
 years

Traverse Yes For Yes Yes
 multiple
 years

Visual Yes For Yes Yes
Accounting multiple
 years

 Is there
 Is there a screen
Accounting a source lookup
Software document by ID
product ID field? field?

ACCPAC Yes Yes

Great Plains Yes Yes
Dynamics

Impact Yes Yes
Encore

MAS 90 Yes Yes

Progression Yes Yes

SBT Pro Yes Yes

Solomon Yes Yes

Traverse Yes Yes

Visual Yes Yes
Accounting


In our earlier study, we complained that some retained journal data only until they were posted. Many of the accounting applications in this article now retain journals for a year or longer. In addition, they all assign sequential transaction numbers for identification and printing a journal in transaction number order.

We believe transaction entry screens should support a field that accepts the identity of any source document and a user should be able to look up the transaction by referring to that ID. All the packages support a source document field, and all except Great Plains Dynamics, MAS 90 and Solomon provide a lookup screen for that purpose.

THE LEDGER

The ledger continues to be a troublesome feature--as it was in our 1995 review. We define a ledger as a listing of accounts, arranged in order by an account identifier, covering a period of time and including the beginning balance, detail of transactions and the ending balance for each account. As shown in exhibit 3, all packages except Progression provide a printout of the general ledger. Although the DOS-based Macola Accounting reported on in our 1995 study printed a general ledger, Macola's current Windows product--Progression--permits only a screen display of a single general ledger account.
Exhibit 3: Ledger Audit Trails

 Are ledgers available for
Accounting software general accounts accounts
product ledger? receivable? payable

ACCPAC Yes Yes

Great Plains Dynamics Yes Yes Yes

Impact Encore Yes Yes Yes


MAS 90 Yes Yes Yes

Progression Screen lookup No No

SBT Pro Yes Yes Yes

Solomon Yes Yes Yes

Traverse Yes No No

Visual Accounting Yes Yes Yes

 Is inventory measures in

Accounting software dollar
product units? values?

ACCPAC No Yes

Great Plains Dynamics Yes Yes

Impact Encore Yes No

MAS 90 Yes Yes

Progression No No

SBT Pro No No

Solomon Yes Yes

Traverse Yes Yes

Visual Accounting Yes No


All except Progression and Traverse provide ledgers for receivables and payables. Inventory ledgers are unique in that both units and dollar values should be presented. Great Plains Dynamics, MAS 90, Solomon and Traverse do provide the inventory ledger in both units and dollar values, but in all the other packages either one or both functions are missing--a serious emission.

The absence of ledgers may explain a phenomenon that we have not previously understood: Many CPAs want their accounting packages to transfer to the general ledger module the details of all transactions recorded in accounts receivable, accounts payable and inventory modules. The scarcity of ledgers in modules other than general ledger may account for this preference.

A continuing audit trail deficiency is the inability to easily trace entries from ledger accounts to their journal source. Exhibit 2 refers to the assignment of transaction numbers to journal entries. A particularly important use of these transaction identification numbers is to trace transactions between the journal and the ledger. A company's own check and invoice numbers are ideal for identifying cash payment and sales transactions, but other transactions lack such "natural" identifiers. For example, you can't use a company's own purchase order (PO) numbers to trace transactions between the purchases journal and the vendor ledger and vice-versa because the purchase transactions in the journal (a chronological record) will not appear in PO number sequence. Exhibit 4, lists references used in ledgers to trace transactions to their originating journals.
Exhibit 4. Reference Data Provided in Ledger Accounts for
Tracing to Source Journal

 Information provided to trace from

 sales entry
 in accounts
Accounting general ledger receivable
software to general ledger to the
product journal sales journal

ACCPAC Source codes Posting sequence,
 batch number
 and/or
 number

Great Plains Journal Document
Dynamics entry number number

Impact Journal Invoice
Encore number number

MAS 90 Source Invoice
 journal code number

Progression Source code Drill down

SBT Pro Batch number Batch number,
 and/or customer number
 transaction and/or invoice
 number number

Solomon Journal type, Invoice number,
 batch number, order number,
 reference order type,
 number date and/or
 and/or date transaction type

Traverse Entry number Invoice number

Visual Batch number, Customer number
Accounting user, time and/or invoice
 and/or date number

 cash receipt purchase entry
 entry in accounts in accounts
Accounting receivable to payable ledger
software cash receipts to purchases
product journal journal

ACCPAC Posting Day-end
 sequence, batch number
 entry number and/or
 entry number

Great Plains Document Document
Dynamics number number

Impact Check number Invoice number
Encore and/or reference and/or goods
 number received note
 number

MAS 90 Check number Receipt number
 and/or date and/or date

Progression Drill down Drill down

SBT Pro Batch number, Batch number,
 customer number vendor number
 and/or invoice and/or voucher
 number number

Solomon Reference number, Reference number,
 transaction type document
 and/or date type, vendor
 invoice number
 and/or date

Traverse Receipt number Invoice number

Visual Customer number Vendor number
Accounting and/or check and/or invoice
 number number

 inventory receipt inventory
 in inventory issuance
Accounting ledger to in inventory
software purchases ledger to
product journal sales journal

ACCPAC Day-end Day-end
 number number

Great Plains Receipt Receipt
Dynamics number number

Impact Goods received Invoice
Encore note number number
 and/or
 purchase order
 (PO) number

MAS 90 Receipt number Source
 and/or date journal number
 and/or date

Progression Lot number Lot number

SBT Pro Inventory control The inventory
 transaction file control journal
 has field with PO has the
 number and sales transaction
 order number. number.

Solomon In inventory In trial
 trial balance, balance, look
 look for receiving for invoice
 report with reference
 reference number, then
 number. In PO go to sales
 screen, enter journal to look
 PO number or up with F3
 receipt number. key the invoice
 number.

Traverse Receipt number Invoice number

Visual PO number Customer
Accounting and/or number and/or
 vendor number invoice number


All the packages provide the ability to trace from the general ledger to the general journal, with all apparently using the assigned transaction numbers except Visual Accounting, which applies the batch number. Tracing from customer accounts to sales journals employs the invoice number; tracing from vendor accounts to a purchases journal is a greater challenge. Since there is no internal, sequentially numbered document identifying a purchase transaction, the assigned transaction numbers referred to in exhibit 2 should be used to refer to the journalized transactions. A PO number, a vendor's invoice number or its receiving report number are inadequate to look up transactions because the reference numbers will not be in chronological order in the source journal.

The variety of identifying data and the omission of assigned transaction numbers in ledger accounts suggest that the software developers don't fully appreciate why and how accountants use audit trails. We were initially pleased to see a reference to a voucher number (which is what such a transaction-assigned number might reasonably be called) by SBT Pro for tracing from vendor accounts to the purchases journal. But on investigation, we found no such transaction number was created when we entered purchases and neither was there a voucher number reference in the purchases journal or in the vendor ledger.

All references in exhibit 4 to invoice or vendor number suggest, at best, that accounting software designers believe audit trail information should be sufficient to give the auditor a "hunting license" to perform a somewhat random search of relevant journals to locate a particular transaction that appears in a ledger account.

DATA FLOW AMONG MODULES

The flow of data among the various modules in an accounting package is a significant part of the audit trail. Its importance is illustrated by the fact that, until recently, accountants often preferred to obtain printouts from "subsidiary" modules that summarized module transactions and then manually entered these data in the general ledger module. With the increasing reliability of computerized systems, such a practice has become unusual. But the ability to trace data flows between the modules is as necessary as ever.

Exhibit 5, shows the nature of such data transfers and the extent of the audit trail. We applaud the option that's provided in all the packages to transfer either detail or summary data to the general ledger. When ledgers are deficient, detail transfers are necessary to obtain an audit trail. With complete ledgers in all relevant modules, we prefer summary transfers for several reasons: minimal posting activity, reduced data storage and improved scanning and analysis of general ledger accounts is expedited since only nonroutine entries appear individually in the general ledger module.
Exhibit 5: Transaction Data Transfers to General Ledger Modules From
Other Modules

 Are data transfers to Within the
 the general ledger general ledger
Accounting software module from other modules, data are
product modules in detail or transferred to the
 summary?

ACCPAC Both Journal
Great Plains Dynamics Both Journal or ledger
Impact Encore Both Journal
MAS 90 Both Journal
Progression Both Ledger
SBT Pro Both Journal
Solomon Both Ledger
Traverse Both Journal
Visual Accounting Both Journal or ledger

 Does posting Is printout
 reference in general of data transfer
Accounting software ledger permit available in
product tracing to source? detail or
 summary?

ACCPAC Yes Both
Great Plains Dynamics Yes Detail
Impact Encore Yes Both
MAS 90 Yes Detail
Progression Yes Both
SBT Pro Yes Both
Solomon Yes Detail
Traverse Yes Both
Visual Accounting Yes Both


Transfers to the general ledger module are often made to one or more journals in that module. Progression and Solomon transfer the data directly to the general ledger accounts. Note that both Great Plains Dynamics and Visual Accounting give the user an option. All the packages provide references in the general ledger module to sources in the other modules. The only criticism we have in this area is the failure of some packages to provide the option of a summary printout of data transfers. Obtaining a printout before posting gives the user the opportunity to judge the reasonableness of the amounts and to make any corrections before the intermodule posting occurs. Another advantage is the ability to use several modules with either a different vendor's general ledger module or with a manual general ledger.

Overall, the quality of audit trails in the packages reviewed is disappointing. We believe an excellent rating requires the printing of all journals by accounting period and the printing of all ledgers. Solomon met all of these requirements. ACCPAC shows inventory dollars but no units, while Impact Encore and Visual Accounting support inventory units but no dollar value. Progression, in contrast, supports only screen lookup of the general ledger on an account-by-account basis. In a sense, Progression's performance may portend a future in which hard-copy printouts are an option and on-screen reporting is the norm. That day has not arrived; in any case, an on-screen review should permit scanning through the entire ledger rather than requiring a call-up of one account at a time.

INTERNAL CONTROL

The need for effective internal control is widely accepted today. Operating a business involves controls, many of which must be designed into the computerized accounting system. Since we can't cover the whole subject of computer controls here, we selected what we consider the important ones.

* Access controls prevent unauthorized access to the accounting system. While most mainframe systems contain multiple, sophisticated controls, the Windows environment supports only passwords. In fact, with a couple of well-timed keystrokes one can bypass the Windows 95 password.

Exhibit 6, below, shows that all the packages permit the assignment of different passwords to individual users. This is significant because in our 1995 study some packages still used passwords common to each task. Having all users of a given task share the password dilutes control significantly. Moreover, assigning different passwords to each task compromises control further since users--who can't be expected to remember several passwords--must write them down. While some of the packages permitted task passwords as an addition to user passwords, their use was optional.
Exhibit 6: Access Controls Available

 Regarding passwords
 What is the What is the
 Are minimum maximum
 passwords number of number of
Accounting assigned to characters a characters a
software users password password
product or tasks? may contain? may contain?

ACCPAC Users 1 8
Great Plains
Dynamics Users 1 15
Impact Encore Users 1 4
MAS 90 Users 3 8

Progression Users 1 10
SBT Pro Users Set by administrator
Solomon Users 1 12

Traverse Users 1 14

Visual Accounting Users 1 15

 Which
 keyboard Does a log
 symbols record the Are
Accounting can be time of program
software used in each user files
product passwords? access? compiled?

ACCPAC Alphanumeric No Yes
Great Plains
Dynamics All Yes Yes
Impact Encore All Yes No
MAS 90 No No Yes
 lowercase
Progression All No Yes
SBT Pro All Yes Yes
Solomon No Yes Yes
 lowercase
Traverse All No No
Visual Accounting All No Yes

 Are data
Accounting files stored Are data
software in ASCII files
product format? encrypted?

ACCPAC No No
Great Plains
Dynamics No No
Impact Encore Yes No
MAS 90 No No

Progression No No
SBT Pro No No
Solomon No No

Traverse No No
Visual Accounting Yes Yes


Password systems should require users to select hard-to-guess passwords--those with a minimum length of several characters. Most of these packages require a minimum length of only one character, which is not satisfactory. The possible exception is SBT Pro, where the system administrator controls the password length. If users are conscientious about security, they can select multiple-character passwords. Unfortunately, Impact Encore limits the length to four characters. Most password system designers believe that passwords should be a minimum of six characters.

Strong password systems commonly permit all alphabetic and all numeric characters and a variety of other keyboard symbols. All of the reviewed packages except for ACCPAC, MAS 90 and Solomon permit any keyboard character. ACCPAC uses alphanumeric characters only and MAS 90 and Solomon cannot use lowercase letters.

For control purposes, the system should record who accesses the accounting program and when. Only Great Plains Dynamics, Impact Encore, SBT Pro and Solomon support such a log.

In summary, we concluded that, while the password systems are far better than nothing, little serious effort was devoted to their design.

* Program control deters users from making unauthorized changes to the software. This is possible only if the software is written in a compiler-based language. All the packages' software are compiled except Impact Encore and Traverse. Those failing to use compiled programming code rely on the programming ignorance of users to prevent unauthorized changes--hardly an effective security method.

* Data security is a critical control. While passwords embedded in accounting systems can constitute a barrier to accessing data through the accounting programs, even a relative computer novice can get into stored data through the operating system--without even entering the accounting program. Such a security lapse can occur when users store data files in an easily viewable format such as ASCII. In that case, an intruder can display such data at the DOS prompt by entering the TYPE command followed by the data file name; the data can be modified by using the EDIT command.

An additional way of modifying data is to use the programming and/or database language commands. Some database products include password systems to protect the data; others do not. Since our study didn't examine the database products used by the accounting applications, we offer this information as an alert to these potential control weaknesses.

An effective way of protecting data files from such exposures is to use encryption. While it may be an effective safeguard, encryption does have its drawbacks: Storing encrypted data requires additional space and more processing time. Various levels of data encryption are available for personal computers; the higher the level of encryption, the more costly its implementation. When we inquired about the use of encryption for data files, four vendors said it was built into their products. However, on further investigation we found three of them not only did not have it, but also the representatives providing the information did not understand the concept of encryption. Since we had not expected any of the products to support encryption, it was both surprising and gratifying to find that Visual Accounting (see exhibit 6) has implemented the technology at the 40-bit level (the maximum permitted by federal regulations for exported products). Failure by this segment of the accounting software industry to include encryption is a significant shortcoming.

* Input controls assume a critical importance in computerized accounting systems. When people process accounting data manually, they handle data multiple times. For example, a posting clerk usually can catch an entry composed of a debit to the allowance for doubtful accounts and a credit to the equipment account. But the computer won't recognize the difference and win post it automatically. Therefore, for data input errors to be caught, the emphasis must be on detection through input controls.

Two good possible data filters for account identifiers (such as general ledger accounts, customer accounts and inventory part numbers) are code checks and check digits. A code check compares the input of an account ID with a stored list of identifiers and rejects invalid identifiers. Usually, the ID lookup retrieves the account description and places it on the input screen next to the identifier, thereby providing visual confirmation of the account selected. Note that the code check per se does not assure that the input ID is correct; it assures only that a valid ID has been entered. The entry of a wrong but valid ID will be accepted. Thus, the accuracy of code checks depends heavily on a visual check. Exhibit 7, below, shows that code checks are used in all packages and the account title is displayed on the input screen.
Exhibit 7: Available Data Entry Controls During data entry

 During data entry

 is a code Can
 check reason-
 performed ablesness
 and the are are limits be
Accounting account check data type established
software title digits checks by the
product displayed used? used? user?

ACCPAC Yes No Yes No
Great Plains
Dynamics Yes No Yes Yes
Impact Encore Yes No Yes No
MAS 90 Yes No Yes No No
Progression Yes No Yes Yes
SBT Pro Yes No Yes Yes
Solomon Yes No Yes Yes
Traverse Yes No Yes No
Visual
Accounting Yes No Yes Yes

 Can
 reason- Can trans-
 ableness actions be
 limits be entered
 established Do hash for other
Accounting by the Do batch totals than the
software system ad- totals accu- current
product ministrator? accumulate? mulate? period?

ACCPAC No Yes No Yes
Great Plains
Dynamics Yes Yes No Yes
Impact Encore No Yes No Yes
MAS 90 Yes Yes No Yes
Progression Yes Yes No Yes
SBT Pro Yes Yes No Yes
Solomon Yes Yes No Yes
Traverse No No No Yes
Visual
Accounting Yes Yes No Yes

 Can the
 entry
 of trans-
 actions
 for other
 periods be
 controlled
Accounting by the
software system ad-
product ministrator?

ACCPAC Yes
Great Plains
Dynamics Yes
Impact Encore Yes
MAS 90 No
Progression Yes
SBT Pro Yes
Solomon Yes
Traverse No
Visual
Accounting Yes


Converting to a check-digit system requires adding one digit to existing account identifiers. That digit is calculated from the numbers in the original identifier. Using a common algorithm for a check digit eliminates about 95% of the keying data errors. Thus, if there are 5,000 entries with an error rate of 2% (100 errors), only 5 errors will not be detected by such a check-digit system. Since check digits do not require any system lookups but require only that the computer calculates the check digit, required computer resources are minimized. On the other hand, if 5,000 account identifiers must be recorded, adding a seventh (check) digit will require 5,000 additional keystrokes.

Code checks need screen confirmation of data entry and thus more computer processing than do check digits; check digits require additional keying time. The presence of check digits in our checking account numbers, credit card numbers and most product bar codes attests to their utility in large data processing environments. Check digits--often associated with heads-down data entry--use an audible sound to alert data entry personnel to errors. Code checks seem to be preferred in low-transaction-volume environments, with the assumption that data entry personnel will "double-check" their work by reading the screen. Given that all of the packages we examined originated in the microcomputer marketplace, it was no surprise they all used code checks and none supported check digits.

Checks to validate quantitative values (dollar or physical) include data type and reasonableness. A data-type check ensures the data entered are composed of a specified character set such as the numbers. Such a system can ensure that entry of transaction values, sales discount rates and wage rates are composed only of numbers and perhaps a decimal point. As exhibit 7 indicates, all packages support data-type checks.

A reasonableness check is a useful control for some quantitative fields such as unit price and transaction amounts. The simplest reasonableness limit for quantitative values entered is a minimum of zero for many fields, thereby precluding the entry of negative numbers. For wage rates one might use both a minimum and a maximum. Great Plains Dynamics, Progression, SBT Pro, Solomon and Visual Accounting support reasonableness limits.

The quality of both account identifiers and values can be further enhanced by use of batch controls--batch totals and hash totals. Before data entry, the user can batch data that has been captured off-line and total both the account identifiers and the associated values. Identifier sums are known as hash totals and value totals are called batch totals. If the accounting software accumulates similar totals as data entry occurs or permits batch printouts with such totals, the processed data totals can be compared with the previously obtained totals. All except Traverse supported batch totals, but none supported hash totals.

In exhibit 1 we noted that most packages supported batch posting of transactions in all except the inventory module. A principal advantage to batch posting is that it makes it possible to find and correct journalized transactions before posting. Since batch and hash totals are a principal method of detecting such errors, their omission negates much of the potential benefit of using batch posting.

The ability to record transactions in the current period for either past or future periods is useful. But this ability, in the absence of controls, also is dangerous. All packages support out-of-period entries, but MAS 90 and Traverse provide no administrator controls.

* Processing controls--in which accounting tasks must be performed in the proper order--are necessary if an organization is to obtain reliable outputs. Manual systems control the sequence of operations by notations on the accounting records and by checklists. Ideally, computerized systems maintain "electronic checklists" that guide users in the proper sequence of operations. While there are many such sequencing rules, we asked four questions to assess the use of these controls in the packages studied. In each case, we asked whether it's possible to perform a specified task before another task that would logically precede it. The possible answers for processing controls in exhibit 8, were yes, no and warning (which means yes, but not before providing a warning).
Exhibit 8: Processing and Output Controls

 General ledger: General ledger:
 Can the financial Can the books
 statements be be closed when
 printed when the financial
Accounting there are statements
software unposted have not
product transactions? been printed?

ACCPAC Yes Yes

Great Plains Dynamics Yes Yes

Impact Encore Yes Yes

MAS 90 No No

Progression Yes Yes

SBT Pro Yes Yes

Solomon Yes Warning

Traverse Yes No

Visual Accounting Yes Warning

 General ledger: Accounts
 Can the books receivable:
 be closed Can the books
 when journals be closed when
Accounting and ledgers journals and
software have not ledgers have not
product been printed? been printed?

ACCPAC No Yes

Great Plains Dynamics Warning Yes

Impact Encore Yes No

MAS 90 Yes No

Progression Yes Yes

SBT Pro Yes Warning

Solomon Yes Yes

Traverse No Warning

Visual Accounting Warning Warning

Accounting Are date Are time
software stamps on stamps on
product printouts? printouts?

ACCPAC Yes Yes

Great Plains Dynamics Yes Yes

Impact Encore Yes Yes

MAS 90 Yes Yes

Progression Yes Yes

SBT Pro Yes Yes

Solomon Yes Yes

Traverse Yes Yes

Visual Accounting Yes Yes


Note that all our questions relate to omitting a print job. In some instances, we prefer that users be able to skip certain printouts if a prior warning is given. With the easy, reliable backup systems available today, companies from the smallest to the largest may prefer to maintain information in electronic form and to make hard copy only when necessary. Electronic archiving is far superior to hard copy not only because access is easier and cheaper, but it's easier to store duplicates in alternate locations for security. Nevertheless, we believe that warnings should always be provided as a minimum.

To our surprise all packages except MAS 90 permit printing of financial statements even when unposted transactions exist. In our earlier study, both Progression and Solomon provided a warning, but no longer. However, Visual Accounting prints a warning on the statement that there are unposted transactions and SBT Pro identifies the last batch posted. All except MAS 90, Solomon, Traverse and Visual Accounting permit closing the general ledger with no warning even though financial statements have not been printed. ACCPAC and Traverse prohibit closing the books until journals and ledgers have been printed, while Great Plains Dynamics and Visual Accounting provide a warning before allowing the closing.

To find out about the use of processing sequence controls in other modules, we asked about closing the receivables module without printing the journals and ledgers. Although some of the respondents only produced partial journals and ledgers in receivables modules, we accepted that as if adequate records could be obtained. On these issues performance ratings improved considerably. Five of the packages either prohibited the action or gave a warning.

The increasing availability of economical electronic storage partially mitigates our concern for a lack of processing controls. All packages except Traverse have the ability to store transaction data for multiple years (see exhibit 2). Consequently, they can print prior-year data for several years after the fact. Note that Traverse has better controls than the other packages. This is particularly important since Traverse stores data only for a single year.

* Output controls were assessed for this study by determining whether the packages included date/time stamps on the hard copy. The date/time stamps indicate when printing occurred and may thus suggest what data are included. We believe the date/time stamps are economical and useful controls and, as indicated in exhibit 8, they're in all the packages studied.

* Controls over changes to accounts are vital for accounting software. Password and input controls may be effective for transactions entered, but they do not protect nontransaction data stored in ledger master files. An effective control provides a chronological log of changes for each master file. These include general ledger, receivables, payables, inventory, payroll and any other modules for which master files exist. The sales and PO modules contain only even files representing unconsummated transactions and thus need no log. Master file changes such as budget revisions, customer address changes and inventory supplier authorizations should be recorded in chronological logs (one for each master file) that show the changes, when they were made and who made them.

Exhibit 9, shows that only MAS 90, SBT Pro and Visual Accounting provide master file activity logs for all of the four modules considered. Progression supports the logs for all of the "subsidiary" modules--receivables, payables and inventory. ACCPAC, Great Plains Dynamics, Impact Encore, Solomon and Traverse maintain no listing of master file changes, although Solomon does maintain master file histories by each master file record.
Exhibit 9: How Nontransaction Changes to Master File Are Monitored

Is there a log of direct changes to the master file for

Accounting software general accounts accounts
product ledger? receivable? payable? inventory?

ACCPAC No No No No

Great Plains Dynamics No No No No

Impact Encore No No No No

MAS 90 Yes Yes Yes Yes

Progression No Yes Yes Yes

SBT Pro Yes Yes Yes Yes

Solomon History History History History

Traverse No No No No

Visual Accounting Yes Yes Yes Yes

 Does the dog
 contains the
 ID of the
Accounting software person making Log
product the change? medium

ACCPAC NA NA

Great Plains Dynamics NA NA

Impact Encore NA NA

MAS 90 Yes Paper or electronic

Progression No Paper or electronic

SBT Pro Yes Paper or electronic

Solomon NA NA

Traverse NA NA

Visual Accounting Yes Paper or electronic


Logs maintained by MAS 90, SBT Pro and Visual Accounting capture the ID of the person making the change-an essential if the log is to be effective. Logs are more convenient to access if users can view them both on the screen and as hard copy. MAS 90, Progression, SBT Pro and Visual Accounting support both.

REPORTING CAPABILITIES

Previously, when we examined reporting abilities of DOS accounting software, some of the packages included third-party proprietary general-purpose report writers. With the move to Windows, we discovered that most of the vendors have done the same. They took that route because they would find it difficult to match those third-party capabilities. These powerful reporting tools generally permit users to extract data from all modules, to manipulate data and to display data in many formats. Exhibit 10, shows the third-party reporting tools distributed with each accounting package or available as an option.
Exhibit 10: Third-Party Reporting Tools and Drill-Down

 Are on-screen
 drill-down
 Third-party reporting capabilities
 tools provided: supported?

ACCPAC Crystal Reports, BRIO Query
 Report and Analysis Report
 Master for Windows,
 Viewmaster for Windows,
 Unisoft Yes

Great Plains Dynamics Crystal Reports, FRx Yes

Impact Encore Crystal Reports Yes

MAS 90 Crystal Reports, FRx, F9 Yes

Progression Crystal Reports, FRx, F9, ERS Yes

SBT Pro F9 Yes

Solomon Crystal Reports, FRx Yes

Traverse Crystal Reports No

Visual Accounting F9, ViewMix, FRx, Crystal Yes
 Reports, R&R


A powerful general reporting capability that many accounting programs now use is "drill-down": the ability to begin, say, with the view of an account balance, then to drill down to the account details and, then, after selecting an Item in, the account, to drill down even further to the underlying journal entry and, in some instances, to an on-line image of a transaction document. Exhibit 10 shows that all the packages except Traverse can perform some type of drill-down.

* General ledger reporting is provided in most packages. However, ACCPAC, Impact Encore and Solomon include no general ledger reports but, instead, include third-party reporting tools and rely on the reseller or the customer to develop those reports. Given the flexibility and power of these tools, one might conclude that end-users are probably well served. But we have some doubts. Given that the accounting software developers usually have more accounting knowledge than their product resellers and users, there is little reason to believe the latter will develop better reporting capabilities than can the developers. Inclusion by developers of example reports with sample data can provide valuable guidance to the resellers and users.

Reports generated by other modules, unlike general ledger reports, have a relatively standard format and usually are included in the packages. Therefore, we don't believe that the omission of general ledger reports is critical.

In our earlier study, none of these packages presented a correct cash flow statement although most claimed to do so. The same pattern is repeated here. The first column of exhibit 11, shows how the vendors responded when we asked if their products produced a cash flow statement. However, when we examined the cash flow statements for all those claiming to produce them, we found deficiencies in all. In every case except Visual Accounting, the developers indicated that decreases in fixed-asset accounts from dispositions were netted against increases for asset acquisitions--an incorrect practice. Visual Accounting was able to show increases and decreases or the net change in fixed assets. We then asked the vendors to show how their products produced the actual cash flow with the disposition of a fixed asset at a gain or loss. None could.
Exhibit 11: General Ledger Reporting

 If it is
 available, Is the
 does it cash flow
 Is a show net statement
 cash flow changes available
 statement or detail (our
 available? changes? evaluation)?

ACCPAC N/A N/A N/A

Great Plains Yes Net No
Dynamics

Impact Encore N/A N/A N/A

MAS 90 Yes Net No Monthly/
 quarterly

Progression Yes Net No

SBT Pro Yes Net No Monthly

Solomon N/A N/A N/A N/A

Traverse Yes Net No

Visual Yes Net/detail No
Accounting

 Do financial Do financial Do
 statements statements financial
 compare compare statements
 this period this period compare
 with the with the current
 immediate same period period actual
 prior period? last year? with budget?

ACCPAC N/A N/A N/A

Great Plains Monthly/ Monthly/ Monthly/
Dynamics quarterly quarterly quarterly/yearly

Impact Encore N/A N/A N/A

MAS 90 Yes Monthly/ Monthly/ Monthly/
 quarterly yearly yearly

Progression Monthly/ Monthly/ Monthly/
 quarterly quarterly quarterly/yearly

SBT Pro Yes Monthly Monthly Monthly/yearly

Solomon N/A N/A N/A N/A

Traverse Monthly/ Monthly/ Monthly/
 quarterly quarterly quarterly/yearly

Visual Monthly/ Monthly/ Monthly/
Accounting quarterly quarterly quarterly/yearly

 Do Do
 financial financial
 statements statements
 include include
 horizontal vertical
 analysis? analysis?

ACCPAC N/A N/A

Great Plains Dynamics Yes No

Impact Encore N/A N/A

MAS 90 Yes Yes

Progression Yes Yes

SBT Pro Yes Yes

Solomon N/A N/A

Traverse No Yes

Visual Accounting No Yes


The remainder of exhibit 11 treats comparative and analytical financial statements. All of those providing financial statements enabled some comparisons between actual and either budget or prior-period actual. However, only MAS 90, Progression and SBT Pro provide both horizontal and vertical analysis of financial statements.

To enhance understanding of financial data, some packages include ratio reports (exhibit 12). Of course, those not generating financial statements could not produce such reports. In rating each product's ability to generate ratio reports, we used as a standard those listed in Industry Norms and Key Business Ratios, published by Dun & Bradstreet Information Services. While we did not expect every ratio to be included in reports, we thought each program should include some in each of the three basic ratio categories: solvency, efficiency and profitability. Information content of the ratios is emphasized rather than the precise format. While no package excelled in ratio coverage, both Progression and SBT Pro calculated 9 of the 15 and those were well distributed among the three ratio categories.
Exhibit 12: Can the Software Produce Ratio Reports?

 Liquidity Ratios Current
 Quick Current liabilities
 ratio ratio to net worth
ACCPAC N/A N/A N/A

Great Plains Dynamics No No No

Impact Encore N/A N/A N/A

MAS 90 Yes Yes No

Progression Yes Yes No

SBT Pro Yes Yes No

Solomon N/A N/A N/A

Traverse Yes Yes No

Visual Accounting No Yes No

 Current Total Fixed
 liabilities liabilities assets
 investment to net worth net worth
ACCPAC N/A N/A N/A

Great Plains Dynamics No No No

Impact Encore N/A N/A N/A

MAS 90 No Yes No

Progression No No No

SBT Pro No Yes No

Solomon N/A N/A N/A

Traverse No No No

Visual Accounting No Yes No

 Efficiency Ratios
 Collection Sales to Sales
 period accounts to
 (days) receivable inventory
ACCPAC N/A N/A N/A

Great Plains Dynamics No No No

Impact Encore N/A N/A N/A

MAS 90 Yes No Yes

Progression Yes Yes Yes

SBT Pro Yes No Yes

Solomon N/A N/A N/A

Traverse No No Yes

Visual Accounting Yes No Yes

 Assets Sales to Accounts
 to net working payable
 sales capital to sales
ACCPAC N/A N/A N/A

Great Plains Dynamics No No No

Impact Encore N/A N/A N/A

MAS 90 No No No

Progression Yes No No

SBT Pro Yes No No

Solomon N/A N/A N/A

Traverse No No No

Visual Accounting Yes No No

 Profitability Ratios
 Return Return Return
 on on on
 sales assets net worth
ACCPAC N/A N/A N/A

Great Plains Dynamics No No No

Impact Encore N/A N/A N/A

MAS 90 Yes Yes No

Progression Yes Yes Yes

SBT Pro Yes Yes Yes

Solomon N/A N/A N/A

Traverse No Yes Yes

Visual Accounting Yes No Yes


* Revenue process reporting, which involves the sales order and accounts receivable modules, provides information on customer orders and on cash collection activities. The first two columns in exhibit 13, at left, show the availability of aging schedules by customer and by invoice. While all packages provide a customer aging, only ACCPAC, Impact Encore, MAS 90, SBT Pro and Solomon can perform an aging by invoice. Omission of this feature is a major defect.
Exhibit 13: Revenue Process Reporting

 Can the software
 produce an aging can the records to
 schedule of be included in
 accounts receivable reports
 by be
 invoice based on
 by (open item account
 customer assumed balances?
ACCPAC Yes Yes Yes

Great Plains Dynamics Yes No No

Impact Encore Yes Yes No

MAS 90 Yes Yes No

Progression Yes No Some

SBT Pro Yes Yes Some

Solomon Yes Yes Yes

Traverse Yes No No

Visual Accounting Yes No Yes

 can the records to
 be included in
 reports
 be based on be
 the difference selected
 between account by a date
 balances and or a range
 budget amount? of dates?
ACCPAC Yes Yes

Great Plains Dynamics No Yes

Impact Encore No Some

MAS 90 No Some

Progression No Some

SBT Pro No Some

Solomon No Yes

Traverse No Yes

Visual Accounting Yes Yes

 Is there a report
 comparing discounts
 offered to discounts taken

 in total
 for the by by
 period? customers? invoice
ACCPAC No No No

Great Plains Dynamics No No No

Impact Encore No No No

MAS 90 No No No

Progression No No No

SBT Pro No No No

Solomon No No No

Traverse No No No

Visual Accounting Yes Yes Yes

 Can a Can a Can a
 projected report of report of
 cash receipts sales by gross profit
 report be customer by customer
 produced? be produced be produced?
ACCPAC No Yes No

Great Plains Dynamics Yes Yes Yes

Impact Encore No Yes Yes

MAS 90 Yes Yes Yes

Progression Yes Yes Yes

SBT Pro Yes Yes No

Solomon Yes Yes Yes

Traverse Yes Yes Yes

Visual Accounting Yes Yes No


The next three columns relate to receivables reports and indicate the degree to which exception reporting is supported. Note that of those packages providing an aging by invoice, only ACCPAC and Solomon can select records for inclusion based on balances; thus they can exclude customer accounts having a trivial balance. Progression and SBT Pro can select in some reports, but not all. In such cases, the selection capability is not customizable and usually is restricted to only a few reports. Only ACCPAC and Visual Accounting can select records based on differences between account balances and budget amounts. This ability is the mark of true performance reporting, since such a report should include only accounts requiring management attention.

Performance is better for selection of accounts based on dates. ACCPAC, Great Plains Dynamics, Solomon, Traverse and Visual Accounting do that.

Visual Accounting is the only package that supports an ability to monitor cash discounts taken; it does the job very effectively by providing reports in total, by customer and by invoice. All the packages except ACCPAC and Impact Encore can project cash flow from receivables.

Reports of sales and gross profit by customer are required to determine which customers are the best. All of the packages provide a sales-by-customer report. Of course, gross profit by customer is a more critical measure, and ACCPAC, SBT Pro and Visual Accounting fall to provide it.

* Purchasing process reporting, which includes PO and accounts payable modules, has as its purpose the effective management of purchasing activities and of trade debt. A report used to monitor whether cash discounts are available is an essential requirement for this task. Since the conventional credit terms of 1/10, net/30 represent an effective annual interest rate of about 18%, only under unusual circumstances should discounts be forfeited. But as exhibit 14, shows, only one package in this survey--Visual Accounting--can provide complete reporting. Four programs, MAS 90, SBT Pro, Traverse and Visual Accounting, provide a report of total discounts lost for a fiscal period. MAS 90, Progression, SBT Pro and Visual Accounting show discounts lost for each vendor. And only Visual Accounting provides a report of the discounts lost on the invoice level.
Exhibit 14: Purchasing Process Reporting
Can one obtain a report of discounts offered and lost

 in total for by by
 the period? vendor? invoice?

ACCPAC No No No

Great Plains Dynamics No No No

Impact Encore No No No

MAS 90 Yes Yes Yes

Progression No Yes No

SBT Pro Yes Yes No

Solomon No No No

Traverse Yes No No

Visual Accounting Yes Yes Yes

 Can one obtain reports by vendor for

 late returns account
 shipments? and allowances? balances?

ACCPAC No No No

Great Plains Dynamics No No No

Impact Encore Yes Yes No

MAS 90 Yes No No

Progression No No No

SBT Pro Yes Yes No

Solomon Yes No Yes

Traverse No No No

Visual Accounting Yes Yes Yes

 Can an Can a report Can a report
 inventory report on inventory on inventory
 on returns and items' sales items' gross
 allowances be generated? profit be
 be generated? generated?

ACCPAC Yes Yes Yes

Great Plains No Yes No
 Dynamics

Impact Encore No Yes Yes

MAS 90 Yes Yes Yes

Progression Yes Yes Yes

SBT Pro No Yes No

Solomon No Yes Yes

Traverse No Yes Yes

Visual Accounting Yes Yes Yes


The ability to evaluate vendor performance is critical to effective supply-chain management. We selected two reports as indicators of the overall performance ability of the packages: late shipments by vendor and returns and allowances. Five of the packages--Impact Encore, MAS 90, SBT Pro, Solomon and Visual Accounting--could produce a late shipment report. Of them, Impact Encore, SBT Pro and Visual Accounting could produce a returns and allowances report.

The ability of the packages to do exception reporting, based on account balances or differences between balances and budget, is somewhat poorer than in the case of receivables. Solomon and Visual Accounting do reports based on balances, and only Visual Accounting can select based on differences. All the packages except ACCPAC, MAS 90 and SBT Pro can select by date. And all the packages provide a report of projected cash requirements for trade obligations.

INVENTORY REPORTING

Realizing that assessment of manufacturing inventory management was beyond the scope of this review, we assumed a retailer and wholesaler environment in selecting inventory reports for consideration.

An order recommendations report can be used to ensure an adequate stock of merchandise. Only ACCPAC falls to provide such a report (exhibit 15). Some vendors call an order recommendations report an inventory report. The report usually calculates whether an order should be placed and for how much. Thus, we asked if an order quantity was suggested, and all reports did.
Exhibit 15: Inventory Reporting

 Is the order
 quantity
 Does the order suggested
 Can an order recommendation on the order
 recommendation report suggest recommendation
 report be the order report equal to an
 generated? quantity? EOQ formula?

ACCPAC No N/A N/A
Great Plains
 Dynamics Yes Yes Yes
Impact Encore Yes Yes Yes
MAS 90 Yes Yes Yes
Progression Yes Yes Yes
SBT Pro Yes Yes No
Solomon Yes Yes Yes
Traverse Yes Yes Yes
Visual
 Accounting Yes Yes Yes

 Can a report of Can a report
 available and of inventory
 on-order Can a report turnover
 inventory (with of excess by inventory
 arrival dates) inventory be item be
 be generated? generated generated?

ACCPAC No Yes Yes
Great Plains
 Dynamics No No Yes
Impact Encore Yes Yes Yes
MAS 90 Yes Yes Yes
Progression Yes Yes Yes
SBT Pro Yes No No
Solomon No Yes No
Traverse Yes Yes Yes
Visual
 Accounting Yes Yes Yes

 Can reports to be included
 in reports be based on

 Can a report of
 difference between date projected cash
 account balances or range requirements
 and budget amount? of dates? be produced?

ACCPAC No N/A Yes
Great Plains
 Dynamics No Yes Yes
Impact Encore No Yes Yes
MAS 90 No No Yes
Progression No Yes Yes
SBT Pro No No Yes
Solomon No Yes Yes
Traverse No Yes Yes
Visual
 Accounting Yes Yes Yes


Not only must management place orders in a timely way but it also must monitor the status of inventory and POs outstanding. All except ACCPAC, Great Plains Dynamics and SBT Pro support such reporting.

Another vital report tells when stock on hand exceeds the maximum stocking level. All except Great Plains Dynamics and Progression have such a report.

Obsolete inventory is indicated by low inventory turnover. Progression, SBT Pro and Solomon do not provide such a report.

Good business managers always investigate inventory items that are returned frequently or that generate many requests for allowances. Consequently, we asked if one or more reports are available showing that information. Four of the nine packages--ACCPAC, MAS 90, Progression and Visual Accounting---supported such reporting.

When considering the revenue process, we had asked whether the packages could prepare reports on sales and gross profits by customers; now we posed the same questions for inventory items. Again, all packages report on sales by inventory item, but Great Plains Dynamics and SBT Pro lack reporting by gross profit.

PRACTICAL ADVICE

What we learned from this study--and we pass this on to wary shoppers-is that all claims about a product, especially if the function is critical to your business, should be checked out and confirmed carefully.

The selection of accounting software is a difficult and complex task. Each user has unique requirements. Consequently, we believe that if we cite a package for what we consider a technical shortcoming, that does not mean the product would not be effective for some users.

The bottom line: There is no simple way to assess a match between a software package and a company. If you're in the market for a new package, we suggest you first outline in detail the functions you need and the functions you would like to have. Only then should you use this review to check off the functions that are closest to your selections. We then suggest you contact the vendors and arrange to receive evaluation copies of the candidate products. At that point you should load some test data and vigorously test each software function that's important to you.

RELATED ARTICLE: When Is a Trial Balance a Ledger?

We believe that casual use of accounting terms is the greatest single handicap of accounting systems. To illustrate this, we retained the exact vendor responses in exhibit 4, even though we did not fully understand what was meant by all of them. We thought the table still provided ample evidence of poor audit trails in general. Moreover, by including the exact responses, you can understand how the lack of precision in terminology not only made our research difficult but also contributed to overall confusion in the design and use of accounting systems.

An example is the use of the conventional and/or date term trial balance. It's often used to refer to a ledger or a listing of transactions rather than to a simple listing of account balances. We believe that the terms used in accounting packages should be immediately understandable by most accountants.

RELATED ARTICLE: EXECUTIVE SUMMARY

* ACCOUNTING SOFTWARE developers are now focusing on the Windows platform; in fact, as an indication of how fast Windows technology is moving, Microsoft NT, not Windows 95, is becoming the platform of choice for accounting programs.

* THIS ANALYSIS OF PROGRAMS investigated audit trails, controls and reporting. The investigations revealed that some of the new Windows packages did more than their DOS counterparts.

* THE AUTHORS' EARLIER STUDY noted that some packages retained journal data only until they were posted. Many accounting applications had eliminated that shortcoming; in fact, all the systems in this review retained journals for a year or longer. In addition, they all assigned sequential transaction numbers for identification and printing a journal in transaction number order.

* SELECTING ACCOUNTING SOFTWARE is a difficult and complex task. For each user, the requirements are unique. Consequently, if a package has a technical shortcoming, according to the authors, it does not mean the product would not be effective for some users.

* ALL CLAIMS ABOUT A PRODUCT--especially if the function is critical to your business--should be checked out and confirmed carefully.

RELATED ARTICLE: How We Conducted This Analysis

Each vendor completed a 94-item questionnaire. Each also furnished us with evaluation copies of its software, with documentation and access to technical support, so we could install the software and validate selected questionnaire responses.

Sometimes getting a vendor to fill out and return a questionnaire took several follow-up calls. In addition, the responses often were incorrect or incomplete. We believe the poor responses resulted from several problems. In a few cases, we concede a question may have been ambiguous or hard to understand. In other cases, however, we thought the respondents did not give adequate attention to a question. For example, it appeared that some respondents worked on the assumption that a "yes" answer reflected well on their product. But several questions--particularly in the control section--asked whether one could perform a given operation when the ability to do so would reflect adversely on the package. In several instances, respondents answered "yes," but when we examined the product, we realized the answers were incorrect.

But the most serious problem we experienced was the lack of product knowledge by many of the vendors' sales representatives. We experienced this problem in our 1995 review, too. The most obvious example was when several respondents indicated that their products used check digits and/or encryption to ensure the accuracy and safety of data. But when we asked for details (such as the weights and modulus used for check digits and the bit-level of the encryption algorithm), it became apparent that not only did the products lack these functions but also the representatives were not familiar with the technology--yet they responded affirmatively anyway.

And as in our earlier study, often the respondents did not understand what constitutes an adequate journal and ledger.

As a practical matter, we could not confirm every claim by a vendor. Often, we had to rely on the consistency of answers, our knowledge of the subject and, frankly, our intuitive judgment. Given the complexity of accounting software, when a vendor said a feature was missing or there was a shortcoming in the software, we accepted the response--except when it was not credible or when we had knowledge otherwise. We usually confirmed affirmative answers by examining the software. If we were unable to verify an answer ourselves, we called the software company for further explanation. Finally, we visited with representatives of all except one vendor to review questionable answers. Since proving the absence of a feature is a formidable task, the assistance of company representatives was essential. In most cases, they were able to guide us to the solution and, in others, the vendor conceded that the information they had provided in the questionnaire was not correct.

RELATED ARTICLE: How to Contact the Vendors
Product Vendor Address
ACCPAC for Windows ACCPAC International 2525 Augustine Dr.,
 Santa Clara, CA
 95054
Great Plains Dynamics Great Plains Software 1701 Southwest 38th
 St., Fargo, ND
 58103
Impact Encore Syspro Impact Metro Pointe,
 Software 959 South Coast Dr.,
 Suite 100, Costa
 Mesa, CA 92626
MAS 90 for Windows State of the Art 56 Technology,
 Accounting Software Irvine, CA 92618
Progression Macola Software 333 East Center St.,
 P.O. Box 1824,
 Marion, OH 43302
SBT Pro Series SBT Corp. 1401 Los Gamos Dr.,
 San Rafael, CA 94903
Solomon IV for Windows Solomon Software 200 East Hardin St.,
 P.O. Box 414,
 Findlay, OH 45840
Traverse Open Systems 7626 Golden Triangle
 Dr., Eden Prairie,
 MN 55344
Visual Accounting RealWorld Corp. P.O. Box 9516,
for Windows 670 Commercial St.,
 Manchester, NH 03108

Product Phone Internet address
ACCPAC for Windows 800-773-5445 www.accpac.com

Great Plains Dynamics 800-456-0025 www.gps.com

Impact Encore 800-369-8649 www.impactsoft.com

MAS 90 for Windows 800-845-3415 www.sota.com

Progression 800-468-0834 www.macola.com

SBT Pro Series 800-944-1000 www.sbt.com

Solomon IV for Windows 800-4-SOLOMON www.solomon.com

Traverse 800-328-2276 www.osas.com

Visual Accounting 800-678-6336 www.realworld.com
for Windows


RELATED ARTICLE: Consistently Inconsistent

A phenomenon we observed repeatedly was the implementation of a concept in one place but its omission in other equally appropriate locations. For example, gross profit reporting by customer and by inventory item for each of the packages were compared as follows:
 Gross profit reported by: Consistent
Package Customer Product treatment?

ACCPAC No Yes No
Great Plains
 Dynamics Yes No No
Impact Encore Yes Yes Yes
MAS 90 Yes Yes Yes
Progression Yes Yes Yes
SBT Pro No No Yes
Solomon Yes Yes Yes
Traverse Yes Yes Yes
Visual Accounting No Yes No


This pattern was repeated countless times in most of the packages. We developed a consistency ratio based on the number of consistent applications of a concept to the number of inconsistent ones and called it the design consistency index. In the above case, the ratio is expressed as 6:3 since six packages were consistent and three were not.

Because in some respects the accounting for receivables and for payables are mirror images, one might,expect more consistency in the software design between the two. But it is not the case. The ability to select records by date in receivables (exhibit 13, column 5) and payables (exhibit 14, column 8) has a consistency ratio of 4:5. Thus four had consistent design and five did not.
Accounting Software Prices

 Single-user version

Package Version Cost

ACCPAC 3.0 $1,300 system
 manager + $1,300
 per module

Great Plains Dynamics 4.0 $1,000 system
 manager + $500-
 $1,000 per module

Impact Encore 3.2 $600 system
 manager + $600
 per module per module

MAS 90 3.2 $675 system
 manager + $1,300-
 $1,500 per module

Progression 7.0 $2,500 system
 manager + $1,150-
 $1,650 per module

SBI Pro N/A N/A

Solomon 2.06 $195 system
 manager + $695-
 $995 per module

Traverse N/A $395 system
 manager + $395
 per module

Visual Accounting 4.11 $795 system
 manager + $495
 per module

 Multiuser version
 Number
Package Cost of users

ACCPAC $1,500 system 10 users
 manager + $1,300
 per module

Great Plains Dynamics $3,000 system 4 users plus
 manager + $1,000-
 $2,000 per module

Impact Encore $1,000 system 4 users or
 manager + $1,000
 per module

MAS 90 $2,375 system 5 users
 manager +$1,300-
 $1,500 per module

Progression $2,500 system 5 users or
 manager + $1,250-
 $1,750 per module

SBI Pro $1,200 system 5 users or
 manager + $1,200
 per module

Solomon Scalable SQL: 3 users or
 $3,095 system
 manager + $1,395-
 $1,895 per module

Traverse $795 system 2 users plus
 manager +$795
 per module

Visual Accounting $1,495 system 3 users or
 manager + $895
 per module

 Number
Package Cost of users

ACCPAC

Great Plains Dynamics $1,000 per
 additional user

Impact Encore $1,400 system 8 users
 manager + $1,400

MAS 90

Progression $4,500 system 10 users
 manager +
 $1,350-$1850
 per module

SBI Pro $2,700 system 10 users
 manager + $1,200
 per module

Solomon MS SQL: $7,995 3 users
 system manager +
 $2,995-$4,995
 per module

Traverse $395 per
 additional user

Visual Accounting $1,995 system 5 users
 manager + $1,495
 per module


HARLEY M. COURTNEY, CPA, PhD, is a professor of accounting and director of the Center for Accounting Software Evaluation at the University of Texas, Arlington. CHERYL L. PRACHYL, CPA, PhD, is an assistant professor at the University of Texas, Arlington.
COPYRIGHT 1998 American Institute of CPA's
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1998, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Glandon, Terryann
Publication:Journal of Accountancy
Article Type:Product/Service Evaluation
Date:Mar 1, 1998
Words:10686
Previous Article:Making college more affordable: the education provisions of the Taxpayer Relief Act of 1997 can help.
Next Article:Talking with the auditor: new management representation rules give some options and also aim for consistency.
Topics:


Related Articles
How healthy is your insurer?
Scheduling & MRP: software buyers' guide.
Accounting software. (Technology Tools).
IREM publishes software survey.
Accounting, finance salaries stabilize.
PayMaxx.
Out of the Red.
TURNING IT OVER.

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters