Hva er SAF-T?
SAF-T forklart med gjeldende versjoner, fristen 1. januar 2027, innhold, kontrollpunkter og planene for SAF-T 2.0.
SAF-T (Standard Audit File – Tax) er et standardisert XML-format for utveksling av regnskapsdata. Norske bokføringspliktige som har bokførte opplysninger elektronisk tilgjengelig, skal kunne eksportere opplysningene i SAF-T-format. Filen sendes ikke inn som en fast periodisk rapport. Den leveres først når Skatteetaten ber om den, normalt i forbindelse med kontroll.
Kravet følger av bokføringsforskriften § 7-8 og gjelder for bokføringsperioder som begynner 1. januar 2020 eller senere. Skatteetatens oversikt over SAF-T Regnskap beskriver hvem som omfattes og når filen skal leveres.
Hvem omfattes av SAF-T-kravet?
Hovedregelen er knyttet til bokføringsplikt og elektronisk tilgjengelige bokførte opplysninger, ikke til om virksomheten er et aksjeselskap eller enkeltpersonforetak.
Virksomheter med mindre enn 5 millioner kroner i omsetning eksklusive merverdiavgift er i utgangspunktet unntatt fra kravet om elektronisk tilgjengelighet. Unntaket hjelper likevel ikke dersom virksomheten faktisk har de bokførte opplysningene elektronisk tilgjengelig. Virksomheter med færre enn 600 bilag i året som bokfører i tekstbehandlings- eller regnearkprogram, kan falle utenfor SAF-T-kravet. De fleste som bruker et ordinært elektronisk regnskapssystem, vil derimot være omfattet.
Skatteetaten kan be om en fil for et avgrenset tidsrom eller et helt regnskapsår. Utvalget skal være ett regnskapsår eller kortere. SAF-T erstatter ikke skattemeldingen, mva-meldingen eller andre ordinære rapporteringer. Mva-meldingen bruker likevel de samme standard mva-kodene, så et riktig mva-oppsett i regnskapssystemet gjør begge deler enklere.
Du må kunne produsere filen for hele oppbevaringstiden, som for regnskapsmateriale er fem år etter regnskapsårets slutt. Kan du ikke levere filen ved kontroll, blir kontrollen mer tidkrevende. Skatteetaten kan pålegge tvangsmulkt for å få opplysningene, og mangelfull dokumentasjon kan i ytterste konsekvens føre til skjønnsfastsetting.
SAF-T Financial 1.40 blir obligatorisk fra 2027
Skatteetaten har publisert SAF-T Financial versjon 1.40, med dokumentasjon datert 31. august 2026. Versjonen omtales også uformelt som 1.4.
| Regnskapsperiode | Gyldig SAF-T-versjon |
|---|---|
| 2024 og tidligere | Versjon 1.20 kan fortsatt brukes |
| 2025 og 2026 | Versjon 1.30 skal brukes, men 1.40 kan tas i bruk allerede nå |
| Fra 1. januar 2027 | Versjon 1.40 blir eneste gyldige format |
Fristen gjelder bokføringsperioder som begynner 1. januar 2027 eller senere. En eldre fil blir altså ikke ugyldig bare fordi den gjelder et tidligere regnskapsår. Skatteetaten opplyser også at 1.40 har full bakoverkompatibilitet på skjemanivå.
De viktigste tekniske endringene i 1.40 er støtte for flere konto-ID-er per eier, større presisjon for valutabeløp og valutakurser, nye valgfrie felt for virtuell valuta og land, samt egne felt for å vise avgiftsbeløp i norske kroner når transaksjonsbeløpet er i en annen valuta. Se Skatteetatens dokumentasjon og XSD-skjema for SAF-T for den tekniske spesifikasjonen.
For virksomheten betyr dette at systemleverandøren må støtte 1.40 før 2027, mens økonomiansvarlig bør kontrollere at valutadata, avgiftsbeløp og kontomapping blir riktige i eksporten.
Hva inneholder en SAF-T Financial-fil?
Den norske 1.x-filen har tre hoveddeler:
| Del | Innhold |
|---|---|
Header | Virksomhet, system, eksporttidspunkt, periode, utvalg og formatversjon |
MasterFiles | Kontoplan, kunder, leverandører, avgiftskoder og annen nødvendig masterdata |
GeneralLedgerEntries | Hovedbokstransaksjoner og poster i kunde- og leverandørreskontro |
Formatet inneholder bilagsreferanser og et strukturert bokføringsspor, men dagens 1.x-versjoner inneholder ikke nødvendigvis selve fakturaen, kvitteringsbildet eller annet originalbilag. Ved systembytte må du derfor planlegge separat eksport av dokumentasjon, rapporter, brukerlogger og andre data som ikke følger SAF-T-filen. Se også hvordan reskontro håndteres i SAF-T og hva du bør vurdere når du skal beholde historiske balanser .
Slik kvalitetssikrer du eksporten
En fil kan være gyldig XML uten at regnskapsdataene er riktige. Kontroller derfor både teknisk struktur og faglig innhold:
- Velg riktig regnskapsperiode og riktig versjon av SAF-T-skjemaet.
- Valider filen mot XSD-skjemaet som gjelder for versjonen.
- Avstem inngående og utgående saldo samt antall og summer mot hovedbok og reskontro.
- Kontroller mapping til gjeldende grupperingskategorier, grupperingskoder og standard mva-koder.
- Undersøk manglende organisasjonsnumre, duplikater, brutte bilagsserier og uventede valutabeløp.
- Sikre at valgfrie data som finnes i kildesystemet, faktisk blir med når de er relevante for eksportutvalget.
- Lagre eksportlogg, avstemminger og forklaringer på eventuelle avvik sammen med kontrollgrunnlaget.
Gjør en testeksport etter større systemoppdateringer, endringer i kontoplanen eller flytting av data. En praktisk SAF-T-validering bør alltid inkludere avstemming, ikke bare en teknisk beskjed om at XML-filen kan leses.
SAF-T ved bytte av regnskapssystem
SAF-T er også den vanligste måten å flytte regnskapshistorikk mellom regnskapssystemer på. Kommer du fra et annet system, kan du importere SAF-T-filen i ReAI og fortsette der du slapp. Se bytt regnskapssystem og hvordan du eksporterer regnskapsdata .
SAF-T Financial og SAF-T Kassasystem er to ulike formater
SAF-T Financial gjengir bokførte opplysninger fra regnskapssystemet. SAF-T Cash Register gjengir den elektroniske journalen fra kassasystemet. En virksomhet med kontantsalg kan derfor måtte kunne produsere begge filtypene.
SAF-T Kassasystem er bygget opp etter virksomhet, salgssted og kassapunkt. Eksporten kan blant annet inneholde:
- salg og retur på transaksjons- og varelinjenivå
- betalingsmåter, beløp og standard mva-koder
- X-rapporter, Z-rapporter og andre rapporthendelser
- ikke-salgsrelaterte hendelser, for eksempel åpning av kassaskuff
- systemspesifikke koder mappet til standardiserte hendelses- og betalingskoder
- digital signatur fra kvitteringstransaksjoner der kassaregelverket krever det
Kassasystemet skal kunne lage XML-filen direkte fra den elektroniske journalen og gjøre eksporten tilgjengelig på forretningsstedet. Filen leveres til Skatteetaten når den blir etterspurt under kontroll. Den erstatter ikke dagsoppgjør, Z-rapport eller avstemming mellom kassesalg, betalingsoppgjør og bank. Les mer om kassasystem, journal og dagsoppgjør i ReAI .
Hva kommer i SAF-T 2.0?
Skatteetaten arbeider med SAF-T Financial 2.0, men versjonen er ikke dagens pliktige format. Prosjektet gjelder særlig SourceDocuments, altså mer detaljerte kildedata som salgs- og kjøpsfakturaer, betalinger, varebevegelser og anleggsmiddeltransaksjoner. Målet er å gjøre formatet bedre egnet til kontroll, analyse og flytting av data mellom regnskapssystemer.
Skatteetatens prosjektside for SAF-T Financial 2.0 opplyser at hele formatet etter planen skal være tilgjengelig for brukere fra 1. januar 2027. Det er ikke det samme som at 2.0 er gjort obligatorisk fra denne datoen. Den fastsatte plikten fra 1. januar 2027 gjelder versjon 1.40. Virksomheter bør derfor følge videre publisering fra Skatteetaten før de legger til grunn endelig innhold, overgangsregler eller en pliktdato for 2.0.
Kort oppsummert
SAF-T er et eksportformat som skal kunne produseres og leveres på forespørsel ved kontroll. Versjon 1.30 gjelder for regnskapsperiodene 2025 og 2026, mens 1.40 kan brukes nå og blir eneste gyldige format fra 1. januar 2027. SAF-T Kassasystem er en egen eksport av kassens elektroniske journal. SAF-T 2.0 er under utvikling og må ikke omtales som et ferdig eller obligatorisk format før Skatteetaten har fastsatt dette. Fra 1. januar 2030 kommer i tillegg kravet om å bokføre i et elektronisk regnskapssystem. Les hva som er vedtatt om digital bokføring fra 2030 .
Les videre
Mer fra Teknisk
Altinn-roller for regnskap
Oversikt over de viktigste Altinn-rollene i regnskapsarbeidet, hvem som får dem automatisk, hvordan de delegeres, og hva som endres med Altinns nye …
API-sikkerhet i regnskap
Praktiske sikkerhetstiltak når nettbutikk, bank, lønn eller egne systemer kobles til regnskapet via API, og hvilke krav bokføringsreglene stiller.
Avvikslogg for bankavstemming
En avvikslogg gjør bankavstemming mer sporbar og lettere å følge opp.
Bankfeed-feilsøking
Feilsøking når bankintegrasjonen mot regnskapssystemet stopper, gir dobbelttransaksjoner eller feil saldo, med sjekkliste og vanlige årsaker.