Slik løste de Altinn 3-overgangen

Da Digitaliseringsdirektoratet satte en absolutt sluttdato for Altinn 2 (19. juni 2026) kjente hele bransjen på tidspresset. 

Regnskap Norge advarte offentlig om høy risiko for feil i overgangen og pekte på at systemleverandører fikk nødvendige spesifikasjoner sent i prosessen. 

Skatteetaten fritok til og med virksomheter fra tvangsmulkt for enkelte innrapporteringer i månedene rundt stenging, fordi tilpasningene tok lengre tid enn planlagt mange steder.

For en statlig tilsynsmyndighet var situasjonen den samme: en hard, ufravikelig frist, og et løsningslandskap som skulle bygges om mens klokken tikket. 

Løsningen er bygget på Salesforce. Arkitekturen, utformet av seniorarkitekt Martin Engelsviken i Sopra Steria, er et resultat av 25 års erfaring med samfunnskritiske prosjekter. Valgene er preget av en disiplinert prioritering: kompleks forretningslogikk er forenklet til en sporbar og transparent struktur. 

Data og prosess i samme post

Den mest interessante beslutningen i løsningen er at forretningsdata og prosesstyring ikke er skilt i to lag, slik man ofte ser i integrasjonsarkitektur. 

Samme post som representerer den innsendte rapporten (regnskapstall, spilldata, organisasjonsinformasjon) er også posten som forteller systemet hvor i behandlingskjeden saken befinner seg akkurat nå.

Det er en avveining, ikke en tilfeldighet. Den koster litt i objektdesign, fordi hver post bærer informasjon som ikke alltid er relevant samtidig. 

Men den vinner tilbake vesentlig mer i sporbarhet og enkelhet: man trenger ikke slå sammen data fra en forretningstabell og en separat logg eller kø-tabell for å forstå hva som har skjedd med en gitt sak. Alt ligger på ett sted.

Hvordan en sak beveger seg gjennom systemet

Når en rapport hentes fra Altinn, opprettes en post med rådataene og en markering av at videre behandling gjenstår. 

Et kall mot Brønnøysundregistrene beriker deretter tabellen med virksomhetsinformasjon, og statusen oppdateres til at berikelsen er fullført. Først når data er komplett, plukkes den opp for videre prosessering og sending til arkiveringssystem P360, og utfallet om det er suksess eller feil, med eventuell feilkode og -melding skrives tilbake i samme tabell som siste steg.

Det betyr at man til enhver tid kan spørre systemet om nøyaktig hvor en gitt sak befinner seg i kjeden mottatt, beriket, sendt eller arkivert og med tidsstempel for hvert steg. Rapportering blir noe man gjør løpende, direkte mot dataene, i stedet for å rekonstruere hendelsesforløpet fra logger i etterkant.

Denne strukturen er også det som gjør automatisk gjenoppretting mulig uten ekstra infrastruktur. 

En jobb som leter etter poster der behandlingen ikke er fullført, trenger ikke kjenne til forretningslogikken bak sakene i det hele tatt, den trenger bare å lese status direkte fra posten. 

Stopper prosessen opp eller feiler et steg, plukker jobben automatisk opp arbeidet igjen ved neste kjøring, uten manuell inngripen. Siden hele kjeden styres av en timerjobb i Apex som kjører hvert femte minutt, betyr det i praksis at en feilet sak sjelden blir liggende lenge før den forsøkes på nytt. 

En egen idempotensnøkkel sikrer samtidig at samme innsending ikke behandles to ganger, selv om jobben skulle plukke den opp flere ganger.

En kobling tilbake til den opprinnelige saksbehandlingen i P360 gjør at en saksbehandler kan finne igjen den konkrete rapporten fra en konkret sak uten å lete i separate systemer, og løsningen er samtidig bygget for å håndtere data fra flere kilder enn bare Altinn. Samme struktur og samme prosesseringslogikk dekker mer enn én integrasjonsvei inn.

Testet mot ekte testinfrastruktur, ikke gjetning

Med en så tidskritisk migrering var det ikke rom for at testingen skulle være det svake leddet. Teamet bygget testregimet rundt Altinns eget testmiljø og Tenor (https://www.skatteetaten.no/testdata/) , i kombinasjon med Test Norge sin løsning for å generere fiktive virksomheter og personer som sikrer en mer realistisk verifisering enn håndlaget eller syntetisk testdata ville gitt, noe som var avgjørende når mye av bransjen for øvrig slet med mangelfull tid til testing før stenging.

Resultatet

Da Altinn 2 stengte 19. juni 2026, markerte det slutten på en svært krevende omstillingsperiode. Rapporter om tekniske utfordringer i etterkant, blant annet knyttet til kjemikaliedeklarering og tilgangsstyring, understreker hvor omfattende dette skiftet har vært. Skatteetatens beslutning om å avstå fra tvangsmulkt i overgangsperioden bekrefter at mange systemleverandører og virksomheter sto overfor problemer med å ferdigstille sine integrasjoner innen tidsfristen.

For tilsynsmyndighetens del betydde det ingen dramatikk: virksomheter kunne fortsette å sende inn regnskap, søke om tillatelser og rapportere uten avbrudd, fordi løsningen og arkitekturen som holder styr på hver eneste sak underveis var på plass akkurat i tid. Arkitekturen sikret en trygg overgang, da all data ble lagret og var sporbart for å ha kontroll over det hele veien. 

Altinn 3, Brønnøysundregistre og arkivsystemet P360 er koblet sammen i én sammenhengende kjede, slik at en innsendt rapport kunne beveges automatisk i Salesforce fra mottak til beriket og arkivert sak uten en eneste manuell hånd innom veien. 

Glossar: 

En idempotens-nøkkel (Idempotency-Key) er en unik identifikator som sendes med i API-forespørsler (f.eks. ved POST- og PATCH-kall). Den sikrer at en handling selv om den sendes og utføres flere ganger kun påvirker systemet én gang. Dette er avgjørende for å unngå dupliserte transaksjoner og feil.