Guide to Accounting Software

T he 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 cant 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 researchaudit trails, controls and reporting. For more on how we handled this review, see the sidebar, How We Conducted This Analysis, page 50. Our investigations revealed that some of the new Windows packages did more than their DOS counterparts, but in at least one caseMICAthe 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 studyABS Accountingsays its Windows version is still under development and is not yet available for testing. In another case, we eliminated Platinum Softwares productPlatinum for Windowsbecause, 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 on pages 52 and 55.

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 were 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 cant produce current information: Its 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 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).

Audit Trails

Accounting software should be able to provide an audit trailthat 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 listings (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.

In our earlier study, we complained that some packages 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 featureas 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, Macolas current Windows productProgressionpermits only a screen display of a single general ledger account.

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 missinga serious omission.

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 companys own check and invoice numbers are ideal for identifying cash payment and sales transactions, but other transactions lack such natural identifiers. For example, you cant use a companys 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.

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 vendors 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 dont 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 thats 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.

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 vendors 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, Progressions 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 cant 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 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 userswho cant be expected to remember several passwordsmust write them down. While some of the packages permitted task passwords as an addition to user passwords, their use was optional.

Password systems should require users to select hard-to-guess passwordsthose 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 changeshardly 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 systemwithout 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 didnt 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 wont recognize the difference and will 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 shows that code checks are used in all packages and the account title is displayed on the input screen.

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 digitsoften associated with heads-down data entryuse 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 controlsbatch 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 orderare 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 its 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).

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 its 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 , theyre 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 event 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 modulesreceivables, 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.

Logs maintained by MAS 90, SBT Pro and Visual Accounting capture the ID of the person making the changean 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.

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 dont 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 acquisitionsan 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.

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 products 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.

• 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.

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 fail 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 surveyVisual Accountingcan 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.

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 packagesImpact Encore, MAS 90, SBT Pro, Solomon and Visual Accountingcould 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 fails 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.

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 packagesACCPAC, MAS 90, Progression and Visual Accountingsupported 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 studyand we pass this on to wary shoppersis 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 youre 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 thats important to you.

Guide to Accounting Software

Guide to Accounting Software