CORDIS Archive
This page has been archived. It will no longer be updated.
draft 0.3 - 30 September 1997
IMPORTANT NOTICE
This is a document provided as a background to those who attended the consultation meetings held by the Commission services with representatives of the public and private sectors. It is merely intended to stimulate discussions involving interested parties, in order to delineate the scope for action for those parties and to highlight and prioritise possible actions and, unless explicitly stated, it does not present the official position of the European Commission on the issues being addressed. The document does not aim at providing any legal or other advice, nor does it endorse any of the positions expressed in the articles or other information sources listed in the References.
Comments and suggestions are welcome and can be sent to
Andrea Di Maio
European Commission
N105 3/36
rue de la Loi 200
B-1049 Brussels (Belgium)
fax. +32 2 296 8364
Email: andrea.dimaio@dg3.cec.be
The latest version of this paper can be found at /esprit/src/y2keuro.htm and can be downloaded in PDF format
Table of Contents
At the turn of the century organisations in all sectors and world-wide are being affected by the Year 2000 computer problem (also known as "millennium bomb"), that is the inability of many computer systems and programs to perform correct computations with dates after 31 December 1999, due to the use of only two digits to indicate the year. At the same time, many of the same organisations are involved in the transition towards a single European currency, which will have a profound impact on the way they work as well as on their information systems.
From a computer systems viewpoint, the two issues have similarities (in terms of the technical approaches to be adopted) but also important differences in terms of problem definition, "responsibility" and strategic impact. However both issues must be addressed over broadly the same timescale and each, in its own right, represents huge resourcing challenges (human and financial). Taken together they present a problem of unprecedented scale for those with responsibilities for software driven systems. At the same time they may stimulate awareness of the need for best practice in IT system procurement, development and deployment which can benefit industry and other organisations in the longer term.
This is a background document produced by the Commission services as an input to extensive consultation with the SOGITS-PPG (Public Procurement Group of the Senior Official Group for Information Technology Standardisation), the Telematics in Administrations Committee, and several European professional, industry, trade and commerce associations. It is merely intended to stimulate discussions involving interested parties, in order to delineate the scope for action for those parties and to highlight and prioritise possible actions.
The document does not aim at providing any legal or other advice, nor does it endorse any of the positions expressed in the articles or other information sources listed in the References.
Since the early days of electronic computing, only 2 digits have been used in very many cases to represent the year in date fields (YYMMDD): therefore in many applications the Year 2000 will interpreted as the year 1900, causing failures in arithmetic computations, comparisons, sorting and access to data. . This is further complicated by the frequent use of "99" and "00" as reserved values with a particular meaning (e.g. "never delete this") as well as by the cases where 2-digits representations are embedded in the program logic and, in spite of the correct four digit representation, only the last two digits are used and the first two are not initialised (thus containing meaningless data). Last but not least, many programs may not take into account that Year 2000 is a leap year.
Although the turn of the century is the date when most problems are likely to occur, many date-dependent algorithms and forward-referencing systems are already beginning to fail and several systems will not show failures until later in Year 2000.
The original reason why programmers took this approach was to save on what used to be expensive computer resources (mostly magnetic storage). More recently, they kept using the same date representation partly in order to allow new applications to interoperate with older ones, and partly as a matter of habit. Although the consequences of this choice now appear in all their seriousness (see sections 3), it has to be noted that - as outlined in [2] - the cumulative savings on magnetic storage due to the 2-digit convention probably exceed the costs of the correction.
Although the Year 2000 problem is fundamentally a computer system problem, its potential impact is huge and wide-ranging. Computer systems have become increasingly business and safety critical and software underpins a wide variety of products and services, both in the private and in the public sectors. Therefore the problem can and will impact European citizens, consumers and enterprises, as well as administrations. Early failures have already been reported by the press, ranging from early release of prisoners from jail, to impossibility to issue credit cards with expiry dates after 1999.
As far as the potential impact on consumers is concerned, examples include the loss or damage of personal and financial transaction records, the miscalculation of transactions impacting savings, bank accounts, mortgages, inability to access funds when needed, disputes with public authorities over underpayment of taxes, errors in invoicing from utilities, unavailability of dairy products in food retail stores, errors on payrolls and salary payments, and so on. Also safety is at stake: the failure of a computer application embedded into an aircraft, a traffic control system or a power station can put human lives at risk.
As far as enterprises are concerned, the consequence of failures in their computer systems may affect, to various extents, their operations as well as all trading and financial partners. Failures in the final product or service might lead to repair and replacement costs, litigation and damage indemnification, depending on the nature of the market and the impact for the customer, whether a business or an individual. Failure in the products and processes supporting the supply chain, as well as in services provided by energy and telecommunications utilities might equally affect the business operations. Failures in the management of financial transactions or the accounting systems might lead to cashflow problems. All this may finally lead to devaluation of the stock value of the company as well as to increasing difficulties in getting short as well as longer term credit: in the extreme this may include business liquidation.
Larger corporations are likely to have sufficient resources to cope with the problem (including the ability to transfer costs to their suppliers by delaying payments or tightening non-IT purchase policies). On the other hand, smaller organisations have smaller and less critical IT assets, but they often depend on local software package suppliers, who may be no longer in business or may have discontinued the relevant product. Medium to large organisations are expected to be among the most vulnerable, due to their relatively low maturity in software development and limited professional software resources but relatively high dependence on their IT systems.
Public administrations, especially at the local level, appear to be the most exposed: the public pressure to decrease budgets, the longer lead time to get approval, the vulnerability to skilled staff turnover due to lower flexibility of rewarding and staff retention policies, put them at a considerable risk. On the other hand they represent an important interface for businesses and individuals and, as such, play a very important role in the changeover process:for instance, failures in governmental applications dealing with taxation, welfare, etc. might create problems for businesses.
Several estimates of the costs have been published and are constantly updated. Amongst the most authoritative are those from the Gartner Group [6] and Software Productivity Research [7], which focus on the U.S. situation and derive the European and world-wide impact. It is now widely recognised that, although the worldwide cost for initial software repair may be in excess of 600 billion ECU, there are additional and substantial items to be considered, such as additional software repairs due to errors introduced while performing the changes to the original software; adaptation of the software and data required to test the programs after their modification; repairs to databases, where both the structure and the actual data relevant to dates may have to be modified; hardware chip replacements (there are more than 3 billion microcontrollers and microcomputers in airplanes, cars, industrial machinery, brown and white goods, weapons, etc); hardware performance upgrades, required to provide further capacity for development and testing; and litigation and damages. This bring the estimated world-wide costs to figures exceeding 1600 billion ECU [7]
Estimates of the impact for Europe differ but concur in indicating costs of the order of (and most probably exceeding) 150 billion ECU. In particular Software Productivity Research [7] estimates that for the ten EU countries with the largest IT expenditures the cost for pure software repair will be of the order of 90 billion ECU: taking into account that this amount may constitute only between one half and one third of the overall expenditure, costs could be substantially higher.
While initial estimates and discussions have focused on business systems and mainframes, there has been an increasing awareness over the last year about the risks for client/server architectures, personal computers, industrial controllers, and a variety of microcomputer-based application embedded in systems and appliances of all kinds.
In particular, although the oldest legacy systems are likely to be the most affected, it would be very dangerous to underestimate the issues concerning more recent platforms, products or applications. Many programs or databases are affected by the two-digit problem because they were developed in compliance with the characteristics and data models of the older applications they interface with or from which they derive.
The solution of the Year 2000 tends to be considered as a "distress purchase", not adding value to the business concerned, the only reward being to remain in business. Nevertheless, the Year 2000 can have a positive impact that is often understated. The necessity to look thoroughly at the entire application portfolio of an enterprise, including contracts with suppliers, is very likely to result into a more effective, streamlined and modernised portfolio, leading to larger-term benefits. Several cases have been reported where unused or outdated programs were a non-negligible percentage of the overall software assets.
Year 2000 projects also represent an invaluable opportunity to re-think and improve the software development process: most organisations will be confronted for the first time with the need for asset management, configuration management techniques, testing tools, more sophisticated project management methods and so on. Also the way in which they relate to their software package and service suppliers will change with more attention to warranties and maintenance contracts.
Examples of beneficial aspects can be found in [8] and [9]. These range from speeding-up initiatives such as reengineering because of Year 2000 work, to finding out-of-date systems that can be phased out, with longer term savings on maintenance contracts, hardware capacity, etc. Further to this, the changeover projects create the favourable conditions to put in place software best practices and to lead to sustainable and continuous software process development improvement.
Last but not least, as observed in [7], the Year 2000 problem is just the tip of the iceberg: date fields are not the only kind of fields which may require to be changed, as shown by the examples of the social security code in the US, the postal code in Germany or data fields for cargo management systems. In this respect, the introduction of the single European currency, let alone its wide ranging business impact, is yet another example.
Over the last two years the millennium issue has been subject to massive levels of public exposure, in various media, via the sales forces of the major computer service companies offering "solutions", at professional conferences, on the World-Wide Web and with Member States administrations contributing, to different extents, to awareness campaigns aimed at alerting businesses. Although awareness of the problem is rapidly increasing, it is less evident that concrete actions are being planned and properly budgeted.
Recent surveys confirm that the level of detailed preparation and progress is still relatively limited, with major differences across Member States. The Neaman Bond survey [10] in March 1997 shows that only 13% of the almost 700 respondents in the main European countries claim to have completed their Year 2000 implementation, but to what extent this includes all systems ranging from desktop to mainframes is less clear, as is the real level of completion (are the new systems already in operation?). The same survey shows that 41% had a strategy in place, but to what extent this translates into a budget allocation or is based on a thorough inventory analysis is not straightforward. A survey of Le Monde Informatique in January 1997 [11] showed that only 17% of the almost 100 interviewees had a precise estimation of the costs and had already made the necessary investments. Il Corriere della Sera on July 4 1997 mentions that 60% of the Italian enterprises are not taking any action.
The situation in the U.S. appears to be comparable: for example, as reported on the Washington Post on 10 July, 35% of the almost 4,400 Government mission-critical systems have not been assessed yet, and only 6% have been fixed.
To better appreciate the urgency of the problem, it has to be noted that the redevelopment from scratch of systems of medium to large size may no longer be an option, since they could not be completed prior to the end of 1999, and that - as claimed in [7] - amongst the large organisations only those starting the conversion prior to October 1997 and making the best possible use of automated tools will have a reasonable chance to successfully complete the process for all their application portfolios.
Although most of a Year 2000 project is implemented under the responsibility of the IT department of an organisation, its business impact can be so huge and far reaching, that all relevant functions of an enterprise must be involved, with a clear understanding and leadership from the board. As shown above, failing the Year 2000 project may turn into liabilities to customers or other trading partners, to financial losses, to qualification of the accounts, loss of market value, and so on.
In spite of minor terminology differences, all sources agree on the main steps of the changeover process. This section is largely based on [12], that provides a very comprehensive description of the process.
The first thing to do is to carry out, in a safe, non-production environment, a preliminary system inventory and testing in order to produce evidence of how seriously the enterprise operations could be affected by the Year 2000 problem: if budget and resources for this kind of testing are not available, a paper-based exercise can be sufficient, trying to determine the financial impact on the organisation of Year 2000-related failures.. At this stage, the IT department should identify the core systems upon which the entire organisation relies by looking at the key business processes and determining which systems will expose these processes to the greatest risk were they not to be available. This will provide senior management with evidence of the potential threat to the core processes and therefore identify for them the need for the development of a strategic approach.
Once the Year 2000 is established as a strategic objective at the highest levels within the company, a Year 2000 team should be established, including at least one member of the senior management who will support the project, and representatives of all the parts of the company that are most impacted (including sales, procurement, legal office). First class project management skills will be required to plan and control such a complex and critical project.
The third step is to build a detailed system inventory to identify all hardware and software system components, including in-house developed systems, third party packages, middleware, compilers, data files, operating systems and job control languages, transaction processing monitors, and their available documentation. This must include desktop applications, that may constitute key business decision tools, as well as equipment with embedded computer chips (such as elevators, access control systems, etc.). A map of the inter-dependencies between business processes, individual programs and data records, including links with external parties and systems, should be drawn, in order to understand the relative importance of addressing each part.
While doing the inventory of applications, it is important for IT users to locate all available documentation concerning the licence agreements and the maintenance agreements for the third party software packages that are in use, as well as the development and maintenance contracts for bespoke systems and any outsourcing agreements. This includes identification of the vendor (which may have changed name or been acquired). As pointed out in [16], the involvement of a legal expert in this process should be considered in order to ensure that its outcome is protected, by way of legal privilege, in order to minimise the risk that, where allowed by the applicable law, this is made subject of compulsory disclosure at a later date in any court proceeding initiated against the enterprise for Year 2000 related failures.
An impact analysis should then be performed, in order to determine the levels of exposure and estimate costs. Commentators suggest to analyse in-depth a limited number of key systems and to estimate the overall costs for the entire IT assets. The detailed impact analysis should examine the different options available, ranging from correcting, to rewriting from scratch or buying from a third party. Also historic data need to be taken into account, as to whether they have to be modified or not.
Since resources (and time) are unlikely to be sufficient to correct all programs, priorities have to be identified (generally based on risks of non-compliance as perceived by the business). A "triage" strategy will have to be followed. Year 2000 managers will have to focus on those applications which are most critical for the business and need to be fixed first, ignoring those which are either problem-free or are likely to be replaced before year 2000, and delaying those which are less critical for the business (and may be coped with after the former are properly fixed).
Further to the above, a detailed planning can be performed, including the procurement of tools and services.
The actual conversion can be supported, at least in part, by the use of automated tools. Several classes of tools can help: however no tool can become the "silver bullet" and their impact on cost savings in unlikely to exceed 20-30%. Tools are available for inventory analysis, for recovering source from object code, for project estimation and management, for analysis, understanding and conversion, for time simulation, etc.
Testing almost certainly constitutes the largest single task, counting for about 50% or more of the overall effort. Detailed test schedules must be developed and coordinated with correspondents and customers and both internal and external data flows need to be tested.
An effective configuration management will be a key asset in a situation where critical software applications and their modules will have to be progressively modified, tested and replaced. In fact [13], because of the long time needed to implement and test a Year 2000 solution, and because of the rapidly changing business needs, it is likely that the production system will undergo other modifications or enhancement in addition to those related to the Year 2000. This implies an iterative process, with strong configuration management, guidelines, and control over changes, to properly manage the frequent re-synchronisations between the Year 2000 project and other system enhancement projects.
As stated in [3], given the complexity of the problem, it is unlikely that any single entity or collective enterprise is able to represent that it has achieved complete Year 2000 compliance and thus to guarantee its remedial efforts: efforts will be mainly directed towards mitigating the risk and will be successful if the number and scope of any technical failure is minimised, and that these are quickly identified and repaired if they do occur. Therefore organisations must be aware that they may fail to complete their conversion process by the end of 1999 and adequate contingency plans should be devised in order to ensure business continuity or survival should the IT support fail or become inadequate. This is a task for the business as a whole and requires direct involvement of the board.
The two primary standards (ISO 8601 and ANSI X3.30) agree on YYYYMMDD as the preferred format for dates. However, both allow variations, including the option of omitting the first two digits in cases where the century is implied. Furthermore, both state that, in case the two first digits are omitted, the century is the current one.
There are several ways of modifying the original six-digits (YYMMDD) date representations, taking into account the expected remaining life of the application as well as cost considerations: they range from expanding the year field to four digits (YYYY), to encoding century information in a six-digit space, from using a 100-year logic window (in cases where the applications deal with data that are no more than 100 years apart) to reversing the system clock by 28 years (or multiple of 28), to retain the same days of the week and month. Combinations of the methods above can also be used to reduce the changes and costs.
Attention has also to be paid to human computer interface issues, such as the habits of reading reports or the number of keystrokes needed to type dates. Dates are often not displayed consistently. Some are in the format MMDDYY, others are displayed as YYMMDD, other as DDMMYY, and this has already caused confusion.
The shortage of programming and project management skills is anticipated to be one of the most critical problems facing organisations in the very near future. Apart from the overall scale of the problem, the availability of programmers who are proficient in relatively old languages, such COBOL, PL/1 and mainframe assembler is quite limited.
For organisations with a substantial internal IT staff, the problem will be staff retention: tactics will have to be developed, ranging from salary increases to term or loyalty bonuses, from conversion of non-IT staff to recall of retired employees. Gartner Group anticipates that organisations at particular risk include those with characteristics such as limited salary or labour flexibility (e.g. local and central government, organisations in countries or industries with lower labour flexibility).
For organisations needing external support, outsourcing or offshore development are an option, but the available capacity is being rapidly exhausted. Furthermore, the shortage of resources is already leading to a price increase.
SMEs are less exposed to these issues, since they seldom have internal software development needs and capabilities, but rather rely on standard packages or externally sourced services. However, they have to act in a very timely manner as far as the compliance of packages and products of other services - often provided by small local suppliers - is concerned (see section 8).
As stated above, the Year 2000 problem is a major business issue and has to be dealt with accordingly. A strategy is required to plan and implement the changes, including securing and using the necessary resources in the best possible manner, minimising the business disruption and preparing a viable contingency plan in case of total or partial failure.
Part of the strategy must cover the legal position of the business, so as to protect its position in a market where the costs of services involved are predicted to rise substantially. Moreover, the business must be shielded against possible claims from trading or financial partners who may be damaged from its failure to switch to the year 2000 correctly, in addition to the need to evaluate whether and how to claim compensation from suppliers, where this is a viable option.
There does not appear to be a single tactic to be recommended about how to deal with these issues. As stated in [16] "level-headed solutions between suppliers and users must be found because, in some cases, users and suppliers will only survive if they weather the storm by clinging together". Therefore looking for compensation from suppliers may not be the best option if this pushes them into trouble and the product is finally discontinued (or the suppliers goes into liquidation). Some commentators suggest to turn litigation into mitigation, i.e. to exploit potential supplier liabilities for negotiation purposes and price containment.
There are several legal issues [16, 17, 18, 19, 20] that need to be looked at and whose relevance and impact differ depending on the nature of the enterprise. The basic issue is whether suppliers of systems that are non Year 2000 compliant can be held - at least partially - liable, according to the terms of the original system purchase or license contract.
First of all, it is important to distinguish between contracts for the purchase of packaged software products and contracts for the purchase of bespoke systems, developed according to customer specifications, the latter being often equivalent to the purchase of professional services. However, in both cases, contractual liabilities depend on the law of the contract, if specified, or on the relevant international private law.
Contracts generally provide warranties that may be either explicit or implied. For explicit warranties, all transaction documents, product manuals as well as sales and marketing material relevant for the sale of the software may be taken into account, but the vendor may have used effective disclaimers to make clear that any statement in that material does not constitute any assurance about the quality of the product and does not belong to the sales contract itself. Examples of implied warranties include the warranty of merchantability (i.e. the product is considered to be suited for the ordinary purposes for which it would be used) and of fitness for purpose (i.e. the vendor has knowledge that the purchaser is buying the product to fulfil a particular need and is relying on the superior skills of the vendor): also these warranties can be disclaimed, but the disclaimer has to conform to requirements set in the legislation of the specific country (such as the Uniform Commercial Code in the U.S., or the Unfair Contract Terms Act in the U.K.).
The duration of warranties is also an issue and depends on the specific national laws as well as on whether the supplier is an enterprise or a professional [19, 21, 22]. At the end of the detailed inventory, software licensees and owners will be able to identify for which systems long-term licenses and maintenance contracts are in place and whether they last until January 1, 2000: in these cases, it is reasonable to assume that costs will be borne by the vendors, although they may try to disclaim this arguing that the Year 2000 problem was known to the customer or that they had to conform to existing 2-digit representations in other customer-owned systems. Further to this, most support agreements are reactive rather than proactive, and whether the fault can be fixed before it has actually occurred depends on the specific terms and conditions.
In the case of software packages, commentators recommend issuing a request in writing to make the package Year 2000 compliant at supplier's cost: the failure to do so may constitute a waiver of the customer's right to seek reimbursement for correction.
In discussions on liabilities, several commentators make reference to a case involving a city council and a supplier in the UK, where the system was defective and caused financial damages to the user. The relevance to possible Year 2000 cases is subject to several discussions [19, 21] involving the nature of software as service or goods, the applicability of exclusion clauses, the implied term of fitness for purpose and the time limitation on clauses. In August 1997 one of the first Year 2000 cases has been filed in Detroit against a manufacturer of cash registers which proved to be incapable of processing transactions with credit cards expiring later than 1999.
For any software product that is a candidate to be modified to make it Year 2000 compliant, there is a risk of copyright infringement (under both the US Copyright Act [24] and the applicable national law implementing Directive 91/250/EEC on the legal protection of computer programs [38]) as well as limitation as far as software modifications are concerned for both the organisation using that piece of software and any support service provider helping in the transition.
In case the user is subject to a license preventing software modifications, contact has to be made with the original software developer to check whether Year 2000 compliant versions of that software are or will be available and, if not, to get an explicit permission to perform the modification. If this is not (or cannot be) obtained, users and their service providers may have to consider the ways in which they can perform the modifications without infringing the copyright. These include looking at provisions such as "considering the changes as an essential step in using a computer program with a machine" or for a "fair use" (under the US law), or considering the changes as necessary to achieve the interoperability with other programs or for use in accordance to the intended purpose (under the EU directive).
It is essential that contracts for all new purchases clearly indicate a condition of conformance to Year 2000 compliance criteria. Examples of related clauses have been published by the Year 2000 Interagency Committee, by the National Institute of Standards and Technology (NIST) in the US, by the British Standards Institute, the CCTA in the UK [19], the Swedish IT Commission [26], Forfás in Ireland [12]. Particular attention will be required for procurement of services relating to the Year 2000 problem. It is likely that issues like limits on liability will need some substantial discussion.
A key aspect is consumer protection. Both the private and the public sector will have to prevent the negative incidence of the problem on the health, safety and economic interests of consumers.
Where consumers and private use are concerned, legislation on product liability could be of relevance, with particular reference to Council Directive 85/375/EEC of 25 July 1985 [23] governing liability without fault for damages caused by defective products.
According to this directive, the producer of a defective product must compensate for damages caused to private individuals and to private property. Liability expires ten years after the product has been on the market. However, this would apply only if software is considered as a 'defective product'. For the purposes of the directive, a defective product is any movable good that has a lack of safety for life and private property.
This directive does not apply to services [25].
There is also a major non-IT part of the legal inventory that deals with the identification of all possible liabilities that the organisation may have with respect to its trading partners (i.e. customers and suppliers) and financial partners (banks, shareholders, auditors), as well as any liability their non-IT suppliers may have. They include [17, 19, 27]:
The potential failure to overcome the Year 2000 problem can have serious repercussions. These may affect on one side the management accounting and internal auditing (i.e. the preparation, use and control of accounting data and other numerical data for management purposes, to better understand the past and to forecast the future) and on the other side the financial accounting and external auditing (i.e. the financial information reported by enterprises to the public). As far as the former, the failure of information systems may seriously impair the ability of management to take correct decisions. As far as the latter, the company may be exposed to more difficult access to credit or loss of stock value.
A question arises as to whether the costs associated with the software modification due to the Year 2000 can be capitalised or should be normally expensed in the financial year in which they are incurred.
According to the general rules contained in the European Accounting Directives, the costs relating to the Year 2000 should be normally expensed, since they should be considered as part of the ordinary costs which enterprises incur in order to constantly adapt themselves to the changing economic environment and technological progress. In very exceptional cases, and exclusively for the part that these costs relate to identifiable future economic benefits, it would be possible to capitalise them.
Similarly, in the United States, the Emerging Issues Task Force of the Financial Accounting Standards Board (FASB) decided in July 1996 that the cost of software modification due to the Year 2000 problem fix cannot be capitalised, with the possible exception [32] of costs allocated to purchase or non-deductible development of a copyright (see section 9.1) that must be depreciated over the life of the copyright.
Although this appears reasonable from a securities disclosure point of view (allowing capitalisation of all Year 2000 expenses would result in indicating corrective work as financial assets, thus misleading investors), the impact on companies can be huge. In particular this level of expenses, especially during a difficult quarter or year, might encourage management to delay the process, possibly exposing officers and directors to liabilities for not disclosing Year 2000 compliance information viz. their shareholders (see 9.3) as well as requiring public disclosure.
The question can also arise whether enterprises are allowed to set up "provisions" in the profit and loss account, to cover the future possible costs associated with the Year 2000.
The general rules contained in the European Accounting Directives would not permit the setting up of provisions for such kind of contingencies, but would require that these amounts, if material, are shown in the notes to the annual accounts or in the annual report, depending on the circumstances.
According to the Generally Accepted Accounting Principles (GAAP) promulgated by the FASB, contingencies which are reasonably possible, whether or not the amount can be calculated or estimated, must be disclosed in a note to the financial statements. This suggests that the risks associated to the Year 2000 should be highlighted and reference to a compliance plan should be added.
On the auditors' side, the Generally Accepted Auditing Standards (GAAS) may require auditors to examine the likelihood of the company's failing to become Year 2000 compliant, by reviewing their plans and progress. In some cases, they may be obliged to issue a qualified opinion. In Europe, auditors' associations have been prompted in several countries, although no specific legislation has been issued.
One additional aspect concerns tax deductibility [32]. The ability of a company to deduct Year 2000 costs may have a substantial impact on its bottom-line results. This mostly depend on the applicable legislation.
The Year 2000 problem can seriously impact, amongst the others, the financial sector.
First of all, this sector hugely depends on information technology. Financial institutions (banks, investment companies, securities dealers, stock exchanges, payment settlment organisations, etc.) and regulatory agencies are tightly interconnected and the failure of one or several entities over this network can have major repercussions on the financial infrastructure of a country, a continent or the entire world. In this respect, several organisations are taking appropriate measures and associations are raising visibility of the business impact of the problem Concrete actions are being taken in the United States, ranging from surveys of readiness and preparedness of regulatory organisations, investment and securities dealer companies [3] to the establishment of inter-organisational data interchange guidelines and the planning of "street-wide" testing based on an integrated architecture built clustering existing testing facilities in different organisations in order to simulate an industry wide production environment [28].
Further to this, the non-compliance and related failures of businesses can have negative consequences on loan agreements, shares and securities, insurance contracts, etc:
The increasing awareness of actors in the financial community, including auditors and accountants, about the business risk constituted by potentially non-compliant borrowers and customers may play an even stronger leveraging effect than the specific Year 2000 communication campaigns sponsored by professional associations or governments. Businesses of all size in all economic sectors entertain frequent and, indeed, vital interactions with all such actors and are likely to take concrete actions if questioned about their compliance by them.
Public administrations, both at national and local level, rely on computer systems to support core processes, such as tax collection, social security, health care, and the electronic interconnection between public administrations by means of EDI is becoming more and more widespread. As indicated before, they are substantially affected by the Year 2000 problem and may be among the most vulnerable.
Furthermore, in most European countries the public expenditure in IT systems and services is the single largest part of the overall IT expenditure. Therefore the behaviour of public procurers is likely to influence both user and supplier industries.
Governments in several Members States in the European Union are contributing to raising awareness of the issue as well as to ensure that public administrations will be ready. The list below is not exhaustive and includes only the efforts of which the Commission has knowledge at the time of writing:
The European Commission is a user and procurer of IT systems. As such it has, for the Year 2000, a primary responsibility for ensuring the survivability of its own internal systems upon which its proper functioning depends. An interservice task force has been established to address both the Year 2000 and the changeover to the Euro and work is in progress.
With respect to matters of general awareness and mobilisation, in the context of the necessarily modest scope of subsidiary action available to the Commission, the following lines of activities have been envisaged and are being implemented: