Balans nr 8–9 2006

Kan vi lita på kalkylark?

De inneboende riskerna är stora och den interna kontrollen svag

Frågan om vilket förtroende man kan ha för beräkningar gjorda i kalkylark är berättigad. Frågan har diskuterats lika länge som kalkylark funnits och använts, men den har ställts på sin spets bl.a. på grund av kraven på intern kontroll i den amerikanska Sarbanes-Oxley-lagstiftningen och den svenska Koden för bolagsstyrning, skriver Anders Beckman och sammanfattar situationen: De inneboende riskerna i kalkylark är stora, samtidigt som den interna kontrollen för kalkylark i de flesta fall är svag. Han diskuterar såväl riskerna som förslag till åtgärder i artikeln.

I artikeln används genomgående benämningen kalkylark. De i särklass mest använda systemen för beräkning och hantering av kalkylark är Microsoft Excel i olika versioner. Kalkylark används i artikeln som benämning på allt från enstaka kalkylark och arbetsböcker till system av ark efter arbetsböcker som samverkar för att tillsammans uppnå en önskad funktion.

Kalkylark är utmärkta hjälpmedel för beräkningar, analyser och presentationer. De gör det möjligt att med små insatser göra inte bara komplicerade beräkningar, utan också grafiskt tilltalande presentationer. Kalkylark kan även användas för att, på samma sätt som andra IT-system, hämta och sammanställa data från ett antal olika källor.

Av dessa och andra skäl används kalkylark i stor omfattning i företagens processer, inklusive den finansiella redovisningen. Antalet kalkylark i ett företag kan vara mycket stort. En sökning genom ett företags filkataloger kan visa på tiotusentals kalkylarksfiler. De flesta av dessa har troligen bara använts någon enstaka gång, till exempel för en avstämning eller som underlag för en presentation. Men det brukar ändå finnas ett antal kalkylark som används i väsentliga finansiella processer. Det är exempelvis inte ovanligt att kalkylark används för värderingar, eller för att flytta data från försystem till huvudboken.

Såväl praktisk erfarenhet som särskilda studier visar att risken för att kalkylark innehåller mer eller mindre omfattande felaktigheter är stor. Olika undersökningar har givit skilda resultat.

Det finns väl underbyggda undersökningar som redovisar materiella fel i 10 procent av de granskade kalkylarken. Dessa kalkylark användes i företag och utförde väl kända beräkningar. Andra undersökningar har visat på mycket högre andel felaktiga kalkylark. Då har man vanligen också räknat in mindre allvarliga fel. (Den uppsats som nämns i slutet av artikeln innehåller omfattande referenser till undersökningar av fel i kalkylark.)

Undersökningar och praktiska erfarenheter av granskningar har också visat att den interna kontrollen för kalkylark i många fall är så gott som obefintlig. Att utvecklingen av arken är ostrukturerad, att testningen inte är dokumenterad, att versionshantering saknas, att arken saknar skydd mot oavsiktliga ändringar och att genomförda beräkningar inte arkiveras är exempel på ofta förekommande brister.

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:

  1. Specifikationen kan vara fel, så att kalkylen löser ett annat problem än det som egentligen behöver lösas.
  2. 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.
  3. 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.
  4. 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”.
  5. 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.

Utvecklingskontroller

I utvecklingskontrollerna kan ingå att:

  1. Det finns en beskrivning av vad kalkylarket gör, inklusive eventuella begränsningar (t.ex. lägsta och högsta ränta som arket kan hantera korrekt).
  2. Det finns en användarhandledning, som beskriver hur arket ska användas, inklusive hur indata ska anges, vilka filer som genereras etc.
  3. Kalkylarket är utvecklat, uppbyggt och underhållet på ett strukturerat sätt, så att det är möjligt att förstå hur det fungerar, och så att det exempelvis är möjligt att testa funktionen hos enskilda delar av kalkylarket var för sig.
  4. Kalkylarket är utformat så, att alla delar är låsta utom de celler där användaren ska mata in data.
  5. Det finns fastställda rutiner för hur ändringar i kalkylarket ska utföras, dokumenteras och testas, och för hur nya versioner av kalkylarket ska identifieras (förändringshantering och versionshantering).
  6. Kalkylarket är testat så att man med rimlig säkerhet vet att det fungerar som avsett, och att automatiserade kontroller i arket fungerar på rätt sätt.
  7. Kalkylarket lagras ”skrivskyddat” på en utpekad plats. Skyddet är till för att säkerställa att arket inte ändras av misstag (eller avsiktligt för att underlätta någon oegentlighet).
  8. Kalkylarket säkerhetskopieras, så att det inte förloras.
  9. ”Ägaren” av kalkylen har formellt godkänt kalkylarket för användning, och därmed också intygat att kontrollerna 1–8 ovan är uppfyllda.

Om utvecklingskontrollerna är rätt utförda, ska resultatet vara ett godkänt, väl fungerande kalkylark, som är säkert lagrat och lätt att hitta och identifiera.

ABA–BAvkortade före subtraktionAvrundade före subtraktion
− 2,5− 4,5222
− 1,5− 3,5222
− 0,5− 2,5222
− 0,5− 1,5213
  1,5− 0,5213
  2,5  0,5222
  3,5  1,5222
  4,5  2,5222
  5,5  3,5222

Ovanstående kalkylark visar skillnaden mellan talen A och B för olika värden (kolumnen A–B). I de övriga kolumnerna visas skillnaden mellan talen när de avkortas respektive avrundas till heltal före subtraktionen. Exemplet är avsett att illustrera hur även mycket enkla funktioner kan ge resultat som förefaller ointuitiva, även om de fungerar som avsett. Den som är uppmärksam ser dock att avrundningen (i detta fall i Microsoft Excel) inte följer SS 014141 Regel A.

Användningskontroller

I användningskontrollerna kan ingå att:

  1. Användaren är inte samma person som kalkylägaren (om man vill ha samma ansvarsuppdelning mellan utveckling och drift som för IT-system).
  2. Rätt kalkyl, och rätt version av kalkylen, används.
  3. Kalkylarket kopieras direkt från den skyddade lagringsplatsen, så att det inte innehåller några av misstag införda fel.
  4. IT-miljön, där kalkylarket används, är skyddad, bland annat från obehörig användning och virus och annan skadlig programvara som kan införa fel i kalkylerna.
  5. Kalkylarket lagras efter användning i ett skyddat ”arkiv”, som verifikation på användningen och resultatet. Arkivet säkerhetskopieras för att förhindra dataförlust.

För att säkra verifikationen ytterligare kan användaren signera kalkylarket med en digital signatur innan det arkiveras. Flera av kontrollerna underlättas om man utnyttjar ett dokumenthanteringssystem för lagring av såväl ”original” som ”verifikat”. I dokumenthanteringssystem finns stöd för såväl skrivskydd som signering och säkerhetskopiering.

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.

Sifferkollen Läs mer

Belopp

Basbelopp
År 2019 2020 2021
Prisbasbelopp 46 500 47 300 47 600
Förhöjt pbb. 47 400 48 300 48 600
Inkomstbasbelopp 64 400 66 800  
Utdelning fåmansföretag
År 2018 2019 2020
Schablonbelopp 169 125 171 875 177 100

Räntesatser

Periodiseringsfond
År 2018 2019 2020
Räntesats 0,36 0,51 0,50

 

Referensränta
År 2016-07-01 2019-07-01 - 
Räntesats -0,5 0,0
Ränta på skattekontot
Period 2013-2016 2017 -
Intäkt 0,5625 0
Kostnad Låg 1,25 1,25
Kostnad Hög 16,25 16,25
Räntefördelning
Inkomstår 2018 2019 2020
Positiv 6,49 6,51 6,50
Negativ 1,50 1,51 1,50
Statslåneränta
År 2018 2019 2020
31 maj 0,49 0,05 -0,01
30 nov 0,51 -0,09  

Traktamenten

Bilresor
Inkomstår 2018 2019 2020
Egen bil 18,50 18,50 18,50
Förmånsbil, diesel 6,50 6,50 6,50
Förmånsbil, bensin 9,50 9,50 9,50
Kostförmån
År 2018 2019 2020
Frukost, lunch och middag 235 245 245
Lunch eller middag 94 98 98
Frukost 47 49 49
Skattefria gåvor
År 2018 2019 2020
Julgåva 450 450 450
Jubileumsgåva 1 350 1 350 1 350
Minnesgåva 15 000 15 000 15 000

Skattesatser

Bolagsskatt
År 2018 2019 2020
Skattesats 22% 21,4% 21,4%
Mervärdesskatt
År 2018 2019 2020
Normal

25 %

25 % 25 %
Livsmedel, krog m.m. 12 % 12 % 12 %
Persontransport, böcker m.m. 6 % 6 % 6 %
Arbetsgivaravgifter/egenaavgifter
Födda -1937 1938 - 1954 1955 -
Arb. avgifter 0 % 10,21% 31,42%
Egenavgifter 0 % 10,21% 28,97%