SAF-T Financial 1.40 – eneste gyldige format fra 2027

SAF-T Financial er standardformatet for å eksportere regnskapsdata fra regnskapssystemet. Versjon 1.40 er en liten revisjon med bakoverkompatible endringer, men den blir eneste gyldige versjon for regnskapsår som starter i 2027 eller senere, og en feilretting i skjemaet fra oktober gjør at noen filer som validerte før, ikke gjør det nå. Her er det byrået bør vite, og det dere bør sjekke hos systemleverandøren før årsskiftet. Kildene er Skatteetatens dokumentasjon og forskriftene.

Hvilken versjon gjelder når

Skatteetaten skriver på dokumentasjonssiden for SAF-T Regnskap: «Nytt skjema (versjonsnavn 1.40) er pliktig fra 1. januar 2027, men kan tas i bruk umiddelbart om ønskelig. Nytt skjema gir full tilbakekompabilitet. De gamle skjemaene (versjon 1.20 og 1.30) kan fortsatt benyttes for tidligere år (regnskapsår 2026 og tidligere).» Samme side kaller 1.40 «eneste gyldige format fra 1. januar 2027».

Den engelske dokumentasjonen, versjon 1.8 av 31. august 2026, knytter kravet til regnskapsperioden (Norwegian SAF-T Financial data – Documentation):

De to tekstene er ikke helt like. Dokumentasjonssiden sier at både 1.20 og 1.30 kan brukes for 2026 og tidligere, mens dokumentasjonen sier at 1.30 er påkrevd fra 2025. En lesning som er i tråd med begge tekstene, er 1.30 eller 1.40 for 2025 og 2026, og 1.40 fra 2027.

Avvikende regnskapsår. Dokumentasjonen knytter kravet til perioden som *starter* 1. januar 2027 eller senere. Hvilken versjon som gjelder for et avvikende regnskapsår som starter i 2026, er ikke avklart i kildene vi har lest. Har dere klienter med avvikende regnskapsår, bør dere avklare det med Skatteetaten.

At skjemaet er bakoverkompatibelt, betyr at endringene i 1.40 er tillegg og utvidede datatyper. Filen må likevel oppgi riktig versjon i AuditFileVersion og validere mot 1.40-skjemaet.

Hva som endres fra 1.30 til 1.40

Skatteetaten beskriver fem endringer, alle med full bakoverkompatibilitet (dokumentasjonen og skjemaet på GitHub):

1. Eiere: AccountID under Owners kan forekomme flere ganger.
2. Ny datatype for lange beløp: SAFlongmonetaryType tillater inntil 38 sifre, hvorav inntil 18 desimaler.
3. Valutabeløp og kurs: CurrencyAmount og ExchangeRate i AmountStructure bruker den nye datatypen.
4. To nye, valgfrie elementer: VirtualCurrencyType og Country i AmountStructure, tatt med for informasjon og analyse. Country kan brukes når valutaen ikke viser landet, for eksempel euro.
5. Mva-beløp i kroner: ny struktur med DebitNOKTaxAmount og CreditNOKTaxAmount i TaxInformation. Den skal bare brukes når mva-beløpene står i annen valuta enn norske kroner.

Dokumentasjonen fikk også nye innsendingskanaler i versjon 1.8. Altinn er ikke lenger egen innsendingskanal for SAF-T Financial. Filen sendes i stedet med et skjema i kontrollsaken eller via API. Mer om det under.

Feilrettingen i oktober 2026

Skatteetaten rettet XSD-skjemaene for både 1.30 og 1.40 i oktober 2026, uten nytt versjonsnummer (Skatteetaten på GitHub). Skjemaene definerte ved en feil SelectionCriteria i Header som valgfritt. Elementet er nå obligatorisk, slik den tekniske spesifikasjonen sier. En fil uten SelectionCriteria som validerte mot det gamle skjemaet, validerer ikke lenger. Det er det viktigste konkrete punktet å sjekke før årsskiftet.

Kravene fra 1.30 som fortsatt gjelder

Overgangen fra 1.20 til 1.30 var ikke bakoverkompatibel, og kravene fra den gjelder også i 1.40 (dokumentasjonen):

• SelectionCriteria i Header er obligatorisk.
• StandardTaxCode i TaxTable er obligatorisk.
• Hver konto i MasterFiles skal ha GroupingCategory og GroupingCode. Mapping til standardkontoer er fjernet som alternativ. Kontoene mappes mot næringsoppgaven. Kommuner bruker KOSTRA-art.
• Kunder og leverandører har BalanceAccountStructure med inngående og utgående saldo per reskontrokonto.
• TaxAmount er erstattet av DebitTaxAmount og CreditTaxAmount, og AnalysisAmount av DebitAnalysisAmount og CreditAnalysisAmount.
• Compensation i TaxCodeDetails skrives med små bokstaver (true eller false), ellers validerer ikke filen.

Obligatoriske felt uten verdi fylles med faste verdier: tekst «NA», dato «0001-01-01», klokkeslett «00:00:00», beløp «0.00» og heltall «0».

Når filen faktisk leveres

SAF-T Financial leveres bare på forespørsel, typisk ved kontroll. Det finnes ingen fast innsendingsfrist (Skatteetaten, «SAF-T Regnskap»). Hjemmelen er bokføringsforskriften § 7-8: bokføringspliktige som skal ha bokførte opplysninger elektronisk tilgjengelig, skal kunne gjengi dem i standardisert form (Lovdata).

Fra 1. januar 2027 oppheves unntaket fra kravet om elektronisk tilgjengelighet for bokføringspliktige med omsetning under 5 millioner kroner (Skattedirektoratets uttalelse, forskriften). Konsekvensen er at også mindre klienter som var unntatt, må kunne levere SAF-T når Skatteetaten ber om det. Skatteetaten skriver ikke dette uttrykkelig, men det følger av at unntaket faller bort.

Slik leveres filen etter dokumentasjonen versjon 1.8:

• Skjema i kontrollsaken: skjemaet finner dere i meldingstråden for kontrollsaken på Min side eller i Altinn-innboksen. Det forutsetter at det er varslet kontroll.
• API fra sluttbrukersystem: filen kan sendes automatisk fra et integrert system.
• Store filer: revisoren hos Skatteetaten kan avtale overføring på annen måte.

Én innsending kan ha inntil 20 filer på inntil 2 GB hver, og flere innsendinger i samme kontrollsak er lov. Hver fil inneholder data for høyst ett regnskapsår (dokumentasjonen).

Skatteetaten validerer filen mot XSD-skjemaet ved innsending, men kontrollerer ikke nøkkelreferanser automatisk, for eksempel at en konto i en transaksjon finnes i MasterFiles. En fil kan altså bli godtatt og likevel være lite brukbar i kontrollen.

Hva byrået bør validere før årsskiftet

Punktene bygger på Skatteetatens dokumentasjon og tekniske beskrivelse. De er råd, ikke lovkrav, med mindre det står.

1. Spør systemleverandøren hvilken versjon eksporten gir for regnskapsår 2027, og om feilrettingen fra oktober 2026 (obligatorisk SelectionCriteria) er tatt inn.
2. Lag en testfil og valider den mot XSD-skjemaet for 1.40 fra Skatteetatens GitHub. Skatteetaten anbefaler XSD-validering av testfiler.
3. Sjekk `AuditFileVersion` og at filen har SelectionCriteria.
4. Gå gjennom kontomappingen. Alle kontoer med bevegelse eller saldo i perioden skal ha GroupingCategory og GroupingCode mot næringsoppgaven. Mappingen er historisk per år.
5. Bruk riktig kodeliste for grupperingskoder. Sjekk på Skatteetatens GitHub om det er kommet en liste for 2027 før årsoppgjøret.
6. Sjekk mva-kodene. Hver intern mva-kode skal ha StandardTaxCode nøyaktig som i kodelisten. Kan den ikke mappes, brukes «NA». Utenlandske mva-koder mappes ikke til norske standardkoder.
7. Valuta: klienter med fakturaer i utenlandsk valuta skal ha mva-beløpene i kroner i 1.40.
8. Obligatoriske felt uten verdi skal ha de faste verdiene over. Valgfrie felt som finnes i systemet, skal også med i filen.
9. Kunder og leverandører: postnummer og poststed er obligatoriske. Mangler adressen, kan «NA» brukes (spørsmål og svar).
10. Sjekk nøkkelreferansene selv. Kontoer, kunder, leverandører og mva-koder som brukes i transaksjonene, skal finnes i MasterFiles.
11. Filnavn: bruk Skatteetatens anbefalte mønster. Det er et råd, ikke et krav.
12. Klienter under 5 millioner kroner i omsetning: avklar at regnskapet er elektronisk tilgjengelig og kan eksporteres fra 1. januar 2027.
13. Avvikende regnskapsår: avklar versjon med Skatteetaten.

Hvem gjør hva i byrået

Systemleverandøren lager eksporten, men Skatteetaten skriver at regnskapsføreren må kontrollere at kontoer og mva-koder er mappet riktig (spørsmål og svar om SAF-T Financial). Legg mappingen og testresultatet i oppdragsdokumentasjonen, så oppdragsansvarlig kan se at kontrollen er gjort.

Når klienten bytter system

SAF-T er ikke bare et kontrollformat. Skatteetaten nevner også bruk som arkivformat, ved flytting av data ved systembytte og ved overføring til andre systemer (dokumentasjonen). Bytter en klient regnskapssystem rundt årsskiftet, er en SAF-T-fil fra det gamle systemet en enkel måte å ta vare på historikken på. Sjekk at filen validerer før det gamle abonnementet sies opp.

KETL eksporterer regnskapsdata som SAF-T Financial. Versjon 1.40 er på plass i eksporten fra serveren og innføres i alle eksportveier. Status står på siden for utviklere.

Les også: EHF-plikt fra 1. januar 2027 – hva byrået må gjøre for klientene

Bakgrunn: hvem som bestemmer formatet

Norsk SAF-T bygger på en anbefaling fra OECD. En prosjektgruppe med Skatteetaten, NHO, Regnskap Norge og Revisorforeningen ga sine anbefalinger i 2014 (dokumentasjonen). Skattedirektoratet fastsatte standarden i 2018, og plikten gjelder for regnskapsperioder som starter 1. januar 2020 eller senere (Skatteetaten, «SAF-T Regnskap»).

Formatet forvaltes av et eget forvaltningsorgan med Skatteetaten, Regnskap Norge, Revisorforeningen, to systemleverandører og to private konsulenter. Skatteetaten er skjemamyndighet (dokumentasjonen). Endringer i skjemaet publiseres på Skatteetatens dokumentasjonsside og på GitHub. Feilrettingen fra oktober ble publisert på GitHub, så det lønner seg å følge med selv og ikke bare vente på systemleverandøren.

Tekniske spørsmål om integrasjon kan stilles i Skatteetatens Slack-kanal for SAF-T. Spørsmål om format og regelverk går gjennom «Kontakt oss» hos Skatteetaten.

Om artikkelen

Artikkelen er skrevet og fagkontrollert av Andreas Hjertaker, grunnlegger av KETL, 5. november 2026. Fagkontrollen er ikke gjort av en statsautorisert regnskapsfører. KETL har ennå ikke knyttet til seg en fagrådgiver med statsautorisasjon, se fagansvar i tillitssenteret. Artikkelen er ikke juridisk rådgivning. Kontroller alltid mot kildene under.