Guide to Accounting Software
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 reporting by: | |
| Package | Customer | Product | Consistent 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.
©1999 AICPA
