I den fjärde ADB-bulletinen från FARs databehandlingskommitté tas några aktuella och delvis kontroversiella frågor upp. Programföretagen bör se till att klienternas redovisningsinformation blir lättare att komma åt med hjälp av registeranalysprogram. Vidare diskuteras bl.a. dokumentationen av klienternas ADB-system, granskning av informationen i klienternas kalkylmallar samt en hel del nya teknikaliteter som snart blir vardagsmat för revisorerna.
Analysvänligare ekonomisystem
Revisorn kan höja kvalitén på revisionsarbetet och spara tid genom att bearbeta dataregister.
Registeranalys kan t.ex. bestå av ålders- och betalningsanalys av kundreskontror, urval av trögrörliga lagerartiklar med stort värde och stickprov på verifikationer från huvudboksregister.
Registerinformation kan fås genom att register i företagets datorbaserade system kopieras eller genom att systemet tar fram registerutdrag med eftersökt information.
Registerkopia/utdrag kan sedan bearbetas på företagets eller revisorns dator.
Oavsett hur registren skapas behöver revisorn en s.k. postbeskrivning till respektive register. Postbeskrivningen ska tala om var olika fält i en registerpost finns. Sådana fält är t.ex. artikelnummer, genomsnittspris, senaste anskaffningspris och saldo.
Men hur ska företagets system se ut för att registren ska kunna analyseras?
Ja, för det första krävs att företaget och/eller revisorn är väl förtrogen med systemen. Företag med egen ADB-funktion kan ofta ge god hjälp åt revisorn. Problem blir det däremot när företagets personal inte har någon djupare ADB-kunskap. Här kan ofta systemleverantören beskriva vilka register som finns och de poster som ingår, åtminstone när det gäller standardsystem för minidatorer.
Med ekonomisystem för PC kan det vara annorlunda. De är ofta standardsystem och inte speciellt anpassade till verksamheten. Leverantören vill – av konkurrensskäl – inte gärna lämna ut information om registerstruktur och -innehåll. Detta framgår ofta inte heller av systemdokumentationen. Den är ofta bara en användarbeskrivning.
Här bör systemleverantörerna ändra och skärpa sig! Att lämna informationen är en service åt användarna. Det borde dessutom vara ett bra försäljningsargument.
Databehandlingskommittén ser fram emot analysvänliga ekonomisystem till nytta för företag och revisorer.
Test av registeranalysprogram
Grant Brodie vid Deloitte Haskins & Sells i Kanada har testat ett antal registeranalysprogram: ACL (Audit Command Language), Applaud, CARS 5 PC, Easytrieve Plus PC samt IDEA (Interactive Data Extraction and Analysis).
Testfilen innehöll 20.000 poster (1,6 megabyte) – enligt rapporten en typisk ”liten revisionssituation”.
Rapportens övergripande slutsats är att det egentligen inte finns några ursäkter för att inte använda PC för registeranalys.
De testade produkterna är kompletta programvaror för ändamålet. De arbetar relativt snabbt, har kraftfulla kommandon och medför ganska låga kostnader för analysarbetet. Användarstödet får gott betyg. Att analysera på PC är också bekvämt. Likheten med stordatorbaserade registeranalysprogram anses stor. Det underlättar för dem som är vana vid den miljön. Arbetet i PC-miljö innebär att revisorn har god kontroll över körningarna.
Alla de granskade programmen klarar att ta över data från stordatormiljö till PC. Två av dem kan direkt läsa band från stor- och minidatorer. Fyra kan läsa/konvertera data när de väl överförts till PC-hårddisken. Ett program har en separat överföringsfunktion för den här processen.
Det är ganska stora skillnader mellan programmen fastän de arbetar inom samma koncept. Vart och ett av dem kan därför upplevas som särskilt starkt under speciella omständigheter.
ACL får toppbetyg. Det bearbetar snabbt och har kraftfulla kommandon. Det är flexibelt och i högsta grad interaktivt om man ser på tiden mellan revisionsfråga och svar från datorn.
IDEA har en interaktiv och heltäckande menystyrning som gör det lätt att komma åt data för analys. Bearbetningshastigheten är inte så hög. Trots att programmet är gjort för dialog med användaren, kommer man för typiska filstorlekar mest att utnyttja det för s.k. satsvis bearbetning.
CARS 5 PC vänder sig till den breda nisch av revisorer som redan förut kan just CARS. Hög bearbetningshastighet är ett starkt plus. Men programmet är inte interaktivt och dokumentationen skral. Ett program främst för experten.
Applaud är främst avsett för att utveckla tillämpningssystem. Även enkla revisionsfunktioner kräver ganska mycket förberedelser. Det sättet att angripa problemen gör det dock mycket enkelt att sedan delegera arbetsuppgifter och att upprepa analyser under kommande granskningssäsonger, bl.a. på grund av den omfattande dokumentation som systemet ger.
Easytrieve PC vänder sig främst till dem som arbetar med att utveckla och använda Easytrieve-tillämpningar i stordatormiljö. Med Easytrieve PC kan delar av arbetet göras i PC och sedan överföras till stordator.
Dokumentation av klienternas ADB-system
Hur ska revisorn tillräckligt väl förstå klientens databehandlingsmiljö? Det är en intressant fråga med många svar.
Revisorn bör börja med att samla in information och dokumentera omfattningen av klientens ADB-rutiner. Ibland saknas tyvärr en övergripande beskrivning i klientens egen dokumentation.
Revisorn bör vidare gå igenom företagets övergripande ADB-kontroller och se på den interna kontrollen i väsentliga applikationssystem.
Det här kan med fördel ingå i den normala riskanalysen när revisionsinsatsen planeras.
Revisorn behöver känna till ADB-verksamhetens organisation och vilka tillämpningssystem som används. I samband med detta är det lämpligt att bedöma om ADB-bearbetningen kan medföra väsentliga fel, brister eller osäkerhet i redovisningen.
När det gäller generella kontroller finns en beskrivning av bakgrund och arbetssätt i FARs bok Revision II. Information om generella kontroller dokumenteras främst genom intervjuanteckningar.
Den interna kontrollen i applikationssystemen granskas som ett led i den ordinarie granskningen av intern kontroll i och kring klienternas redovisningssystem. Inriktningen bör styras av slutsatserna från den inledande riskutvärderingen beträffande datormiljö och övergripande kontroller.
Kontrollerna inom respektive tillämpningssystem bör innebära att samtliga data bearbetas, att de bearbetas endast en gång och att endast godkända data bearbetas. Bearbetningen måste vara korrekt och ändamålsenlig och kontrollera att transaktioner och registerposter är kompletta och riktiga. Kontroll ska ske av att data bevaras betryggande, att systemet redovisar en obruten verifieringskedja och att erhållna rapporter och kontrollistor används på avsett vis.
Revisorns systemdokumentation – i första hand avsedd för intern kontroll och planering av revisionsinsatsen – bör innehålla indata, bearbetningar, register, koppling till andra system, rapporter och kontroller.
Hittar revisorn väsentliga svagheter vid revisionen av ett tillämpningssystem ska detta rapporteras till företagsledningen och i allvarligare fall även till styrelsen.
Slutsats angående dokumentationen av klienternas ADB-system: Det är viktigt att revisorns granskning, dokumentering, bedömning och slutsatser angående intern kontroll och ändamålsenlighet i klienternas datorbaserade redovisningssystem tas till vara inom ramen för den gängse revisionen.
Åskådlighet är särskilt viktig: klienten kan ju också använda revisorns dokumentation för att stärka den interna kontrollen.
Granskning av klienters datoriserade kalkylmallar
Allt fler klienter använder kalkylprogram, t.ex Lotus 1-2-3, Symphony, Excel och SuperCalc, för ekonomiska modeller – allt från koncernkonsolideringar med tillhörande skatteberäkning till redovisning av anskaffningsvärden och avskrivningar på anläggningstillgångar.
Därför får revisorerna allt oftare ta ställning till om uppgifter i kalkylmallar är fullständiga och riktiga.
Ett problem är att materialet då inte kan stickprovsgranskas på vanligt sätt eftersom kalkylmallar sällan är transaktionsorienterade. Dessutom är många kalkylmallar inte dokumenterade eller särskilt välstrukturerade. Revisorn kan rimligen inte heller veta hur samtliga kalkylprogram fungerar och vilka svagheter de har. Det finns olika sätt att lösa de här problemen.
En möjlighet är en ”visuell” granskning. Revisorn och klienten går igenom mallen på bildskärmen. Det fungerar i huvudsak på enklare mallar.
Revisorn kan också utforma egna kontroller utifrån utskrifter från klienten. Sedan kan revisorn lägga in sina kontroller i en kopia av mallen.
Revisorn kan även simulera beräkningar – med hjälp av egna inlagda värden där resultatet är känt på förhand. På så sätt kan revisorn se om mallen stämmer.
Vilka olika tekniker kan revisorn tillämpa?
Ja, de flesta program kan ställas om så att de visar formler i stället för belopp för de celler som innehåller beräkningar. I många program fungerar detta bara när formlerna är korta. Annars finns risken att de inte får rum i utskriften.
De flesta program kan skriva ut cell för cell med exakt innehåll. En sådan lista kan ses som en ”källkod” för kalkylmallen. Listan bör alltid tas ut. Den är under alla omständigheter en bra referens när revisorn går igenom mallen på bildskärmen.
Granskningen underlättas om klienterna gör kalkylmallen på rätt sätt. Tio viktiga punkter att tänka på är:
1. Planera mallen väl. Då blir den bra.
2. Enkelhet framför allt.
3. Organisera mallen väl. Dela upp den i områden: indata, beräkning, utdata.
4. Använd okomplicerade formler. Förändringar underlättas och andra förstår bättre hur mallen fungerar.
5. Använd valideringstester. Lägg in tester som visar att riktiga uppgifter matats in.
6. Testa mallen och gå igenom den ordentligt innan den tas i produktion.
7. Använd gärna grafik för att förklara trender, relationer m.m.
8. Dokumentera mallen väl. Det har både den som byggt mallen och andra användare nytta av.
9. Använd ”Protect”-kommandot för att skydda formlerna. Det minskar risken för att formler skrivs över med felaktiga resultat som följd.
10. Gör regelbundna säkerhetskopior av både mallar och data.
Slutsats om kalkylmallar: Underlag för redovisningen måste ofta direkt verifieras av revisorn. Det gäller även data och beräkningar i en kalkylmall. Välj ett angreppssätt som svarar mot hur tekniskt invecklad klientens kalkylmall är. Uppgifter i kalkylmallen måste naturligtvis också där det är tillämpligt kontrolleras mot källdokument.
Funktioner i systemprogram är intressanta för revisionen
Systemprogram är t.ex. MS-DOS, OS/2, Unix och Finder. Dessa program tolkar instruktionerna från tillämpningsprogrammen och översätter dessa till begrepp som datorn ”förstår”. Systemprogrammen brukar ofta också övervaka verksamheten i datorsystemet.
Dessa program har naturligtvis stor betydelse för frågor om kontroll och säkerhet i ADB-miljöer – som i sin tur har stor inverkan på ett företags interna kontroll och på hur företagsledningen kan övervaka verksamheten.
Det finns flera skäl för revisorn att granska funktioner i systemprogram.
Ett skäl är behörighetskontrollerna. De låg tidigare i själva tillämpningssystemen. Nu sköts de ofta av generella systemprogram.
Vissa funktioner i systemprogrammen är också nödvändiga för att skydda mot obehörig åtkomst till ADB-systemen.
Att behörighetskontrollen flyttats från tillämpningssystemet till generella behörighetskontrollsystem innebär både ökad säkerhet och ökad sårbarhet.
Säkerheten ökas genom att administrationen förenklas.
Sårbarheten ökar därför att fler tillämpningssystem – och därmed ett större antal transaktioner – berörs.
Detta ställer i sin tur högre krav på väl fungerande kontroller av själva operativsystemet.
Att gå igenom en större ADB-miljö behöver omfatta att granska såväl manuella rutiner och programfunktioner i tillämpningsprogram som programfunktioner i systemprogram och kontrollfunktioner i själva datorerna.
Likheterna mellan system- och tillämpningsprogram är från kontrollsynpunkt ganska stora. I praktiken granskas ändå funktioner i systemprogram mycket sällan, främst på grund av att de är svårtillgängliga och invecklade. Revisorn bör dock som en del i sin granskning göra klart för sig om klientens företagsledning har tillgodosett att kontrollen över åtkomst och data är tillfredsställande.
Några begrepp från en IBM-stordatormiljö
Operativsystemet MVS för IBMs större datorer är mycket vanligt i dagens kommersiella databehandling. RACF heter ett av de behörighetssystem som IBM har. Men beskrivningen här kan också tillämpas på andra behörighetssystem i samverkan med MVS.
I MVS skiljer man på när program bearbetas med ”auktoriserad status” eller ”problemstatus”. Bearbetning med auktoriserad status uppfattas som en utvidgning av operativsystemet. Då kan man skaffa sig behörighet att ”göra allt” inom systemet. När program däremot bearbetas som ”problemprogram” kan ursprungligen tilldelad befogenhet inte överskridas.
Ett centralt kontrollmål i just MVS-miljö är därför att bara speciellt godkända program ska ha auktoriserad status.
Med auktoriserad status kan man upphäva behörighetskontrollen och loggningen i RACF, såväl generellt som selektivt. En person med rätt kunskaper kan alltså totalt ändra förutsättningarna för sitt arbete med systemet och övervakningen av vad som utförts.
Kontrollen över program som fått auktoriserad status är alltså viktig. Risken för databrott finns. Oavsiktliga fel kan också begås med den indirekta risken att de kan inleda någon i frestelse att göra något otillåtet.
Befintliga kontrollfunktioner kan användas bättre
De användare som kan tänkas avsiktligt missbruka auktoriserad status är i huvudsak de som utvecklar tillämpningssystem – d.v.s. ofta mer än halva arbetsstyrkan inom en större ADB-avdelning. Genom att utnyttja MVS arkitektur och funktioner i behörighetskontrollsystemet kan man ganska billigt hindra att den här gruppen missbrukar känsliga funktioner.
Värre är det med möjligheterna att kontrollera t.ex. systemprogrammerare och operatörer. Systemprogrammerarna vet ofta tillräckligt för att kunna missbruka väsentliga funktioner. Men systemprogrammerarna är inte så många. Operatörerna har vanligen en omfattande behörighet men vet ofta inte tillräckligt om systemet för att kunna missbruka det.
I dag finns det hjälpmedel för revisorer som ska granska systemprogram. För MVS-miljö har programmet Examine MVS utvecklats. Examine ger omfattande och överskådlig information om hur man löst bl.a. de frågor som beskrivits här.
Slutsats om systemprogram: Funktioner i systemprogram är av stort intresse för revisionen. Där de har väsentlig inverkan på omständigheterna kring databehandlingen bör de granskas av revisorn inom ramen för den vanliga revisionen.