Revisjon i et datamaskinbasert miljø

Relevant For Foundation Level Paper FAU Og ACCA Kvalifikasjonspapirer F8 Og P7

Spesifikke aspekter av revisjon i et datamaskinbasert miljø

Informasjonsteknologi (IT) er integrert i moderne regnskap og ledelse informasjonssystemer. Det er derfor avgjørende at revisorer er fullt klar over HVILKEN innvirkning DETTE har på revisjonen av en klients regnskap, både i sammenheng med hvordan den brukes av en klient til å samle inn, behandle og rapportere finansiell informasjon i sitt regnskap, og hvordan revisor kan bruke den i prosessen med revisjon av regnskapet.
formålet med denne artikkelen er å gi veiledning om følgende aspekter ved revisjon i et datamaskinbasert regnskapsmiljø:

• Applikasjonskontroller, som omfatter input, processing, output og master file controls etablert av en revisjonsklient, over sitt datamaskinbaserte regnskapssystem og
• Computer-assisted audit techniques (CAATs) som kan benyttes av revisorer for å teste og konkludere om integriteten til en klients datamaskinbaserte regnskapssystem.

Eksamensspørsmål på hvert av de aspektene som er identifisert ovenfor, blir ofte besvart til en utilstrekkelig standard av et betydelig antall studenter-derav årsaken til denne artikkelen.
Håndtere applikasjonskontroller og CAATs i sin tur:
APPLIKASJONSKONTROLLER
Applikasjonskontroller er de kontrollene (manuelle og datastyrte) som relaterer seg til transaksjons-og stående data knyttet til et databasert regnskapssystem. De er spesifikke for en gitt søknad, og deres mål er å sikre fullstendigheten og nøyaktigheten av regnskapet og gyldigheten av oppføringer som er gjort i disse postene. Et effektivt databasert system vil sikre at det er tilstrekkelige kontroller som eksisterer ved inngangs -, prosesserings-og utgangsstadiene i databehandlingssyklusen og over stående data som finnes i masterfiler. Applikasjonskontroller må fastslås, registreres og evalueres av revisor som en del av prosessen med å bestemme risikoen for vesentlig feilinformasjon i revisjonskundens regnskap.
Inndatakontroller
Kontrollaktiviteter som er utformet for å sikre at inndata er autorisert, fullstendig, nøyaktig og rettidig, kalles inndatakontroller. Avhengig av kompleksiteten til det aktuelle applikasjonsprogrammet, vil slike kontroller variere når det gjelder kvantitet og raffinement. Faktorer som skal vurderes ved fastsettelse av disse variablene inkluderer kostnadshensyn, og konfidensialitetskrav med hensyn til datainngang. Inndatakontroller som er felles for de mest effektive applikasjonsprogrammene, inkluderer rask tilgang på skjermen (for eksempel en forespørsel om at en autorisert bruker skal logge inn) og et anlegg for å produsere et revisjonsspor som gjør det mulig for en bruker å spore en transaksjon fra opprinnelsen til disposisjon i systemet.
Spesifikke inndatavalideringskontroller kan omfatte:
Formatkontroller
disse sikrer at informasjon skrives inn i riktig form. For eksempel kravet om at datoen for et salg i stemmen bare skal skrives inn i numerisk format-ikke numerisk og alfanumerisk.
Range sjekker
disse sikrer at informasjonen er rimelig i tråd med forventningene. For eksempel, når en enhet sjelden, om noen gang, foretar kjøp i bulk med en verdi på over $50 000, avvises en kjøpsfaktura med en inngangsverdi på over $50 000 for gjennomgang og oppfølging.
Kompatibilitetskontroller
disse sikrer at datainngang fra to eller flere felt er kompatibel. En salgsfakturaverdi bør for eksempel være kompatibel med mva-beløpet som belastes på fakturaen.
Gyldighetskontroller
disse sikrer at datainngangen er gyldig. For eksempel, der en enhet driver et jobbkostnadssystem – kostnader inndata til en tidligere fullført jobb skal avvises som ugyldig.
Unntakssjekker
disse sikrer at det produseres en unntaksrapport som fremhever uvanlige situasjoner som har oppstått etter inntasting av et bestemt element. For eksempel bære frem av en negativ verdi for beholdningen holdt.
Sekvenskontroller
disse letter fullstendigheten av behandlingen ved å sikre at dokumenter som behandles ut av sekvens, avviser ed. For eksempel, hvor pre-nummererte varer mottatt notater er utstedt til ac kunnskap mottak av varer i fysisk inventar, noen innspill av notater ut av sekvensen skal avvises.
Kontroll totals
disse også lette fullstendigheten av behandling ved å sikre at pre-input, manuelt forberedt kontroll totals er sammenlignet med kontroll totals inngang. Ikke-samsvarende totaler for en satsvis kjøpsfakturaer bør for eksempel resultere i en brukerprompt på skjermen, eller produksjon av en unntaksrapport for oppfølging. Bruken av kontrolltotaler på denne måten blir også ofte referert til som utgangskontroller (se nedenfor).
kontrollsifferbekreftelse
denne prosessen bruker algoritmer for å sikre at datainngang er nøyaktig. For eksempel internt genererte gyldige leverandør numeriske referansekoder, skal være formatert på en slik måte at eventuelle innkjøpsfakturaer inn med feil kode vil bli automatisk avvist.
Behandlingskontroller
Behandlingskontroller eksisterer for å sikre at all datainngang behandles riktig og at datafiler oppdateres riktig i tide. Behandlingskontrollene for et spesifisert applikasjonsprogram skal utformes og deretter testes før ‘live’ kjører med ekte data. Disse kan typisk omfatte bruk av løpende kontroller, som sikrer integriteten til kumulative totaler som finnes i regnskapet, opprettholdes fra en databehandling som kjøres til den neste. For eksempel blir balansen fremført på bankkontoen i et selskaps generelle (nominelle) hovedbok. Andre behandlingskontroller bør omfatte etterfølgende behandling av data avvist ved inntastingspunktet, for eksempel:

• en datamaskin produsert utskrift av avviste elementer.
• Formelle skriftlige instruksjoner som varsler databehandlingspersonell om prosedyrene som skal følges med hensyn til avviste elementer.
• Hensiktsmessig undersøkelse / oppfølging med hensyn til avviste elementer.
• Bevis på at avviste feil har blitt korrigert og re-input.

Output controls
Output controls eksisterer for å sikre at alle data behandles og at utdata bare distribueres til foreskrevne autoriserte brukere. Selv om graden av utgangskontroller vil variere fra en organisasjon til en annen (avhengig av konfidensialiteten til informasjonen og størrelsen på organisasjonen), omfatter felles kontroller:

• bruk av batch kontroll totaler, som beskrevet ovenfor (se ‘input controls’).
• Hensiktsmessig gjennomgang og oppfølging av unntaksrapportinformasjon for å sikre at det ikke er noen permanent utestående unntakselementer.
• Nøye planlegging av behandling av data for å bidra til å lette distribusjonen av informasjon til sluttbrukere i tide.
• Formelle skriftlige instruksjoner som varsler databehandlingspersonell om foreskrevne distribusjonsprosedyrer.
• Kontinuerlig overvåking av en ansvarlig tjenestemann av fordelingen av produksjonen, for å sikre at den distribueres i samsvar med autorisert politikk.

Master file controls
formålet med master file controls er å sikre den pågående integriteten til stående data som finnes i master-filer. Det er svært viktig at strenge ‘sikkerhet’ kontroller bør utøves over alle master-filer.
disse inkluderer:

• adekvat bruk av passord, for å begrense tilgangen til hovedfildata
• etablering av tilstrekkelige prosedyrer over endring av data, som omfatter hensiktsmessig adskillelse av plikter, og myndighet til å endre er begrenset til egnede ansvarlige personer
• regelmessig kontroll av hovedfildata til autoriserte data, av en uavhengig ansvarlig tjenestemann
• behandlingskontroll over oppdatering av hovedfiler, herunder bruk av opptegnelser og kontrolltall.

COMPUTER ASSISTED AUDIT TECHNIQUES (CAATs)
arten av databaserte regnskapssystemer er slik at revisorer kan bruke revisjonsselskapets datamaskin, eller sin egen, som et revisjonsverktøy, for å hjelpe dem i deres revisjonshandlinger. I hvilken grad revisor kan velge mellom Å bruke CAATs og manuelle teknikker på et bestemt revisjonsoppdrag, avhenger av følgende faktorer:

• det praktiske ved å utføre manuell testing
• kostnadseffektiviteten ved bruk Av Caat
• tilgjengeligheten av revisjonstid
• tilgjengeligheten av revisjonsklientens datamaskinfasilitet
• nivået på revisjonserfaring og ekspertise ved bruk av en spesifisert CAAT
• Nivået På Caat utført av revisjonsklientens internrevisjonsfunksjon og i hvilken grad ekstern al-revisor kan stole på dette arbeidet.

Det er tre klassifikasjoner Av CAATs-nemlig:

• Revisjonsprogramvare
• Testdata
• Andre teknikker

Å håndtere hvert av de ovennevnte i sin tur:
Revisjonsprogramvare
Revisjonsprogramvare er et generisk begrep som brukes til å beskrive dataprogrammer designet for å utføre tester av kontroll-og/eller substanshandlinger. Slike programmer kan klassifiseres som:
Pakkede programmer
disse består av forhåndsforberedte generaliserte programmer som brukes av revisorer og er ikke ‘klientspesifikke’. De kan brukes til å utføre en rekke revisjonsoppgaver, for eksempel å velge et utvalg, enten statistisk eller dømmende, under aritmetiske beregninger og sjekke for hull i behandlingen av sekvenser.
Formålsskrevne programmer
disse programmene er vanligvis ‘klientspesifikke’ og kan brukes til å utføre tester av kontroll-eller substansprosedyrer. Revisjonsprogramvare kan kjøpes eller utvikles, men revisjonsfirmaets revisjonsplan bør under alle omstendigheter sørge for at det gjøres bestemmelser for å sikre at spesifiserte programmer er passende for kundens system og revisjonens behov. Vanligvis kan de brukes til å re-utføre datastyrte kontrollprosedyrer (for eksempel kostnader for salg beregninger) eller kanskje å utføre en alderen analyse av kundefordringer (debitor) saldoer.
Forespørselsprogrammer
disse programmene er integrert i kundens regnskapssystem; men de kan tilpasses for revisjonsformål. For eksempel, når et system gir for rutinemessig rapportering på månedlig basis av ansatte startere og avgangselever, dette anlegget kan benyttes av revisor når revisjon lønn og lønn i klientens regnskapet. Tilsvarende kan et anlegg for å rapportere betalbar handel (kreditor) lange utestående saldoer brukes av en revisor når verifisere den rapporterte verdien av kreditorer.
Testdata
Revisjonstestdata
Revisjonstestdata brukes til å teste eksistensen og effektiviteten av kontroller som er innebygd i et program som brukes av en revisjonsklient. Som sådan behandles dummytransaksjoner gjennom kundens datastyrte system. Resultatene av behandlingen blir deretter sammenlignet med revisors forventede resultater for å avgjøre om kontrollene fungerer effektivt og systemenes objektivitet oppnås. For eksempel kan to dummy bank betalingstransaksjoner (en innenfor og en utenfor autoriserte parametere) behandles med forventning om at bare transaksjonen behandlet innenfor parametrene er ‘akseptert’ av systemet. Dersom dummytransaksjoner som behandles ikke gir de forventede resultatene i produksjonen, må revisor vurdere behovet for økte substanshandlinger i området som gjennomgås.
Integrerte testfasiliteter
for å unngå risikoen for å ødelegge kundens kontosystem, ved å behandle testdata med kundens andre ‘live’ data, kan revisorer sette i gang spesielle’ kun testdata ‘ behandlingskjøringer for revisjonstestdata. Den største ulempen ved dette er at revisor ikke har full sikkerhet for at testdataene behandles på samme måte som klientens live data. For å løse dette problemet kan revisor derfor søke tillatelse fra klienten til å etablere en integrert testfasilitet i regnskapssystemet. Dette innebærer etablering av en dummy-enhet, for eksempel en dummy-leverandørkonto mot hvilken revisors testdata behandles under normale behandlingskurer.
Andre teknikker
denne delen inneholder nyttig bakgrunnsinformasjon for å forbedre din generelle forståelse.
Andre CAATs inkluderer:
Embedded audit facilities (Eafs)
denne teknikken krever at revisors egen programkode skal bygges inn (inkorporeres) i kundens applikasjonsprogramvare, slik at verifikasjonsprosedyrer kan utføres som nødvendig på data som behandles. For eksempel kan kontrolltester inkludere reperformansen av spesifikke kontroller for inndatavalidering (se inndatakontroller ovenfor) – utvalgte transaksjoner kan merkes og følges gjennom systemet for å fastslå om angitte kontroller og prosesser har blitt brukt på disse transaksjonene av datasystemet. EAFs skal sikre at resultatene av prøvingen registreres i en spesiell sikker mappe for senere gjennomgang av revisor, som skal kunne konkludere om integriteten til behandlingskontrollene generelt, fra resultatene av prøvingen. En ytterligere EAF, av ti oversett av studenter, er det av et analytisk gjennomgangsprogram som muliggjør samtidig ytelse av analytiske gjennomgangsprosedyrer på klientdata som det behandles gjennom det automatiserte systemet.
Undersøkelse av Søknadsprogram
ved fastsettelse av i hvilken grad de kan stole på applikasjonskontroller, må revisorer vurdere i hvilken grad spesifiserte kontroller har blitt implementert på riktig måte. Dersom det for eksempel har skjedd systemendringer i løpet av en regnskapsperiode, vil revisor trenge forsikring om at det foreligger nødvendige kontroller både før og etter endringen. Revisor kan søke å oppnå en slik forsikring ved å bruke et program til å sammenligne kontrollene som var på plass før og etter endringsdatoen.
Sammendrag
hovedmålene for en revisjon endres ikke uavhengig av om revisjonsoppdraget utføres i et manuelt eller datamaskinbasert miljø. Revisjonstilnærmingen, planleggingshensynene og teknikkene som brukes for å innhente tilstrekkelig og hensiktsmessig revisjonsbevis, endres selvsagt. Studentene oppfordres til å lese videre for å øke sin kunnskap om revisjon i et databasert miljø og å praktisere sin evne til å svare på eksamensspørsmål om emnet ved å forsøke spørsmål satt i tidligere ACCA eksamensoppgaver.
Skrevet av et medlem av audit eksamen teamet