Et ERP-bytte handler tilsynelatende om data og funksjonalitet. Men det du egentlig flytter er hele kontrollmiljøet ditt: hvem som kan godkjenne hva, hvilke beløpsgrenser som gjelder, hvilke felter som er obligatoriske, og hva som logges. Disse kontrollene er ofte bygget inn i det gamle systemet over mange år — og de blir sjelden dokumentert før de skal reproduseres i det nye.
Resultatet er forutsigbart: tre måneder etter go-live oppdager regnskap at en godkjenningsterskel som lå i Visma aldri ble konfigurert i det nye systemet. Eller revisor spør etter en attestasjonslogg som ikke lenger finnes. Kontrollen var der — den forsvant bare i migreringen.
Hvorfor kontroller forsvinner i ERP-bytter
- De er usynlige til daglig. En godt fungerende kontroll merkes ikke. Ingen tenker på beløpsgrensen for PO-godkjenning før den er borte.
- System-integratoren konfigurerer funksjonalitet, ikke kontrollintensjon. Integratoren vet hvordan man setter opp en godkjenningsflyt — men ikke at din flyt har en spesifikk grense på 250 000 fordi styret bestemte det i 2019.
- Kontrollene er ikke skrevet ned. Hvis de bare finnes som konfigurasjon i det gamle systemet, finnes det ingen kravspesifikasjon å konfigurere mot i det nye.
Kartlegg kontrollene FØR du migrerer
Den eneste pålitelige måten å sikre kontinuitet på er å dokumentere kontrollmiljøet som en del av as-is-mappingen — før design-fasen. For hver kjerneprosess vil et kontrollregister fange:
- Hvilke preventive kontroller finnes (godkjenningsgrenser, arbeidsdeling/SOD, obligatoriske felter)
- Hvilke detektive kontroller finnes (3-veis matching, avstemming, avviksrapporter)
- Hvem som eier hver kontroll, og hvilken risiko den demper
- Hvilket bevis (evidence) kontrollen produserer — loggen revisor faktisk ser etter
Dette registeret blir kravspesifikasjonen din mot system-integratoren. Da konfigurerer dere ikke kontroller fra hukommelsen, men fra en liste.
Arbeidsdeling (SOD) er der det smeller hardest
Den vanligste kontrollen som knekker er arbeidsdeling. I det gamle systemet hadde dere kanskje rollestyring som hindret at samme person både oppretter og godkjenner en faktura. I det nye systemet starter alle med brede rettigheter «midlertidig, så vi kommer i gang» — og midlertidig blir permanent. For en revisor er svekket SOD en av de første tingene som flagges.
Sjekkliste: kontroll-kontinuitet ved ERP-bytte
- Dokumenter kontrollmiljøet per kjerneprosess før design-fasen.
- Gjør kontrollregisteret til en eksplisitt leveranse fra system-integratoren — ikke en antakelse.
- Test kontrollene i UAT, ikke bare funksjonaliteten. Forsøk aktivt å bryte en godkjenningsgrense.
- Sett opp rolle- og rettighetsmatrise før go-live, ikke etterpå.
- Verifiser at loggene revisor trenger faktisk genereres i det nye systemet.
Koblingen til revisjonen
Hvis dere bytter ERP i samme regnskapsår som revisjonen, vil revisor være ekstra oppmerksom på kontrollmiljøet — et systembytte er i seg selv en risikofaktor i ISA 315-vurderingen. Å kunne legge frem et oppdatert kontrollregister som viser at kontrollene er bevart gjennom byttet, sparer mye tid i revisjonsdialogen.
NorthControl kartlegger kontrollmiljøet som en uavhengig tredjepart før ERP-bytter — slik at kontrollene følger med over. Se hvordan vi jobber og eksempel-leveransen.
Oppsummering
Et ERP-bytte er ikke risikofritt for internkontrollen — det er en av de største enkelt-hendelsene som kan svekke den. Forskjellen mellom et bytte som bevarer kontrollene og ett som mister dem, er om kontrollmiljøet ble dokumentert før migreringen eller ikke. Skriv ned kontrollene mens de fortsatt finnes.