Aanpassen software aan euro: proces met fouten

De invoering van de euro heeft vaak ingrijpende gevolgen voor de IT. De kosten van de invoering zijn aanzienlijk. Ze worden niet alleen veroorzaakt door IT; organisatorische vraagstukken zijn verantwoordelijk voor zeker de helft van de kosten. Een onderdeel van de voorbereidingen op de euro is het opwaarderen van de software. Auditors Nico Huizing en Ivo Bolderhey over de fouten die hierbij gemaakt worden. 

Veel leveranciers van standaard financiële software hebben inmiddels ‘euro-compliant’ versies (voor de euro geschikt gemaakt) van hun software op de markt gebracht. Onduidelijk is echter aan welke eisen software dient te voldoen om te mogen spreken over een ‘euro compliant’ versie.
Om duidelijkheid te verschaffen heeft de Business and Accounting Software Developers Association (Basda), een overkoepelende organisatie van software ontwikkelaars, de Europese wet- en regelgeving vertaald in functionele eisen met betrekking tot ‘multi-currency & triangulation’. De functionele eisen worden wordt beschreven in de ‘Basda EMU Specification for Application Software’. Deze door Basda in samenwerking met onder andere de Bank of England en de Fédération des Experts Comptable Européens (FEE) ontwikkelde standaard wordt in de branche algemeen erkend als de bruikbare standaard voor software applicaties. Dit document bestaat uit twee delen:
 
Multi-currency & triangulation. ‘Multi-currency’ heeft betrekking op de functionaliteit facturen en betalingen in meerdere valuta te kunnen verwerken, een vereiste voor de invoering van de euro. ‘Triangulation’ is de benaming van de wettelijk verplichte omrekeningswijze van EMU-bedragen via de euro.
 
Conversie. Dit is de overgang van de basisvaluta van het financiële systeem naar de euro.
 
De eerste certificaten zijn 15 januari 1999 uitgereikt en sindsdien zijn 24 financiële pakketten geaccrediteerd, waaronder producten van enkele van de grootste leveranciers van financiële software, zoals SAP, Oracle, Baan, Peoplesoft en Navision (zie kader 1).
Hoewel de vereisten die volgen uit de Europese wet en regelgeving door Basda zo goed mogelijk zijn vertaald naar functionele eisen die gesteld worden aan financiële software, blijkt ongeveer een derde van de pakketten niet direct te voldoen aan de gestelde eisen. Voor ons en voor de betreffende software-ontwikkelaars is dit vaak een ontnuchterende ervaring, die echter wel het nut van de accreditatie aantoont. Indien het product niet volledig blijkt te voldoen aan de gestelde criteria wordt nader overleg gevoerd over de te maken aanpassingen besproken, waarna een hertest plaats vindt.
Hieronder volgt een indruk te geven van de fouten die we het meest tijdens het accreditatieproces zijn tegenkomen.
 
Afronding tussentijds (‘intermediate’) euro-bedrag op twee decimalen
Voor de berekening van bijvoorbeeld een bedrag in Nederlandse gulden naar Finse Markka dient gebruik gemaakt te worden van het principe van ’triangulation’. Dat wil zeggen dat conversies tussen valuta binnen de EMU via de euro moeten worden berekend. Hierbij dient het tussentijdse euro-bedrag berekend te worden op minimaal drie decimalen. De fout die hierbij kan optreden is dat er voor de berekening gebruik wordt gemaakt van het op twee decimalen afgeronde eurobedrag, zie kader 2.
 
Afkappen. Er kan sprake zijn van afkappen (’truncation’) op drie decimalen, waarbij de derde decimaal van het tussentijdse euro-bedrag niet correct wordt afgerond maar ‘afgekapt’. Dit wordt weergegeven aan de hand van het voorbeeld in kader 3.
 
Dubbele afronding. Dit wordt weergegeven in kader 4.
 
Inverse wisselkoers. Bij het converteren van grote bedragen kan het gebruik van een inverse wisselkoers tot aanzienlijke verschillen leiden (kader 5).
 
Totaal versus regels. Een andere specifieke eis is dat bij het converteren van een factuur met meerdere orderregels het totaal leidend is en niet de sommatie van de geconverteerde individuele orderregels (kader 6).

Onjuiste logica

Een van de voornaamste redenen waarom pakketten worden afgekeurd is een onjuiste logica bij het boeken van de gevonden verschillen naar de juiste rekeningen. Er dient een aparte rekening te zijn voor de afrondingsverschillen binnen de EMU. Als gevolg van de fixatie van de koersen kan er geen sprake meer zijn van koersverschillen. Op deze EMU afrondingsrekeningen mogen echter geen betalingsverschillen worden geboekt. Indien één van beide bedragen niet in een EMU-valuta of de euro is weergegeven dient het verschil op een andere rekening, voor bijvoorbeeld koersverschillen of betalingsverschillen, te worden geboekt. Waar het op papier eenvoudig lijkt, is de praktijk toch weerbarstiger. Geregeld komen we pakketten tegen die geen onderscheid maken tussen betalingsverschillen en afrondingsverschillen of pakketten die kleine koersverschillen toch boeken op de EMU afrondingsrekening.

Beveiliging

Verder komt het voor dat de beveiliging van een pakket niet afdoende is. Het pakket dient in het geval van omrekeningen tussen EMU-valuta het gebruik van ’triangulation’ af te dwingen. Het is in deze gevallen niet toegestaan directe wisselkoersen (‘cross rates’) te gebruiken. Tevens mag het niet mogelijk zijn voor de eindgebruiker deze vaste wisselkoersen te wijzigen, bijvoorbeeld tijdens het aanmaken van een factuur. Deze maatregelen moeten in de software worden getroffen en wijken vaak af van gangbare beveiligingsmaatregelen.

Functionele eisen

Er is een aantal specifieke functionele eisen waaraan een pakket dient te voldoen. Ten eerste dienen veldgrootten voor de invoer van wisselkoersen groot genoeg te zijn voor het opslaan van de correcte vaste wisselkoersen. De wisselkoersen moeten dusdanig zijn gedefinieerd dat EMU = ‘vaste koers’ * EUR. Geen van de pakketten die wij getest hebben, had hier problemen mee. Wat wel voorkomt is dat pakketten niet in staat zijn alle valuta op de juiste wijze af te ronden. Pakketten die voorheen niet met decimalen gewerkt hebben, zoals bijvoorbeeld ‘single currency’-pakketten met als basisvaluta de Belgische franc, moeten nu decimalen kunnen gebruiken. Pakketten die voorheen alle valuta afrondden op twee decimalen dienen ook in staat te zijn bedragen weer te geven zonder decimalen. Een bijzondere positie neemt de Portugese escudo in: deze dient als enige EMU valuta te worden afgerond op één decimaal.
Hiernaast zijn er nog enkele andere eisen waaraan een pakket moet voldoen, die niet direct verband houden met de euro. Zo dient het invoerveld voor de facturen en betalingen voldoende groot te zijn. Pakketten die met name gebruikt worden in landen als Groot-Brittannië en Ierland die een relatief ‘dure’ munt hebben, moeten soms de invoervelden aanpassen zodat het ook mogelijk is aanzienlijke bedragen in een ‘goedkope’ valuta als de Italiaanse lire in te voeren. Dit is een vereiste, omdat de certificering geldig is voor heel Europa.

Onduidelijkheid bij ontwikkelaars

De ervaring bij het uitvoeren van de accreditaties heeft geleerd dat de euro-functionaliteit niet eenvoudig is in te passen in de software, en dat er bij de ontwikkelaars vaak onduidelijkheid heerst over de eisen waaraan het product moet voldoen. Basda heeft eisen geformuleerd waaraan (financiële) standaardpakketten dienen te voldoen. Het op juiste wijze vertalen van deze vereisten in een goede functionele specificatie voor het product blijkt in de praktijk echter geen eenvoudige opgave.
De toetsing door onafhankelijke EDP auditors levert niet alleen de nodige zekerheid voor ontwikkelaars en gebruikers, maar het doorlopen van het accreditatieproces kan ook daadwerkelijk bijdragen aan de kwaliteit van het product. De ontwikkelaars worden doordrongen van de complexiteit van de problematiek en eventuele fouten in het pakket komen tijdens de accreditatie onherroepelijk aan het licht.
 
Nico Huizing en Ivo Bolderhey, respectievelijk partner Ernst & Young EDP Audit, en senior EDP-auditor