Visma eEkonomi leverantörsfakturor: PDF till Excel och SI-fil

En byrå tar över en ny klient och får 140 PDF-leverantörsfakturor i en pärm. Volymen är för hög för att registreras en och en i Inköp → Leverantörsfakturor, och klienten är en allmän tjänsteverksamhet — ingen av Vismas vertikalsspecifika integrationer (Byggdagboken, Seven Time, SmartDok, Blikk) passar. Det är precis det scenariot som leder bokförare att söka på visma eekonomi leverantörsfakturor till excel och fastnar på en SERP där Vismas egna hjälpsidor förklarar enskild registrering, vertikalintegratörerna marknadsför sina branschlösningar, och ingen artikel ritar den allmänna byråns flöde från PDF till verifikat.

SI-filen är den individuella verifikatfilen som används för att importera enskilda verifikat löpande under räkenskapsåret. SE-filen är hela årsbokföringen som lämnas till revisor eller flyttas till en ny plattform. För att massimportera leverantörsfakturor från PDF bygger du en SI-fil som följer SIE-formatets #VER- och #TRANS-syntax (kontering mot 2440 Leverantörsskulder och relevanta 4xxx- eller 2641-konton) och läser in den via Inställningar → Import/Export → Bokföringsdata i Visma eEkonomi. PDF-originalen kopplas separat till respektive verifikat efter import så att Bokföringslagens krav på räkenskapsinformation uppfylls. Leverantörsreskontran med fakturanummer, förfallodatum och OCR per faktura följer däremot inte automatiskt med SI-importen — det glappet hanteras parallellt och förklaras i flödesavsnittet längre fram.

Fältschema för svensk leverantörsfaktura — och hur fälten landar i Visma

Innan en enda PDF ska bli ett verifikat behöver du en mall för vilka fält som ska extraheras. Mallen är samma artefakt oavsett om batchen sedan registreras manuellt, byggs om till SI-fil eller skickas via API — alla tre flödena bygger på samma strukturerade Excel. Nedan är fältuppsättningen som faktiskt behövs för Visma-import, grupperad efter vilken nivå fältet hör hemma på och vad Visma-funktionen kräver av det.

Leverantörsinformation

Fält	Visma-funktion det stödjer	Status
Leverantörsnamn	Matchning mot befintligt leverantörsregister	Obligatoriskt
Organisationsnummer	Primärnyckel för leverantörsmatchning	Obligatoriskt
F-skatt-status (Godkänd / Ej godkänd)	Flagga om preliminärskatt måste innehållas	Obligatoriskt vid svensk leverantör
Adress	Fyller leverantörsregistret vid första registrering	Trevligt att ha
VAT-nummer	Krävs vid EU-faktura för omvänd skattskyldighet	Obligatoriskt vid EU-leverantör
Bankgiro, Plusgiro eller IBAN	Betalningsförslag i Visma	Obligatoriskt för betalning

Visma matchar nya fakturor mot leverantörsregistret via organisationsnummer först, leverantörsnamn som fallback. Får organisationsnumret en exakt träff föreslår Visma också senast använda kostnadskonto via sin konteringshistorik per leverantör — ett moment som sparar konteringsarbete i nästa avsnitt.

Fakturahuvud

Fält	Visma-funktion det stödjer	Status
Fakturanummer	Unik nyckel i leverantörsreskontran, dubblettkontroll	Obligatoriskt
Fakturadatum	Bokföringsdatum vid SI-import	Obligatoriskt
Förfallodatum	Förfalloöversikt och betalningsförslag	Obligatoriskt för reskontrapost
Betalningsvillkor	Beräknar förfallodatum om det saknas	Trevligt att ha
OCR-nummer	Bankavstämning och betalningsmatchning	Obligatoriskt vid OCR-betalning
Vår referens / Er referens	Frivilliga fält men ofta krav i större organisationer	Trevligt att ha

OCR-fältet är där reskontra-avstämningen står och faller. Felaktigt extraherad OCR betyder att bankens betalning inte automatkopplas till rätt leverantörsfakturapost i Visma — manuell utredning per faktura följer.

Belopp

Fält	Visma-funktion det stödjer	Status
Belopp exklusive moms	Beloppsbas för 4xxx/5xxx/6xxx-konton	Obligatoriskt
Momsbelopp per momssats (25, 12, 6, 0 procent)	Bokning på 2641, 2642 eller 2643	Obligatoriskt per förekommande sats
Totalt belopp	Kreditbeloppet på 2440 Leverantörsskulder	Obligatoriskt
Rabatter	Reducerar beloppsbasen	Vid förekomst
Tillkommande avgifter (frakt, expedition)	Egen kostnadsrad eller ingår i varuinköp	Vid förekomst

Mallen måste kunna bära flera momssatser per faktura. Livsmedelsleverantörer ger ofta 25, 12 och 6 procent på samma faktura; hotellfakturor 25 och 12 procent. En summakolumn räcker inte.

Radnivå

Fält	Visma-funktion det stödjer	Status
Artikelnummer	Matchning mot artikelregister vid varuinköp	Trevligt att ha
Beskrivning	Verifikatstext, ger sökbarhet i bokföringen	Obligatoriskt
Antal	Lagerrörelse vid varuinköp	Vid varuinköp
À-pris	Lagerrörelse och prisrevision	Vid varuinköp
Radsumma	Avstämning mot fakturasumma	Trevligt att ha
Momssats per rad	Splittar momsbokningen korrekt	Obligatoriskt vid blandade satser
BAS-konto (4-siffrigt)	Direkt kontering vid SI-import	Obligatoriskt

Radnivåextraktionen är där tjänstefakturor och varuinköp skiljer sig. För en konsultfaktura räcker en eller två rader; för en grossistfaktura kan radantalet vara tre- till fyrasiffrigt. Excel-mallen behöver hantera båda utan att radantalet exploderar i ett separat ark per faktura.

Specialfält

Fält	Visma-funktion det stödjer	Status
ROT- eller RUT-arbetstyp	Underlag till Skatteverkets skattereduktionsbegäran	Obligatoriskt vid ROT/RUT
Fastighetsbeteckning	Samma	Obligatoriskt vid ROT/RUT
Slutkundens personnummer	Samma	Obligatoriskt vid ROT/RUT
Omvänd skattskyldighet inom bygg (flagga)	Bokning 3231 + 2645 vid SI-import	Vid förekomst
EU-omvänd moms (flagga)	Momsruta 20/21/22 och 50	Vid förekomst

Specialfälten gör batchen komplex, och de flesta extraktionsverktyg som inte är byggda för svensk redovisning faller här. Edge cases-avsnittet går igenom varje case i detalj.

En sista poäng om värdet av mallen: samma fältschema som driver leverantörsfaktura-importen ger dig också ett komplett underlag för momsdeklaration — beloppsfält per momssats och flaggor för EU-inköp och omvänd skattskyldighet är samma kolumner som behövs för att bygga momsdeklarationsunderlag ur samma leverantörsfaktura-extrakt. Ett extraktionssteg, två arbetsflöden ner.

Inköp eller Leverantörsfaktura — välj rätt Visma-modul innan batchen går in

Visma eEkonomi har två närliggande menyposter under inköpsmodulen som låter snarlika men gör olika saker. Att blanda ihop dem är en av de vanligaste orsakerna till att en batchimport som tekniskt går igenom ändå skapar problem vid månadsbokslutet. Distinktionen behöver sitta innan SI-filen byggs, inte efter.

Inköp är en kostnadsregistrering som omedelbart bokförs. Verifikatet skapas direkt — debet på ett kostnadskonto (4xxx, 5xxx eller 6xxx), kredit på likvidkontot eller ett tillfälligt skuldkonto — och ingen post läggs in i leverantörsreskontran. Funktionen är byggd för kvitton, småinköp där betalning skett kontant eller direkt med företagskort, periodiseringsverifikat, och liknande där det inte finns någon framtida betalning att följa upp.

Leverantörsfaktura är en reskontrapost. Här fångar Visma fakturanummer, förfallodatum och OCR per leverantör, lägger posten som en obetald skuld mot 2440 Leverantörsskulder, och stänger posten först när betalningen kommer in och matchas mot OCR-numret. Det är denna modul en batch på 140 PDF-fakturor med framtida förfallodatum hör hemma i — utan undantag.

Konsekvensen av att låta batchen gå in som Inköp i stället för Leverantörsfaktura är inte teoretisk. Du förlorar betalningsuppföljningen (Visma vet inte att fakturan väntar på att betalas), OCR-matchningen vid bankavstämning (bankens utbetalningar går inte automatiskt mot rätt skuldpost), och förfalloöversikten i Leverantörsreskontra-rapporten (kassaflödesprognoser som baseras på obetalda leverantörsfakturor blir tomma). Bokföringen på 2440 stämmer på saldonivå men du har ingen leverantörsspecifikation bakom saldot — och vid revision eller årsbokslut är det specifikationen revisorn frågar efter.

SI-filsflödet kräver en extra mental anteckning här. När du importerar en SI-fil bygger Visma upp bokföringsverifikatet exakt som det står i #VER- och #TRANS-blocken — debet på rätt kostnadskonto, debet på 2641 för moms, kredit på 2440 Leverantörsskulder. Vad SI-filen däremot inte gör är att skapa en motsvarande post i leverantörsreskontran med fakturanummer och förfallodatum kopplade till en specifik leverantör. Bokföringen är rätt; reskontran är osynlig.

Var ärlig med klienten innan importen körs — SI-fil är snabbast in, men leverantörsreskontran kräver en parallell plan, antingen efterföljande registrering i Leverantörsfaktura-modulen eller en Excel-baserad förfalloöversikt under övergångsperioden.

Tre flöden från PDF till verifikat i Visma eEkonomi

Utgångspunkten i samtliga tre flöden nedan är samma strukturerade Excel — fältschemat från föregående avsnitt, en rad per faktura (eller en rad per radnivå när du extraherar artikeldata). Det som skiljer flödena är hur datat sedan tar sig från Excel in i Visma. Volymintervallen är riktmärken byggda på vad som rent praktiskt blir hanterbart, inte hårda gränser.

Flöde 1 — Excel som arbetslista, manuell registrering i Visma

Lämpligt för 20–60 fakturor. Bokföraren har Excelarket öppet på ena skärmen och Visma eEkonomi på den andra, och registrerar varje leverantörsfaktura via Inköp → Leverantörsfakturor (eller motsvarande meny i SPCS Administration, Bokföring 2000 eller Smart). Excel är inte direktimport här — det är arbetslistan som gör volymen genomförbar.

Tre saker som flödet ger utöver tidsbesparingen jämfört med att läsa varje PDF direkt:

Avstämningsschablon. Summera Excelarket per leverantör innan registrering börjar. Stämmer leverantörssumman mot vad klienten har uppgivit som obetald skuld? Avvikelser hittas innan de blir reskontraposter.
F-skatt-kontroll i förväg. Filtrera Excelarket på leverantörer som saknar F-skatt-flagga. Visma flaggar detta vid registrering men det är effektivare att hantera samtliga avvikelser i en omgång före registreringen än att avbryta arbetet en faktura i taget.
Konteringsförslag per leverantör. För återkommande leverantörer ger Vismas konteringshistorik ett förslag, men för nya leverantörer behöver kontot väljas. Att lägga konteringen i Excel innan registrering startar gör att registreringen blir mekanisk i Visma — du klickar igenom snarare än överväger.

För batchar som ändå kräver attestbeslut per faktura (typiskt när en attestant utanför ekonomiavdelningen ska godkänna) är detta flöde rimligt även vid något högre volym, eftersom attesten ändå förutsätter manuell handpåläggning. När attestlogiken är fastställd i förväg eller saknas helt vinner flöde 2 snabbt.

Flöde 2 — Excel → SI-fil → Visma SI-import

Lämpligt för 60–500 fakturor. Detta är den massregistrering som artikelns första hälft pekat på: Excelarket transformeras till en SI-fil med #VER- och #TRANS-poster, filen importeras via Visma, och verifikaten skapas direkt i bokföringen utan att en enda faktura registreras manuellt.

En minimal SI-fil-skiss för två leverantörsfakturor ser ut så här:

#FLAGGA 0
#PROGRAM "ExcelExport" 1.0
#FORMAT PC8
#GEN 20260522
#FNAMN "Klientföretag AB"
#ORGNR 5560000001
#RAR 0 20260101 20261231
#VER A 1001 20260515 "Leverantörsfaktura 24-1187 Acme Konsult AB"
{
    #TRANS 2440 {} -12500.00
    #TRANS 2641 {} 2500.00
    #TRANS 6530 {} 10000.00
}
#VER A 1002 20260516 "Leverantörsfaktura F2026-553 Nordic Office AB"
{
    #TRANS 2440 {} -3750.00
    #TRANS 2641 {} 750.00
    #TRANS 5410 {} 3000.00
}

Strukturen är reglerad — varje #VER-block börjar med verifikatserie, verifikatnummer, verifikatdatum och verifikationstext, och innehåller därefter #TRANS-rader som måste summera till noll (debet positiv, kredit negativ). För full record-syntax och alla post-typer hänvisas läsaren till SIE-formatets fullständiga specifikation och record-syntax. Det som är värt att notera redan här är att SI-filen är ren text i PC8-kodning (kodsida 437 med svensk anpassning), läsbar i vilken textredigerare som helst, och fullt versionhanterbar.

Importen i Visma eEkonomi körs via Inställningar → Import/Export → Bokföringsdata, där du väljer SI-filen, granskar verifikatlistan i förhandsvisningen och bekräftar. Vismas förhandsvisning är där sista kontrollen mot fakturaschemat sker — kontroller du gör i Excel innan SI-filen byggs är billigare än att backa en redan importerad batch. Importen är reversibel inom samma session men inte enkelt efter, så ta för vana att alltid testköra mot ett testbolag först om du är osäker.

Flöde 3 — Excel → Visma Developer Portal API

Lämpligt för byråer med 500+ fakturor per månad, multiklientvolym, eller ett driftsteam som vill automatisera hela kedjan. Visma erbjuder API-åtkomst via Visma Developer Portal med OAuth2-autentisering — applikationen registreras, slutkunden auktoriserar åtkomsten till sitt bolag, och programmet kan därefter göra POST-anrop mot endpoint för leverantörsfakturor (/v2/supplierinvoices eller motsvarande beroende på den specifika Visma-produkten).

Tekniskt är skillnaden från SI-fil-flödet att API:t skapar både bokföringsverifikatet och en motsvarande post i leverantörsreskontran med fakturanummer, förfallodatum och OCR — vilket är just det glapp som SI-fil-flödet lämnar efter sig. Mot detta står setup-kostnaden: utvecklarkonto, OAuth2-implementation, klienthantering, token-rotation och felhantering är ett mindre integrationsprojekt snarare än en konfigurationsuppgift. För byråer som hanterar 25+ klienter med löpande månadsvolymer betalar arbetsinsatsen sig snabbt; för en engångsbacklog är SI-fil-flödet nästan alltid rätt val.

Det moment alla tre flöden bygger på

Det som de tre flödena delar är att Excel-arbetslistan måste finnas — och steget från PDF-batchen till strukturerad Excel är där den tidigare manuella tiden låg. Att fältmappa 140 PDF-fakturor för hand är där byråns timmar går förlorade, inte i själva Visma-registreringen. Det är detta moment vi har byggt AI-driven extraktion av leverantörsfakturor till strukturerad data för. Användaren laddar upp PDF-batchen (upp till 6 000 filer per omgång, enskilda PDF:er upp till 5 000 sidor), beskriver fältschemat i en prompt — exakt det schema avsnittet ovan listar — och får tillbaka en Excel-fil där varje rad är en faktura och varje kolumn ett namngivet fält. Excelarket går sedan in i vilket som helst av de tre flödena ovan utan vidare anpassning.

När batch-extraktion är rätt val — och när det inte är det

Batch-extraktion till Excel och SI-fil är ett av fyra legitima sätt att få leverantörsfakturor in i Visma, och frågan är inte vilket som är bäst i abstrakt mening utan vilket som passar volymen, fakturaflödets karaktär och byråns klientportfölj. En byrå kan rimligen ha alla fyra i drift parallellt för olika klienter. Matrisen nedan placerar varje alternativ mot situationen där det gör sig självt motiverat — och mot den där ett annat alternativ är ett bättre val.

Alternativ	Passar när	Passar inte när
Nativ registrering i Visma	Löpande volym under cirka 20 fakturor per månad, eller varje faktura kräver attestbeslut som ändå förutsätter manuell handpåläggning	Backlog från ny klient, klientbyte eller månadsvolym över 50 fakturor; byrå med multiklientansvar
Visma fakturatolkning (Winvoice, Spendency, Document Center)	Löpande digitalt flöde med e-faktura eller PDF via mejl, flerstegsattest önskvärd, abonnemang motiverat av månadsvolymen	Engångs- eller säsongsbacklog, klienter där abonnemangskostnaden inte kan vägas mot volymen, byrå som behöver enhetlig metod över många små klienter
Vertikalsspecifik integratör (Byggdagboken för bygg, Seven Time för tid och projekt, SmartDok, Blikk)	Klienten ligger i integratörens målbransch och utnyttjar integratörens vertikala funktioner (projekt, tidsuppföljning, materialspecifikation)	Allmän byrå utan vertikal anknytning, SME utanför integratörens bransch, eller byrå med klienter spridda över många olika branscher
Batch-extraktion till Excel eller SI-fil	Backlogs och migrationer, klientbyten, multiklientbyråer som inte vill betala per-klient-abonnemang för flera integratörer, allmänna byråer utan vertikal koppling	Löpande högvolym digitalt flöde där fakturatolkning eller vertikal integratör redan finns på plats och fungerar — då är dubbelarbete inte värt det

Den vanligaste användningen av batch-extraktion i en svensk redovisningsbyrå är att hantera de tre situationer som löpande flöden inte täcker: nya klienter med backlog, klientbyten där öppna leverantörsfakturor behöver flyttas, och migrationer mellan Visma-versioner eller mellan Visma och andra plattformar. Fakturatolkning och vertikalsintegratörerna är komplement snarare än konkurrenter — samma klient kan ha både ett löpande tolkningsflöde och en backlog som hanteras via batch-extraktion.

BAS-kontering som faktiskt landar på en leverantörsfaktura i Visma

Konteringsdelen av extraktionsmallen är där batchen blir användbar för Visma-import. SI-filen kräver att varje #TRANS-rad har ett konkret 4-siffrigt BAS-konto — det går inte att importera "kategori" eller "kostnadstyp" och hoppas att Visma listar ut resten. Listan nedan är begränsad till de konton som faktiskt dyker upp på leverantörsfakturor, inte BAS i sin helhet. För kontoplanens fullständiga struktur ligger arbetet hos BAS-intressenternas Förening — BAS-kontoplanens förvaltare — cirka 95 procent av alla företag i Sverige använder någon form av BAS-kontoplan, vilket gör den till det helt dominerande kontoplaneringssystemet i svenskt näringsliv, och varje SI-fil mot Visma utgår från dess struktur.

Skuld- och momskonton

2440 Leverantörsskulder är kreditbasen i varje leverantörsfakturaverifikat. Beloppet är hela fakturasumman inklusive moms, och posten stängs vid betalning.
2641 Debiterad ingående moms är standardkontot för svensk inhemsk moms 25 procent. Beloppet på 2641 är det som rapporteras i momsruta 48 (ingående moms att dra av).
2642 Debiterad ingående moms 12 procent och 2643 Debiterad ingående moms 6 procent används för reducerade satser — typiskt livsmedel, persontransport, hotell, kultur och tryckta böcker.
2645 Beräknad ingående moms vid omvänd skattskyldighet används vid omvänd byggmoms och EU-inköp av varor och tjänster där köparen är momsskyldig. Edge cases-avsnittet kommer tillbaka till hur 2645 paras med ett utgående momskonto i samma verifikat.

Varuinköp och materialkonton

4010 Inköp varor 25 procent är standardkontot för varuinköp till verksamheten, oavsett om varorna går vidare till lager eller direktförbrukas.
4056 Inköp varor omvänd skattskyldighet används specifikt vid EU-varuinköp där omvänd skattskyldighet tillämpas.
4531 Importmoms varor från EU-relaterade konton dyker upp vid importer från icke-EU-länder med tullhantering.

Tjänste- och kostnadskonton

5410 Förbrukningsinventarier är kontorsmaterial, småinventarier under aktiveringsgränsen, och annat förbrukningsmaterial som inte aktiveras som anläggningstillgång.
5460 Förbrukningsmaterial används för material som direkt förbrukas i tjänsteproduktionen utan att aktiveras.
6110 Kontorsmaterial för specifik kontorsmaterialbokning i organisationer med fördjupad kostnadskontoplan.
6212 Telefoni mobil och 6230 Datakommunikation är de vanligaste IT- och kommunikationskostnadskontona. 6310 Företagsförsäkringar för försäkringspremier.
6420 Revisionsarvoden, 6530 Redovisningstjänster och 6540 IT-tjänster är typiska konsultkostnader. Skilj mellan revision (6420) och löpande redovisningstjänster (6530) — det är två olika tjänstetyper och blandas regelbundet ihop i extraktionen.
6071 Representation extern och 6072 Representation intern har särskild avdragsbegränsning för moms och bör flaggas redan i extraktionssteget.

Konteringshistorik som arbetsbesparing

Visma har en konteringshistorik per leverantör — när samma organisationsnummer dyker upp föreslår Visma senast använda konto baserat på tidigare verifikat mot just den leverantören. Funktionen fungerar i den nativa registreringen och i fakturatolkningen, men inte vid SI-import (där konteringen redan är inbakad i filen). Vägen att vinna samma effekt vid batch-extraktion är att lagra senast använda konto per organisationsnummer i en separat referenstabell och låta extraktionssteget föreslå kontot automatiskt för varje ny faktura — extraktionen blir därmed inte bara fältidentifiering utan också konteringsförberedelse.

För nya leverantörer som inte har konteringshistorik finns ingen automatisk förvalspolicy att luta sig mot. Här tjänar en kostnadskategoriregel i extraktionssteget bättre: "leverantörsnamn innehåller 'konsult' eller 'redovisning' → 6530; innehåller 'telefon' eller 'mobil' → 6212; innehåller 'försäkring' → 6310". Konkret regelbas slår abstrakt klassificering varje gång.

Edge cases som SERP-toppen sällan adresserar

För en typisk månadsbatch är runt 80 procent av leverantörsfakturorna okomplicerade — svenska leverantörer, en momssats, standardkostnadskontering. De återstående 20 procenten är där SI-import-flödet kan bryta sönder, antingen genom att importen själv stoppas eller — vanligare — genom att importen går igenom men skapar fel i momsdeklarationen, ROT- och RUT-underlaget eller leverantörsreskontran. Nedan är de vanligaste varianterna och vad var och en kräver av extraktionen och konteringen.

ROT- eller RUT-arbete. Visma SPCS Bokföring och Visma eEkonomi har stödfunktioner för ROT- och RUT-underlag till Skatteverket. För att Visma ska kunna förbereda underlaget måste extraktionen fånga arbetstyp (ROT eller RUT, och vilken arbetskategori), fastighetsbeteckning och slutkundens personnummer från fakturan. Saknas något av de tre fälten stoppas inte SI-importen — bokföringen går rätt — men underlaget för skattereduktionsbegäran blir ofullständigt och måste rekonstrueras innan begäran lämnas in. Fullständig fältlista för svenska ROT- och RUT-fakturor ligger i Skatteverkets fältkrav för ROT- och RUT-fakturor.

Omvänd skattskyldighet inom bygg. Fakturan från byggentreprenören saknar moms — säljaren är inte momsskyldig på leveransen. Köparen redovisar i stället både utgående moms (konto 3231) och ingående moms (konto 2645) i samma belopp på samma verifikat. Vid SI-import måste #TRANS-blocket för en sådan faktura innehålla fyra rader i stället för tre: debet kostnadskonto, debet 2645, kredit 3231, kredit 2440. Mellan 3231 och 2645 går nettoeffekten på momsdeklarationen ut till noll, men båda raderna måste finnas i bokföringen för att momsrapporten ska bli korrekt.

EU-faktura med VAT-nummer. Vid varuinköp eller tjänsteinköp från en EU-leverantör med giltigt VAT-nummer tillämpas omvänd skattskyldighet på samma sätt som vid byggomvänd. Beloppet redovisas i momsdeklarationsruta 20 (varuinköp från EU), ruta 21 (tjänsteinköp från EU) eller ruta 22 (övriga tjänsteinköp), beroende på köpets karaktär, och köparens beräknade ingående moms hamnar i ruta 50. VAT-numret bör valideras mot EU-kommissionens VIES-databas i extraktionssteget innan SI-fil byggs — en faktura med ogiltigt VAT-nummer kan inte hanteras som omvänd skattskyldighet och blir därmed momsbelagd.

F-skatt-status. Om en svensk leverantör saknar godkänd F-skatt måste köparen själv innehålla preliminärskatt på ersättningen (30 procent på arbetsdelen). Visma flaggar detta vid registrering om F-skatt-status är registrerad på leverantören, men i en batchimport som hoppar över registreringssteget syns flaggan inte automatiskt. Extraktionsmallen bör därför göra en F-skatt-kontroll mot Skatteverkets register och lägga statusen som en kolumn i Excel innan SI-fil byggs. Vad F-skatt-statusen som styr om köparen måste innehålla preliminärskatt konkret betyder för bokföringen ligger i den separata artikeln.

Multi-valuta. Visma stödjer multi-valuta i eEkonomi Pro och i flera SPCS-versioner. Fakturabelopp i EUR, USD, NOK eller annan valuta måste extraheras med originalvaluta och belopp, och valutakursen som ska tillämpas vid bokföringsdagen. Visma räknar om till SEK vid registrering eller importtillfälle och bokar valutakursvinst på 3960 respektive valutakursförlust på 3970 om kursen avviker från den ursprungligen bokade vid betalning. Extraktionen behöver alltså fånga både originalvalutan och originalbeloppet, och inte konvertera till SEK för tidigt.

OCR-checksumma. OCR-nummer är inte godtyckliga sifferföljder — de följer en checksifferalgoritm som banken validerar vid betalning. En felaktigt OCR-extraherad faktura (vanligt vid skannade fakturor med dålig bildkvalitet) skapar en betalning som banken inte kan automatkoppla till rätt leverantörsskuldspost, och varje sådan post måste utredas manuellt vid bankavstämningen. Extraktionssteget bör därför validera OCR med Mod 10 enligt SS 61 41 14 och flagga avvikelser för manuell granskning innan SI-fil byggs. Bakgrund och referenser till standarden finns i Mod 10-validering av OCR-numret enligt SS 61 41 14.

Periodisering. Förskottsfakturor, hyresfakturor, försäkringspremier och prenumerationer som sträcker sig över räkenskapsårsskiftet ska periodiseras. Visma har 1790 Förutbetalda kostnader och 2990 Upplupna kostnader som standardkonton för periodiseringsverifikat. För att kunna generera periodiseringsverifikat automatiskt eller halvautomatiskt behöver extraktionen fånga både kostnadens start- och slutdatum från fakturan — och kostnadsperioden är ett fält som ofta står som löpande text ("Hyra kvartal 3 2026", "Försäkring 2026-07-01 till 2027-06-30"), inte som strukturerade datum.

Kreditfaktura. En kreditfaktura har negativa belopp och hänvisar till en tidigare utfärdad faktura. Visma kräver att kreditfakturan kopplas till ursprunglig faktura via fakturanummer för att leverantörsreskontran ska balansera korrekt — den ursprungliga skulden minskas, kreditfakturan blir inte en egen utestående post. Extraktionsmallen behöver fånga ursprungligt fakturanummer i ett separat fält (vanligen "Avser faktura nr" eller liknande på själva kreditfakturan) och flagga raden som kreditfaktura så att SI-filen kan bygga ett #VER-block med negativa belopp i rätt riktning.

Skannad PDF utan textsignal. Pappersfakturor som digitaliserats — vanligen scanned-to-PDF utan OCR-bearbetning — innehåller ingen utvinningsbar textsignal. Mallbaserade tolkningsverktyg som bygger på textkoordinater faller helt här. Extraktionsverktyget måste antingen OCR:a PDF:en innan fältidentifiering eller stödja bildbaserad extraktion direkt. För en byrå som tar över en backlog från en ny klient är skannade PDF:er regel snarare än undantag — om verktyget inte hanterar dem är 30–50 procent av batchen ointaglig.

Migration mellan Visma-versioner, övergång till Fortnox, och arkivering enligt Bokföringslagen

Två migrations-scenarier dyker upp regelbundet i en svensk redovisningsbyrås vardag, och båda berör samma fältschema och SI-fil-struktur som artikeln byggt: uppgraderingen från SPCS Bokföring 2000 till Visma eEkonomi, och plattformsbytet från Visma till Fortnox. Båda kräver också att arkiveringen av PDF-originalen hanteras explicit — SI-fil-importen tar inte med dem.

Migration SPCS Bokföring 2000 → Visma eEkonomi. SPCS-användare som uppgraderar till molnversionen får ofta en hybrid övergångsperiod där bokföringen för innevarande räkenskapsår behöver flyttas och öppna leverantörsfakturor parallellt landa i den nya miljön. Den enklare halvan: exportera en SE-fil från SPCS Bokföring 2000 (Arkiv → Export → SIE 4) och läs in den i Visma eEkonomi via Inställningar → Import/Export → Bokföringsdata. Kontrollera att leverantörsregistret har mappats korrekt — organisationsnummer är den nyckel Visma använder för att para SPCS-leverantören med en eventuellt redan existerande post i eEkonomi-registret. Den svårare halvan är de öppna leverantörsfakturorna. SE-filen tar med bokföringssaldot på 2440 Leverantörsskulder men inte de individuella obetalda posterna med fakturanummer, förfallodatum och OCR — exakt samma reskontra-glapp som SI-fil-importen lämnar efter sig. Två alternativ: manuell registrering av varje öppen leverantörsfaktura i eEkonomi efter SE-importen, eller en SI-fil byggd från ett Excel-extrakt av de öppna posterna (samma extraktion som artikeln har beskrivit, riktad mot enbart obetalda fakturor). Vilket alternativ som är snabbast beror på antalet öppna poster — under 30 är manuell registrering ofta snabbare än att bygga SI-fil.

Visma → Fortnox plattformsbyte. Plattformsbyten initieras vanligen av klienten själv (prisförändring, missnöje med funktionalitet, byråbyte som följs av plattformsbyte). Konkret flöde: exportera en SE-fil från Visma för hela räkenskapsåret som ska migreras, plus en SI-fil med öppna leverantörsfakturor genererad ur Excel-extrakt av reskontran vid bytespunkten, och läs in båda i Fortnox via deras motsvarande importflöde. Detaljerna på Fortnox-sidan — fältmappning, kontoplan-validering, vad som faktiskt landar i Fortnox leverantörsregister — ligger i samma flöde för en Fortnox-byrå, och Fortnox-artikeln är skriven som komplement till denna så att en konsult vid plattformsbyte har båda sidornas perspektiv på samma migration.

Bokföringslagens digitala arkivering. Här ligger det praktiskt viktigaste — och oftast underskattade — efterarbetet vid både SI-fil-import och migration. Bokföringslagen (1999:1078) kräver att räkenskapsinformation, inklusive originalfakturan, bevaras i minst 7 år efter utgången av det kalenderår då räkenskapsåret avslutades, och att informationen ska vara åtkomlig i den form den togs emot (eller i en konverterad form som uppfyller Bokföringsnämndens pålitlighetskrav: oförändrad, åtkomlig, läsbar under hela arkivperioden). SI-fil-importen skapar verifikatet i Visma men kopplar inte automatiskt PDF-bilagan till verifikatet.

Två praktiska sätt att stänga gapet. Det första är att manuellt koppla varje PDF till motsvarande verifikat i Visma efter SI-importen — eEkonomi har ett bilageparkeringsläge där PDF:er kan laddas upp och kopplas via dra-och-släpp eller bulkuppladdning. Vid 100+ verifikat blir det ett tidsödande moment men metoden ger den enklaste arkivstrukturen ("PDF:en sitter där verifikatet sitter"). Det andra är att arkivera hela PDF-batchen separat i ett digitalt arkiv (företagets eget filsystem, ett dedikerat dokumentarkiv eller en molntjänst som uppfyller pålitlighetskraven) och bygga en avstämningslista som länkar verifikatnummer till PDF-filnamn. Avstämningslistan är själv räkenskapsinformation och måste arkiveras lika länge. Den andra metoden skalar bättre vid stora migrationer men kräver mer disciplin i hur PDF-filerna namnges och katalogiseras.

Båda metoderna uppfyller lagkravet — valet styrs av byråns interna arbetsflöde, klientens framtida behov att hitta originalfakturor och hur länge förhållandet med klienten förväntas bestå. För klienter som lämnar byrån inom en eller två år är det enklare att lämna ifrån sig ett katalogiserat PDF-arkiv än att be klienten exportera bilagor från Vismas bilageparkering.