Testplan for nytt regnskapssystem

En demo viser ofte hvordan en faktura opprettes. Den viser sjeldnere hva som skjer når fakturaen blir delbetalt, banktransaksjonen mangler referanse eller den gamle og nye reskontroen har ulike saldoer. En testplan for nytt regnskapssystem bør derfor bruke bedriftens egne, anonymiserte eksempler og ha et tydelig ferdigkriterium for hver arbeidsflyt.

Bestem hva som må stemme før oppstart

Start med siste avsluttede periode i dagens system. Ta vare på saldobalanse, åpne kunde- og leverandørposter, bankavstemming, eventuelle lønnsgrunnlag og rapporter per prosjekt eller avdeling. Noter antall poster og sum per gruppe. Dette er kontrollgrunnlaget ved migrering; en vellykket importmelding alene viser ikke at tallene stemmer.

Utpek én ansvarlig fra bedriften og én fra regnskapsfører eller økonomiteam for hvert kritisk område. De skal både utføre testen og signere avvikene som gjenstår. Les hva som må være klart for migrering før testdata flyttes.

Test normalflyt og avvik

Test	Bruk et konkret eksempel	Bestått når
Saldo og åpne poster	En kunde med delbetaling og en kreditnota	Åpen sum og historikk kan forklares i begge systemer
Utgående faktura	En ordinær faktura og en korrigering	Nummerering, kunde, beløp, status og bokføring stemmer
Inngående faktura	Faktura med attestasjon og avvist bilag	Riktig person kan godkjenne; avvist bilag går ikke til betaling
Bank	Innbetaling med KID og én uten referanse	Match og uavklart post vises separat
Lønn	En vanlig lønnskjøring og en korreksjon	Roller, grunnlag, lønnsslipp og regnskapspostering kan kontrolleres
Rapportering	Resultat og balanse for en avtalt dato	Differanser mot kontrollgrunnlaget er forklart

Ta med de integrasjonene som faktisk brukes: bank, nettbutikk, kassasystem, timeføring eller lønn. For hver integrasjon bør testen vise hva som skjer ved duplikat, forsinket synkronisering og feil konto. Dokumenter også hvem som retter feilen og hvor den opprinnelige hendelsen kan finnes igjen.

Bruk en enkel avvikslogg

For hver feil registrerer du test-ID, skjermbilde eller bilagsreferanse, forventet resultat, faktisk resultat, eier og frist. Del avvik i tre nivåer: stopper oppstart, må rettes før første månedsavslutning, og kan forbedres senere. En bankkonto som ikke kan avstemmes eller en reskontro som ikke stemmer, bør stoppe oppstart. En visningspreferanse kan normalt vente.

Når feilen er rettet, kjør samme test igjen. Ikke marker saken som lukket bare fordi leverandøren har gjort en endring. Lag en kort protokoll med totalsummer, åpne avvik og hvem som godkjente oppstartsdatoen.

Vurder løsningene mot samme test

Hvis dere sammenligner leverandører, bruk samme fem til ti eksempler hos alle. Da kan dere vurdere arbeidstid, kontrollspor og hvem som må gjøre manuelle rettinger, i tillegg til abonnementspris. For bedrifter som vurderer ReAI, kan ReAIs veiledning om å bytte regnskapssystem være et konkret neste steg. Bekreft hvilke data og integrasjoner som kan flyttes i deres oppsett før dere bestemmer dato.

Koble testplanen til overgangsplan for systembytte og opplæring etter systembytte.