Auktor revisor Lars Elvstad, FARs ordförande 1970–1972, och Stefan Elvstad, som i 4 år arbetade på ett större företags dataavdelning och nu är knuten till en revisionsbyrå, tar i denna artikel upp revisorns granskning av datorbaserad redovisning. Författarna framhåller att ADB-tekniken ej har ändrat revisionens uppgifter, men har lett till att arbetet i större utsträckning omfattar studium och bedömning av system, deras uppbyggnad och användning.
Utvecklingen mot större företag och företagskombinationer ledde till att revisorerna fick en annan inriktning i sitt granskningsarbete. Den växande volymen av verifikationer blev alltför tidsödande att detaljgranska. Man kom istället att fästa allt större vikt vid den interna kontrollens betydelse för riktigheten i företagens löpande redovisning. Bedömning av den interna kontrollens effektivitet fick därigenom även en förebyggande betydelse för eliminering av brister och fel i bokföringen. Tillkomsten av alltmera avancerade behandlingsmetoder främst genom ADB-tekniken accentuerade denna utveckling. Svårigheten – ibland omöjligheten – att visuellt följa en transaktion från start till mål genom ett klart referenssystem för varje post i och mellan olika behandlingsled (audit trail) gjorde det nödvändigt för revisorerna – liksom för klientens egen personal – att i detalj känna redovisningssystemen för att kunna bedöma resultatens tillförlitlighet.
ADB-tekniken har ej ändrat revisionens uppgifter, men har lett till att arbetet i större utsträckning har kommit att omfatta studium och bedömning av system, deras uppbyggnad och användning. Denna utveckling – liksom den ökade användningen av stickprovsteknik – har även haft en stimulerande effekt på granskaren, som kommit ifrån den monotona verifikationsgranskningen.
Revisorns granskning av datorbaserad redovisning kan sammanfattas i följande huvudavsnitt: granskning av intern kontroll, bokslutsgranskning samt användning av särskilda program för efterkontroll och analys med utnyttjande av datorn.
Intern kontroll
Vid huvudsakligen manuella system kräver en riktig behandling av primärmaterialet – förutom bl a en lämplig arbetsfördelning innefattande viss efterkontroll av i tidigare led utfört arbete – mer eller mindre utförliga instruktioner för arbetets utförande. Graden av utförlighet är beroende av arbetskraftens kvalifikationer. En dators behandling av primärmaterialet är helt beroende av de i programmet givna instruktionerna. I motsats till människan kan datorn ej utföra sitt arbete på annat sätt än instruktionerna anger.
Men de givna instruktionerna kan ändras genom operatörens ingripande. Det är därför nödvändigt att göra instruktionerna (programmet) så utförliga att förutsättningar finns för att databehandlingen kan ge riktiga resultat. Det är också viktigt att dessa instruktioner inte sättes ur spel genom oavsiktliga felgrepp av operatören. Huvudvikten måste därför läggas på utvecklingen av programmen och på organisationen av arbetet i datacentralen. Givetvis måste också det i datorn inmatade utgångsmaterialet vara riktigt för att slutresultatet skall bli riktigt. Vidare måste tillses att de färdiga resultaten kommer till rätt användare.
SYSTEM- OCH PROGRAMUTVECKLING
System- och programutvecklingen har flera faser. Den första består i fastställandet av den information som erfordras av användaren på grundval av det tillgängliga primärmaterialet (t ex externa och interna verifikationer till transaktioner som skall behandlas). Detta är av grundläggande betydelse för det systemarbete som sedan skall utföras. Då revisorn är en av användarna, bör han liksom företagets egen berörda personal medverka redan på detta stadium, bl a av det skälet att systemarbetet är mycket tidskrävande och därför kostsamt. Ändringar i ett färdigt system för att tillfredsställa senare framförda önskemål är mycket dyrbara och kan inte alltid genomföras utan betydande tidsförlust. Härav följer att en fast organisation för hela systemutvecklingen bör tillskapas där samtliga användare är representerade och ansvariga för sina kravspecifikationer. Dessa bör presenteras i skriftlig form och ingå i systemdokumentationen och efter prövning godkännas av styrgruppen. Om användarna får ett ekonomiskt ansvar för den begärda informationen, undvikes lättare att kravspecifikationen göres onödigt omfattande och därmed kostsam att producera.
Med utgångspunkt från dessa underlag utarbetar systemspecialisterna en översiktlig systembeskrivning som prövas av styrgruppen och de av systemet berörda. Bl a undersökes om systemet svarar mot de uppställda kraven och om det kan genomföras på grundval av tillgängliga primäruppgifter. Efter revidering och godkännande vidtar detaljerad systembehandling och – efter godkännande – programmering, d v s framtagning av erforderliga instruktioner för datorn.
Såväl systemutveckling som programmering bör utföras enligt fastställda regler, bl a omfattande krav på enhetliga normer och fullständig dokumentation med föreskrivet godkännande i olika delfaser.
När programmet godkänts överföres det till för datorn läsbar form och provas i datorn. Programtestet bör ske med ”levande” material, d v s inom företaget befintligt, aktuellt primärmaterial, som bör omfatta alla förekommande och praktiskt tänkbara varianter av transaktioner o dyl. Det är nödvändigt att användarna av den begärda informationen noga tar del av och prövar testresultaten innan programmet slutgiltigt godkännes för produktion. Det måste också tillses att programmet i dess helhet är fullständigt dokumenterat innan styrgruppen ger sitt godkännande. Senare ändringar i systemet skall följa samma rutiner för specificering, provning, dokumentering och godkännande innan de får tillämpas i produktion. Om programmet – vilket är det vanliga – skall samköras med andra program måste givetvis programtestet även omfatta sådan samkörning.
Då det ofta visat sig att fel och brister uppstår vid inkörning av ett program, bör inkörningen under en övergångstid ske parallellt med förutvarande rutiner för behandling av primärmaterialet.
Dokumentationen över system och program bör förvaras under betryggande former. Detta är nödvändigt av säkerhetsskäl – kopior bör finnas på säkert ställe så att en eventuell brand eller sabotage ej hindrar ostörd produktion; dokumentationen bör ej heller vara tillgänglig för operatörerna, så att deras möjlighet att ändra programmen eller manipulera med dem ej onödigtvis underlättas.
Vid systemutvecklingen bör noga tillses att önskade kontroller – bl a sådana som kan inbyggas i programmet – tillvaratas. Datorbehandlingen är dyrbar och sker under tidspress, varför man måste söka undvika ofullständiga resultat och omkörningar av materialet. Vidare bör i systemet ingå rutiner för avstämning av datorbehandlingens resultat i olika stadier mot utgångsmaterialet.
REGISTER OCH DATABEHANDLING
Vid databehandlingen användes, förutom det till maskinläsbar form överförda primärmaterialet (t ex en verifikation), särskilda register i vilka datorns arbete regleras och resultatet uppsamlas. Sådana register kan ha olika innehåll efter sitt ändamål och kan ha olika form.
Efter ändamålet skiljer man emellan sådana register som innehåller de resultat som framkommit vid behandlingen endast av utgångsmaterialet – t ex transaktionsregister. Detta register kan i sin tur samköras med ett huvudregister, t ex innehållande huvudbokens konton eller personkontona i reskontran. Man talar om uppdatering av huvudregistret. Man använder även särskilda register med t ex prisuppgifter för olika varuartiklar eller lönesatser. Genom samkörning av transaktionsregister över exempelvis levererade varor med ett varuprisregister kan man via datorn erhålla färdiga kundfakturor och en journal över dessa fakturor. Även datorns program kan ligga i ett register.
De vanligaste formerna för register är magnetband och skivor (skrivminnen). Datorn är normalt sammankopplad med en konsolskrivare för utskrift av information om databehandlingen (program, register, tidpunkter för körningens början och slut samt för avbrott och för ingrepp av operatören). För önskad utskrift i vanlig läsbar form av körningens resultat användes särskild skrivare som får sina impulser från datorns program.
Program och andra register bör förvaras avskilt från obehöriga, vartill även bör räknas operatörerna. Detta motiveras av krav på ordning för att erforderliga register skall finnas tillgängliga i rätt tid för planerad körning. Det är även viktigt att endast avsedda register utlämnas till operatörerna så att ej registrens innehåll förvanskas. Dessutom reduceras operatörernas möjlighet att ändra programmens och registrens innehåll genom den begränsade tid varunder de kan hantera dem. Systemberedare och programmerare bör ej heller ha tillgång till register och för produktion godkända maskinprogram. Hanteringen av och kontrollen över huvudregister och register med stående uppgifter (t ex prisregister) bör vara särskilt omsorgsfull.
Utlämning och återlämning av program och register bör diarieföras – då så är tillämpligt vid aktuell installation – med angivande av klockslag och datum samt av mottagare och inlämnare.
Arbetet i datacentralen bör utföras enligt skriftliga instruktioner som innefattar erforderlig arbetsfördelning. Att instruktionerna efterleves bör övervakas av chefspersonalen i datacentralen och utfört arbete bör vara så dokumenterat att det kan kontrolleras i efterhand, t ex av revisorn.
Likaså bör fullgod dokumentation föreligga över mottaget primärmaterial och utlämnade resultat samt över de avstämningar som skett. Regler bör finnas för löpande kontroll av datautrustningens kondition.
Noggranna regler bör finnas även ifråg om formerna för att begära körningar i datacentralen av visst material. Varje körning bör noteras i en särskild dagbok med erforderliga uppgifter om tidsåtgång, avbrott, använda register, berörd personal m m.
Revisorn bör genom besök i datacentralen förvissa sig om att givna regler är tillfredsställande och att de följes. För sin granskning av system, bearbetning och övrig hantering kan han använda frågeformulär. Lämpliga hjälpmedel är av FAR utgivna publikationer med synpunkter på intern kontroll i resp revision av datorbaserade redovisningssystem.
Bokslutsgranskning
När revisorn förvissat sig om att den interna kontrollen fungerar tillfredsställande (både före, under och efter databehandlingen; att lämplig arbetsfördelning skett vid system- och programutformningen; att program- och registervård samt bearbetning sker under betryggande former och övervakas; att yttre säkerhetsåtgärder är vidtagna; att realistiskt handlingsprogram föreligger i händelse av brandskada o dyl) kan han använda den datorbaserade informationen på ungefär samma sätt som han använder uppgifter i manuella system.
Han bör sålunda förvissa sig om att erforderliga kontospecifikationer framtages för bokslutsgranskningen. Kontrollen av dessa mot från tredje man erhållna uppgifter (bankbesked; saldobekräftelser från kunder, leverantörer och andra kreditgivare) sker med samma mål och samma teknik som revisorn använder i andra fall. Likaså hans avstämning av konton genom egen fysisk inventering eller genom egna beräkningar av t ex upplupna kostnader och av balansgilla kostnader. Skillnaden är egentligen den att revisorn i allmänhet kan erhålla mera detaljerade underlag och analyser än vad som vanligen står till buds vid andra redovisningssystem. Men hans planering av granskningen blir mer krävande om han önskar erhålla uppgifter som inte framtages i de normala rutinerna. Han måste i god tid precisera sina önskemål. Att i efterhand erhålla en icke rutinmässigt framställd utskrift kan vara förenat med stora kostnader; i vissa fall kan ett sådant önskemål vara nära nog omöjligt att efterkomma. Kommer en sådan begäran i samband med bokslutsgranskningen då tidspress i allmänhet råder på såväl ekonomiavdelningen som på datacentralen, riskerar han att ej få uppgiften innan revisionsberättelsen skall ha avgivits.
ADB-tekniken ger ofta tillgång till djupare och bredare detaljinformation än annan teknik. Detta sammanhänger med att företagsledningen på olika nivåer kan ha haft anledning att av systemen begära mera än de fått i äldre system. Det är även möjligt för revisorn att – om han så begär i god tid – erhålla utskrift av alla poster som motsvarar av honom uppställda kriterier, vilket kan underlätta och effektivisera hans granskning.
Givetvis bör revisorn förvissa sig om att i den nya bokföringslagen intagna krav på dokumentation, arkivering, verifikationsform, utskriftsmöjligheter m m är tillgodosedda.
Speciella tekniker
Vid revision av företag som i väsentlig utsträckning använder ADB i sin redovisning kan det ofta bli svårt eller kräva ytterst voluminös granskning att bilda sig en uppfattning om kvalitén på företagets bokföring och dess fullständighet. I många fall finns möjligheten fortfarande kvar att betrakta datorn som en magisk låda och utföra granskningsarbetet enligt traditionella metoder med relativt liten hänsyn tagen till ADB-rutinernas funktion. Metoden att göra så benämns ofta ”around the machine” – metoden, och går såsom namnet antyder ut på att granska transaktioner och deras verifikationer mot av datorn framställda listor.
En alternativ granskningsmetod är användandet av s k test deck. Ett test deck är en samling konstruerade händelser, utformade så att ett ADB-systems alla kontrollfunktioner testas. Först upprättas ett facit manuellt enligt avsedda kriterier. Därefter körs testdecket i ADB-rutinen och erhållet resultat stäms av mot facit. På detta sätt erhålles ett svar huruvida avsedda kontrollfunktioner fungerar eller ej.
Test-decket har sedan lång tid, om än i begränsad omfattning, använts i revisionsarbete med avsett resultat. I dag är emellertid svårigheterna och bristfälligheterna i ett sådant förfarande större än då första och andra generationens datorsystem användes. Risken att göra felaktiga uppdateringar av register är avsevärt större nu än då, beroende på den ökade automatik och komplexitet som uppkommit i senare generationers registersystem. Vidare är systemen eller programmen mindre definitiva idag. Mer eller mindre regelbundna ändringar görs, vilka ställer krav på ökat arbete med underhåll och förnyelse av test-decken. En tredje svårighet består i sammansättningen av test-decket. Betydande fantasi och förutseende krävs för att garantera att värderingen blir adekvat, d v s att alla funktioner som bör kontrolleras verkligen blir testade och att revisorn inte låser sig vid systemets teknik utan testar de fall som enligt revisorns uppfattning bör orsaka en avvikelserapport etc.
Såväl ”around the machine” som test-deckmetodiken representerar ett i viss mån negativt betraktelsesätt till förekomsten av ADB i redovisningen och svarar närmast på frågan ”På vad sätt kan jag i möjligaste mån eliminera datorns inverkan på revisionsarbetet?” I stället för att se ADB-förekomsten på detta sätt kan ett mera positivt synsätt anläggas: ”Hur kan jag i revisionen aktivt använda ADB som ett hjälpmedel i revisionsarbetet?” Svaret på en sådan fråga ligger i första hand i de generella revisionspaket som idag finns att tillgå. För detaljerad jämförelse mellan och beskrivning av de olika tillgängliga paketen se ”A Survey of Audit Software”, The Journal of Accountancy (sept 1972).
Programpaketen utgör utomordentliga hjälpmedel för granskning, stickprovsurval och analys, verifikation av kundfordringar etc. De kan klassificeras olika med avseende på den beredning de kräver, där allt ifrån typer som kräver kodning i programspråk till de som i stort består av specialiserade rutiner – och därför kräver ifyllandet av parameterkort – ingår. Auditape, utvecklat av Haskins & Sells, är det först framtagna paketet och hör till den senare typen ifråga om standardmässigt användande. Då det gäller mer avancerad användning med logik annan än den standardiserade krävs parameterkodning snarast jämförbar med programmering i programspråk. Audassist (Alexander Grant & Co) och Computer file analyzer (Price Waterhouse & Co) är exempel på paket av den första typen, åtminstone vad gäller tidigare versioner. Generellt erhålls i alla applikationer vissa standardfunktioner utan att särskild kodning därför krävs. Exempel på sådana funktioner är recordräkning och totalsummor på kvantitativa fält. Vilka speciella funktioner som utmärker de olika paketen ligger utanför ramen av denna framställning, men exempel på typiska funktioner som gäller generellt kan nämnas.
Summera en file med hänsyn tagen till positiva och negativa poster.
Summera en file för åldersanalys.
Selektera poster med hänsyn till kvantifierbara kriterier.
Selektera en viss proportion av poster som inte överensstämmer med valda kriterier enligt 3. a.
Selektera och sammansätta konton till saldobesked för verifikation.
Jämföra erhållna svar på saldoförfrågan med förväntat saldo från 4 ovan samt producera nya saldobesked för konton som ej verifierats.
Behandla record enligt matematisk formel.
Jämföra record för konsekvent behandling och rapportera eventuell inkonsekvens.
Testa record för resp redigera record till ett betraktelsesätt som stämmer överens med revisorns intentioner. T ex kan ett negativt saldo på en kundfordran klassificeras om till en positiv skuld.
Sammanställa en komplett rapport för ökad överskådlighet av olika posttyper.
Utbildningstiden som krävs för att effektivt kunna använda de olika paketen varierar av naturliga skäl kraftigt och är kopplad till vilken typ av kodning som krävs. För enklare applikationer, typiskt 1–4 ovan, behövs mera sällan mer än en veckas utbildning. Den tid som krävs för mer specialistbetonade applikationer beror i större utsträckning på tidigare erfarenheter inom ADB.
Relativt ofta kommer man att finna att klienten har program, vanligen framtagna för internrevisionen, eller är villig att konstruera program som är användbara för revisionsändamål. Någon entydig rekommendation att använda eller inte använda sådana program kan inte ges. Har klienten stor erfarenhet av ADB och programmet är väl dokumenterat kanske man efter testning finner att ett sådant program kan användas. Det bör observeras att klienten känner programmets konstruktion. Kan klienten med hjälp av programmet förutse exempelvis vilka poster som kommer att selekteras för analys kan han teoretiskt påverka resultatet. Under dessa och liknande omständigheter bör i stället ett generellt revisionspaket användas.
Tillgång till Time-Sharing-terminaler kan också utgöra ett värdefullt instrument vid revision. Med Time-Sharing eller tidsdelningsystem avses ett kommunikationssystem mellan decentraliserade användare och en central dator. En stor mängd användare kan samtidigt ha tillgång till datorn utan att konflikter dem emellan uppstår.
Applikationer med relativt små mängder in- och utdata men med avancerade och tunga bearbetningar utförs med fördel i Time-Sharing-byråernas välutvecklade standardprogram till överkomlig kostnad. Time-Sharing-prograrm är också relativt lätta att själv konstruera i programmeringsspråket basic om något användbart standardprogram inte är tillgängligt. Den främsta användningen av Time-Sharing för revisionsändamål är stickprovs- och annan statistisk analys, där beräkningarna kan innehålla för många variabler för att praktiskt utföras manuellt.
I mitten av 60-talet redovisade amerikanen W S Boutell (Auditing with the Computer. Univ of Calif Press, Berkeley, 1965;
Auditing trough the Computer, The Journal of Accountancy, Nov 1965) en ny infallsvinkel på bedömningen av ADB-rutiner: användning av normativa modeller. Metodiken har sedan utvecklats vidare i The Fifth John V Ratcliffe Memorial Publication, University of New South Wales 1974. Här kommer av utrymmesskäl att lämnas endast en principiell beskrivning av tekniken. Angreppspunkten är intern kontroll för bedömning av hur stort behov av kvalitetskontroll, enligt ovan redovisade principer, av det undersökta systemets record som föreligger.
Första delen av arbetet består i konstruktion av en normativ modell, d v s en modell innehållande alla de ideala kontrollfunktioner det undersökta systemet bör inkludera enligt revisorns krav. Därefter följer kodning i programspråk på ett sådant sätt att klientens input kan läsas och att erhållen output får samma struktur som klientens output. När kodning och testning av modellen är klar följer bearbetning av ”frusna” inputfiler från en av klientens ordinarie produktionskörningar och jämförelse mellan modellens och klientens resultat.
Jämförelsen görs som en del av revisorns program och vid alla tillfällen då en händelse behandlats olika i de båda programmen ”stämplas” recordet med en kod som anger skiljaktighetens signifikansgrad och vilken kontroll som brustit. Recordet lagras sedan separat för avvikelserapportering. Sedan alla transaktioner behandlats sorteras de avvikande recorden efter signifikansgrad och listas i sjunkande sekvens efter densamma. Ett gott mått på systemets tillförlitlighet med avseende på intern kontroll erhålles således till skillnad från testdecksmetodens verifikation av kontrollens existens eller rapport om dess avsaknad. Stora fördelar ligger också i att input från ordinarie körningar och output från desamma ligger som grund för värderingen, då en mera verklighetsanknuten bedömning utföres i stället för en bedömning av konstruerade händelser med alla de begränsningar och ofullkomligheter sådana behäftas med. Vidare krävs inte någon assistans från klientens dataavdelning annat än filebeskrivningar och frusna in- och utfiler, vilket medför mycket liten möjlighet till vilseledande manipulation från klientens sida.
Lars Elvstad, auktor revisor, FARs ordförande 1970–1972, och Stefan Elvstad, arbetade i 4 år på ett större företags dataavdelning och är nu knuten till en revisionsbyrå.