SAF-T 1.40: krav fra 2027 og en testbar overgangsplan

Skatteetaten oppgir at SAF-T Regnskap 1.40 blir påkrevd fra 1. januar 2027, og at utgaven kan tas i bruk allerede nå. Dokumentasjonen beskriver også hvilke eldre utgaver som kan brukes for tidligere regnskapsår. Kontroller den gjeldende informasjonen for perioden filen faktisk gjelder; eksportdatoen alene avgjør ikke versjonsvalget.

En overgang er mer enn å endre versjonsteksten i XML-filen. Avsenderen må produsere riktig struktur og riktige opplysninger, og mottakeren må forstå dem. Bevar et prøvedatasett der dere kjenner kontoer, saldoer, motparter og referanser før første eksport i den nye utgaven.

Hvilken SAF-T-versjon skal brukes?

Dokumentasjonen beskriver 1.40 som fullt tilbakekompatibel. Det er likevel nyttig å teste lokale importere og valideringsjobber: et lokalt program kan ha lagt inn begrensninger som formatet selv ikke har. At en bestemt mottaker avviser en fil, avgjør ikke alene hvilken utgave myndighetenes dokumentasjon tillater.

SAF-T Regnskap er et format for regnskapsdata. Det er ikke det samme som EHF-faktura eller SAF-T Kassasystem. Levering til Skatteetaten skjer på forespørsel ved kontroll, ikke som en generell månedlig SAF-T-innsending. Se leveringsloggen ved kontroll.

En prøve med samme kildegrunnlag

Anta at dere har en kontrollert eksport for regnskapsåret 2026. Lag en prøve i 1.40 med samme avgrensning, uten å endre regnskapsdata under sammenligningen.

1. Last ned riktig XSD og dokumentasjon fra Skatteetaten.
2. Registrer utgave og sjekksum for testgrunnlaget.
3. Kjør strukturkontroll og uavhengig avstemming.
4. Prøv mottakeren med både nye og relevante historiske filer.
5. Dokumenter uavklarte avvik før produksjonsbruk.

Eksempel: samme nettosaldo, ulikt innhold

To lokale bankkontoer, B-01 og B-02, har 10 000 og 30 000 kroner. Etter formatbyttet viser en kontrollrapport fortsatt 40 000. Det ser lovende ut, men hvis bare B-01 finnes i mottakeren, er detaljen borte. En totalsum kan ikke bekrefte at de to kontoidentitetene er bevart.

Prøv derfor både samlet saldo og saldo per kildekonto. Bevar koblingen til eventuell kontogruppering. AccountID og standardisert kontogruppering forklarer hvorfor lokal kontokode og standardisert gruppering trenger egne kontroller.

Test også en transaksjon i fremmed valuta, en post med kunde- eller leverandørreferanse og en historisk fil. Skriv forventet resultat før testen kjøres. Velg ut fra data dere faktisk bruker, ikke bare eksempelfilen som fulgte validatoren.

Bestått XSD-kontroll viser struktur mot det valgte skjemaet. Den erstatter ikke saldoavstemming eller kontroll av regnskapsinnhold. Ikke merk filen «godkjent» uten å beskrive hvilke kontroller som faktisk er utført.

Se versjon og navnerom og kontokoblingens ulike felt.

Godkjenn overgangen separat for hver arbeidsprosess. En ny eksport kan være klar for myndighetskontroll, mens en ekstern saldoimport fortsatt mangler prøving. I det syntetiske 2026-uttrekket bør samme fil derfor prøves både for struktur, økonomisk sammenheng og den konkrete mottakerens behandling. Dokumenter disse resultatene som forskjellige beslutninger.

Sett også en kontrollert dato for produksjonsbyttet. En jobb som ble startet med gammel konfigurasjon, skal ikke fortsette med ny struktur midt i samme leveranse. Bevar eksportinnstillinger og mapping, slik at et avvik etter byttet kan knyttes til riktig utgave uten at den tidligere kontrollerte filen må endres.

En overgangslogg som kan brukes ved feil

Noter kildeuttrekk, programversjon, AuditFileVersion, valgt XSD, mappingutgave og kontrollresultat. Registrer både eksportjobb og mottakerjobb. Da kan en utvikler skille en feil i avsenderens fil fra en begrensning i mottakerens leser.

Bruk testpakken for regnskapsimport hvis filen skal flyttes til et nytt system. En vellykket eksport for kontroll og en godkjent import til videre drift er to forskjellige leveranser.

Kilder

• Skatteetatens gjeldende SAF-T-dokumentasjon
• Offisielt XSD for SAF-T 1.40