Can your software make it into year 2000?

Getting ready for the next millennium.

While many different kinds of software are affected by the Year 2000 problem (Y2K), accounting applications are probably the most severely affected and also the hardest to bring into compliance. That's because accounting systems depend on many date-sensitive operations--from posting sales to inventory control, from accounts payable to receivables and from payroll to fixed-asset management.

Most accounting software vendors have been striving to make their applications Y2K-compliant. This article provides the results of a survey we conducted of the major accounting software vendors, detailing which versions are compliant, which aren't and how compliance was achieved.

But before reporting those findings, it's essential that readers understand the two basic ways compliance is engineered--the four-digit and the two-digit windowing solutions.

Caveat: The four-digit windowing solution requires that you not only fix the application software but you also must completely restructure the entire database and provide two new spaces for all the year-oriented information. It's not sufficient to fix just one and not the other. And while solutions for the applications and the data are related, the techniques are entirely different.

WHO DOES THE FIX?

Unless you or someone on your staff is both an expert programmer and experienced in the specific programming language of the software application, it's probably wise not to attempt to implement the fix in-house. As a practical matter, either you should contract out the fix (if you can find a programmer at this late date) or, more than likely, you should purchase new Y2K-compliant software.

Following are the basic ways to solve the problem:

* Four-digit solution: The most comprehensive--and expensive--solution is to convert all year-designated data from two to four digits (for example, 97 would be recast as 1997). In addition, a programmer must rewrite significant parts of the software application's code, expanding all the fields that define years from two to four digits. For many homegrown applications, that's going to be a major headache because a typical application has millions of lines of code, and for many legacy (old) programs the documentation has long been lost.

Even worse, many of those applications were written by unconventional, free-spirit programmers who frequently coded some of their work with funny labels--including the names of friends or pets--making the year-field search even more difficult.

* Two-digit window: The second solution is a relatively quick fix. Although it's less than perfect, it works well in most applications-especially when the date data stored by the application do not extend too many years into each century or when there's little doubt whether a year should be 19xx or 20xx. In the two-digit solution, a user continues to use two digits in both the application and the data. However, a special program must be added that converts two-digit years into four-digit years.

How, you may ask, can the computer know whether 97 is 1997 or 2097?

The answer: You've got to give it a hint. And therein lies both the windowing solution's economy and potential imperfection. For the technique to work, a user must first select what's called a pivot point--a number at which the computer slots a two-digit date into either the 20th or the 21st century. (Technically, the year 20(10 is still in the 20th century, but to simplify the explanation we're taking the liberty, as are so many others, of referring to the year 2000 as the 21st century.)

For example, if 46 is taken as a pivot point, any two-digit date below 46 is assumed by the program to be 20xx; any number 46 or higher is assumed to be 19xx. So, although the dates in the database are still formatted and stored as two digits, when a date calculation is required, the program converts the two-digit year to four digits as follows:

For year values entered:       Two digits to be placed in
                                 front of the entered values:
Larger than 45               =   19xx
Less than 46                 =   20xx

Therefore, the year 92 will be interpreted as 1992 and 43 as 2043. The windowing solution can be made to "move" by adding one year to the values in the first column above at the end of each year. After 55 years, one year must be added to the second column values since the 21 st century will be approaching and dates in the 20th century (1900s) will no longer be supported.

Some developers using a two-digit windowing solution are nevertheless storing data as four-digit years--usually because some of their data stretch far into both centuries and a windowing program just won't work. Thus, when entering data about a fixed asset acquired in 1997, the date may be entered as 05723797; however, the computer will store the data as 05231997; and an acquisition acquired in 2001 may be entered as 05/23/01 and stored as 05232001.

* A mix of the two: Another possibility is to use a mixture of the above methods. It's more precise than the windowing solution and cheaper and easier to implement than the four-digit solution. A four-digit solution can be used when required and a two-digit method can be used in all other cases. For the typical company, the fixed-asset and shareholder ledgers may be the only must-use four-digit applications.

RELATIVE MERITS

Without question, the four-digit solution provides a higher level of accuracy than any other method--but at a hefty price. For the four-digit solution it's not enough to just fix the software: Every field of its database must be scrutinized and converted to a four-digit year and all changes must be made to both the data and the program or the data will be corrupted.

The biggest single advantage of the two-digit windowing solution is that no conversion--either of the application or the database--is required. Date input is still two digits for the year and storage continues in two digits.

An enormous problem in conversion to a four-digit database (with either four- or two-digit input) is that the entire enterprise information system and all data files must be converted and tested before the system can go online. After all program changes are made and tested, the changeover must be done in one step; as a result, this conversion method is called the "big bang" approach. To accomplish this, the entire program must first be halted, data files through the halt date must be converted and then the new software installed. With the two-digit method, in which two-digit databases are retained, conversion can be done gradually, with the individual programs being updated, tested and placed in production alongside yet-to-be-converted programs.

An expensive, albeit sometimes necessary, alternative to a big bang conversion is to convert each application or module, such as payroll or general ledger, individually--what amounts to a series of little bangs. The downside to this is that new, temporary programs must be developed that stand between old and new applications and that convert the data from two digits to four digits or vice-versa.

As shown in the exhibit on pages 38-39, a few accounting software packages give the input operator a choice of two- or four-digit years. In some cases, the database interprets the input and stores a four-digit year, while in others two digits are stored and reinterpreted when retrieved later.

For many accounting software vendors, the Y2K problem is a bonanza. Organizations with noncompliant applications have to make a choice: Should they keep their current software and reprogram it to be compliant, or would it be more cost-effective to dump it and buy a new, already compliant package?

An increasing number of enterprises have decided to take the new software route. Many have concluded that not only does this solve part of the problem but they will also end up with a new, more current and probably more powerful application. Evidence for this shift comes from a recent Deloitte & Touche study of 400 large companies, which found that 89% planned to select new packaged software during 1997 and 1998; that compares with 81% planning to buy new accounting software in 1995.

We sent a questionnaire to the major vendors of accounting software asking whether their packages are Y2K-compliant and, if they are, how they achieved it. Some failed to respond to our initial inquiry, and so we followed up two, and in some cases three, times. Eventually, a total of 35 vendors (representing 70 packages) responded. However, 5 vendors did not, and while failure to respond is hardly proof that a vendor's products aren't compliant, it does raise some doubt and their customers would be wise to press for that information. All the vendors--those responding and those that did not--are listed in the table.

Intuit, which declined to fill out the questionnaire, instead wrote us that QuickBooks currently can handle dates up to 2027. However, the vendor refused to say when that feature was incorporated into the package now being shipped. Therefore, users of versions of QuickBooks acquired before August 1997 cannot be assured of Y2K-compliance.

TWO VS. FOUR

Although we did not ask for it, some vendors using a two-digit solution attached explanations to their responses that said their products were designed to handle four digits but also permit two-digit entry. And some said their software required four-digit input for some information--such as fixed-asset acquisition dates--but only two digits for high-volume data such as sale and purchase transactions. Those details were not included in the table because that information came in too late to revise the questionnaire. It would be prudent for all users to contact their vendors for more information about the solution engineered for each module.

To be sure, the four-digit solution is the most popular: It's used in 36 packages, compared with 20 that used the two-digit method. Storage cost is no longer a relevant factor and clearly data-entry efficiency (typing in two rather than four digits) apparently is no longer viewed as a significant problem. Note, too, that some vendors said they planned to make their products compliant but offered no firm dates for completion.

It is somewhat surprising that two recently introduced products--Business Vision 2000 (released in 1996) and Platinum for Windows (released in 1995)--are not already compliant, although the vendors say solutions are being planned.

The table includes only products that are currently being sold. However, our questionnaire had asked vendors to include all their accounting packages sold since 1980, even for the discontinued products. None did so. Such a disclosure would have alerted those using discontinued products to whether they are likely to encounter problems. For safety, we suggest that, unless a vendor reports otherwise, users assume products are not compliant.

When seeking information about a discontinued product, be sure you have the exact name and version of the product because some vendors often market new packages with similar names, which can create confusion.

All of the respondents--even those whose products were not compliant--indicated that their programs recognized 2000 as a leap year.

The Y2K problem is real. But that doesn't mean you should assume either a Chicken Little or an ostrich stance in addressing it. Rather, you should promptly assess the extent of the problem, both internally and externally. Time is quite short for remedying internally developed software solutions in many organizations. Some companies have acknowledged already that timely completion of the task is impossible, and they plan expensive ad hoc solutions to resolve the problem properly. Fortunately, the increased availability of industry-specific or industry-adaptable packaged accounting software means that for most organizations a deliberative solution approach is still possible if they take steps immediately.

[TABULAR DATA NOT REPRODUCIBLE IN ASCII]

RELATED ARTICLE: Test for Compliance

All accounting software packages--even those that claim compliance--should be tested to be sure they can handle the next century years correctly Even if your organization lacks the training or facilities to fully test for compliance, here are some simple steps to take:

1. Using a backup copy of data files, perform several operations involving dates such as

* Set your system clock to December 31, 1999, and the time at 11:58 RM., and observe the results.

* Input transactions using various dates beyond 12/31/99, watching for error messages.

* Add master file records with a new century date (for a new employee, say).

* After entering a sale on or beyond January 1, 2000, for an active customer having some outstanding items before that date, perform an aging of that customer's account and observe the results for accuracy in aging.

* If your software sorts the contents of reports based on dates, enter a transaction in the new century and then print the report, observing the correctness of the date sort. Some vendors said their software was fully compliant except for reports that sorted on dates.

If the software does not pass the above tests, contact your supplier for an update or new software that solves the problem.

2. Obtain written assurance from the software developer that your version is compliant. Even if your software passes all of the tests attempted under item 1, do not assume that it is fully Y2K-compliant.

3. Do not expect perfection in the software, but do expect your vendor to remedy any problems consistent with the support agreement to which you subscribed. If you do not have a support agreement and your accounting system is vital to business operations, secure one.

HARLEY M. COURTNEY, CPA, PhD, is a professor of accounting and director of the Center for Accounting Software Evaluation (CASE) at the University of Texas at Arlington. He is a member of the American Institute of CPAs. DANIEL C. BENCO is a PhD candidate at the university.