SAF-T fra nyttår – hva må du tenke på?

Kontoplan og MVA-kodene må tilpasses SAF-T, og det bør testes om SAF-T-eksporten fungerer.

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

Basert på samtaler med flere av våre medlemmer satser mange bokføringspliktige og regnskapsforetak på at systemleverandøren leverer en SAF-T-eksport fra regnskapssystemet som ivaretar kravet i bokføringsforskriftens § 7-8. Våre observasjoner hittil tilsier at det ikke er helt rett frem å lene seg på at systemleverandør løser alle kravene til eksportfilen. Hva må du som bokføringspliktig eller regnskapsfører tenke på? 

Hva er egentlig SAF-T? 

Gjennom et offentlig og privat samarbeid, med Skatteetaten og Regnskap Norge i spissen, ble SAF-T-standarden utviklet for å ivareta en smidig transport av data mellom IT-systemer og sikre en effektiv metode for å hente data ved et varslet bokettersyn.  

SAF-T er teknisk sett en strukturert XML-fil som, i tillegg til faste data om virksomheten, inneholder alle transaksjoner i hovedboken og i kunde- og leverandørspesifikasjonene. SAF-T-filen skal ved forespørsel kunne eksporteres fra regnskapssystemet og leveres inn til Skatteetaten via Altinn. Skatteetaten har publisert generell informasjon og teknisk informasjon om SAF-T til hjelp for bokføringspliktige og systemutviklere. 

Eksempel på en XML-struktur i SAF-T 

Har den bokføringspliktige ansvar for XML-strukturen? 

Det korte svaret er ja. Skatteetatens kontrollører vil ved feil i filen, som gjør ettersynet vanskelig eller umulig, kun forholde seg til den bokføringspliktige som har kravet på seg. Dog er det ikke unaturlig at den bokføringspliktige vil søke regress hos enten regnskapsfører og/eller systemleverandør – hvis det er feil i det tekniske uttrekket og den bokføringspliktige har fått en bot etter straffelovens § 392. 

Ulempen med standardisering er at det dessverre utvikles dialekter av standarden hos forskjellige systemleverandører. Årsaken til dette kan være manglende kompetanse på det bokføringstekniske, men også at kravene i standardene ikke er tilstrekkelig dokumentert og eksemplifisert. Dette åpner for ulik tolkning av hva som skal ligge hvor i den strukturerte filen. Feil bruk av taggen «journaltype» (GL, AR, AP og A) er et eksempel på observerte feilFilen kan teknisk sett valideres i Altinn, men likevel inneholde feil som gjør at filen ikke representerer bokføringen. Data kan være ufullstendige, unøyaktige eller fremstilles som noe annet enn hva det er. 

Det kan ikke forventes at den bokføringspliktige i detalj skal kontrollere den tekniske strukturen i XML-filen, men som et minimum må den bokføringspliktige sikre at filen validerer i Altinn. Her er det mulig å sende inn testfiler. Systemleverandør gjør normalt dette, men den bokføringspliktige må innhente informasjon om resultatene av testen 

I tillegg må den bokføringspliktige stille spørsmål til systemleverandør eller regnskapsfører om visse forhold i oppsettet. Eksempler på slike spørsmål skal vi se nærmere på i det følgende. 

Mapping av kontoplan 

I SAF-T-strukturen skal den bokføringspliktiges kontoplan mappes opp til en standard kontoplan. Begrunnelsen for dette er at kontrollmyndigheter, revisorer, regnskapsførere med videre skal kunne lage standardiserte analyse- og kontrollhandlinger ut ifra en standardisert kontostruktur.  

SAF-T-standarden legger opp til fire hovedkategorier av mapping av kontoer. Den bokføringspliktige kan fritt velge mellom disse. 

  • Firesifret utvidet kontoplan (Kilde: Regnskap Norge) 
  • Tosifret kontoplan (Kilde: Regnskap Norge) 
  • Næringsoppgaver (Kilde: Skatteetaten) 
  • KOSTRA (Kilde: Kommunal- og moderniseringsdepartementet) 

Skatteetaten eller andre har ikke gitt noen føringer for valget, men fra vårt perspektiv er mapping til tosifret kontoplan den minst anvendbare ut ifra et analyse- og kontrollformål. Skatteetaten jobber også med et prosjekt hvor “fra skjema til tema” er målet. Det er derfor usikkert hva som skjer med næringsoppgavene fremover, og om nummereringen i næringsoppgavene opprettholdes i systemer som skjulte koder. Benyttes næringsoppgaven som mappingstruktur, kan det være at den bokføringspliktige må endre dette om noen år. KOSTRA er kun relevant som mapping for kommunale virksomheter. 

Det er vår oppfatning at noen systemleverandører lar den bokføringspliktige velge mappingmetode, mens andre leverandører velger en type mapping i systemet.  

Den bokføringspliktige må se igjennom mappingen slik at rapporteringen ser fornuftig ut. Det er ikke meningen at den bokføringspliktige skal endre sine kontoplaner, men mappe så langt det lar seg gjøre til standardstrukturen. Hvis den bokføringspliktige er usikker på mappingen, kan det være greit å gi opplysninger om dette ved bokettersynet for å unngå misforståelser hos kontrollørene. 

Mapping av MVA-koder 

I likhet med kontoplanen, skal MVA-koder som den bokføringspliktige bruker mappes til en standardisert MVA-kodestruktur. Standard kodestruktur åpner for å vise forholdsmessig fradrag, endring i satser gjennom året mv.

I likhet med mapping av kontoplanen, må den bokføringspliktige kontrollere at MVA-kodene i bruk i bokføringen blir korrekt mappet til standard MVA-kodestruktur og med korrekte parametere på satser mv. 

Frivillige felt kan være obligatoriske! 

I SAF-T standarden har vi en gruppe data som heter “AnalysisTypeTable”. Dette kan typisk være en tabell over avdelingskoder, prosjektkoder, bilagsarter, ansattnummer mv. Datagruppen er i standarden definert som frivillig. Dette er en snubletråd for mange.  

Hvis den bokføringspliktige for eksempel benytter avdelingskoder og/eller prosjektkoder i sin bokføring, skal disse legges med i SAF-T-filen, og datafeltene i konteringsstrengen blir derfor obligatoriske. De bokføringspliktige som ikke bruker denne type koder i sin bokføring skal ikke forholde seg til denne datagruppen.  

Årsaken til at denne snubletråden finnes, er at filen ikke skal feile i valideringen i Altinn hvis datagruppen av faktiske årsaker ikke skal være med. Den bokføringspliktige må sikre at alle relevante konteringskoder blir med i eksportfilen. 

NUF og bruk av utenlandske systemer 

Flere regnskapsførere har henvendt seg til vår fagsupport vedrørende NUF og hvordan disse skal forholde seg til reglene rundt SAF-T. En vanlig problemstilling er at regnskapet føres i utlandet på utenlandske systemer uten funksjon for norsk SAF-T-eksport. Bokføringsregelverket rundt SAF-T har ingen unntaksregler ved bruk av utenlandske regnskapssystemer. Dispensasjonsadgangen er også streng.  

Skatteetaten legger til grunn at eksportmuligheten blir implementert i tide, eller at det inngås en avtale med et selskap som kan konvertere filer fra det utenlandske systemet til SAF-T-formatet. Det er flere i markedet som tilbyr en slik konverteringstjeneste. Et søk på internett vil synliggjøre noen av disse. Her må den bokføringspliktige gjennomføre en grundig test av konverteringen slik at SAF-T-filen er fullstendig og nøyaktig. 

SAF-T skal normalt ikke påvirke hvordan den bokføringspliktige legger opp bokføringen. Likevel kan vi se at en praksis i bokføring av visse transaksjoner i NUF kan vise seg å være uhensiktsmessig når de jobber med SAF-T-eksporten. Vi tenker da spesielt på føring av mellomværende mellom NUF og morselskapet. Flere NUF har ikke en tradisjonell reskontro med morselskapet, men det føres midler mellom selskapene primært ut ifra et likviditetsbehov som bokføres sammen med fakturaer mellom partene. Mellomværkontoen blir da en evigvarende konto uten mulighet til å dokumentere saldoen med åpne poster. Skatteetaten legger til grunn at krav og betaling skal krysses ut og at saldoen skal være mulig å avstemme og dokumenteres med åpne poster 

Det andre som vi ser er at NUF ikke alltid har bankkonto i Norge. Her må det benyttes en mellomregningskonto eller annen konto for å mappe saldoen. Mappingen av kontoen må reflektere eierskapet til midlene (NUF eller morselskapet). 

Noen internasjonale konsern har tusenvis av hovedbokskontoer tilgjengelige i regnskapssystemet. Det norske NUF eller et datterselskap kan kanskje bruke et lite utvalg av disse i sin bokføring. Det er vår oppfatning at det kun er relevante hovedbokskontoer i bruk som skal inkluderes i eksportfilen og mappes til standard kontoplan. 

MVA-representanter 

MVA-representanter vil være ansvarlig for deler av bokføringen siden de er MVA-registrert, jamfør bokføringslovens § 2, 2.ledd, uavhengig av solidaransvar for MVA. Dersom bokføringen er elektronisk etter bokføringslovens § 13b er det krav om å kunne gjengi informasjonen i SAF-T format etter bokføringsforskriftens § 7-8. 

En del regnskapsførere foretar ikke bokføringen for de utenlandske selskapene, men de vil ha et ansvar for at «sine» bokførte opplysninger må kunne gjengis i SAF-T format, eksempelvis grunnlaget for skattemelding MVAHer må MVA-representanter sikre at de evner å levere en slik fil inn i Altinn ved forespørsel. 

 

Aktuelt nettkurs: SAF-T