In-Depth

The Year 2000 ... What Lies Beyond

• 11/01/1998

Call it what you will "The Year 2000 Problem," "The Millennium Bug," "The Y2K Crisis," the label that you attach to it is not nearly as important as the realization that the problem is real. The problem is pervasive, and almost without exception, the problem will affect everyone. Modern man has historically counted on only two absolute truths: death and taxes. However, to that list a third can now be added: the Year 2000 challenge.

Over the last four decades, IT has established date storage in both hardware and software as a two-digit number. (For example, 1997 was stored as 97) Two digits were used to save both time and money. Many of the early systems were planned to be replaced. However, the replacement systems continued to use two digits, which became the de facto standard. Until recently, few systems were affected by these decisions. As the Year 2000 draws closer, the move from the number 99 to 00 will result in failures that must be addressed.

Software and hardware may fail to operate, generate erroneous calculations or present information in an unusable form. For example, humans recognize 97 as 1997 and 00 as 2000. However, computers recognize 97 as a two-digit number and 00 as a two-digit number. Thus, 00 minus 97 is three years to humans and -97, 97 or an unknown answer in a computer program. In some cases, 00 may be interpreted as 1900 and processed incorrectly. Therefore, all instances where dates are used must be found and fixed if necessary. There are many ways to fix this; the challenge is to find all the dates and ensure they are fixed. After all,the changes are made, they must be tested and implemented.

A second problem is that the values 99, 98 and even 97 were sometimes used for special processing purposes. For example, 99 was often used to signal the end of input data. Therefore, when the real 1999 data needs to be processed, it will signal "end of input" and no 99 data will be processed. This problem must be fixed by January 1, 1999.

This concept of an "event horizon" means the problem needs to be addressed some time before some date, in this case before January 1, 2000, occurs. Systems store future dates for things, such as expiration or renewal dates. For example, in 1995 some car licenses were renewed until 2000. Credit cards, batteries and pharmaceuticals are all items that expire as much as two, three or four years in the future. Therefore these systems need to be fixed by 1998.

Another problem is the representation of information. For example, it is obvious that a mortgage expiring on 97/06/30 or 30/06/97 expires on June 30, 1997. However, it is difficult to predict the expiration of one dated 01/02/03. Similarly, when data is sorted in date sequence, 00 is a lower number than 99 and will be at a bottom of a list rather than at the top.

The final issue is how systems process leap years. The Year 2000 is a leap year. There are three rules for determining if a year is a leap year. If the year is divisible by 4 it is a leap year unless it is divisible by 100, in which case it is not. Therefore, 1800 and 1900 were not leap years. But if the year is divisible by 400 then it is a leap year. The Year 2000 is a leap year. Unfortunately, some systems were not programmed to include this third rule and, consequently, there will be errors concerning February 29, 2000.

Experience has shown that an individual’s viewpoint concerning the Year 2000 problem moves through several stages. The first stage is naiveté. They simply fail to understand the scope and size of the problem. This happens to non-technology and technology people alike. For example, some people claim, "We use PCs, so we are not affected." When they are shown that there are problems with PC BIOS, as well as with databases, spreadsheets and other applications, only then do they realize that they will have to deal with it.

Another simple example is, "The system is new, and we only use four-digit years to store information." In this case, when asked what is done with information received that was only two-digits, the answer will indicate that the program inserts a 19 in front of the two digits to create a four-digit year. When asked what happens when they get 00, they suddenly must re-evaluate their original position of being compliant.

The second phase is denial. As individuals begin to understand the problem, they feel that the problem is really not as big as it seems to be. There must be a "silver bullet" solution that will solve the problem quickly and inexpensively. They also feel that it is just a technology problem and that there really is not much business risk associated with it. As they learn more about the problem, they move to the next stage.

The next stage is the panic phase. They realize the problem is bigger and more all-encompassing than they realized. Now fear sets in. They also realize that other people have been working to address the Year 2000 issues within their respective organizations for years. They understand that the costs are real and, in fact, it is a "stay in business" issue. The panic comes from the thought that there is simply too much work to do in the time remaining.

The final stage is the realization that the changes are not impossible. If only one system required changing, it would be a non-event without much management involvement. Because there are no functional changes, much of the time-consuming debate between developers and users is eliminated. But this, more often than not, is one of the key sources of project failures. At this point, it is apparent that this is simply a very large project with many sub-projects that need to be coordinated. At this stage, people can begin planning the work. There is a date for every organization at which fixing everything becomes impossible; thereafter triage must be performed and even a rethinking of the fundamental premises of the business. Many are past this point already - focus is called for.

The scope of the Year 2000 problem is much larger than expected. In fact, as we learn more about the problem, we keep finding new layers of issues (see Figure 1). The much-maligned COBOL mainframe system may account for the greatest volume of code requiring date-conversions, but given the tools and consulting support, they are the easiest to correct. Client/server systems, meanwhile, are not completely compliant - and much harder to fix. Furthermore, end user software is fraught with problems. Just because Excel and Access are compliant does not mean that the applications using them will function. Date problems appear in a huge variety of non-IT systems and devices including environmental control units, factory printing and packaging machinery, process control equipment, video recorders, security and access control systems, civilian and military avionics, networks and telecommunications equipment, embedded computer chips, billing and collection services and even end products.

To minimize these problems, we must realize we are all dependent on each other; one company’s compliance is useless unless other companies remain viable. After all, business is not conducted in a vacuum. For example, credit cards cannot process transactions unless all links between merchants and banks are operating. A compliant assembly line cannot create products without supplies. We all depend on federal, state and local governments for an array of services. It’s a good bet that numerous local governments either don’t know about the problem or have not mobilized the resources required to alleviate the problem before the deadline.

The upside is that the Year 2000 is leading to greater cooperation between companies than ever before. The downside is that legal liability concerns are chilling the flow of information.

Not an IT Problem

Contrary to what many may believe, the Year 2000 is not an IT problem, but rather a business problem. Although the root of the problem is technical, procrastination has turned the century date change into a business concern. Fixing the Year 2000 problem without a deadline would be a large task, but would be classified as an everyday preventive maintenance activity. What differentiates the Year 2000 challenge from the "business as usual" is the irrevocable deadline. It is the first time IT has had to work on the same problem at the same time on a global basis. The volume of work to do is enormous. Many of the most critical issues, such as customer and supplier compliance, are outside the control of IT. Legal and audit concerns, resources and budget requirements, and the effects on merger and acquisition strategies have forced the Year 2000 issue into the domain of senior management. As the awareness grows, overall responsibility for corporate Year 2000 projects is shifting from IT to the business community.

Most organizations have a plan for deployment of new technology over the next several years to either improve operational efficiency or deliver a new function to serve customers and/or clients. As resources are deployed to fix this "stay in business" problem, some of the new initiatives will not be completed. This has a bottom-line impact to planned revenues and costs that must be understood and explained to shareholders.

When companies begin addressing their Year 2000 problems, one of the first things they want to know is how much it’s going to cost them. Rules of thumb for estimating cost are based on an organization’s total application inventory. If the estimate is based on function points, the average cost for software repairs is $512 per function point actually repaired, or $42 for every function point in the enterprise, depending on the industry. If the estimate is based on lines of code, the average cost is $1 to $2 per line of code, with a range from 75 cents to more than $7 per line. A third way to estimate is to estimate that the conversion will cost about 30 percent of the annual IT operating budget. The problem with all these estimation approaches is that all have high margins of error, because they are based on average costs. Furthermore, the enterprises using these formulas differ greatly, as do their applications.

The two most common methods for estimating Year 2000 costs use either number of lines of code or function points as the estimation metric; both approaches are based on the total size of the application inventory. While no one knows for certain what the total costs will be in one enterprise — let alone on a national or global basis — it may be useful to compare cost estimates (see Figure 2):

Comparison of Year 2000 Estimates $ in billions

Global Total $300 - 600 $530 $322 - 486

U.S. Total $200 $70 $136.4

U.S. Private

Sector n/a n/a $125.0*

U.S. Federal

Government $30 n/a $ 8.1

State

Governments n/a n/a $ 3.3

* Base amount does not include software purchases

Source: Software Magazine (10/97)

The Gartner Group estimates that the global cost of the Year 2000 fix will be $300 billion. The U.S. will pay about one-third of this total, with the Federal Government contributing $30 billion. The Gartner estimates are based on lines of code and include primarily software repairs. Caper Jones, Chairman of Software Productivity Research (SPR) Inc., bases his estimates on function points and arrives at a global software cost figure of $530 billion. His total Year 2000 global estimate of $1.3 trillion includes data, hardware, and other considerations, but excludes litigation. In a study based on data from the Society for Information Management (SIM) Year 2000 Working Group’s survey, it was found that Year 2000 costs are approximately 30 percent of an enterprise’s annual IT budget.

In addition, there will be hidden costs associated with solving the Year 2000 date problem that will not appear on balance sheets or in project budgets. Some examples include costs associated with not meeting the immutable deadline; costs for producing and mailing credit cards on a two-year cycle rather than every three or four years because cards expiring in the year "00" cannot currently be used with all card readers; costs for hiring a Year 2000 solution provider; and opportunity costs associated with changing or delaying strategic projects while the IS organization completes Year 2000 compliance projects.

Although true total costs will never be known; two things are certain: one or more of these estimates will be wrong; and the Year 2000 event is the largest and most expensive problem to ever confront the IT world.

In the Year 2000 software case, The Financial Accounting Standards Board (FASB) reached consensus on how such costs should be handled - in most cases, they should be expensed as they are incurred.

The FASB develops and publishes a body of accounting guidelines and requirements that are collectively referred to as "Generally Accepted Accounting Principles" (GAAP). When publishing certified financial statements, an enterprise must adhere to the GAAP or, with the concurrence of the enterprise’s certified public accountants, specifically identify all deviations to the GAAP and explain their impact on the enterprise’s financial statements. Because such explanations must typically be made to the board of directors, the shareholders (through the annual report for publicly owned companies), and various regulatory agencies and oversight bureaus, such as the Securities and Exchange Commission in the United States, generally frown upon deviations made to the GAAP and avoided when possible.

In some highly specific cases, the costs may be capitalized and amortized, but they are the exception. As a result of this ruling, enterprises will be more likely to replace affected applications with new software for which there is more accounting flexibility.

The Emerging Issues Task Force (EITF) of the FASB met on July 18, 1996, and concluded — after examining three alternative recommended accounting treatments — that internal and external costs specifically incurred in modifying software code so that it will accurately calculate dates for the Year 2000 must be charged to expense; such costs cannot be capitalized and amortized beyond the current fiscal year (Issue 96-14). The three positions that the EITF considered were:

Costs represent repair and maintenance expenses. This position argues that changes made to the software so that it will correctly calculate dates beyond 2000 are "not readily distinguishable from other types of repair and maintenance activities — the changes do not improve the software beyond the state in which it was originally intended to be used and do not do more than merely restore the software to its normal state." Because the costs represent "maintenance," they should be expensed in the current period. This position was selected for the case of modifying Year 2000 program errors.

Changes represent betterment or enhancement. By modifying the software to accommodate the Year 2000, the useful life of the software is extended and enhanced, and thus it should be capitalized. This position draws parallels to the allowable capitalization of certain environment-abatement and asbestos-removal costs and argues for capitalization of software modification costs.

Accounting consistency is the prime consideration. An enterprise should account for costs consistently with its established software capitalization and expense policy. Because there are no definitive accounting guidelines for internal software, enterprises have been required to interpret the available body of accounting practices, and the inevitable result is considerable variation in how enterprises report the costs.

Within the FASB published document, EITF 96-14, that discusses Year 2000 accounting issues, two additional points are worthy of special mention:

• The discussion and conclusion to charge costs to current-period expenses hinge on the point that the software changes merely restore full functionality to the software. If additional functionality is added during the Year 2000 overhaul, then an enterprise has the obligation to account for these costs consistent with its internal policy for reporting software costs and expenses.
• If an enterprise chooses not to modify the affected software and replace it with new software, either internally created or externally purchased, the costs would be accounted for consistently with the enterprise’s software accounting policies — they may be capitalized or expensed, depending on the policies established by the enterprise.

Formal recommendations from the American Institute of Certified Public Accountants entitled, "Accounting for Internal-Use Software," is expected to be issued before the end of 1997. To be reported as internal-use, software must not be marketed or sold to third parties. As a result, enterprises and the auditors who certify their financial statements are required to interpret the current body of accounting practices and derive a set of policies for each enterprise. As can be expected when different parties evaluate a large body of information, different conclusions will be reached. A survey of enterprises indicates a variety of accounting practices. Traditionally, many enterprises have expensed software licensing fees.

In the opinion delivered - that expense related to Year 2000 modifications should be charged to expense immediately — an apparent contradiction exists: expenses for software modifications that merely restore functionality should be expensed. However, if an enterprise chooses to replace the software altogether with a new internally created or externally purchased application, the enterprise is bound to report the expenditure consistently with owns policies — that is, if the enterprise selectively capitalizes software license fees and amortizes them over several years, it must do the same with the new application. As a result, it may be able to capitalize the expense and spread costs over multiple years, whether the work is done internally or by outside consultants.

In providing guidance on how certain costs must be reported, FASB has influenced the nature of the solution many enterprises choose to employ to address the issue. The requirement that costs associated with modifying internal-use software for Year 2000 compliance be expensed in the current fiscal period will skew the evaluation processes enterprises use when deciding to repair or replace applications vs. purchasing new applications. Through 2001, as software license, development and maintenance costs become a larger component of the total cost of ownership, financial executives will increasingly call upon IT professionals to provide input and justification to underpin the financial accounting process.

IT planners, faced with the continuing problem of how to pay for it all, now face a broader dilemma:

• Do they fix Year 2000 date problems and pay for all repairs by charging them immediately to expense?

• Do they simply replace the non-compliant software with new software, and then capitalize and spread expense over multiple years?

• Do they increase the scope of Year 2000 repairs, add significantly new functionality, and view the project as a complete overhaul that may qualify for multi-year accounting treatment?

Gartner Group research findings show that when enterprises decide to redesign an application, move to a new platform, and add significant new functionality, they have had considerable difficulty staying on schedule and within budget. As a result, only a small number of enterprises will follow such a route.

Two likely outcomes remain: fix or replace. Since expenses for modifying internal-use software for Year 2000 compliance must be recognized in the same fiscal period, the decision process will be skewed in favor of replacing non-compliant applications with purchased applications that may be amortized over multiple years.

Budget limitations are never far from strategic IT decisions. The latest information on accounting treatment for Year 2000 internal-use software changes highlights the need to ensure that software asset management strategies are integrated with an enterprise’s business plan.

There are many nuances and subtleties in how the accounting profession translates and reports business activities. In the Year 2000 software case, FASB reached a consensus on how such costs should be handled: they should be expensed. IS organizations should discuss the possible effects of this action with senior financial executives.

The Securities and Exchange Commission will begin reviewing disclosure statements by companies, investment advisors, and investment firms to determine if current regulations are adequate to ensure that investors are warned of potential Year 2000 problems. Disclosure reviews will target companies in industries most likely to be affected by Year 2000 problems, and will begin with disclosures in annual reports for companies with fiscal years ending December 31, 1997.

Under SEC Release 6385, a Management Discussion/Report must be included with management’s filing and audited financial statements. The purpose is to allow investors to look at the quality of earnings reported in the audited financials (i.e., to disclose the company’s ability to continue to perform at that level in the face of such potential problems as the Year 2000 situation). Under SEC Release 6385, management is required to make known; trends, demands, commitments and events likely to come to fruition that can have a material impact on the company’s earnings and its future.

Footnotes, reserves and other accounting treatments may be possible depending on specifics. A material effect may occur for many companies and management must address the problems today or face stiff penalties in court. However, overzealous disclosure can force selling the company’s stock when such panic is not warranted. It would be wise to seek expert and legal assistance to help position the disclosure in the proper context.

In the past, directors and officers (D&Os) enjoyed an unspoken legal immunity against failed computer systems and related projects within their companies. In the event of a failed system, project managers, CIOs or maybe even a CFO might be fired - but that was all. With the advent of the ubiquitous Year 2000 problem, directors and officers will be held liable for the impact on their organizations of this known, predictable and potentially massive computer failure.

As fiduciary stewards for the company and its assets, D&Os are responsible for understanding material threats facing the company, enlisting appropriate outside expertise if required, investigating alternatives, developing meaningful and reasonable plans, and executing such plans expeditiously following the business judgement rule to solve problems and minimize risks. With CIOs changing employers every 2.1 years on average, D&Os can expect several CIOs between now and the Year 2000 and each with no accountability/liability.

In today’s business environment, computers are so key to successful operations that their failure causes catastrophe, not inconvenience. If a company’s Year 2000 solution will not be available in time and causes the company to lose market share, market value, contracts, or control over financial transactions, or even causes shutdown of operations for several months, D&Os will pay much of that price. Additionally, D&Os will be held liable for nondisclosure of Year 2000 problems and failure to prepare, budget and execute a Year 2000 fix strategy on a timely basis. Damages and judgements per board can be in the billions of dollars, and criminal liability may also be found.

CPAs have some opportunities to help firms and clients successfully tackle the Year 2000 problem. In some cases, it has been determined that the cost of fixing systems cannot be cost-justified. In marginal lines of business, the profit for the next several years could be eaten up by the cost of fixing and testing the software. In these cases, decisions need to be made concerning the strategic nature of the business vs. the bottom-line impact.

Another business issue that must be addressed is the organization’s legal liability to its customers if it fails to deliver promised services or products. In addition, there is liability of the directors to the shareholders. Finally, there is liability of the suppliers to the organization and any legal issues that arise from their inability to provide service. There will be a significant amount of litigation surrounding the Year 2000 problem, and it will be vital that the organization’s legal staff be involved in the problem from day one.

From an accounting perspective, Year 2000 costs will be treated as an expense if no significant new function is included. The inability to capitalize the cost will result in some unique one-time charges to the bottom-line of the organization.

From a cash flow perspective, financial institutions must understand the risk of loss of loans outstanding to organizations that may not survive and the bottom-line impact this could have. Similarly, for many firms account receivables are important to cash flow; if they are unable to collect from firms that can no longer pay them, it will have a ripple effect on their ability to operate.

The biggest challenge of all is to make all the changes in the time frame required. The deadline is immovable. Understanding these issues in advance allows proactive efforts to ensure minimization of loss and a viable liquidity. The more you know, the more prepared you and your firm will be.

ABOUT THE AUTHOR:

To Sidebar