Kan vi lita på kalkylark?

Fel i kalkylark

System för hantering och beräkning av kalkylark är idag oerhört kraftfulla och ger användaren tillgång till en mycket stor uppsättning funktioner och hjälpmedel. Just denna stora flexibilitet och kraftfullhet är samtidigt ett av de stora problemen. Med relativt få funktioner och referenser kan användaren bygga komplicerade beräkningsfunktioner. Samtidigt kan det räcka med ett enda referensfel, eller en felaktigt vald funktion, för att beräkningen ska ge helt fel resultat.

Det är väl känt sedan lång tid tillbaka att programmeringsfel är oundvikliga vid framtagning av datorprogram. Det är också väl känt att datorprogram måste testas ytterst noga, om merparten fel ska upptäckas. Tyvärr finns också gott om erfarenheter av att till synes mycket små fel i beräkningar kan medföra stora konsekvenser.

Konstruktion av kalkylark liknar i mångt och mycket programmering, och det finns samma möjligheter till fel:

• Specifikationen kan vara fel, så att kalkylen löser ett annat problem än det som egentligen behöver lösas.

• Förutsättningarna kan vara felaktiga, antingen därför att de är felaktigt angivna, eller därför att den som konstruerar kalkylarket missförstått dem.

• Modellen, metoden eller beräkningarna som används i arket är fel valda, antingen därför att den som konstruerar arket inte vet bättre, eller av misstag.

• Funktioner, referenser eller annat blir fel. Skälen kan vara allt från att den som konstruerar arket inte kan eller förstår de funktioner som används till rena ”mänskliga misstag”.

• Nya fel smyger sig in vid ändringar eller rättningar i kalkylarket.

Vissa risker är unika för kalkylark. Det är ytterst sällan som användare av misstag gör tekniska ändringar i vanliga IT-system. Däremot är det inte ovanligt att användare av kalkylark oavsiktligt ändrar funktioner eller referenser i arken.

Det kan räcka med några felaktiga ”peka och klicka” för att flytta en referens eller helt förändra en funktion. Om man dessutom använder ”förra veckans” kalkylark som underlag för nästa veckas beräkning, kommer varje oavsiktligt fel att leva vidare till dess någon upptäcker det, eller tills någon går tillbaka till ursprungsarket.

Kontroller för kalkylark

Det går att formulera enkla och tydliga kontrollmål och kontroller för kalkylark. De kontroller som beskrivs nedan kan förefalla onödigt omfattande, särskilt för den som är van att snabbt sätta ihop kalkylark. Kontrollerna är avsedda att göra det möjligt att med rimlig säkerhet lita på kalkylernas resultat. Omfattningen av kontrollerna illustrerar den skillnad – även vad gäller kostnader – som alltid finns mellan en första version av ett datorprogram eller kalkylark, och pålitliga IT-produkter.

Kontrollerna kan delas upp i utvecklingskontroller och användningskontroller. Utvecklingskontrollerna ska säkerställa att kalkylarket löser rätt problem och ger rätt resultat, medan användningskontrollerna ska säkerställa att rätt kalkylark används på rätt sätt.

Testning av kalkylark

Det har i praktiken visat sig vara mycket svårt att på ett effektivt sätt testa funktionen hos något mer komplicerade kalkylark.

Testning av datorprogram är erkänt svårt, oavsett vilka slags program det rör sig om. Kalkylark är på många sätt svårare att testa än andra program, bland annat därför att kalkylarken kan innehålla så många kraftfulla funktioner. Kalkylark saknar dessutom många av de inbyggda kontroller som andra programmeringssystem har. Ett exempel är att utvecklaren av kalkylark inte i förväg måste ange vilka slags data som varje cell ska få innehålla.

Ett av de kända problemen med testning är att det är svårt att testa alla tänkbara situationer som kan uppstå. Illustrationen med avrundning ovan är ett banalt exempel. Subtraktionen av de avrundade värdena ger ”fel” resultat när talen bar olika tecken. Om kalkylarket testas med enbart positiva (eller enbart negativa) värden, kommer detta inte att upptäckas.

Erfarna testare vet att man måste arbeta systematiskt och metodiskt. Ett exempel är att man alltid bör testa ”gränsfall” och felaktiga data – värdet noll, data som saknas, för små eller för stora värden, tomma filer, för stora filer etc. Annars riskerar användarna att råka ut för obehagliga överraskningar.

Det är också känt att det sällan räcker att bara testa program (eller kalkylark) som om de vore ett svart låda, som man inte vet hur den fungerar inuti. Man måste också granska och testa själva konstruktionen, bland annat genom att följa data från inmatning till resultat och genom att granska de formler som används. Testningen underlättas om man kan identifiera områden där risken för fel är särskilt stor. För kalkylark innebär detta bland annat att man undersöker hur olika celler refereras, om det finns absoluta referenser, om det finns celler med data som aldrig refereras, om det finns kopierade formler, där någon av kopiorna skiljer sig från de andra etc.

Erfarenheterna av hårt kontrollerad testning av kalkylark pekar på att det i de flesta organisationer är praktiskt taget omöjligt att genomföra effektiv och kvalitetsmässigt godtagbar testning av kalkylark utan automatiserade testhjälpmedel. En systematisk manuell testning medför dock vanligen en avsevärd höjning av kvaliteten av kalkylarken. Det är av många skäl bra att dokumentera testningen noga, både för att underlätta framtida testning och för att i efterhand kunna visa hur testningen gått till.

Kalkylark vid revision

Av det som sagts ovan framgår att det krävs många väl fungerande kontroller för att säkerställa att det går att lita på applikationskontrollerna i kalkylark. Om en eller flera kontroller saknas, kan vi således inte förlita oss på kalkylarkets resultat, varken för kontrollbaserad granskning eller som revisionsbevis.

Eftersom kontrollerna för kalkylark är bristfälliga i de flesta bolag, betyder detta att man normalt inte kan förlita sig till kalkylarken. Ett annat sätt att uttrycka det är att kalkylark nästan alltid måste jämställas med manuella beräkningar.

Detta behöver dock inte betyda att kontrollbaserad granskning är utesluten, så snart man stöter på ett kalkylark, Kalkylark som exempelvis bara används för extra avstämningar eller analyser ökar knappast risken för fel i redovisningen. I andra fall kan det finns ytterligare kontroller, som gör att de risker som kalkylarket tillför är små. Det kan därför löna sig att vara noggrann vid analysen av de risker som är förknippade med kalkylark och de kontroller som finns kring kalkylarken.

Koden för bolagsstyrning

Av FAR:s förslag till rekommendationer om översiktlig granskning av styrelsens rapport enligt Koden framgår tydligt att rapporten också ska omfatta IT-kontroller, i den utsträckning som andra kontroller i processerna är beroende av dessa. I rekommendationerna sägs att bolaget behöver kartlägga de IT-system som stödjer den finansiella rapporteringen, och identifiera risker relaterade till dessa IT-system. Bolaget behöver också utforma och införa kontroller för att hantera riskerna.

Dessa rekommendationer gäller oavsett om IT-systemen är kalkylark eller standardsystem. Det avgörande är vilka risker som är relaterade till IT-systemen, och vilka kontroller som behövs. Om bolaget i sin finansiella redovisning förlitar sig på beräkningar i kalkylark, måste bolaget därför se till att det finns tillräckliga utvecklings- och användningskontroller för kalkylarken, samt att kontrollerna är ändamålsenliga och fungerar.

Också här gäller att det kan finnas andra kontroller, som gör att bolaget inte behöver förlita sig enbart på kalkylarken. Detta är ytterligare ett skäl till att det är viktigt att kartlägga kalkylarken och de risker som är relaterade till dessa. Det är inte ovanligt att man först identifierar ett stort antal kalkylark av betydelse för den finansiella redovisningen, för att sedan successivt eliminera merparten, allt eftersom man upptäcker att de inte ökar risken för väsentliga fel i den finansiella rapporteringen.

Man kan argumentera för att bolagets inställning till användningen av kalkylark i den finansiella redovisningen, liksom i framtagningen av underliggande data till rapporteringen, är en del av de bolagsövergripande kontrollerna. Avsaknaden av bolagsövergripande riktlinjer för användningen av kalkylark är i så fall en brist, som ökar risken för fel.

Råd till företagen

Varje förbättring i kontrollerna kring kalkylark kan vara intressanta för företagen, eftersom de minskar riskerna för felaktiga resultat. Det finns gott om enkla tips och råd om säkrare utveckling och användning av kalkylark. Det räcker med att söka på internet för att hitta såväl hela handböcker som enkla sammanställningar av tips.

Ett exempel på vad företag kan göra finns i en magisteruppsats, som två studenter från Högskolan i Borås skrev i våras. De undersökte problemen med kalkylark, och föreslog en enkel metod för att förbättra utvecklingen och användningen (Jenny Sjöström och Marie Wilhelmsson, ”Säkrare utveckling och användning av kalkylark i mindre och medelstora företag – en metod”, Högskolan i Borås 2006). Uppsatsen innehåller exempel på hur man kan motivera och genomföra olika åtgärder.

Avslutning

Kalkylark är, som det sägs i inledningen, utmärkta hjälpmedel för beräkningar, analyser och presentationer. De gör det möjligt att med små insatser bygga vad som egentligen är komplicerade IT-system. Det är just dessa möjligheter som är det stora problemet vad gäller intern kontroll för kalkylark. Det är en utmaning för företagen – och oss alla – att utnyttja friheten och kraftfullheten i kalkylarken, samtidigt som man upprätthåller nödvändig intern kontroll i de finansiella processerna.

Anders Beckman är director inom avdelningen för IT-revision och Informationssäkerhet vid Ernst & Young i Stockholm.