SAF-T ett år etter

Kravet om å kunne levere bokførte opplysninger som er tilgjengelig elektronisk i SAF-T-formatet har passert ett år. Hva er erfaringene så langt?

Del
!
Artikkelen er over ett år gammel og innholdet kan derfor være utdatert

Fra 1.1.2020 måtte bokføringspliktige være i stand til å levere SAF-T Regnskap (hovedbok, kunde- og leverandørspesifikasjoner) via Altinn ved forespørsel fra myndighetene. Systemleverandører har nok vært noe sene med å implementere dette i sine løsninger. Andre etterspurte funksjoner fikk prioritet i perioden før kravet ble iverksatt. Kort tid til testing har medført noen utfordringer som vi omtaler mer nedenfor. 

Regnskap Norge sitter i forvaltningsorganet til SAF-T-standarden. I vårt møte i februar 2021 stilte vi spørsmål til Skatteetaten om erfaringer så langt. Her er de tilbakemeldinger vi fikk.

Bruksområder for SAF-T

Forespørsel om en SAF-T-fil er vanligst ved varslede bokettersyn hos den bokføringspliktige. Skatteetaten sier at de også har bedt om SAF-T-filer i forbindelse med kontroller av MVA-melding og ved kontroller knyttet til kompensasjonsordningen. Vi ser positivt på at etaten velger effektive løsninger for sin kontroll. Selv om ikke loven krever data fra før 1.1.2020, kan de fleste systemleverandører levere eldre data i formatet. Når det gjelder ytterligere bruksområder, er Skatteetaten opptatt av at formatet blir justert for å minimere feil, og at dagens løsning kommer ordentlig på plass. Dette før de ser for seg å utvide formatet, og dermed bruksområdet.

Strategien vil kunne påvirke næringslivets behov for utvidet bruksområde. Eksempelvis er det ikke med dagens format mulig å effektivt bytte regnskapssystem. Kun deler av databasene vil kunne oppdateres, mens mye må legges inn i tillegg. En utvidelse av formatet vil kunne bidra til mindre manuelt arbeid ved et bytte. 

Det er spesielt på to områder vi ser at SAF-T-formatet vil kunne spille en god rolle, og det er Nordic Smart Government (NSG) og MEMO.

NSG har i sitt prosjekt konseptet "Open Accounting" som et fokusområde. Dette innebærer en god flyt av regnskapstall mellom to eller flere interessenter. Vi har spilt inn til NSG at SAF-T må være med videre slik at ikke de store kostnadene til implementering av formatet er bortkastet. Prosjektets fase 4 skal vurdere en eventuell utvidelse av SAF-T-formatet for å nå målsettingen om "open accounting".

Vi er også i løpende dialog med MEMO-prosjektet om ny MVA-melding. SAF-T-mvakodene vil spille en sentral rolle i den nye rapporten, noe som knytter SAF-T-formatet enda tettere til offentlig rapportering, og gjør maskin-til-maskin-rapportering mer attraktivt.

Formatets utbredelse

Vi er av den oppfatningen at de fleste systemleverandørene i vår bransje har SAF-T-eksport på plass. Skatteetaten har kun et fåtall dispensasjonssøknader på bordet, noe som indikerer en bred utbredelse. De henvendelser vi i Regnskap Norge får er gjerne knyttet til eksport fra forsystemer, typisk faktura/kundespesifikasjoner hvor detaljene ligger i egne forsystemer og totaler i hovedboken. Flere spesialiserte forsystemer har ikke SAF-T-eksport, så den bokføringspliktige må enten få dette på plass, eller foreta en konvertering fra en proprietær løsning til SAF-T-formatet. En mulighet er også å overføre detaljer til hovedboken og ta SAF-T-eksport herifra.

Feil i filene

Det er to kategorier feil som oppleves i SAF-T-filene. Den ene kategorien kan regnskapsfører gjøre noe med, den andre kategorien må systemleverandørene rette på. 

En vanlig feil som regnskapsfører kan rette på er mapping til standard kontostruktur og mapping til standard MVA-koder. Noen har glemt å mappe i det hele tatt, mens andre har mappet til koder som ikke er gyldige. Det er viktig at regnskapsfører kontrollerer mappingstrukturen på sine kunder slik at feil i innsendelsene kan unngås og at kontrollene blir mer effektive. 

De feil som systemleverandør må rette på er; 

  • Feil datobruk. Bokføringsloven har flere datobegreper som ikke mappes korrekt i XML-strukturen. 
  • Bruk av pluss- eller minustegn i beløpsfelt (beløpene skal være uten fortegn, men med angivelse av debet eller kredit i XML-strukturen).
  • Feil tegnkoding i filformatet (det er UTF-8 som gjelder)
  • Oversendelse av unødige elementer i filen (Det som ikke er aktuelt for den bokføringspliktige skal ikke sendes over. Mengden av unødvendige data vanskeliggjør kontrollen)
  • Feil i totaler på filene (number of entries, total debit og total credit). Dette gjelder spesielt for delinnsendelser av filer. Ved delinnsendelse fra samme regnskapssystem skal totalene gjelde filene samlet. 

Det som er litt bekymringsfult er at alle disse problemstillingene kunne vært unngått om systemleverandørene hadde satt seg godt inn i teknisk informasjon som foreligger på Github-sidene til Skatteetaten. Skatteetaten varsler i dag om at feil må rettes og filer sendes inn på nytt. Vi må forvente på et eller annet tidspunkt at Skatteetaten ser på feil i fil som "ikke levert" med de konsekvenser det medfører for den bokføringspliktige.