Systems Modelling Ltd.
SME Changeover

Home ] Spreadsheet Best Practices ] Consulting ] Book List ] Euro Index ] Search ]

 

 

Related Pages: FEE Paris 2000 ] Enterprises 2002 ] Euro Compliance ] 7 steps to success ] Eurotown Project ] Lessons learnt ] UK Decimalisation ] Euro Implications ] Managing Risk ] [ SME Changeover ] Euro Myths/Facts ] Leclerc 1996 trial ]


 

Euro Scenario - SME

By Patrick O'Beirne, Systems Modelling Ltd.

Last updated 2000-08-07  by Patrick O'Beirne


Euro IEP value image Central Audiovisual Library, European Commission

Visualise the scenario.

A small retail company (ABC )is trading in Irish Pounds (IEP) only, and its bank account is in IEP. It has a shop serving the public, accepting notes, coins, credit and charge cards, and it also sells on account to other businesses. All its customers pay in IEP, and the few foreign suppliers are paid by bank draft in their currency. It does not need to report results to a parent company in any other currency. It runs a standard single-currency accounting software package, and would like to handle the Euro without going to the complexities of a multi-currency package. It would seem strange if Irish businesses were forced to the expense of multi-currency processing in the transition to a single currency!
Their French & German suppliers inform them that they are converting to the Euro, but will still accept payments denominated in their old national currency (FRF, DEM).

Q: Should ABC open a Euro account as well as their current IEP a/c?

A: The bank may well offer dual cheque books, IEP and Euro, but make a second account charge for two accounts. However, ABC will not be in a position to write cheques on their Euro account and send them off in payment to foreign suppliers as the Banks do not currently have any facility to clear these cheques outside of this country. Drafts will still have to be used or proposed new electronic payment systems.

Later, the Irish suppliers (e.g. DEF Ltd) announce their changeover and send out price lists in Euros. They should show original IEP prices and Euro prices to make comparison easy, and demonstrate accuracy of the conversion. There must be no hidden price changes in this conversion. The Euro must always be the IEP amount converted at the rate 0.787654.

 

Sample Conversion Price list

DEF Ltd Price List 06/04/2001 Rate: €1.00 = £0.787564

Item Pack Qty £Price Euro Price Rounded
Widget single 1     1.10     1.396712     1.40
Widget box 100 100.00 126.97381 126.97
Widget Special E 100 93.72* 119.00 119.00

DEF Policy: "Note * that the special promotional price is converted from E to £ for guidance only and is not calculated from £". Our policy on payments is that customers should remit the total statement amount in Euro or its equivalent in £ at the fixed rate shown above. We will not dispute rounding variations of up to 5 cents per invoice introduced by converting individual invoice Euro amounts to £ and then calculating a £ total, rather than converting the total of the Euro amounts to £. We encourage all our customers to convert to Euro as soon as possible to make business simpler all round.

ABC simply enters any new prices into their own cost price list, reviews margins, and adjusts retail prices where required. Their internal list is still in IEP. As long as DEF continues dual pricing, this is easy, so ABC will insist on dual pricing as long as they are working in IEP. For reasons that will become obvious at the time of ABC's changeover, it would be particularly helpful if the package could hold the supplier's price in Euro, perhaps in a spare field.

Supplier Invoices

When ABC receives invoices in Euros, the accounts clerks first group and subtotal the invoice lines into analysis codes, as at present. Then they check the total of the analysis lines (including VAT) against the invoice total, adjusting one analysis amount by any odd cents difference due to rounding. Then they convert the analysis line subtotals and the invoice total to Euros for posting in IEP in their purchase ledger.

DEF may show IEP equivalents of line items for ABC's information and convenience, but because an analysis code may apply to several line items, ABC will probably convert the total of the Euros rather than add the IEP amounts shown.

Rounding example: 

10 items at £100 each becomes 10 at €126.97, a total of €12697.00.

£1000 is however €1269.74, so there is a four cent difference.

I assume that all traders will agree that odd cents differences in invoice totals will be ignored.

Supplier Statements

When changing to Euro, it is unlikely that a company will roll up all the outstanding items into one opening balance. They will probably retain an aged statement. An alternative might be to have four opening balance items for different ageing periods, but that is unlikely. Again, the conversion to Euros will result in a total of Euro that will be a few cents different from the old total in IEP, but that will be a once-off small variance.

Original in IEP:

Date
Ref.
Trans
Debit
Credit
Balance
Previous
Balance
    0.00
03/01/01
1224
Invoice-Dec'98
1,086.58
1,086.58
27/01/01
160
Lodge-Pmt
1,086.58
  0.00
03/02/01
1228
Invoice-Jan'99
  363.00
  363.00

With Euro column added:

Date
Ref.
Trans
Debit
Credit
Balance
Euro
Previous
Balance
  0.00
0.00
03/01/01
1224
Invoice Dec'98
1,086.58
	
1,086.58
1379.67
27/01/01
160
Lodge Pmt
1,086.58
  0.00
0.00
03/02/01
1228
Invoice Jan'99
  363.00
  363.00
460.91

 

All converted to Euro:

Date
Ref.
Trans
Debit
Credit
Balance
Previous
Balance
  0.00
03/01/01
1224
Invoice-Dec'98
1379.67
	
1379.67
27/01/01
160
Lodge-Pmt
1379.67
  0.00
03/02/01
1228
Invoice-Jan'99
460.91
  460.91

When ABC receives statements, the first statement will contain a mixture of - fully paid and part-paid invoices originally in IEP, payments and credit notes originally in IEP, unpaid invoices originally in IEP, and unpaid invoices in Euros. Later, they will see payments made by ABC in IEP converted to Euro.

How will they be shown? One method, which makes matching and reconciliation with ABC's purchase ledger easier, is for DEF to show the original IEP amount as a memo column in the statement. OR to supply two statements, one in each currency. OR they may divide their customers into Euro and IEP groups, and send the appropriate statement type to each. If that is not done, ABC will have to run a special report from their package to show the converted amounts. If the package cannot handle that, they will just have to assume that the conversions are correct and match by invoice reference. There is no risk in this, as if any conversion was not correct, the payment totals would not match.

ABC will select invoices for matching in the usual manner, skipping any disputed ones. Once ABC have decided on a payment amount, they can pay from their IEP bank account if they wish, on the "no compulsion, no prohibition" principle. DEF will have to convert it to Euro for their ledger and lodge as normal in the bank. It will be up to DEF's bank to convert that into Euro for DEF's account. 

ABC's changeover.

Once enough customers want invoices in Euros, ABC will eventually change. As in interim measure, they may wish to consider presenting IEP invoices converted to Euro. As this might imply that ABC had changed to Euro, that would be confusing. The internal accounting (including VAT) will still be in IEP. This is a customer service decision. If they decide to do this, and their accounting software is in single currency, a converter package will have to re-print invoices in Euros. This may not be available. It can be argued that if ABC's bank account is in IEP, their invoices should be that way too.

They might wish to investigate alternative accounting packages from other software companies. This may be desired for other reasons of functionality or performance - e.g. e-business or Windows compatibility. These vendors will almost certainly provide conversion services from older packages, to capture their market. It is not safe to attempt to change too many things at once. If a new package is being contemplated, this must be done well before the Euro changeover, and of course the ability of the vendors to assist in this will be one of the considerations.

Assume the changeover will be in April 2001, a relatively quiet trading period. Its retail branch will change last, when the notes & coins are introduced in January 2002. ABC will have two price lists - trade and retail. Let's consider the trade changes first.

ABC's bank account will be changed to be denominated in  Euro. The bank should be able to print statements in either denomination.

ABC's employees will be paid in National currency (IEP) cheques, which their bank will convert as the employees still have accounts in IEP until the notes & coins come in.

Accounting System Changeover

  1. Print a full set of customer and supplier statements and retain them on paper file in case copies are required. Of course, a permanent computer data backup will also be retained off-site.
  2. Do a Period End routine to clear out all allocated transactions. They will also do a Year End routine to clear out the analysis figures. Even though this is part way through their financial year, the only effect is that their auditors will receive two sets of accounts - IEP up to April 2001, Euro from then on.
  3. Print a full set of customer and supplier statements in IEP showing the opening balances and outstanding transactions.
  4. Run a conversion package that converts all money data in their files to Euro. If the software suppliers have not made that available, there may be alternatives from independent suppliers, which will have to be tested before the changeover is made for real. Failing that, they may have to clear out all transactions and enter new opening account balances. That would make it harder on customers who will only have the paper statements to work from.
  5. The conversion will also apply to the sales price list. This has two parts - the cost of items and their selling price.
  6. Costs can be converted, but because of rounding, they may not correspond to the Euro prices from suppliers which were converted into IEP while ABC was operating in IEP. So they will all have to be checked, a tedious business. Unless, of course, the package had the ability to store the Euro cost price as well, in which case they can be now transferred into the fields for current cost price. Check whether the package holds more than two decimal places in a cost price - this is often necessary when a price is quoted as per Kg or per 24 by the supplier but changed to Lbs or Each by ABC.
  7. Dual pricing will be required by customers, so the printed price list will have to be altered to add an extra column at least. If the package does not permit that, it may be possible to export the data to a spreadsheet or database and create the report from that. These operations are time-consuming and a new more capable accounts package may well save both time and money.
  8. Later, when the retail prices are being updated, they may need to be changed to restore margins affected by rounding on low-price items. A policy decision will have to be taken as to when that will be done, before or after the Euro conversion. It cannot be done at the same time without incurring the wrath of consumer's associations.
  9. Margin checking may be easier by calculating in advance what prices will be affected, e.g. all the £0.49 products, and then checking only those products with those prices. Most packages will allow "filtering" the database to select only those products; again, if not, I would recommend looking for a new one now.
  10. All historical files will have to be changed, unless ABC wishes to start all its trend analysis again from a new starting date. This again should be done automatically - I cannot see such a task being done manually.
  11. Every calculation that depends on historical data, such as stock item re-ordering, will have to be checked to avoid distortions from historical figures suddenly appearing 25% larger.
  12. Every conversion will have to be checked by sampling the results - e.g. checking 100 prices at random.

Once the change is made, invoices will now be in Euros. Any occurrences of the £ symbol in programs or on stationery will have to be replaced. If a customer wishes to be invoiced in pounds, a converter may be required again. Again, my opinion is that the invoices should reflect the currency of the company. If ABC's accounting software is multi-currency, then dual invoicing is easy.

The Supermarket

Dual price labelling will be required by consumer legislation, both before and after Euro changeover. The current layout is :

________________________________

NESCAFE COFFEE £0.79

MILD BLEND 250G
________________________________

Possible changes are:

  1. Print two labels, a green/red one for IEP, a blue one for Euro. This may cause confusion on the shelves.
  2. Print the Euro price in smaller digits with a prefix of an E or the Euro symbol (at the head of this document) , under the main price in £, and reverse their position after changeover.

________________________________

NESCAFE COFFEE £0.79

MILD BLEND 250G €1.00
________________________________

  1. Use some of the product description space to hold the "other" price. This will be difficult or impossible for many products, as the descriptions are very terse already.

Also for the supermarket, the tills will have to be changed. They can receive a download of new prices easily enough. They will need to be reprogrammed so that before and after the changeover they convert the total at the bottom to the "other" currency. I see no need for individual line item price conversion. That will have to be discussed with your consumer panel. The timing of the conversion of several stores will have to be scheduled.

 

Original version 1998-05-02  by Patrick O'Beirne

 
 

Up ]

  Traduisez / ‹bersetzen / Tradurre / Traduza / Traduzca Babelfish translator 

These pages are provided subject to Copyright and a disclaimer
Copyright © 2000-2004 Systems Modelling Ltd., Tara Hill, Gorey, Co. Wexford, Ireland.
Telephone +353-55-22294  Fax +353-55-22165 
Email Send email to sysmod.com  provided subject to the terms and conditions below.

PRIVACY: Your email address is treated as confidential and never disclosed without your explicit permission.
OPT-OUT: The phone and fax numbers and email addresses at sysmod.com provided on this web site are provided solely for one-to-one communications to Systems Modelling Ltd. We forbid any harvesting of email addresses from this site, or the inclusion of any sysmod.com address in any mail list without our explicit permission.
SPAM: Unsolicited bulk email to sysmod.com will be reported to SpamCop.

Last updated January 03, 2005