SAF-T-eksport for norske regnskap: Hva, hvorfor og når

SAF-T er en internasjonal standard utviklet av OECD, men den norske varianten har egne krav. Filen inneholder hovedbok,kontoplan, kundereskontro, leverandørreskontro, journaler og bilagsdetalj, alt strukturert i et XML-skjema som Skatteetaten har publisert. Formatet er ikke en backup, ikke en regnskapsdump, og ikke et migreringsformat. Det er et kontrollformat, designet for at Skatteetaten skal kunne kjøre automatiske kontroller mot data fra ulike regnskapssystemer uten å måtte lære hvert system i detalj.

For et byrå betyr standarden flere ting. Det er forutsigbart hva Skatteetaten kan utlede av fila, det er mulig å kjøre de samme kontrollene selv før innsending, og en velbygget SAF-T-eksport er et godt mål på om regnskapssystemet ditt har orden i bunn. Hvis systemet sliter med å generere en valid SAF-T, sliter det sannsynligvis også med andre grunnleggende ting du ikke ser i daglig bruk.

Filen skal valideres mot et offentlig XSD-skjema før innsending. Den må dekke perioden Skatteetaten har bedt om, og den må være generert fra et godkjent regnskapssystem. Det finnes ingen formell sertifisering av at et system er godkjent, men i praksis betyr det at systemet ditt må produsere en fil som faktisk validerer. Hvis fila ikke validerer, blir den avvist, og byrået må generere en ny.

Det er også et krav om at fila skal kunne sendes inn innen den fristen Skatteetaten setter. Det er typisk to til fire uker, men ved omfattende bokettersyn kan fristen være kortere. Hvis byrået ikke kan levere innen fristen, kan Skatteetaten ilegge forsinkelsesgebyr, og i alvorlige tilfeller kan det utløse estimat-skatt i stedet for grunnlagsbasert vurdering. Det er sjelden, men det skjer.

Du må ha mulighet til å produsere SAF-T-eksport når som helst for inneværende og forrige regnskapsår. Selve eksporten skjer kun ved konkret etterspørsel fra Skatteetaten, vanligvis ved bokettersyn eller stikkprøvekontroll, og fristen er typisk 2 til 4 uker fra forespørselen. Det er kort tid hvis systemet ditt ikke har funksjonen. Det betyr at byrå bør teste SAF-T-eksport som en del av onboarding av et nytt regnskapssystem, ikke først når Skatteetaten ringer.

Filen åpner med en header med selskapets organisasjonsnummer, programvareversjon og periode. Deretter følger fire hoveddeler.

• MasterFiles, med kontoplan, kundereskontro, leverandørreskontro, ansattliste og avgiftskoder.
• GeneralLedgerEntries, med alle journaler og linjer i hovedbok for perioden.
• SourceDocuments, med fakturaer, betalinger og lager-transaksjoner.
• AuditFile-footer, med totaler som Skatteetaten kan avstemme mot innholdet.

Strukturen høres tungvint ut, men en korrekt SAF-T-fil lar Skatteetaten kjøre kontroller på avgiftsgrunnlag, avstemminger, perioder og fullstendighet uten å åpne det originale regnskapet. For byrået betyr det at en god SAF-T er også en god intern kontroll, fila skal stemme før den sendes.

Last ned XSD-skjemaet fra Skatteetatens nettside, og kjør fila gjennom en lokal validator før innsending. De fleste IDE-er og kommandolinjeverktøy kan validere XML mot XSD i sekunder. Validering gir deg navn på elementet som er feil, linjenummer, og en feilmelding du kan fikse direkte i regnskapssystemet. Hvis systemet ditt ikke gir deg lett tilgang til fila for validering, er det et tegn på at SAF-T-funksjonen er etter-bygget, ikke integrert.

• Avgiftskoder må mappes mot Skatteetatens standardkoder, ikke byråets interne koder. Hvis du har en egen kode 27 for et spesialtilfelle, må den mappes til en gyldig SAF-T-kode i eksporten.
• Åpne poster i reskontro må stemme på krona med saldobalansen. Vanlige avvik kommer fra utligning som ikke er bokført med riktig dato.
• Bilagsserier må være sammenhengende og uten hull. Slettede bilag skal flagges som annullert, ikke fjernes fra fila.

Avgiftskode-mappingen er den tabbe vi ser oftest. Et byrå har bygget seg en intern avgiftslogikk over årene, og når SAF-T-eksporten kjøres første gang, ramler det ut tegn på at mappingen ikke holder. Da må byrået ta omveien å rette koden i selve regnskapet, ikke bare i eksporten. Det er tidkrevende hvis det avdekkes når Skatteetaten allerede har satt en frist.

SAF-T og MVA-meldingen er to forskjellige innsendinger, men de skal stemme overens. MVA-grunnlaget per kode i SAF-T-fila skal være lik beløpene rapportert i MVA-meldingen for samme periode. Hvis Skatteetaten kjører kontroll og finner avvik mellom de to, er det første spørsmålet hva som er riktig. En velbygget intern kontroll kjører denne avstemmingen før hver MVA-innsending, ikke først når Skatteetaten ber om fila. Vi har skrevet mer om dette i MVA-melding-guiden.

SAF-T-eksport står på veikartet for Q2 2026 (placeholder, ikke i drift ennå). I dag har vi en intern validator som kjører på hovedbok-data, slik at byrå kan ta interne kontroller selv før funksjonen er ferdig. Når den er i produksjon, vil du kunne generere en validert SAF-T direkte fra regnskap-modulen uten ekstra eksport-trinn. Avgiftskoder mappes automatisk mot Skatteetatens standard, og avstemming mot MVA-grunnlaget per termin går i bakgrunnen.

SAF-T er ikke valgfritt, og ventelisten ved bokettersyn er kort. Test eksporten før Skatteetaten ber om den, valider mot XSD-skjemaet, og mapp avgiftskoder mot standarden. Da blir kontrollen rutine, ikke krise. Hvis byrået ditt vurderer å bytte regnskapssystem, er SAF-T-eksport en god test å kjøre tidlig i prosessen. Det avslører om det nye systemet håndterer norske krav i bunn, eller om det er en lokalisering på toppen av et internasjonalt produkt.