Her går vi gjennom noen ting som er lurt å vite angående SAF-T import og import fra ulike systemer. Velg systemet som du har brukt tidligere for å lese mer.
SAF-T
Standardisert format som kan erstatte følgende andre importer eller manuelle jobber:
- Åpningsbalanse
- Historisk Balanse
- Kunder/leverandører (samtlige eller kun de med bevegelse)
- Prosjekter og Avdelinger
Dimensjoner prosjekt / avdeling
SAF-T fil inneholder transaksjoner mot dimensjoner prosjekt og avdeling, men har ingen IB/UB på disse dimensjonene (slik filen har på kunde/leverandør). Det vil si, har du et prosjekt som startet i 2019 og tar en SAF-T fil fra 2019, så får du korrekt IB på prosjekt 1. Jan 2020.
Men har du derimot startet med et prosjekt i 2018, og kun overfører SAF-T fil for 2019 så vil IB 1. Januar 2020 kun vise sum av transaksjonene i 2019, og dermed ikke korrekt IB for prosjektet.
Angremulighet
Etter import kan du angre, men dette må gjøres FØR du eventuelt bokfører noe etter importen. Skal det importeres i et selskap så kan det dermed være en fordel å be andre med bokføring/fakturerings-tilgang om å avvente bokføringen i tiden du foretar importen.
Fallgruver
- Vi anbefaler at du bruker eksempelfilene som finnes på de ulike importsidene i systemet og fyller inn informasjonen du skal importere direkte i disse filene. Da vet du at formatet blir korrekt. Du kan også se kravene for hva filene må inneholde ved å se «Beskrivelse av filformat» på samme side.
- Definer fakturakontoer (spesielt dersom det er flere og i ulike valutaer) før du utfører en SAF-T-import. Du kan miste muligheten til å definere en bankkonto som fakturakonto dersom denne er i en annen valuta og det er tatt SAF-T-import mot denne kontoen.
Eksempel:
EUR-konto 1940 er mappet til 1941 (NOK-konto) i SAF-T-fil for å unngå valutaproblematikk - da SAF-T-filen ikke inneholdt valutaføringer. 1940 og 1941 blir likevel koblet sammen, og EUR-kontoen 1940 kan ikke velges som fakturakonto i etterkant. 1941 kan heller ikke velges da denne har samme kontonummer som 1940 og kan ikke defineres med EUR.
Uni
Har eksport både årlig og månedlig.
eAccounting
Oppgir ikke kunde i SAF-T fil ved fakturering. Dette fører til at mange transaksjoner mot 1500 ikke er definert med Kunde. Tripletex løser dette med å sette kunden som «Ukjent kunde».
Sum 1500 (kundereskontro) er altså riktig, men det blir ikke liggende på korrekt kundereskontro (kunde). Dette medfører en del varslinger fra Saf-t fil om at UB kunde ikke stemmer med UB fra transaksjoner, men disse varslingene kan oversees. Hvis du synes det er ryddigere å ikke ha de mot reskontro i det hele tatt, så map konto 1500 til f.eks 1501.
Visma Business
Er det en feil i SAF-T eksport som gjør at enkelte bilag ikke balanserer i importen av SAF-T filen, kan følgende kan løse problemet:
- Sjekk at du har siste versjon (14.10.1).
- Det er en innstilling i Visma Business: «G/L trans pr invoice in the Account processing», som må settes til riktig verdi.
-
Deretter forsøke å importere denne SAF-T filen, og se over at det er korrekt.
SAF-T eksport fra Mamut
Hele avgiftsregisteret tas med i eksportfilen, alle avgiftskoder må derfor mappes (også de som ikke er i bruk) da de tas med i importen.
Les mer om SAF-T eksport til Skatteetaten
Importfilen inneholder ugyldige mva-koder. Avgiftskode (TaxCode) 10 har standardkode 0 i SAF-T-oppsettet. Mva-kodene må spesifiseres korrekt i SAF-T-filen
Dette betyr at en eller flere standardkode ikke er definert på avgiftskoden(e) for mva i Mamut. Dette kan defineres i Mamut, og så eksporterer du på nytt.
Hvordan få mappet kontoplan og avgiftsregister med SAF-T koder?
Visma.net
Dersom du får differanse på konto 2400 kan det være at skyldig beløp på moms, skatt og/eller aga er ført på reskontro. Ved SAF-T import dukker da skyldig momsbeløp opp både på konto 2740 (MVA) og på en leverandørreskontro som er styrt mot 2400 - det dukker altså opp dobbelt.
Gjeld/fordringen kan da slettes fra åpningsbalansen.
Åpningsbalanse
Reskontroeksport fra Mamut. Her er riktig beløp i raden «amount», ikke «UB».
Fakturaimport
Uni micro: KID lagres ikke i databasen i UNI, dvs det er ikke mulig å få over en fakturaimport med KID-info. Ønsker du å fortsette med kid på faktura må du opprette ny OCR-avtale for Tripletex.
Les mer om bankintegrasjon via Autopay
Eksempel:
En kunde med ekstremt mange åpne fakturaer ved overgang til Tripletex:
Fakturaimporten kom uten KID. Forslaget her da var at kunden beholdt Uni i noen måneder slik at innbetalingene fortsatte å komme inn til UNI. På den måten fikk de lukket postene mot korrekt kundereskontro. Deretter tok de hver måned ut en saf-t import med banktransaksjoner. Ny OCR-avtale ble opprettet ved overgangen og denne ble benyttet ved ny fakturering fra Tripletex.
Fakturaimport med store filer bør deles opp slik at du unngår evt feilmeldinger og krasj ved importen. Feilmeldingene kan være misvisende da du får feilmelding uten henvisning.