Brussels, 15 December 1997
XV/7038/97

European Commission
Directorate General XV
Internal Market and Financial Services

Preparing Financial Information Systems for the euro

Brussels, 15 December 1997
Pieter DEKKER
European Commission
Directorate General XV, Internal Market and Financial Services

Reproduction is authorised provided the source is acknowledged

CONTENTS

Introductory Note

Foreword by Commissioner Mario Monti

I Executive Summary

II Introduction

III. Strategic preparation

IV. Technical preparation

INTRODUCTORY NOTE

This document can be obtained by:

FOREWORD BY COMMISSIONER MARIO MONTI

The preparations for the introduction of the euro on 1 January 1999 are well underway. The Single Currency will contribute significantly to further market integration. It will not only increase market transparency by making prices more easily comparable. Cross-border transactions will also become more attractive as market operators will no longer be exposed to exchange rate risks and costs associated with currency conversion will be eliminated.

The Single Market is in turn one of the main pillars of Economic and Monetary Union. EMU is only possible thanks to the powerful impetus to economic integration which the Single Market gives. That is why the Single Market Action Plan adopted in the summer of 1997 sets a target date of 1 January 1999 for completing some important steps which will help to ensure that the Single Market delivers its full economic potential.

In order to take full advantage of the introduction of the Single Currency, businesses need to prepare themselves thoroughly for the changeover to the euro. The changeover will in particular have a number of practical consequences for the day-to-day operations of enterprises. The document that lies before you deals exclusively with one of those practical consequences: ensuring that information systems are ready for the use of the euro. The document is designed to be a practical guide, dealing with the strategic and technical issues related to the changeover of information systems to the euro. It addresses the scope of the changeover, transitional issues, the relation with the year 2000 problem, functionality problems and a range of technical questions.

The Commission will continue to follow the developments in this area closely and will be interested to hear from practitioners of any gaps that may emerge when our advice is put into operation. Meanwhile I hope that enterprises and information technology specialists will find this paper a practical answer to their needs.

Mario Monti
Commissioner for the Single Market and financial services

I. EXECUTIVE SUMMARY

a. Legal framework for the introduction of the euro

The euro will be introduced gradually from 1999 to 2002. On 1 January 1999 the rates of conversion between the euro and the participating national currencies will be irrevocably fixed and the euro will become a currency in its own right. At this date enterprises can begin operating in euro. On 1 January 2002 the new euro banknotes and coins will be put into circulation in substitution for banknotes and coins in the old national currency units.

During the transition period two different currency units will be used within the same Member State. Financial information systems will have to be prepared in order to deal with this unique situation.

b. Strategic preparation

Planning the changeover of information systems to the euro is not just a matter of dealing with the practical issues and consequences. For many enterprises there will be strategy level issues that warrant attention, issues that will fundamentally affect the way an enterprise conducts its affairs. Changes in the business environment, such as the introduction of the euro, can change the functionality that is expected from information systems. In this document discussion of the strategy level issues is confined to a brief description of how they may influence the preparation of the information systems. The strategic considerations should be taken into account before modifying those systems for the use of the euro.

To prepare an enterprise's information systems for the introduction of the euro it is important to establish which information systems are affected by the euro. The basic rule is that:

Only systems that are used to process financial information in one of the participating national currencies can be affected by the euro changeover.

This means that many information systems, principally those dealing with non-financial information, will not be affected by the euro at all.

The changeover to the euro is often compared to the year 2000 problem, probably because both are related to information systems and occur at roughly the same time. The basic rule is:

Systems that use dates, directly or indirectly, can be affected by the year 2000 problem.

This means that hardware and software that is not used to process financial information can still be affected by the year 2000 problem.

Since most financial information systems also use dates, they must be reviewed for problems associated with both the changeover to the euro and the year 2000. Additionally, the preparations for the introduction of the euro, on 1 January 1999, and the year 2000 will necessarily need to be made at the same time. Therefore some enterprises have therefore decided to combine preparation for both issues in order to avoid modifying the same information systems twice. When setting up separate euro changeover and year 2000 projects, enterprises should take into account that the projects are sometimes closely related, because:

  1. For both projects an information systems inventory must be made;
  2. Decisions to fix or to replace information systems in view of the euro changeover and year 2000 problem cannot be taken independently;
  3. Both projects relate in part to the same information systems.

However, there are good reasons for managing the subsequent phases of the projects separately, because:

  1. The two projects are fundamentally different. The year 2000 problem is largely a technical problem in information systems. Whereas the euro changeover requires additional functionality in information systems, and also affects an enterprise in other areas;
  2. . The combined project could be of unprecedented size and complexity, and may become difficult to manage
  3. Deadlines for the euro and year 2000 projects are different (a delay in the euro IT project should not lead to a delay in the year 2000 fix).

In planning for the euro enterprises need to address the following five aspects that are essential for a successful changeover:

  1. Euro project team - The euro changeover of information systems is a complicated process that should not be underestimated. Therefore, all but the smallest enterprises need to set up a euro project team that can guide the them through the changeover process;
  2. Define the scope and nature of the changeover problem - Describing the existing systems and determining the quality of those systems is extremely important for determining the changeover strategy;
  3. Determine priorities and strategy - In setting priorities the importance of the information systems and their complexity must both be taken into account. Furthermore. enterprises need to decide which changeover strategy is most appropriate - a 'big bang' changeover, a gradual changeover, or implementation of new information systems;
  4. Dependency on third party software - Enterprises that rely on third party software have little control over the functionality, timing, quality, and price of the 'euro compliant' software. Therefore, they must reduce the associated risks to acceptable levels;
  5. Training employees.

c. Technical preparation

The introduction of the euro has already been described as a unique event in history. It is this uniqueness that causes most of the problems. The introduction of the euro is unprecedented in the following respects:

  1. During the transition period two different currency units will be used within the same Member State:
  2. At a certain point in time enterprises will have to switch over to the euro completely. The historical financial information, denominated in the national currency unit, that an enterprise still needs after the changeover to the euro, must be converted to the euro unit (conversion problem).

In order to deal with these functional problems several strategies are suggested in this document.

There is a wide range of technical details that need to be taken into account when modifying information systems for the euro:

  1. Rounding - Converting amounts between the euro and participating currency units will unavoidably cause rounding differences. The effects of these rounding differences vary from being merely a nuisance to being able to bring information processing to a halt;
  2. Interfaces between systems - Developing interfaces between systems that use different currency units is often more complicated than expected because of rounding differences.
    Many enterprises have linked their own information systems to those of other enterprises and they must decide together how and when these systems are changed over to the euro.
    Finally, special care needs to be taken to avoid information systems accidentally combining amounts expressed in euro with amounts expressed in the national currency unit (data pollution).
  3. Converting historical data - Many financial information systems store the same information more than once. Conversion of historical data requires that all instances of the same data are converted in exactly the same way, otherwise unpredictable results and errors may occur.
    Conversion from the national currency unit to euro involves rounding to the nearest cent. Multiplication of amounts that have been rounded results in multiplication of the rounding differences.Some financial information may be stored in the 'description' fields of a database, converting such information to euro may often not be possible.
    Some financial information may be stored in the 'description' fields of a database, converting such information to euro may often not be possible.
    Two methods exist for converting amounts denominated in another participating currency unit to euro, each of which offers its own advantages. As these methods produce different outcomes, enterprises need to decide which method they prefer and then use it consistently;
  4. Decimals - Financial information systems that were designed to work with a national currency unit without decimals will need to be modified in order to work with euro cents;
  5. Thresholds - Very often financial information systems use threshold values that define the actions of the system. These thresholds must be converted to euro to avoid unexpected actions by the information system;
  6. Displaying two currencies - Displaying information in two currency units at the same time can be difficult because the amount of space (number of columns) available on computer displays and printed reports is limited.
  7. Spreadsheets - It is impossible to design a utility that can automatically convert spreadsheet models to euro. Therefore the preferred option will often be to rebuild the spreadsheet model, rather than trying to convert an existing spreadsheet model manually.

II. INTRODUCTION

A. FOREWORD

The introduction of the euro as the single currency will have a profound impact on the way enterprises operate. It will be one of the most important changes in the economic landscape of Europe in the next few years. The changeover to the euro also has a number of practical consequences for the day-to-day operations of enterprises. One of those practical consequences is that information systems need to be ready for the use of the euro. Many people would agree that it is important to be well prepared for the euro and that careful planning is essential. However, recent surveys have shown that few enterprises, except perhaps for large banks and insurance companies, are actually preparing themselves for the introduction of the euro.

This document addresses a number of issues which are considered to be of relevance for the preparation of information systems to the euro. It is intended to provide the best technical guidance currently available and it does not, unless explicitly stated, present the official position of the European Commission. Furthermore, the examples used in this document are based on purely fictitious exchange rates and a random selection of currencies, which are all assumed to be participating national currency units.

The document consists of the following three sections:

  1. Introduction -This section gives a brief summary of the changeover time table, parts of the legal framework for the euro, and the conversion and rounding rules for those who are not familiar with them yet and those who would like to refresh their knowledge;
  2. Strategic preparation - Planning the changeover to the euro requires the management of the enterprise to make a number of crucial decisions. This section indeals with the issues on which management needs to take important decisions, such as determining the strategic effects of the euro, establishing the scope of the changeover process, and several critical success factors;
  3. Technical preparation - This section presents an analysis of the functional and technical aspects of the euro changeover. The technical aspects will principally be of interest to software engineers and programmers. However, as these aspects determine to some extent whether a particular changeover strategy is feasible, the analysis may also be of interest to others.

B. LEGAL FRAMEWORK FOR THE INTRODUCTION OF THE EURO

a. Phases

The transition to the single currency will take place in three phases, for which definite dates have been set:

  1. Phase A - Launch of the third stage of the Economic and Monetary Union (EMU): In 1998, as soon as the group of countries taking part in EMU is known, the European Central Bank will be set in place. The conditions for conducting the single monetary and exchange-rate policy will be finalised, and the production of euro banknotes will begin. Preparations in the participating countries will be stepped up throughout this phase, particularly in administrations, banks and financial institutions. The economy as a whole will continue to function as before, in other words on the basis of the national currencies;
  2. Phase B - Effective start of economic and monetary union: This phase begins on 1 January 1999 on which date the rates of conversion between the euro and the participating national currencies will be irrevocably fixed and the euro will become a currency in its own right. The currencies of the participating Member States will be replaced by the euro which will be denominated both in its own unit (1 euro) and sub-units (100 cents) and in national currency units, i.e. the former national currencies of the participating Member States.
    Economic agents may also begin operating in the euro unit. Enterprises most heavily involved in international and European trade are the ones most likely to opt for early conversion of all or part of their operations. Administrations will also continue to prepare actively for their own changeover where they have not already executed the changeover. This phase ends on 31 December 2001.
  3. Phase C - Definitive changeover to the euro:
    1. After 31 December 2001, amounts which on 31 December 2001 are still expressed in national currency units of the participating Member States will be deemed to be expressed in euro units, converted at the official rates;
    2. On 1 January 2002, and over a short period (to be determined by each Member State but a maximum of six months), the new euro banknotes and coins will be put into circulation in substitution for banknotes and coins in the old national currency units. This phase should last no longer than is strictly necessary in order to minimise the complications for users that could be caused by national currency units remaining in circulation for an extended period alongside the single currency. The operation will end by 1 July 2002, (at the latest) when euro banknotes and coins will be the only banknotes and coins to have legal tender status in participating Member States.

b. Legal framework

The legal framework for the introduction of the euro comprises two Regulations:

  1. Council Regulation (EC) No. 1103/97 of 17 June 1997 (Official journal NO. L 162, 19/06/1997 P. 0001) on certain provisions relating to the introduction of the euro, which is based on Article 235 of the EC Treaty. This Regulation covers those aspects which need to come into force as soon as possible to provide the market certainty for the early preparation of the changeover. This concerns the one for one equivalence between the ECU basket and the euro, continuity of contracts, conversion and rounding rules; and
  2. Resolution of the European Council of 7 July 1997 on the legal framework for the introduction of the euro (Official journal NO. C 236, 02/08/1997 P. 0007-0012) on the introduction of the euro. This Regulation will be adopted on the basis of Article 109L(4) of the Treaty immediately after the decision on Member States adopting the euro has been taken as early as possible in 1998 and will then become legally binding.

This legal framework confirms that the euro will be the single currency of the participating Member States from 1 January 1999 and provides the necessary legal certainty for all economic agents.

The legal framework for the euro includes several basic principles which are of importance for enterprises:

  1. The euro will be substituted for the currencies of the participating Member States at the fixed conversion rates applicable from 1 January 1999 (Articles 2 and 3 of the 109L(4) Regulation);
  2. As from 1 January 1999 every reference in a legal instrument to the ECU is replaced by a reference to the euro at a rate of one euro to one ECU (Article 2 of the 235 Regulation);
  3. Where in a legal instrument reference is made to a national currency unit, this reference shall be as valid as if reference were made to the euro unit (Article 6 of the 109L(4) Regulation);
  4. The introduction of the euro shall not have the effect of altering any term of a legal instrument or of discharging or excusing performance under any legal instrument, nor give a party the right unilaterally to alter or terminate a legal instrument. However, as the freedom of contract is respected, this provision remains subject to anything which parties may have agreed (Article 3 of the 235 Regulation); and
  5. As from 1 January 1999 any amount denominated either in the euro unit or in the national currency unit of a given participating Member State and payable within that Member State by crediting an account of the creditor, can be paid by the debtor either in the euro unit or in that national currency unit (Article 8(3) of the 109L(4) Regulation).

c. Definition of terms in the legal framework

The legal framework for the introduction of the euro defines the following terms, which we will use throughout the document:

d. No compulsion - no prohibition

In the explanatory memorandum of the Commission to the proposed Council Regulations, it is stressed that the proposals strike a balance between 'no compulsion' and 'no prohibition' for the use of the euro unit as laid down in the reference scenario decided by the European Council of Madrid.

In the legal framework, the fundamental principle applicable during the transitional period is that acts to be performed under legal instruments stipulating the use of one of the units possible - the national currency unit or the euro unit - shall be performed in the stipulated unit unless otherwise agreed by the parties (Article 8(1) of the 109L(4) Regulation). This rule ensures that economic agents will only have to use the unit to which they have agreed. However, economic agents may feel obliged to deal with the euro before the end of the transitional period for competitive reasons because customers may require invoices in euro, or for logistical reasons, to avoid a high risk 'big bang' conversion to euro on 31 December 2001.

Article 8(4) of the 109L(4) Regulation contains provisions that allow for an early redenomination of debt and the changeover of organised markets. Apart from these specifically mentioned exceptions of Article 8(4), Member States may allow the use of the euro unit but can only impose it on the basis of further Community legislation (Article 8(5) of the 109L(4) Regulation).

The principles of 'no compulsion' and 'no prohibition' concerning the use of the euro were laid down during the Madrid summit. There is an inevitable trade-off between the freedom of the economic agents and that of the Member States. As a result of this trade-off enterprises may be faced with the following situations:

The important conclusion is that economic agents will have to deal with amounts denominated in euro and national currency unit during the transitional period. Few, if any, enterprises will be able to completely avoid using the euro before the end of the transitional period.

e. Payments in euro

Article 8(3) of the 109L(4) Regulation enables debtors to settle their debts in book money by making a payment in either the euro unit or in the national currency unit. Banks are under an obligation to convert such payments into the unit of account of the creditor.

When an enterprise only maintains a bank account in the national currency unit, receipts in euro must be converted into the national currency unit. The euro Regulations do not expressly address the issue of charging for the convertion ofamounts between the national currency unit and the euro unit.

f. Conversion and rounding rules

Article 4 of the 235 Regulation lays down the conversion rules for the euro:

  1. The conversion rates shall be adopted as one euro expressed in terms of each of the national currencies of the participating Member States. They shall be adopted with six significant figures (counted from the left and starting with the first non-zero figure);
  2. The conversion rates shall not be rounded or truncated when making conversions;
  3. The conversion rates shall be used for conversions either way between the euro unit and the national currency units. Inverse rates derived from the conversion rates shall not be used;
  4. Monetary amounts to be converted from one national currency unit into another shall first be converted into a monetary amount expressed in the euro unit, which amount may be rounded to not less than three decimals and shall then be converted into the other national currency unit. No alternative method of calculation may be used unless it produces the same results.

In addition, Article 5 of the 235 Regulation lays down the rounding rules for the euro. Monetary amounts to be paid or accounted for when a rounding takes place after a conversion into the euro unit pursuant to Article 4 shall be rounded up or down to the nearest cent. Monetary amounts to be paid or accounted for which are converted into a national currency unit shall be rounded up or down to the nearest sub-unit or in the absence of a sub-unit to the nearest unit, according to national law or practice to a multiple or fraction of the sub-unit or unit of the national currency unit. If the application of the conversion rate gives a result which is exactly half-way, the sum shall be rounded up.

The conversion and rounding rules do not specifically describe the conversion from a participating national currency unit to a third currency (a currency that is not taking part in EMU). Where a quotation between a third currency (for example the US dollar) and a national currency unit (for example NLG) is no longer available the conversion should be performed as follows:

  1. Conversion from USD to NLG - The USD amount would first have to be converted into a euro amount by application of a USD/EUR exchange rate. The intermediate euro amount would then be converted into a NLG amount by using the conversion rate. It is only to this last calculation that the rounding rules of Article 5 of the 235 Regulation are applicable;
  2. Conversion from NLG to USD - The NLG amount would first have to be converted into the euro unit by applying the conversion rate. The intermediate euro amount resulting from this calculation would not have to be rounded to the nearest cent because this amount is not "…to be paid or accounted for…" The intermediate euro amount would the be converted into a USD amount by using the EUR/USD exchange rate. This final step of calculating the USD amount is not covered by the Council regulation.

Article 5 of the 235 Regulation lays down the rounding rules for a "Monetary amount to be paid or accounted for…" These rules do not apply to converted monetary amounts such as price indications, which are not to be paid or accounted for. Therefore, it is not necessary to round prices, which are indicated with more than two decimals in the national currency unit, to the nearest cent after conversion into the euro unit.

g. ISO code and euro symbol

The ISO 4217 Maintenance Agency has adopted the currency code 'EUR' for the euro. Furthermore, the European Commission has created the following symbol for the euro: (picture available on PDF version only)

This logo can be constructed using yellow on a clear background or yellow on a blue background. Its four colour printing references are as follows: Yellow = Yellow 100 and Blue = Cyan 100 + Magenta 80. Alternatively, in Pantone Matching System (PMS) it is: Yellow = PMS Yellow and Blue = PMS Reflex Blue.

III. STRATEGIC PREPARATION

This section first addresses the strategic aspects of the euro that are important to enterprises. Secondly, a definition of the scope of changeover issues in information systems is presented, and a comparison is made with the year 2000 problem. The section concludes with an analysis of critical success factors.

The following terms will be used with the meanings as defined:

A. STRATEGIC CONSIDERATIONS

Economic Effects

Planning the changeover of information systems to the euro is not just a matter of dealing with the practical issues and consequences. There are also a number of more strategic issues that warrant attention. It is naive to assume that the introduction of the euro will only change the currency of payment and nothing else. It is more realistic to assume that there will be additional economic effects:

  1. The exchange risks between participating Member States will disappear. It is likely to lead to a reduction of transaction costs for international payments, which will in time stimulate cross-border sales and purchases within the euro area and affect the competitive position of enterprises;
  2. Enterprises are sometimes able to profit from price discrimination, whereby they are able to maximise their revenues by charging different prices in different geographic markets. After the introduction of the euro these hidden price differences may become painfully visible, and enterprises may lose their ability to charge different prices;
  3. Certain types of activities will become redundant. For instance, a treasury department that mainly occupies itself with managing exchange risks between participating Member States will find that this activity is no longer necessary after the introduction of the euro;
  4. In some industries customers use information systems (for ordering, payments, or bookkeeping) that are developed by their suppliers. A wholesaler, franchisor, or bank that is able to provide a superior IT solution (because it is capable of dealing with the euro changeover issues) to its customers may be able to capture additional market share;
  5. Similarly, an enterprise that is able to invoice its customers in the currency unit which they prefer will gain popularity over competitors who may be limited to the non-preferred option.

The above list of consequences of the euro is included to show that enterprises should use the introduction of the euro to examine their business processes in detail with a view of identifying how revisions in the manner in which they do business can lead to longer term advantage. Changes in the business environment, such as the introduction of the euro, can change the functionality that is expected from information systems. Therefore, strategic considerations should be taken into account when modifying those systems for the use of the euro. In deciding on additional functionality enterprises need to take into account that the most flexible approach will often be the most expensive in terms of administrative overheads and modifications of information systems.

IT environment

Enterprises also need to consider the quality, structure, and organisation of their IT environment when planning for the introduction of the euro. In many cases the existing IT infrastructure of enterprises is far from perfect, for example

  1. Enterprise A has acquired several other enterprises over the past ten years. Consequently, many different information systems are in use that perform more or less the same tasks. Preparing for the euro changeover could mean that this enterprise has to make similar modifications to, for example, five or six information systems that perform the same tasks. Such a duplication of efforts can be both inefficient and expensive;
  2. Enterprise B has been using an information system for the past 15 years. As a result of the changing business environment and new functionality demands by users, the system is now becoming obsolete. Normally, the system would be used for an additional four or five years before replacement. However, the prospect of a potentially expensive upgrade to deal with the euro changeover might be reason to opt for an early replacement.

These examples show that a modification of all existing information systems may well not be an automatic choice as the most attractive changeover strategy. In both examples there is an underlying need to improve the IT environment; the euro changeover (in combination with the year 2000 problem) may trigger enterprises to make more fundamental changes in their IT environments.

These examples are certainly not meant as an exhaustive list of possible strategic considerations which may be fundamental to the future of the enterprise. However, it is clear that strategic considerations should be taken into account when modifying thoseinformation systems for the use of the euro.

B. SCOPE OF EURO CHANGEOVER ISSUES IN INFORMATION SYSTEMS

a. Scope of euro changeover

To prepare an enterprise's information systems for the introduction of the euro it is important to establish which information systems are affected by the euro. The basic rule is that:

Only systems that are used to process financial information in one of the participating national currencies can be affected by the euro changeover.

This means that many information systems, principally those dealing with non-financial information, will not be affected by the euro at all.

Examples of systems that are affected by the introduction of the euro include:

  1. Accounting software (general ledger);
  2. Electronic payment systems;
  3. Invoicing and billing systems;
  4. Payroll systems;
  5. Accounts receivable and accounts payable subledgers;
  6. Inventory subledgers, which record the value of the inventory;
  7. Fixed asset subledgers, which keep track of the fixed assets, their value, and calculate the depreciation charge for the period;
  8. Work-in-progress systems;
  9. Financial planning and budgeting software;
  10. Costing systems;
  11. Enterprise resource planning (ERP) systems;
  12. Treasury management systems;
  13. Legal databases containing financial contracts.

The above list of financial information systems is certainly not seen as exhaustive. Many categories of information systems that will also be affected by the euro are sometimes easily overlooked, for example:

  1. Cash registers and other types of point-of-sale terminals process financial information. These systems may store comparative historical information (such as the turnover on the same date last year), calculate cumulative turnover figures (which are used in cash reconciliations), are often linked to other financial information systems, and in some cases are not able to deal with decimals;
  2. Enterprises often have more financial information systems that process financial information than they themselves realise. This is especially true for large enterprises that have standardised on a certain software package. Many branches of such large enterprises use additional software packages that the parent company is not aware of. Often small spreadsheet applications and databases are developed locally that give the branch the additional information systems functionality that the standard software package does not offer;
  3. Some financial information systems are not used by the accounting department, for instance software for making cost calculations or databases used by the marketing department. It is easy to overlook these applications if the euro changeover is initiated from the accounting department.

Enterprises outside the EMU area need to take the euro changeover into account in the following cases (this list is not meant to be exhaustive):

  1. An enterprise outside the EMU area that has dealings in one of the participating currency units may have to convert amounts in these national currency units to euro or other national currency units;
  2. Enterprises that have subsidiaries in the EMU area need to ensure that those subsidiaries are preparing themselves adequately for the euro changeover;
  3. The euro changeover will usually require that changes are made to information systems. Multinational enterprises that use the same information systems for all their operations may have to upgrade information systems located both inside and outside the EMU area in order to maintain compatibility.

Year 2000

The changeover to the euro is often compared to the year 2000 problem, probably because both are related to information systems and occur at roughly the same time. The basic rule is:

Systems that use dates, directly or indirectly, can be affected by the year 2000 problem..

This means that hardware and software that is not used to process financial information can still be affected by the year 2000 problem. Therefore, the number of systems affected by the year 2000 is likely to be greater than the number of systems affected by the euro changeover.

Since most financial information systems also use dates, they must be reviewed for problems associated with both the changeover to the euro and the year 2000. Additionally, the preparations for the introduction of the euro, on 1 January 1999, and the year 2000 will necessarily need to be made at the same time. Therefore some enterprises have therefore decided to combine preparation for both issues in order to avoid modifying the same information systems twice. When setting up separate euro changeover and year 2000 projects, enterprises should take into account that the projects are sometimes closely related, because:

  1. For both projects an information systems inventory must be made;
  2. Decisions to fix or to replace information systems in view of the euro changeover and year 2000 problem cannot be taken independently;
  3. Both projects relate in part to the same information systems.

There are good reasons for managing the subsequent phases of the projects separately, because:

  1. The two projects are fundamentally different (reference is made to the next paragraph);
  2. The combined project could be of unprecedented size and complexity, and may become difficult to manage
  3. Deadlines for the euro and year 2000 projects are different (a delay in the euro IT project should not lead to a delay in the year 2000 fix).

From a practical and organisational point of view it may be convenient to deal with the euro and the year 2000 problem at the same time. However, there is a fundamental distinction between the two:

  1. Solving the year 2000 problems means ensuring that the information systems will continue to do what they always did, that is calculate the dates correctly. This makes the year 2000 problem largely a technical problem that needs technical solutions. The users of the information systems must be involved in the process of identifying the potential problems. Furthermore, management support for year 2000 projects is important to ensure that these projects receive sufficient attention from the users and that the business consequences of non compliance are properly understood. However, most of the actual work on remedying the year 2000 problem will have to be done by the information technology (IT) department of the enterprise;
  2. Solving the euro changeover issues will in many cases mean that functionality must be added to the financial information systems. Adding functionality means that the users must be heavily involved in firstly identifying problem areas and then in finding the solutions for these problems. It also requires management to take decisions on the functionality to be added, because these decisions will affect the daily operations of the enterprise during the transitional period. Therefore, the euro is not primarily an IT problem.

C. CRITICAL SUCCESS FACTORS

Many different methodologies have been developed over the years for designing and modifying information systems. This section does not develop a new methodology or describe existing methodologies in detail, instead it highlights five aspects that are essential for a successful changeover:

Euro project team

The euro changeover of information systems is a complicated process that should not be underestimated. Therefore, all but the smallest enterprises need to set up a euro project team that can guide them through the changeover process. This euro project team needs to be knowledgeable about:

The euro project team should play a role in i) gathering information on the introduction of the euro, ii) determining the effects of the euro on the enterprise, iii) preparing a changeover strategy, and iv) managing the implementation of the strategy in areas such as information systems, legal issues, accounting, commercial and marketing issues.

b. Scope and nature

Before starting the actual work on planning the changeover to the euro, an enterprise must have a good overview of its financial information systems. This step is rather technical because it requires the enterprise to do the following:

Conducting a systems inventory has clear commonalities with the approach taken in dealing with the year 2000 problem and if tackled in this light the synergies can be exploited to help reduce overall costs and efforts.

Describing the existing systems and determining the quality of those systems is extremely important. Attempts to modify poor quality software are seldom successful. However, there is a risk that enterprises may embark upon such an attempt anyway:

  1. It is not uncommon that enthusiasm or the wish to make difficulties go away lead to overly optimistic assessments of IT projects;
  2. Organisations may have a subconscious tendency to favour incremental changes over fundamental changes that are perceived as being riskier.

Enterprises may want to take the opportunity to replace existing information systems, although there is always a trade off to be made between the costs of doing this and the risks which will be run by not doing it. It is important that enterprises do not overlook the option of completely replacing existing information systems.

b. Priorities and strategy

The next step in the process is to determine priorities and a strategy for the changeover to the euro. The priorities for changing information systems depend on:

Several changeover strategies come to mind when considering the changeover to the euro:

An additional complication associated with a big bang approach is related to the fact that in many information systems the transactions are assigned to a financial period. For example:

Enterprise A has a financial year that runs from 1 January until 31 December. From the start of the new financial year all new transactions are recorded in the financial period January. However, the financial period December is not 'closed' yet because the enterprise still needs to make year-end closing entries and corrections. The financial period December will only be 'closed' somewhere between January and April. A big bang approach would be complicated in this case because the financial period December is in a 'national currency unit' year, while the financial period January is in the first 'euro unit' year.

It is clear from the above example that a big bang approach at year-end may not be possible if previous financial periods must remain 'open' or 'active' for an extended period (more than a few weeks). An alternative would be a changeover during the financial year, when financial periods may not need to remain 'open' for so long. A changeover during the financial year is not without its own disadvantages as described in the paragraph "Changeover during the financial year";

For each of the possible strategies noted above the matter of testing (at individual module, application, and system level) should receive sufficient attention, in addition to the need for good version control and configuration management. For the year 2000 the testing and integration efforts are judged to be the single most substantial activity (that is, approximately 50% of all costs), this is likely to be similar for the euro.

An important part of the changeover strategy of any enterprise is reducing the number of instances where it has to deal with two different currency units. Enterprises themselves can take several actions to reduce possible changeover problems in the following ways (reference is also made to the paragraph on "Interfaces between systems")::

This implies that an enterprise's choice of changeover date is restricted by external conditions.

c. Depending on third party software

Most enterprises use third party software to some extent. Despite the fact that some software vendors have announced that their software will be made 'euro proof' or 'euro compliant', very few have been able to show working products. Defining 'euro compliant' is difficult because it requires an evaluation whether a particular financial information system meets the particular functional requirements of an enterprise changing over to the euro. These functional requirements depend both on the business of the enterprise and the changeover strategy it has adopted. Therefore, no standard definition of "euro compliant" exists. Hence, enterprises should always verify for themselves whether 'euro compliant' software actually meets their needs.

Five aspects of the dependency on third party software warrant special attention:

  1. Enterprises usually have little influence on the type of changeover solution that the software vendor will choose in dealing with the euro, and little influence on the euro functionality that is added or not;
  2. The lack of influence over the software vendor can impact the choice of the timing of the euro changeover. If the software vendor has not completed software modifications then the enterprise cannot changeover to the euro;
  3. Software vendors may not have the financial and human resources necessary to successfully complete a euro changeover project;
  4. The 'euro compliant' software may turn out to be less reliable than the previous release of the same software. The enterprise should allow itself sufficient time to evaluate the new version of the software and time to develop alternative possibilities in case serious problems do surface;
  5. The price of the 'euro compliant' upgrade of the existing software is uncertain. The price of an upgrade can be excessive when the original software was poorly designed, a substantial amount of unnecessary functionality was added, or when the software vendor takes advantage of the situation.

Enterprises that depend on third party software should not wait until the very last moment to plan their changeover to the euro, nor should they unconditionally rely on the good intentions of their vendors.

d. Training employees

The introduction of the euro more or less coincides with the year 2000. From an information technology point of view this means that a substantial amount of work needs to be done in a relatively short period. The current IT departments of enterprises may not be able to modify the information systems, in time for the euro and the year 2000, without additional staff. Therefore, an enterprise will need to train and hire additional IT staff and must make an effort not to lose valuable IT specialists, who were involved in developing and building the enterprise's existing systems, to other enterprises that also have a temporary shortage of IT staff.

Training of employees is extremely important when changing over to the euro. The employees will have to deal with a number of issues for which they should be well prepared:

IV. TECHNICAL PREPARATION

This section deals with the functional and technical problems related to the euro changeover. Solutions to some of these problems will be suggested, however, their effectiveness will largely depend on the particular business environment of the enterprise and the way existing information systems are implemented.

A. FUNCTIONAL PROBLEMS ASSOCIATED WITH THE EURO CHANGEOVER

The introduction of the euro has already been described as a unique event in history. It is this uniqueness that causes most of the problems from an information systems point of view. The introduction of the euro is unprecedented in the following respects:

  1. During the transitional period two different currency units will be used within one Member State:
  2. At a certain point in time enterprises will have to switch over to the euro completely. The historical financial information, denominated in the national currency unit, that an enterprise still needs after the changeover to the euro, must be converted to the euro unit (conversion problem).

The extent to which the enterprise will experience the input functionality problem and the output functionality problem greatly depends on the type of information systems that it uses. Generally, when a multi-currency input/output system or a system with multiple base currencies is in use, the euro input and output functionality problems will be less important. For a definition of these types of systems reference is made to the paragraph "What is a base currency?".

a. Input functionality problem

In most cases the financial information systems of an enterprise are built with the implicit assumption in mind that all transactions take place in the same currency unit. That is, the financial information system expects the user to input all financial data in the same currency unit. What happens when such an enterprise is suddenly faced with a situation in which it has to deal with two different currency units at the same time? Depending on the situation that enterprise has the following options:

  1. Almost all transactions are in the national currency unit and only a few transactions are in euro:
  2. Many transactions are still in the national currency unit but a substantial number of transactions are already in euro:
    1. Manual solution - In this situation the manual conversion of amounts is rarely a realistic option;
    2. Standard software - Some software vendors offer special "foreign currency" modules that can be used to extend the functionality of their standard software packages. Usually the "foreign currency" functionality of these modules is restricted to areas such as invoicing, accounts receivable, accounts payable, and cash or bank transactions;
    3. Modify information systems - The solution can be to modify the financial information system in such a way that it can accept either the national currency unit or the euro as input. This means that the financial information system performs the conversion for the user. Modifying existing software requires planning, time and testing, and is not without costs. Furthermore, the users need to be trained in using the new features of the financial information system. Also in this case there is an increased risk of clerical errors (such as mixing up of currency units and typing mistakes). These mistakes can be very costly, accidentally paying EUR 100,000 instead of BEF 100,000 may cause serious problems.
    4. Parallel systems - Another solution is to use two versions of the existing financial information system in parallel. One of the systems could be used to process amounts in the national currency unit, the other could be used for the euro. For example, one cash register could be used for the national currency unit and another for the euro, or an enterprise could run two copies of the same software simultaneously. However, difficulties may exist:
      • This solution is often not possible because of technical restrictions in the hardware and/or software;
      • Users of two identical information system with different currency units could easily mistake the euro system for the national currency system;
      • Each system may receive only part of the transactional data, with the consequence that each system is working on the basis of partial data. In situations where transactions are not independent, but are related to other transactions, this can be a problem. For instance:
        • When an invoice is recorded in one system, the payment should not be recorded in the other system;
        • When a system calculates quantity discounts based on the total sales to a customer, it is not possible to record these sales in two different systems;
        • When a system has a built-in credit limit per customer, the use of two systems will lead to undesirable results;
      • At some stage the output of one of the two systems must be translated manually anyway. This is of course not a significant problem when the output is highly summarised.
    5. Sequential changeover - In some situations the currency unit used will depend on the type of transaction. For instance, all purchases from corporate suppliers could be in euro while all sales to individuals could be in the national currency unit. In this case the financial information system dealing with purchases could be in euro, with the sales system continuing in the national currency unit. This approach would, however, require the implementation of an interface between the two systems that converts the amounts from one currency to the other. Also here the risk exists that users get confused about the currency that the system uses.

b. Output functionality problem

The other end of the input problem is of course the output problem. Many enterprises will be faced with one of the following situations:

  1. Important customers or tax authorities insist on receiving financial information in the national currency unit while the enterprise has already changed over to euro. In this case the same solutions are possible as mentioned under the input functionality problem:
  2. The customers of the enterprise would like to receive financial information both in euro and in the national currency unit. Financial information systems rarely have the built-in capability to print the same information in two currencies on one schedule. . Even special "foreign currency" modules rarely offer this functionality. The following solutions may exist:
  3. The enterprise has switched over to the euro, but needs to keep its historical data available in the national currency unit in order to maintain the existing audit trail. It will often not be acceptable that the transaction amounts recorded in the information system suddenly no longer match the amounts on the underlying physical documents (such as invoices and contracts) that are still denominated in the national currency unit. Furthermore, in most countries national law requires enterprises to keep their accounting records in their original form for at least 5 to 10 years. Here an enterprise must always be able to reproduce the accounting records in their original form. Possible solutions for this problem are:

c. Interface problem

When different financial information systems are changed over to the euro at different points in time, a problem arises with respect to the communication between those systems. Several approaches exist with respect to the interface problem:

  1. Build converters - It is possible to build interfaces that not only link two systems, but that also convert the amounts from one currency unit to the other. However, technical problems (such as rounding) can make this approach very unattractive;
  2. Simultaneous changeover - Change all information systems to the euro at the same time. This eliminates the need for interfaces between information systems that convert amounts to and from euro;
  3. Autonomous groups - Identify groups of information systems that are relatively autonomous, that is, groups of information systems that have no or only a few links to other information systems. These groups of information systems could be changed over to the euro at different points in time, while requiring few interfaces that can convert between currency units. This approach, which combines the advantages and disadvantages of the other approaches, can be a practical solution in some situations.

d. Conversion problem

At some point in time enterprises will need to change over to the euro. The historical financial information denominated in the national currency unit will then have to be converted to euro. Although not all historical financial information may be equally relevant, it is necessary to convert all data that has a future use to the euro.

Converting historical financial information poses a significant problem for virtually all financial information systems, even those that have a "foreign currency" module, because multiplying or dividing historical balances by a fixed conversion rate is not a built-in option. The following options are available to convert historical data:

  1. Manual conversion - This requires that all historical data is manually translated into euro and then input into the financial information system. This solution has the disadvantage that it is very susceptible to errors and is labour intensive. Nevertheless, in the case of small financial information systems that keep little historical data it may be the most cost efficient alternative. Enterprises may also want to take this opportunity to implement a new financial information system;
  2. Conversion utility - The historical information can also be converted automatically, but this requires the development of a special one-off conversion utility. Developing such a conversion utility can be fairly easy when the financial information system is based on a standard (relational) database management system. However, in the case of proprietary data formats, developing a conversion utility may not be a trivial exercise. Furthermore, the conversion may require some extra processing time and hence will need an associated review of processing capacity;
  3. Modify information systems - In this case the conversion utility is built into the financial information system and forms part of the added 'euro functionality' of the system. This method probably offers the most flexibility to the user of the financial information system but it comes at a cost.
  4. Encapsulation -All historic financial information continues to be stored in the original national currency unit, but all input and output is converted to and from the euro unit. Encapsulation can only be a temporary solution because converting all input and output is burdensome; and the information systems will tend to generate rounding differences.

B. TECHNICAL TRAPS AND PITFALLS

In order to implement additional euro functionality properly, a number of technical issues need to be taken into account. These issues include, among others, understanding what a 'base currency' is, dealing with rounding problems, converting historical data, and modifying financial models.

a. What is a base currency ?

The base currency is the currency unit in which a financial information system processes and stores financial information. Normally it suffices to use the national currency unit as the base currency for the financial information system, but there may be advantages to using multiple base currencies. The following types of systems are possible:

Description Input currency Output currency Processing Storage
a. Single currency system Single Single Single Single
b. Multi-currency input Multiple Single Single ?
c. Multi-currency output Single Multiple Single ?
d. Multi-currency input/output Multiple Multiple Single ?
e. Multiple base currencies Multiple Multiple Multiple Multiple
Single - using only one currency unit
Multiple - using more than one currency unit

Each of these systems outlined above has particular characteristics which make it attractive in particular situations:

  1. Single currency system - Most enterprises use a single currency system. This means that it in order to process financial information originally expressed in another currency unit it must be translated manually into the base currency. In ordinary situations these systems offer all currency functionality that most enterprises will ever need. Unfortunately, these systems have substantial disadvantages when changing over to the euro, because they do not allow the user to input data in another currency unit and cannot generate output in another currency;
  2. Multi-currency input - See a., however, in this case the user can input data in one of several currency units. This allows the user to input a transaction in the transaction currency, that is the currency in which the transaction was originally expressed. The input is stored in both the transaction currency and the base currency, however, all processing is done in the base currency. Many multi-currency input systems are in reality hybrid, in the sense that they only allow multi-currency input for certain types of transactions (usually just sales and cash transactions);
  3. Multi-currency output - See a., however, in this case the user can generate output in several currency units. All data is stored in the base currency, the amounts denominated in another currency are calculated from the base currency amount every time output is requested. Many systems are hybrid, they will only allow multi-currency output of a limited number of reports for a limited number transaction types;
  4. Multi-currency input/output - See a., however, in this case the user can input data in several currencies and generate output in several currency units. These systems could use the euro as their base currency and use the national currency units as the transaction currency (or vice versa). When processing amounts denominated in the national currency unit, these would be converted to euro, then processed and finally converted back to national currency units. As will be explained in the next paragraph on rounding, this can give rise to a continuous stream small rounding differences, depending on the choice of base currency (reference is made to the paragraph "Unavoidable rounding differences - Reconversions"). In situations where rounding differences are not a major concern, the enterprise and its customers can accept these differences, these systems offer the following advantages:

If an enterprise were to use a multi-currency input/output system it would be of great importance to gain acceptance and understanding for the small rounding differences that may occur during the transitional period. Customers, tax authorities, and other parties concerned should be informed of this at an early stage so they can take this fact into account;

  1. Multiple base currencies - These systems appear to be the same as the one described under d. However, these systems offer a high quality audit trail that makes it possible to trace a transaction from beginning to end (from input to output of processed data) in two base currencies. This can be of special importance in connection with certain rounding problems. The main advantage of a system with multiple base currencies is that the enterprise can start using the euro whenever it wants to do so. Systems with multiple base currencies are not without their own problems:

b. Rounding

The rounding and conversion rules of the Article 235 Regulation prescribe in detail how amounts must be converted from a participating national currency unit to the euro and another participating currency unit. These rules reduce the number of rounding and conversion problems significantly, but problems still remain.

AVOIDABLE ROUNDING DIFFERENCES - CROSS RATES AND INVERSE RATES

The most common conversion will be the conversion between the national currency unit and the euro. Less frequently enterprises will have to convert amounts between two participating national currency units. It is extremely important that conversion and rounding rules are implemented correctly.

Article 4.3 of the Article 235 Regulation prohibits the use of inverse conversion rates for converting amounts between a national currency unit and the euro, because the use of inverse rates can lead to rounding differences. For example:

Assume the following conversion rates:

Conversion rate: EUR 1 = GBP 0.704182

Inverse rate (10 digits): EUR 1.420087421= GBP 1

GBP EUR
Conversion rate 7,500,000 10,650,655.65
Inverse rate 7,500,000 10,650,655.66

Despite the high accuracy (10 digits) the inverse rate method still resulted in a rounding difference.

It is important to note that some information systems display the exchange rates in a different format than the one that is used in calculations. For example: Exchange rate as shown on screen: BEF 100 = DEM 20.8227 Exchange rate used in calculations: BEF 4.80245 = DEM 1.00

The conversion rules as laid down in the Article 235 Regulation leave some freedom to enterprises. The conversion rules state that: "Monetary amounts to be converted from one national currency unit into another shall first be converted into a monetary amount expressed in the euro unit, which amount may be rounded to not less than three decimals…" [emphasis added]. Therefore, enterprises are allowed to round the intermediate euro amount to a number of decimals that is three or greater. The following example shows that that rounding to three decimals will not always lead to the same end-result as rounding to four or more decimals:

Assume the following conversion rates: EUR 1 = GBP 0.704182 and EUR 1 = FRF 6.73847

Decimals GBP EUR FRF
3 210.00 298.218 2,009.53
4 210.00 298.2184 2,009.54

The rounding option ("…not less than three decimals…") could cause rounding differences between enterprises that use the option differently. To avoid rounding differences between information systems of the same enterprise, it is important to round to the same number of decimals in all software.

Article 4.4 of the Article 235 Regulation describes how amounts must be converted between participating currency units via the euro (the triangulation method). Other methods of calculation are only allowed when they produce the same results. Therefore, information systems need to be adapted to do the conversion in the way as prescribed, because all other methods of conversion can lead to small rounding differences. For example assume the following conversion rates:

EUR 1 = GBP 0.704182 and EUR 1 = FRF 6.73847

An enterprise defines a 10 digit cross rate as: GBP 1 = FRF 9.569216481

GBP EUR FRF
Triangulation method 467,167.35 663,418.477 4,470,425.50
Cross rate method (bilateral rate) 467,167.35 - 4,470,425,51

In the above example the triangulation always produces the same result, independent of the number of decimals used for the intermediate euro amount. However, despite the high accuracy (10 digits) the cross rate method produced a different result (albeit that the difference is very small, FRF 0.01). When an even greater accuracy is used the number of rounding differences diminishes (however, a spreadsheet simulation showed that even a 15 digit cross rate occasionally produces rounding differences). These differences can become a major nuisance, for example:

A French enterprise (A) sells goods to an English enterprise (B) in the amount of GBP 467,167.35. Enterprise A uses the cross rate method and records the amount as FRF 4,470,425.51 in its information system. Enterprise A will receive "only" FRF 4,470,425.50 when enterprise B (which uses the triangulation method) pays for the goods. When matching the sale of goods with the receipt of cash a difference of FRF 0.01 results. The difference itself has no economic importance, however, in order to clear it the user will need to enter an additional transaction that removes the remaining balance from the system.

Many existing financial information systems use conversion methods based on cross rates and inverse rates. Modifying these information systems in order comply with the prescribed conversion rules can be expensive. It is useful to take the following into account:

The only way to avoid the type of rounding differences as shown, is by using the conversion rules as prescribed by the Article 235 Regulation. Other methods will lead to unnecessary rounding differences, no matter what accuracy is used.

UNAVOIDABLE ROUNDING DIFFERENCES

Unlike the rounding differences as discussed in the previous paragraph, some rounding differences are really unavoidable. It is technically speaking impossible to avoid these rounding differences:

The classic rounding problem in accounting, which has annoyed many bookkeepers and information systems developers, is that of the fixed asset with a cost of 1,000 and a useful life of 3 years. The depreciation charge for years one and two is 333.33 but the charge for year three must be 333.34 in order to reach zero at the end of year 3. It is clear that no matter what mathematical accuracy is used in performing this calculation, the rounding difference persists.

Similarly, it is not possible to completely avoid some euro related rounding problems. These rounding differences are analysed below.

UNAVOIDABLE ROUNDING DIFFERENCES - CUMULATIVE AMOUNTS

Rounding problems can occur when converting individual items and cumulative amounts based on the same items to euro. Take the following example:

Assume the following conversion rate: EUR 1 = DEM 1.93805

DEM EUR
Item #1 100,000.00 51,598.26
Item #2 100,000.00 51,598.26
Item #3 100,000.00 51,598.26
Item #4 100,000.00 51,598.26
Total 400,000.00 206,393.04
Check 400,000.00 206,393.02
Difference 0.00 0.02

Applying the conversion and rounding rules to individual items and adding up the individual outcomes does not necessarily lead to exactly the same outcome as applying the rules to the cumulative amounts. This in itself is nothing new, but may still lead to confusion in certain cases, for example:

UNAVOIDABLE ROUNDING DIFFERENCES - RECONVERSIONS

A second type of rounding problem surfaces in situations where amounts are converted back and forth between currencies. This can be best explained by the following example:

Assume the following conversion rate: EUR 1 = NLG 2.17248

Enterprise A decides to convert its data from NLG to EUR but discovers later that it still needs the amounts in NLG and decides to convert it back:

NLG EUR NLG
Convert to EUR 198.10 91.19
Convert back to NLG 91.19 198.11

Converting the EUR amount back into NLG does not result in the original NLG amount. The reason is that part of the accuracy was lost because the smallest intermediate unit, the EUR cent, is greater than a NLG cent. That is, in real terms one EUR cent represents a greater value than one NLG cent (this is sometimes referred to as the granularity problem). The EUR-NLG-EUR conversion does not result in rounding problems because no accuracy is lost when converting EUR to NLG.

For British Pounds the situation would be reversed because the penny is larger than one EUR cent. This means there is no reconversion problem for GBP-EUR-GBP conversions, however, differences will arise on EUR-GBP-EUR conversions.

In summary, the following picture emerges:

EUR 0.01 smaller than EUR 0.01 greater than
GBP 0.01 ATS 0.01
IEP 0.01 DEM 0.01
BEF 1 DKK 0.01
LUF 1 FIM 0.01
FRF 0.01
NLG 0.01
ESP 1
SEK 0.01
ESP 1
ITL 1
GRD 1
ITL 1
PTE 1

Enterprises need to keep the following in mind:

  (a) NLG (b) EUR (c) EUR
Item #1 198.10 91.19 91.18[6]
Item #2 198.10 91.19 91.18[6]
Total 396.20 182.38 182.37[2]
Total NLG 396.20 396.22 396.20

When the euro amounts are rounded to euro cents, the sum of item #1 and #2 cannot be converted back to NLG without a rounding difference (see column (b)). Storing an additional digit (column (c)) solves the reconversion problem, however, now the addition in euro appears to be incorrect (remember that the decimal in square brackets remains hidden for the user).

UNAVOIDABLE ROUNDING DIFFERENCES - DEALING WITH SMALL AMOUNTS

Finally, in some cases the effect of rounding has a material effect on the outcome of calculations:

Assume the following conversion rate: EUR 1 = BEF 40.3555

Enterprise A decides to convert its data from BEF to EUR:

BEF Exact EUR Rounded EUR Effect
1 0.024780 0.02 -19%
2 0.049560 0.05 1%
3 0.074339 0.07 -6%
4 0.099119 0.10 1%
5 0.123899 0.12 -3%
6 0.148679 0.15 1%
7 0.173458 0.17 -2%
8 0.198238 0.20 1%
9 0.223018 0.22 -1%
10 0.247798 0.25 1%

When dealing with very small amounts or margins between small amounts the effect of rounding may be noticeable for enterprises. An enterprise that has an inventory of nuts and bolts, each valued at BEF 5, could experience a rounding effect of 3% on its inventory.

ARE ROUNDING DIFFERENCES IMPORTANT?

From an economic point of view the rounding differences as described will rarely be of importance for several reasons:

Rounding differences can have a significant impact on the way financial information systems work:

Enterprise A receives a payment of EUR 25,344.85. Normally, the system would highlight all outstanding invoices in the same amount. However, if the original invoice was EUR 25,344.86 the user would have to look longer before he could allocate the payment to an invoice.

It should be noted that information systems can match transactions on the basis of other information (name, address, ZIP code, invoice number, etc.). Where this is already the case, matching will not become a problem. Changing the matching mechanism only to deal with the euro might not be advisable because it could add significantly to the implementation load;

Enterprise A received a payment of EUR 25,344.85 and matched it against and invoice of EUR 25,344.86. This means that a balance of EUR 0.01 is still outstanding according to the system.

Enterprises that encounter small payment differences on a regular basis may already have simplified procedures in place for dealing with such differences. In that case the euro rounding is only an additional source of differences, and it is not necessary to take additional action;

DEALING WITH UNAVOIDABLE ROUNDING DIFFERENCES

Enterprises can deal with the unavoidable rounding differences in different ways:

  1. Tolerate - Some rounding differences may be inconvenient but do not affect the way the information systems function, for example:
    When converting the value of 50,000 inventory items from BEF to EUR this could theoretically result in a maximum rounding difference of EUR 249.99 (=50,000 times 0.49999 EUR cent). There is usually no reason why the enterprise should try to increase the value of 24,999 inventory items by EUR 0.01 in order to get rid of the rounding difference;
  2. Built-in tolerance - In cases where an information system looks for a match with an identical amount, it is easy to build in a tolerance of a few euro cents, for example:
    Instead of just looking for invoices of EUR 25,344.85, the information system could look for invoices between EUR 25,344.80 and EUR 25,344.90;
  3. Automatic clearing - Clearing of unmatched balances, such as rounding differences, is often cumbersome, the procedures may require many separate steps in the information system and authorisation from more than one person. These procedures are often put in place in order to reduce the risk of fraud, for instance, stealing goods and then fraudulently clearing the record of them from the information system. It may be worthwhile for many enterprises to provide for a simple (automatic) clearing procedure for small differences (all differences less than EUR 0.25). An automatic clearing procedure could transfer all rounding differences to a special 'balancing' account. This would greatly reduce the burden of dealing with rounding differences, but does require and periodic review for irregularities;
  4. Look up original amounts - Sometimes rounding differences are unacceptable. In these cases the amounts must always be available in the transaction currency. Where the transaction currency is different from the base currency of the financial information system, a mechanism must be created that allows the users to retrieve the amounts in the transaction currency;
  5. Avoid small amounts - The rounding effect on small amounts can be avoided in most cases by expressing amounts not on a per unit basis, but by expressing the amounts per 100 or 1000 units. By expressing the price of nuts and bolts per 100 units the rounding effect immediately becomes insignificant.

c. Interfaces between systems

For organisational or practical reasons it may not be desirable to changeover all financial information systems at the same time.

A good example of a system that most enterprises will want to change over to euro at a very late stage are payroll systems. Generally, employees are not interested in receiving their payroll slip in euro when they do not yet have a bank account in euro.

When one system still uses the national currency unit while the other systems use the euro it is necessary that the interface between the two systems is modified in such a way that it will be able to translate the amounts from one currency unit to the other.

It is of great importance to take note of the possible rounding problems that may occur (reference is made to the paragraph on "Rounding differences"). Given the fact that some rounding problems are unavoidable it may be difficult to develop a straight-forward currency converter that can take care of everything. This means that the costs of temporarily modifying the interface between two information systems can be excessive.

Many enterprises have linked their own information systems to those of other enterprises (examples include: electronic banking systems, links to external databases, and the use of EDI messages). Enterprises that have linked their information systems must decide together how and when these systems are changed over to the euro. Where it is not possible to reach agreement on changeover issues, some of the enterprises may need to modify their interfaces to the external information systems.

Special care needs to be taken to avoid information systems accidentally combining amounts expressed in euro with amounts expressed in the national currency unit (data pollution). Mathematically there is no problem with adding up these amounts, but the result of the calculations will be complete nonsense. Enterprises should therefore:

Manually restoring lost or polluted data can be extremely expensive and time consuming.

d. Converting historic data

NON-NORMALISED DATA

Relational database theory requires normalisation of databases to ensure that information systems do not store the same information more than once. This is a sound principle, however, for performance and other practical reasons software developers often find themselves in a position where they have to depart from this principle. Therefore, many financial information systems store the same information more than once:

Identifying all the instances in which an information system duplicates data can be a daunting task in itself.

When converting historical data it is important to ensure that data that is stored more than once remains consistent. If the underlying information is converted to euro, but the cumulative or summarised data is not converted to euro properly, financial information systems may produce either unreliable data or refuse to operate normally, for example:

Rounding differences could easily lead to situations where the sum of the details is no longer equal to the subtotals. The effects of this will depend on the particular design of the information system.

In some cases it may be attractive to restructure the storage of historical data in a way that entirely avoids data duplication. This solution avoids rounding differences, but does require substantial modifications to existing systems.

To convert cumulative data properly the following steps are necessary:

Any other method, that does not recreate the cumulative data, is susceptible to the rounding problem associated with cumulative amounts as described before. Recreating cumulative data can be extremely complicated, because many information systems calculate cumulative amounts on the basis of other cumulative amounts (for instance, even simple report generators allow up to 9 levels of subtotals). Where recreating cumulative data is not feasible three other solutions exist:

  1. A special conversion program could convert all details from the national currency unit to the euro unit and insert rounding adjustments where necessary. For an invoice this could be done as follows:
    Assume the following conversion rate: EUR 1 = BEF 40.3555
    Code Description BEF EUR
    1000 Invoice #1548, 28 Jan 2001 1,300 32.21
    1100 VAT Invoice #1548 273 6.76
    9999 ***EURO ROUNDING*** - 0.01
    Total 1,573 38.98

    The rounding adjustment is clearly recognisable for the user and the information system will group all rounding differences under code "9999". Advantages of this method are that i) the cumulative information remains consistent with the underlying details, ii) the cumulative amounts remain the same which avoids consistency problems at a higher level, iii) the user can easily trace the origin of the rounding differences (summarised under code "9999") and only has to deal the cumulative difference, and iv) this method may well be the easiest to implement;
  2. Convert the cumulative amounts directly and then review and adjust the rounding differences manually. For large data sets this can be either too complicated or too time consuming (the rounding difference is only moved around and not solved. This will sound familiar to bookkeepers and auditors who have tried to make a "fixed asset schedule" work);
  3. Tolerate the rounding differences in the historical data and perform tests on the information system to ensure that it will continue to work as expected despite rounding differences.

MULTIPLYING ROUNDING DIFFERENCES

In avoiding data duplication information systems often do not actually store amounts that can be easily calculated based on other data fields, take for example the following invoice denominated in DEM:

a b c = a *b
Description Quantity DEM Price/unit (calculated) Amount
Gasoline (litres) 100,000 1.48 148,000.00
Diesel (litres) 50,000 1.21 60,500.00

The "description", "quantity", and "price/unit" fields are stored by the information system, but the "amount" field is never stored because it can easily be calculated based upon the other fields (only the items shown in italics are stored by the information system). When the historical data is converted to euro the following happens (assume a conversion rate of EUR 1 = DEM 1.93805):

d e = b/1.93805 f = d * e g = c/1.93805
Description Quantity EUR Price/unit (calculated) Amount Converted Amount
Gasoline (litres) 100,000 0.76 76,000.00 76,365.42
Diesel (litres) 50,000 0.62 31,000.00 31,216.94

In converting the historical data only the "price/unit" field was converted to euro and rounded to the nearest euro cent (column e). In order to display or print the "amount" field (column f) the information system has to multiply "quantity" with "price/unit". The amounts calculated in this way differ substantially from the amounts obtained by converting the DEM amounts directly (column g). The reason for the substantial difference lies in the fact that an amount that has been rounded ("price/unit") is subsequently multiplied by a large number ("quantity"), which leads to a multiplication of the rounding difference.

In most cases the multiplication of rounding differences will not be as dramatic as shown in the example. Nevertheless, the existence of substantial rounding differences will not be acceptable to most enterprises. Two solutions come to mind in avoiding the multiplication of rounded amounts:

  1. Allowing a certain degree of data duplication, by storing the product of the multiplication together with its factors (for example: store the amount in addition to the quantity and price per unit). This method does, however, violate data normalisation rules;
  2. Data that is expected to be multiplied could be stored with greater accuracy (for example: store the price/unit with an 8 digit accuracy);
  3. Store the product of the multiplication and all but one of its individual factors (for example: store the amount and quantity and calculate the price/unit when needed). This does require substantial modifications to the existing information systems and may not be attractive for that reason.

MIXED FIELDS

Some enterprises have grown into the habit of storing part of the financial information in one data field together with non-numeric data, for example:

Quantity Description Amount
12 bolts 1.80/dozen 1.80
12 nuts 11 cents/piece 1.32
… etc.  

This example shows it is not possible to convert the numerical data that is stored in the "description" field to euro. This will not influence the way the information system functions, because the information system does not use the "description" field for any calculations. However, for users of the information system it will be very confusing because they do use the "description" field. Where it is technically unfeasible to convert this type of financial information to euro, the enterprise should make sure that all employees are aware of this. Otherwise, time consuming "witch hunts" for non-existing conversion errors could keep them busy.

HISTORICAL DATA ANOMALIES

Historical data anomalies can arise in connection with historical data that has been translated at the fixed conversion rate. This is easiest explained with an example:

Assume that a German enterprise operates in Germany and France. The exchange rates are as follows:

1997: ECU 1.00 = DEM 2.00 = FRF 8.00

1998: ECU 1.00 = DEM 2.00 = FRF 7.00

1999: EUR 1.00 = DEM 2.00 = FRF 6.00

In order to calculate the total sales, both must be expressed in the same currency unit. Two methods are available:

1997 1998 1999
Method A
1 France FRF 800 700 600
2 DEM 200 200 200
3 Germany DEM 250 250 250
4 Total DEM 450 450 450
5 EUR 225 225 225
Method B
6 France FRF 800 700 600
7 EUR 133 117 100
8 Germany DEM 250 250 250
9 EUR 125 125 125
10 Total EUR 258 242 225

The explanation for the difference in the outcomes is that the historical exchange rate in the respective years was different from the irreversibly fixed conversion rate. Still it is important to be aware of this anomaly since it can cause significant inconvenience. Enterprises that use advanced software for preparing consolidated financial statements or that use data mining applications with drill down functions may encounter these types of anomalies.

e. Decimals

Some national currencies are normally expressed without decimals (examples include the peseta and the lira). Financial information systems that were designed to work with amounts expressed in such currency unit usually cannot handle decimals. As the euro is subdivided in 100 cent it is necessary to modify these systems so they can handle two decimals.

The Article 235 Regulation requires that when converting amounts from one participating currency unit to another the conversion is done as follows:

  1. Translate the amount from participating national currency unit A to the euro; and then
  2. Translate the amount from the euro to participating national currency unit B.

The intermediate product in this calculation, the euro amount, must be expressed in at least three decimals. This means that even when systems can handle amounts expressed in two decimals, it may be necessary to modify these systems so they can handle the three decimals necessary for the intermediate product in this calculation.

f. Thresholds and ranges

Thresholds

Very often financial information systems use threshold values that define the actions of the system, for instance:

How the thresholds can be changed will depend on the design of the financial information system. Changing them can be very cumbersome when they are 'hard coded' in the software. Changing validity checks and data input masks that are built into the 'forms' that an application uses, is easier as this does not affect the software directly. Finally, where the thresholds are stored in a special look-up table or special file for parameters, it may be quite easy to change them.

Changing threshold values is not something that can be done automatically because the thresholds must be set at rounded amounts that people can remember. Having thresholds converted automatically to awkward amounts such as EUR 247.80 will normally not be satisfactory. Moreover, changing threshold values are often quite important management policy decisions and as such require management attention (for example in the case of discount levels and credit limits of customers).

The issue of 'psychological' prices and amounts (such as FRF 24.95 or FIM 199) is not dealt with in this document. However, it is clear that enterprises may need to revise certain prices and amounts because the conversion to euro results in 'inconvenient' or 'unpleasant' amounts.

Ranges

Many financial information systems classify transactions in different categories depending on the transaction amount (in some cases these classifications are based on contractual obligations), for example:

When the upper and lower boundaries of these categories are automatically converted into euro, different problems may arise depending on the original national currency.

In the case of a national currency unit for which the smallest unit of denomination is greater than EUR 0.01, the following can happen:
Assume the following conversion rate: EUR 1 = BEF 40.3555

Category BEF EUR
Category I <= 1000 <= 24.78
Category II 1001 to 2000 24.80 To 49.56
Category III 2001 to 3000 49.58 To 74.34
Category IV 3001 => 74.36 =>

Once the category boundaries are converted into euro it turns out that there are gaps between the different categories. Transactions in the amount of EUR 24.79, EUR 49.57, and EUR 74.35 belong to no category at all.

Depending on the technical specifications of the information system, the following could happen to transactions that fall in between categories, they might:

  1. Not be grouped in any category;
  2. Be grouped together with the lower neighbouring category;
  3. Be grouped together with the higher neighbouring category; or
  4. Be grouped differently by different parts of the information system

In the case of a national currency unit for which the smallest unit of denomination is smaller than EUR 0.01, the following can happen:
Assume the following conversion rate: EUR 1 = FRF 6.73847

Category BEF EUR
Category I <= 1000.00 <= 148.40
Category II 1000.01 To 2000.00 148.40 To 296.80
Category III 2000.01 To 3000.00 296.80 To 445.20
Category IV 3000.01 >= 445.21 >=

Once the category boundaries are converted into euro it turns out that the different categories are overlapping. Transactions in the amount of EUR 148.40 and EUR 296.80 belong to two different categories.

Depending on the technical specifications of the information system, the following could happen to transactions that belong in two categories, they might:

  1. Be grouped in two categories;
  2. Be included only in the lower category;
  3. Be included only in the higher category; or
  4. Be grouped differently by different parts of the information system.

To avoid inconsistent or unpredictable outcomes information systems should:

  1. Not make use of both upper and lower boundaries for categories, instead they should use either upper or lower boundaries;
  2. Not calculate, for example, the lower boundary of Category III as the upper boundary of Category II plus "1" because the smallest subdivision of the euro is 0.01; and
  3. Use the boundaries in a consistent manner to avoid different groupings of transactions by different parts of the information system.

g. Displaying two currencies

DUAL DISPLAY

During the transitional period, and possibly sometime thereafter, it would be convenient to display the same amount both in the national currency unit and the euro. From a technical point of view, presenting amounts in two currencies may pose certain problems:

In many cases it is sufficient if comparative figures in a second currency unit are presented only on at the subtotal level, without really providing details in two currencies for all individual items. Where details need to be provided in two currencies it may be possible to include them at the end of the description field However, this solution is a clear violation of the database normalisation rules and should not be used if it can be avoided.

LABELLING

In many instances financial information systems display amounts under the implicit assumption that all amounts are denominated in the same currency unit (for instance all amounts are Deutsch Marks). Where information systems are capable of displaying amounts in one of two currency units, or in environments where not all information systems use the same currency unit, it is important that all amounts displayed or printed are properly labelled. If this is not done the resulting confusion will surely lead to a higher number of clerical errors.

Enterprises will need to review their software to determine which screen layouts and printed reports need to be modified in order to indicate the currency unit in which the data is expressed. Instead of labelling all amounts individually it will often suffice to indicate the currency unit used in the header of printed reports or in the top corner of screen layouts.

h. Financial models

Some enterprises use statistical models based on historical data expressed in the national currency unit. In order to apply these models to euro amounts it may be necessary to revise the parameters of such models. Changing nonlinear models (such as certain mathematical models, neural networks, and other systems trained using historical data) may be particularly complicated, for example:

A credit card company may have software that reviews the incoming transactions for abnormalities. The system could for instance scan for withdrawals of rounded amounts (such as DEM 100, 500, or 1000) that are unusual for credit cards. It is of little use to convert those amounts to EUR 51.60, EUR 257.99 or EUR 515.98.

SPREADSHEETS

Financial models are often implemented as a spreadsheet model. The major advantage of spreadsheet models is that even people with a very modest background in information technology can build these models. Spreadsheet models are used for a wide range of applications, such as:

Spreadsheet models can play an important role in pre-processing input for other financial information systems and in processing output received from other systems. The link between spreadsheet models and the other financial information systems often consists of retyping financial information or downloading print files.

Modifying spreadsheet models so they will work with euro instead of the national currency unit is extremely complicated for several reasons:

  1. Spreadsheet models can be very large. A spreadsheet of one megabyte will contain 20,000 to 25,000 individual spreadsheet cells. Spreadsheets models of this size are not uncommon in many enterprises;
  2. There are different types of spreadsheet cells, they contain: i) text, ii) formulas, iii) non-financial numerical information, iv) financial numerical information, v) dates, and vi) links to other spreadsheets or data sources.
    In order to prepare spreadsheets for the use of the euro only the cells with financial numerical information and some cells containing formula's must be modified. Identifying only the right cells to modify, not forgetting any or selecting too many, is a lot of work. An example:
    Enterprises may be using certain valuation models, based on discounted cash flows, in making investment decisions. If the model's discount rate were to be multiplied by the fixed conversion rate (which is incorrect) or if some of the cash flows remained in the national currency unit (which is also incorrect), then the model could produce dangerously inaccurate results. Such an error can be hard to detect and may lead to incorrect investment decisions.
    The situation becomes even more complicated when the spreadsheet model contains financial numerical information in different currencies.
  3. Spreadsheet models are mostly built by employees with a modest background in information technology. Consequently, spreadsheet models are not built according to any standard methodology, are poorly structured, and are completely undocumented. Of course there are positive exceptions, but they are few;
  4. Spreadsheet models often duplicate some information that is also recorded elsewhere. However, modifying the original data source will usually not update the same information in the spreadsheet model. Therefore, there is a high risk of creating inconsistencies between spreadsheet models and other information systems.

It is important for enterprises to get an overview of the different spreadsheet models that are used. Most enterprises will be unpleasantly surprised by the variety and quality of the models that are in use. Spreadsheet models are used to process important financial information and are used to 'lubricate' the automated data processing. Therefore, it is essential to start planning for the euro changeover early. Because of the great variety in spreadsheet models it is usually not possible to design utilities that can do the conversion automatically. Therefore the preferred option will often be to rebuild the spreadsheet model, rather than trying to convert an existing spreadsheet model.

i. Changeover during the financial year

Enterprises are free to decide when they want to changeover their financial information systems to the euro. However, in this choice they are limited by a number of practical factors. One of these factors is the limitation of their financial information systems. For several reasons the end of an enterprise's financial year appears to be a more or less natural moment for changing over from the national currency unit to the euro:

However, there are several good reasons for a changeover during the financial year:

j. Internal controls

Introducing new information systems or modifying existing ones is not a routine process in most enterprises. This in combination with the euro changeover, which by definition is not routine, leads to certain risks for which enterprises need to be prepared:

year2000/euro home