·Audun Martinussen

Slik forbereder du prosess-walkthrough før revisjonen

Walkthrough med revisor er ofte det første du gjør i en årsrevisjon, og det er ofte det som setter tonen for hele revisjonen. Her er hva som faktisk forventes og hvordan du forbereder deg.

Walkthrough er det første du gjør med revisor i en årsrevisjon, og det er ofte det som setter tonen for hele oppdraget. Hvis prosessdokumentasjonen din er på plass, blir resten av revisjonen kortere, billigere og mindre stressende. Hvis ikke, går revisor rett over i mer detaljert testing — og det merkes på fakturaen.

Etter mange år med å sitte på revisor-siden av bordet, kan jeg si at de aller fleste walkthroughs feiler på samme måter. Denne artikkelen gjennomgår hva som faktisk forventes, hvilke spørsmål du kan vente deg, og hvordan du kan forberede deg slik at møtet tar én time i stedet for tre.

Hva er en prosess-walkthrough?

En walkthrough er en systematisk gjennomgang av én transaksjonssyklus, fra start til slutt. Typiske sykluser revisor ser på er:

  • Inntekt-til-innbetaling (salg, fakturering, inkasso, kontering)
  • Innkjøp-til-betaling (bestilling, varemottak, fakturahåndtering, utbetaling)
  • Lønn (ansettelse, registrering av timer, lønnsberegning, utbetaling, A-melding)
  • Periodisering og lukking (avstemming, periodiseringer, avskrivninger, MVA)

For hver syklus følger revisor én eller flere reelle transaksjoner gjennom hele løpet og noterer hvilke kontroller som er på plass. Målet er ikke å finne feil — det er å forstå hvordan systemet fungerer, slik at revisor kan vurdere risiko og planlegge videre testing.

Hva revisor faktisk ser etter

Etter ISA 315 (revidert) skal revisor forstå:

  1. Hva som initierer transaksjonen
  2. Hvordan den registreres, autoriseres, behandles og rapporteres
  3. Hvilke IT-systemer som er involvert
  4. Hvilke kontroller som er på plass, og hvem som utfører dem
  5. Hvilke risikoer som finnes for at noe kan gå galt — og hvordan kontrollene reduserer risikoen

Det er punkt 4 og 5 som ofte er svakest hos selskaper som ikke har dokumentert prosessene sine. Du beskriver hvordan ting går — men ikke hvem som godkjenner hva, hva som faktisk hindrer at noen registrerer en falsk leverandør, eller hva som skjer hvis noen er syk.

Vanlige fallgruver

Fallgruve 1: Du beskriver SOPen, ikke praksis

Det vanligste problemet i en walkthrough er at den som svarer leser opp eller refererer til den offisielle prosedyren. Revisor er ute etter den faktiske prosessen. Hvis det er gap mellom SOP og praksis — og det er det ofte — er det bedre å være ærlig om det. Revisor finner det uansett når de tester.

Fallgruve 2: Du har ikke kart over systemlandskapet

Mange selskap har fem til ti IT-systemer involvert i én syklus: ERP, banksystem, lønnssystem, dokumenthåndteringssystem, BI-løsning, og så videre. Hvis du ikke har et enkelt diagram som viser hvilke systemer som snakker med hverandre, blir første time av walkthrough brukt til å tegne dette på en tavle.

Fallgruve 3: Du har ikke en oversikt over hvem som gjør hva

RACI eller en enklere ansvarsoversikt sparer enormt med tid. Revisor må vite hvem som registrerer, hvem som godkjenner, og hvem som avstemmer. Hvis det er den samme personen — det er en rød flagg.

Hvordan forberede deg

Her er en konkret sjekkliste tre uker før walkthrough:

  1. Tegn et enkelt systemdiagram. Hvilke systemer er involvert? Hvor flyter dataene? Det trenger ikke være pent — en boks-og-pil-skisse er nok.
  1. Lag en prosessbeskrivelse på 1–2 sider per syklus. Skriv det som om du forklarer det til en ny ansatt. Inkluder beslutningspunkter, godkjenningsterskler og hva som skjer ved unntak.
  1. Identifiser de viktigste kontrollene. For hver syklus, hvilke 5–10 kontroller er kritiske? Beløpsgrenser for godkjenning, segregering av oppgaver, månedlig avstemming, fire-øyne-prinsipp ved leverandøropprettelse. List dem opp med navn på den som utfører, hvor ofte, og hvilken evidens som finnes.
  1. Pek på reelle transaksjoner. Revisor kommer til å be om eksempler. Vær klar med 2–3 reelle bilag per syklus som dekker normaltilfeller og minst ett unntak.
  1. Forbered IT-eier eller systemadministrator. Spørsmål om brukerstyring, segregering, logg-tilganger og endringshåndtering kommer alltid. Det er ofte en annen person enn økonomisjefen som må svare.

Et eksempel på god dokumentasjon

Den beste prosess-walkthrough jeg har sittet i hadde tre ting på plass før vi startet: et BPMN-diagram per syklus, en kontrollregister-Excel med 18 kontroller per prosess kategorisert etter ISA 315-komponenter, og en kort narrativ tekst som forklarte de viktigste beslutningspunktene. Hele walkthrough tok 90 minutter for tre sykluser. Til sammenligning brukte vi typisk hele dager hos selskap som ikke hadde dokumentert noe.

Hvis du vil se hvordan en slik leveranse ser ut i praksis, har vi publisert et komplett eksempel på en innkjøp-til-betaling-syklus: se eksempel-leveransen.

Hva du bør gjøre i dag

Hvis revisor kommer om tre måneder og du ikke har dokumentasjon på plass, prioriter slik:

  • Uke 1: Sett opp systemdiagram og ansvarsoversikt
  • Uke 2–3: Skriv narrativ for de to mest kritiske syklusene (typisk inntekt og innkjøp)
  • Uke 4–6: Identifiser og dokumenter kontrollene
  • Uke 7: Walkthrough internt, fang opp gaps
  • Uke 8+: Tett gaps eller dokumenter dem som kjente svakheter

Det er fullt mulig å gjøre dette selv, men det er ofte raskere å få hjelp med formatet. NorthControl leverer komplette walkthrough-pakker i åpne formater du eier selv — se pakkene.

Oppsummering

Revisor er ikke ute etter å fange deg. De skal forstå hvordan virksomheten din fungerer og om det er noe som er åpenbart galt. Hvis du møter med ferdig dokumentasjon og kan vise dem hvordan transaksjoner faktisk flyter, sparer du tid og penger. Hvis du møter uforberedt, betaler du for at revisor rekonstruerer prosessene dine på egen regning.

Beste tegn på en moden virksomhet er at walkthrough ikke avdekker overraskelser — fordi du allerede vet hvor svakhetene ligger og har en plan for å adressere dem.

Vil du se hvordan vi dokumenterer prosesser i praksis?

Et komplett eksempel — innkjøp-til-betaling for en 80-personers grossist — er publisert med BPMN, kontroller og risikoer.