# Fluit ERP: kunskapsartiklar, ordlista och nyheter

> Fullständig brödtext. Kurerad översikt med enbart länkar finns på
> https://fluit.se/llms.txt

Utgivare: Fluit System AB (org.nr 559421-4909), Skellefteå, Sverige.
Innehållet får citeras med källänk.

---

# Kunskapsartiklar

## Vad är ett affärssystem? Komplett guide

Källa: https://fluit.se/kunskap/affarssystem/vad-ar-ett-affarssystem
Ämne: Affärssystem
Uppdaterad: 2026-08-31

Ett affärssystem är ett samlat system där ett företags återkommande processer körs mot en gemensam databas: order, lager, inköp, produktion, fakturaunderlag och uppföljning. Det avgörande är inte funktionerna i sig utan att de delar data, så att en lagd order syns direkt i lagersaldot och i inköpsbehovet. Affärssystem och ERP betyder samma sak.

Ett **affärssystem** är ett samlat system där ett företags återkommande processer körs mot en gemensam databas: försäljning och order, lager, inköp, produktion, fakturaunderlag och uppföljning. Det avgörande är inte att varje enskild funktion är unik, utan att de delar samma data. När en order läggs vet lagret om det, inköpet ser behovet och ekonomin får sitt underlag, utan att någon flyttar en fil mellan två program.

På svenska används **affärssystem** och **ERP** synonymt. ERP står för Enterprise Resource Planning och är den internationella termen för samma sak.

## Vad ett affärssystem faktiskt löser

Nästan alla företag har redan funktionerna. Ordrarna finns någonstans, lagersaldot finns någonstans, inköpen finns någonstans. Problemet är oftast att de finns på fyra olika ställen.

Ta en helt vanlig situation. En kund beställer 40 enheter av en artikel. Utan ett gemensamt system händer det här: säljaren kollar ett kalkylblad som uppdaterades i förrgår, lovar leverans på torsdag, mejlar lagret. Lagret upptäcker att det står 12 på hyllan, inte 40. Någon ringer inköp, som lägger en beställning med tre veckors ledtid. Kunden får ett nytt besked. Under tiden har en annan säljare lovat bort de 12 som fanns.

I ett affärssystem sker samma sak i en enda kedja. Ordern reserverar saldot i samma stund den läggs, så att de 12 enheterna inte kan lovas bort två gånger. De 28 som saknas syns som ett behov i inköpet. När godset kommer in går reservationen över på det nya saldot automatiskt, och fakturaunderlaget byggs på det som faktiskt levererades.

Det är hela poängen. Ett affärssystem är inte en samling funktioner, utan en gemensam sanning om vad som är sålt, vad som finns och vad som är på väg in.

## Vilka moduler ingår?

Vilka delar som ingår varierar mellan system och leverantörer. De här återkommer i de flesta:

| Modul | Vad den gör |
|---|---|
| Försäljning & CRM | Kunder, kontaktpersoner, affärsmöjligheter, offerter och prislistor |
| Order | Orderregistrering, reservation av saldo, delleveranser och restorder |
| Lager | Saldo per artikel och lagerställe, hyllplatser, inventering, spårbarhet |
| Inköp | Beställningsförslag, inköpsorder, inleverans och leverantörsuppföljning |
| Produktion | Strukturer, operationer, materialuttag och arbetsorder |
| Ekonomi | Fakturaunderlag, betalningsvillkor, moms och underlag till bokföringen |
| Rapportering | Dashboards, uppföljning och export till BI-verktyg |

Alla behöver inte allt. Ett grossistbolag utan egen tillverkning har ingen nytta av produktionsmodulen, och ett tjänsteföretag utan lager behöver inte hyllplatser. Hur det prissätts varierar: vissa leverantörer tar betalt per användare, andra per modul, andra för ett paket där allt ingår. [Fluit](/priser) prissätts per modul med obegränsat antal användare. Kontrollera vilken modell en leverantör använder innan du jämför prislappar, annars jämför du inte samma sak.

## Affärssystem och ekonomisystem är inte samma sak

Det här är den vanligaste sammanblandningen, och den kostar pengar när den leder till fel beslut.

Ett **ekonomisystem** hanterar bokföring, moms, kund- och leverantörsfakturor, betalningar, lön och bokslut. Fortnox och Visma eEkonomi är två exempel som används av många mindre och medelstora bolag i Sverige.

Ett **affärssystem** hanterar det som händer före bokföringen. Vilket pris kunden ska ha, vad som ligger i offert och order, var varan står på lagret, vem som plockar den, vad som behöver köpas in och när.

Många växande bolag upptäcker gränsen på samma sätt: bokföringen fungerar utmärkt, men ingen vet vad som finns på hyllan. Det är inte ett tecken på att ekonomisystemet är dåligt. Det är ett tecken på att bolaget har vuxit ur att sköta verksamheten vid sidan av det.

Slutsatsen blir ofta att man behöver båda. Affärssystemet sköter verksamheten och skickar fakturaunderlag och lagerrörelser vidare, ekonomisystemet sköter redovisningen. Fluit är byggt för just den uppdelningen och [integrerar mot Fortnox](/lagersystem/fortnox), så att ekonomin kan ligga kvar där den ligger.

## Vilka affärssystem finns i Sverige?

Marknaden brukar delas i tre grupper. Ingen av dem är bättre än de andra i allmänhet, de är byggda för olika saker.

**Internationella storsystem.** SAP, Microsoft Dynamics 365 Business Central, Oracle NetSuite och Infor. Mycket bred funktionalitet och stark närvaro i koncerner. Införandet sker normalt som ett konsultprojekt, och funktionsdjupet kostar i form av komplexitet.

**Etablerade svenska system.** Monitor ERP, Pyramid, Jeeves, Garp och Visma.net. Ofta starka i tillverkning och grossist, med lång erfarenhet av svenska förhållanden som SIE-export, momsregler och Skatteverkets format. Flera av dem har sitt ursprung i installerade versioner och erbjuder numera molndrift i någon form.

**Molnbaserade nyare system.** Här ligger Fluit, tillsammans med andra som byggts för webben från början. Kortare väg igång, prenumeration i stället för licens, och funktionsbredd som ännu inte matchar de största.

Vilket som passar avgörs sällan av leverantörens storlek. Det avgörs av om systemet klarar era faktiska processer, hur mycket införandet kostar i pengar och tid, och vad det innebär att växa i det. Vi har samlat en [jämförelse mellan Fluit och de system svenska bolag oftast väljer mellan](/jamfor), med reservation för att den bygger på offentlig information.

## Molnbaserat eller installerat?

Ett **molnbaserat** (eller webbaserat) affärssystem körs hos leverantören och nås via webbläsaren. Uppdateringar sker löpande, det finns ingen server att underhålla, och kostnaden är en prenumeration. Det går att jobba hemifrån eller från lagret utan VPN.

Ett **installerat** system körs på egen server eller i egen hyrd miljö. Det ger mer kontroll över drift, uppgraderingstakt och anpassningar, till priset av att någon måste sköta det.

För de flesta små och medelstora bolag är molnet numera förvalet, framför allt för att ingen behöver ha en åsikt om servrar. Har ni särskilda krav på datalagring eller djupa anpassningar är det värt att ta upp tidigt med leverantören, eftersom det påverkar både val och pris.

## När är det dags?

Det finns sällan ett enskilt tillfälle då behovet uppstår. Däremot finns det återkommande tecken:

- Samma uppgift matas in i två system, och ingen minns vilket som har rätt.
- Lagersaldot i systemet stämmer inte med hyllan, så personalen går och tittar i stället.
- Säljaren kan inte svara på om en vara finns utan att fråga någon annan.
- Inköpen bygger på magkänsla, vilket ger både bristsituationer och hyllvärmare.
- Uppföljningen bygger på ett kalkylblad som en enda person kan underhålla.
- Nyanställda tar orimligt lång tid att få produktiva, eftersom kunskapen sitter i huvuden.

Känner ni igen tre eller fler av de här är det troligen inte fler rutiner som behövs, utan gemensam data.

## Vad kostar ett affärssystem?

Priset består normalt av tre delar, och den som bara jämför den första blir överraskad.

**Licens eller prenumeration.** Antingen per användare och månad, per modul, eller en kombination. Modulbaserad prissättning är oftast mer rättvis för mindre bolag, eftersom man slipper betala för funktioner man inte rör.

**Införande.** Uppsättning, migrering av artiklar och kunder, konfiguration och utbildning. Här skiljer det sig mest mellan systemen. Vissa kräver ett konsultprojekt innan något går att använda, andra går att komma igång med på egen hand.

**Löpande drift och support.** I molnbaserade system ingår drift normalt i prenumerationen. I installerade tillkommer server, backup och uppgraderingar.

Var särskilt uppmärksam på hur användare räknas. Ett system som ser billigt ut per användare blir dyrt när lagerpersonalen ska ha åtkomst. Fluits [prissättning](/priser) bygger på moduler med obegränsat antal användare, just för att undvika att man börjar snåla med vem som får logga in.

## Så väljer du

Börja i era egna processer, inte i funktionslistor. Skriv ner hur en order faktiskt går genom bolaget idag, från förfrågan till betald faktura, inklusive de manuella stegen. Den beskrivningen är kravspecifikationen.

Testa sedan varje kandidat mot de tre eller fyra ställen där det brukar gå fel hos er. Är det restorder? Kundspecifika priser? Batchspårning? Delleveranser? Be om att få se just det i en demo, med er egen typ av data, i stället för en generell rundvandring.

Fråga också vad som händer efter införandet: vem svarar när något inte fungerar, hur ofta kommer uppdateringar, och vad kostar det att lägga till en modul om två år. Ett affärssystem byts sällan oftare än vart tionde år, så frågan är inte bara om det passar nu.

De frågorna finns samlade, tillsammans med en genomgång av vad marknaden erbjuder, på sidan om [ERP-system och hur du väljer ett](/erp-system).

### Vanliga frågor

**Vad är ett affärssystem?**

Ett affärssystem är ett samlat system där ett företags återkommande processer körs mot en gemensam databas: försäljning, order, lager, inköp, produktion, fakturaunderlag och uppföljning. Skillnaden mot flera separata program är att alla delar läser och skriver samma data, så att en lagd order syns direkt i lagret, i inköpsbehovet och i fakturaunderlaget.

**Är SAP och ERP samma sak?**

Nej. ERP (Enterprise Resource Planning) är namnet på systemkategorin, alltså samma sak som affärssystem. SAP är ett företag som säljer ett av systemen i den kategorin. Att säga att man kör SAP är ungefär som att säga att man kör Volvo: det säger vilken tillverkare, inte vilken sorts fordon.

**Är CRM ett affärssystem?**

Nej, men gränsen är flytande. Ett CRM (Customer Relationship Management) hanterar relationen till kunden: kontakter, affärsmöjligheter, aktiviteter och uppföljning av säljarbetet. Ett affärssystem hanterar hela verksamheten och har ofta CRM-funktioner inbyggda. Ett renodlat CRM saknar däremot lager, inköp och fakturering.

**Vad finns det för affärssystem?**

På den svenska marknaden finns dels internationella system som SAP, Microsoft Dynamics 365 Business Central, Oracle NetSuite och Infor, dels svenskutvecklade som Monitor ERP, Pyramid, Jeeves, Garp och Visma.net, dels nyare molnbaserade alternativ, Fluit inräknat. Vilket som passar beror mindre på storleken på leverantören och mer på vilka processer ni faktiskt kör.

**Vad är skillnaden mellan affärssystem och ekonomisystem?**

Ett ekonomisystem hanterar bokföring, moms, kund- och leverantörsfakturor, betalningar och bokslut. Ett affärssystem hanterar verksamheten före det: offert, order, lagersaldo, plock, inköp och produktion. Många bolag kör de två sida vid sida och låter affärssystemet skicka fakturaunderlag och lagerrörelser till ekonomisystemet.

**Behöver ett litet företag ett affärssystem?**

Inte nödvändigtvis. Så länge överblicken ryms i huvudet och i ett par kalkylblad fungerar det. Behovet uppstår när flera personer ska veta samma sak samtidigt, när lagersaldot måste stämma utan att någon räknar manuellt, eller när samma uppgift matas in i två system. Storleken på bolaget spelar mindre roll än hur många händer som rör samma data.

---

## CRM eller affärssystem: vad är skillnaden?

Källa: https://fluit.se/kunskap/affarssystem/crm-eller-affarssystem
Ämne: Affärssystem
Uppdaterad: 2026-08-07

Ett CRM hanterar relationen fram till avslut: kontakter, aktiviteter, affärsmöjligheter och pipeline. Ett affärssystem hanterar det som händer efter avslutet: order, lager, leverans, fakturering och uppföljning. Gränsen går vid den punkt där en affärsmöjlighet blir en order, och det är också där dubbelarbetet uppstår när systemen inte hänger ihop.

**Skillnaden går vid avslutet.** CRM handlar om tiden innan kunden bestämt sig, affärssystemet om allt som händer efter. Det låter som en tydlig gräns, och är det ända tills man märker att båda systemen behöver samma kunduppgifter.

## Vad respektive system gör

| | CRM | Affärssystem |
| --- | --- | --- |
| Tidsperspektiv | Före avslut | Efter avslut |
| Kärnobjekt | Affärsmöjlighet, aktivitet | Order, artikel, faktura |
| Frågan det svarar på | Kommer vi att sälja? | Vad har vi sålt och levererat? |
| Nyckeltal | Pipeline, vinstandel | Marginal, leveransprecision |
| Användare | Säljare | Order, lager, ekonomi |

Det som inte syns i tabellen är att kunden lever i båda. Det är där all friktion sitter.

## Var det skaver

**Kunden läggs upp två gånger.** En prospekt i CRM som blir kund måste bli kund även i affärssystemet, med organisationsnummer, faktureringsadress och betalningsvillkor. Sker det manuellt uppstår stavfel och dubbletter.

**Offerten och ordern lever isär.** Offerten skrivs i CRM, kunden tackar ja, och någon skriver om samma rader i affärssystemet. Priset som förhandlades finns i det ena systemet och priset som faktureras i det andra.

**Säljaren ser inte leveransen.** Kunden ringer och frågar var ordern är. Säljaren har CRM uppe och ser en vunnen affär, inte att leveransen är försenad i två veckor.

**Historiken splittras.** Vad kunden köpt finns i affärssystemet, vad som sagts i CRM. Ingen av dem ger hela bilden inför nästa förhandling.

## När ett inbyggt CRM räcker

Argumentet för ett separat CRM är starkast när säljprocessen är komplex: långa affärer, många intressenter, behov av avancerad prognos och kampanjuppföljning.

För ett bolag med tio säljare, affärer som avgörs på veckor och ett sortiment som redan ligger i affärssystemet är bilden ofta den motsatta. Då är vinsten av att slippa integrationen större än vinsten av specialiserade CRM-funktioner, särskilt eftersom kunddatan då bara finns på ett ställe.

Frågan är alltså inte vilket system som är bäst utan var din komplexitet sitter: i säljprocessen eller i leveransen.

## Om du har båda

Bestäm två saker innan integrationen byggs:

1. **Vilket system som äger kunden.** Ett av dem måste vara källan. Utan det beslutet driver uppgifterna isär, och sedan går det inte att avgöra vilken adress som är rätt.
2. **Var offerten skrivs.** Skrivs den i CRM måste den kunna bli en order utan omskrivning. Skrivs den i affärssystemet behöver säljaren komma åt den därifrån.

## I Fluit

[Fluit](/funktioner/crm) har CRM inbyggt: kunder och prospekt, kontakter, aktiviteter, affärer i pipeline med stadier, förlustorsaker och konkurrenter. En prospekt konverteras till kund utan att uppgifterna skrivs om, och kundens tidslinje visar både aktiviteterna och det som hänt på order-, leverans- och fakturasidan.

Vinsten är att gränsen mellan före och efter avslut aldrig blir en systemgräns. Offerten blir en order, ordern blir en leverans, och säljaren ser hela kedjan utan att byta flik.

### Vanliga frågor

**Vad är skillnaden mellan CRM och affärssystem?**

CRM följer kundrelationen och säljprocessen fram till avslut, med kontakter, aktiviteter och affärsmöjligheter i en pipeline. Affärssystemet tar vid vid avslutet och hanterar order, lager, leverans, fakturering och historik. De överlappar i kunddatan, vilket är där problemen brukar uppstå.

**Behöver jag både CRM och affärssystem?**

Inte alltid. Har du en säljprocess med långa affärer, flera säljare och behov av prognos på pipeline behövs CRM-funktionalitet. Är säljet transaktionsdrivet räcker ofta affärssystemets kund- och aktivitetshantering, särskilt om den finns inbyggd.

**Vad blir dubbelarbete när systemen inte hänger ihop?**

Kunduppgifter läggs upp två gånger, offerten skrivs i ett system och ordern i ett annat, och säljaren måste byta system för att se om kunden fått sin leverans. Dessutom uppstår frågan vilket system som har rätt uppgifter när de skiljer sig åt.

**Vilket system äger kunduppgifterna?**

Ett av dem måste göra det, annars driver de isär. Vanligast är att affärssystemet äger kunden eftersom det är där fakturering och leveransadresser lever, och att CRM får uppgifterna därifrån.

---

## Pipeline, affärer och aktiviteter i CRM

Källa: https://fluit.se/kunskap/affarssystem/pipeline-och-affarer
Ämne: Affärssystem
Uppdaterad: 2026-08-07

En pipeline är säljprocessen uppdelad i stadier, där varje affär ligger i det stadium den nått. Värdet av det som ligger i pipeline vägs mot sannolikheten per stadium och ger en prognos. För att prognosen ska betyda något måste övergången mellan stadier ha ett tydligt kriterium som bygger på kundens beteende, inte på säljarens känsla.

**En pipeline är säljprocessen ritad som en följd av stadier.** Varje pågående affär ligger i det stadium den nått, och summan av det som ligger där ger en bild av vad som är på väg in.

Det gör den till ett av få verktyg som säger något om framtiden i stället för om det som redan hänt. Under förutsättning att stadierna betyder något.

## Stadierna måste ha kriterier

Den vanligaste anledningen till att en pipeline inte går att lita på är att övergångarna är godtyckliga. Ett stadium som heter "intresserad" betyder olika saker för olika säljare, och då är summan meningslös.

Kriteriet ska bygga på vad kunden gjort, inte på hur säljaren känner:

| Stadium | Kriterium som kunden uppfyllt |
| --- | --- |
| Kvalificerad | Behov bekräftat, budget och beslutsordning kända |
| Lösningsförslag | Kunden har sett ett förslag anpassat till sitt behov |
| Offert | Skriftlig offert lämnad med pris och villkor |
| Förhandling | Kunden diskuterar villkor, inte om |
| Vunnen | Beställning eller signerat avtal |

Med den sortens kriterier går affärer bara framåt när något faktiskt hänt, och prognosen blir användbar.

## Vägt värde och dess gränser

Sannolikheten per stadium gör att pipeline kan summeras till en prognos: värdet gånger sannolikheten. Det är ett grovt mått, men bättre än den ovägda summan, som alltid ser ut som en rekordmånad.

Två saker gör måttet sämre än det ser ut. Sannolikheterna är genomsnitt, och en enskild affär är antingen vunnen eller förlorad. Och en pipeline full av gamla affärer som ingen vågar stänga ser stark ut utan att vara det.

Det andra problemet har en enkel motmedicin: följ hur länge affärerna legat i sitt stadium. En affär som legat i "offert" i fem månader är sannolikt förlorad, oavsett vad någon hoppas.

## Aktiviteter är det som flyttar

En affär rör sig inte av sig själv. Det som flyttar den är aktiviteter: samtal, möten, uppföljningar, demonstrationer.

Den enskilt bästa vanan i ett CRM är att varje pågående affär alltid har en nästa aktivitet inbokad. Affärer utan nästa steg är i praktiken vilande, även om de ligger mitt i pipeline, och listan över dem är oftast den mest användbara rapporten i hela systemet.

## Förlustorsaker är gratis information

Att registrera varför en affär förlorades känns som administration i stunden. Sammanräknat över ett år är det den billigaste marknadsundersökning som finns.

Skillnaden mellan att förlora på pris, på leveranstid, på funktion eller på att kunden sköt upp beslutet är avgörande, eftersom åtgärderna är helt olika. Utan orsakskoder blir svaret på frågan varför ni förlorar alltid "priset", för det är vad kunder säger.

## I Fluit

[Fluit](/funktioner/crm) har pipelines med stadier, affärer som flyttas mellan dem med historik, aktiviteter kopplade till kund och affär, förlustorsaker och konkurrenter. Affärerna går att se både per pipeline och samlat i en översikt.

Det som skiljer från ett fristående CRM är kopplingen framåt: den vunna affären blir en [order](/kunskap/order/order-to-cash-steg-for-steg) i samma system, och kundens tidslinje fortsätter med leverans och fakturering i stället för att sluta vid avslutet.

### Vanliga frågor

**Vad är en pipeline i CRM?**

Säljprocessen uppdelad i stadier, från första kontakt till avslut, där varje pågående affär placeras i det stadium den nått. Den visar både vad som är på gång och var affärerna fastnar.

**Hur många stadier bör en pipeline ha?**

Så få som möjligt och så många som behövs, ofta fyra till sex. Fler stadier ger sken av precision men gör att säljarna flyttar affärer godtyckligt, och då blir prognosen sämre och inte bättre.

**Vad är vägt pipelinevärde?**

Summan av affärernas värde multiplicerat med sannolikheten i deras stadium. En affär på 500 000 kronor i ett stadium med 40 procents sannolikhet bidrar med 200 000. Det är ett grovt mått men mer användbart än den ovägda summan.

**Varför ska förlorade affärer få en orsak?**

För att förlustorsakerna sammanräknade är den billigaste marknadsundersökning som finns. Förloras affärer systematiskt på pris är det ett prisproblem, förloras de på leveranstid är det ett produktionsproblem, och de kräver helt olika åtgärder.

---

## Ärendehantering med kö och SLA

Källa: https://fluit.se/kunskap/affarssystem/arendehantering-med-ko-och-sla
Ämne: Affärssystem
Uppdaterad: 2026-08-07

Ärendehantering samlar inkommande frågor och problem som spårbara ärenden med ägare, status och prioritet. Ärenden fördelas till köer efter typ eller kompetens, och en SLA-policy anger vilka svars- och åtgärdstider som gäller. Det avgörande är att statusarna skiljer på om det är ni eller kunden som är nästa part att agera, eftersom SLA-tiden annars mäts fel.

**En delad inkorg fungerar tills den slutar göra det.** Brytpunkten kommer när ingen längre vet vilka mejl som är besvarade, två personer råkar svara samma kund olika, och den som var sjuk i en vecka har trettio olästa ärenden som ingen tog över.

Ärendehantering löser det genom att göra varje fråga till ett objekt med ägare, status och historik.

## Kön ger ansvaret en adress

Det första ett ärende behöver är en kö. En kö är en definierad grupp som äger sina ärenden, till exempel support, teknik, order eller ekonomi.

Poängen är inte att sortera för sorterandets skull. Det är att ansvar som ligger på alla inte ligger på någon. Ett ärende i en kö plockas upp av någon i den kön, och blir det liggande syns det i just den kön och inte i ett gemensamt hav.

Triagen, alltså det första beslutet om vart ärendet hör, är därför det viktigaste momentet i hela flödet. Går den fel förbrukas hela den utlovade svarstiden på att skicka ärendet rätt.

## Statusar som säger vem som väntar

Den vanligaste designmissen är statusar som bara beskriver hur långt arbetet kommit. Det som faktiskt behövs är att kunna se **vem som är nästa part att agera**.

| Status | Vem som är nästa part |
| --- | --- |
| Ny | Vi, ingen har tagit i den |
| Pågående | Vi, någon arbetar |
| Väntar på kund | Kunden |
| Väntar internt | Vi, men på någon annan |
| Löst | Ingen, invänta bekräftelse |
| Stängd | Ingen |

Skillnaden mellan **väntar på kund** och **väntar internt** avgör två saker samtidigt: om SLA-klockan ska ticka, och om ärendet ska ligga kvar i handläggarens lista. Utan den uppdelningen blir uppföljningen orättvis, och den som ställer många frågor till kunden ser sämst ut i statistiken.

## SLA mäter två saker

Ett serviceavtal utlovar normalt två tider:

- **Första svarstid**: hur snabbt kunden får ett bemannat svar. Ett automatiskt kvittensmejl räknas inte.
- **Åtgärdstid**: hur snabbt problemet är löst.

Tiderna varierar med prioritet, och prioriteten bör sättas av två faktorer i kombination: hur allvarlig påverkan är och hur många som berörs. Ett stopp i produktionen hos en kund är inte samma sak som en fråga om en inställning, även om båda kom in samtidigt.

Kopplingen till [avtal](/kunskap/ekonomi/avtalshantering) är det som gör SLA meningsfull. En kund med premiumavtal ska få sin avtalade svarstid utan att någon minns vilka kunder som har vilket avtal.

## Eskalering behöver en mottagare

När tiden håller på att ta slut ska något hända. En eskalering som bara innebär en röd markering i en lista är ingen eskalering, den är en påminnelse.

Fungerande eskalering flyttar ärendet till någon med annan kompetens eller mandat, eller höjer prioriteten så att det går före annat. Båda kräver att det finns någon som tar emot, och att den personen vet att det är deras jobb.

## Vad man bör mäta

Fyra tal räcker för att se om ärendehanteringen mår bra:

1. **Andel inom SLA**, uppdelat på svarstid och åtgärdstid.
2. **Antal öppna ärenden per kö**, som visar var det växer.
3. **Andel som löses vid första kontakten**, som säger något om kompetensen i första ledet.
4. **Återöppnade ärenden**, som avslöjar ärenden som stängdes för tidigt.

Det fjärde är underskattat. En kö som stänger snabbt och återöppnar mycket har inte hög produktivitet, den har en mätning som belönar fel sak.

## I Fluit

[Fluit](/funktioner/arendehantering) har ärenden med kö, ägare, bevakare, taggar och kommentarer, samt ett statusflöde som skiljer på att arbeta, vänta på kund och vänta internt. SLA-policyer sätter tiderna, och triagen fördelar inkommande ärenden till rätt kö.

Ärenden kan skapas ur [inkorgen](/funktioner/inkorg) från inkommande meddelanden, och som service- eller [RMA-ärenden](/kunskap/order/rma-och-returhantering) kopplade till order och artiklar. Det sista är skillnaden mot ett fristående supportverktyg: den som svarar ser vad kunden köpt och när det levererades, utan att fråga.

Ärendets detaljsida, intern eskalering till en kollega utan att lämna ifrån sig ärendet och import av ärenden från ett annat system är genomgångna i [nyhetsbrevet för augusti 2026](/nyheter/nytt-i-fluit-augusti-2026).

### Vanliga frågor

**Vad är ett ärendehanteringssystem?**

Ett system som tar emot frågor och problem, gör dem till spårbara ärenden med ägare och status, och följer upp att de blir lösta inom utlovad tid. Skillnaden mot en delad inkorg är att ansvar, historik och tidsuppföljning finns per ärende.

**Vad är SLA i ärendehantering?**

Ett avtal om servicenivå, i praktiken utlovade tider: hur snabbt ett ärende ska få första svar och hur snabbt det ska vara löst. Tiderna varierar normalt med prioritet, och mäts inte under den tid ärendet väntar på kunden.

**Varför behövs köer?**

För att ansvar som ligger på alla inte ligger på någon. En kö ger en definierad grupp som äger ärendena, vilket gör att de plockas upp i stället för att ligga och se andra i mängden.

**Vad är eskalering?**

Att ett ärende flyttas uppåt i kompetens eller prioritet när det inte löses inom utlovad tid, eller när det visar sig kräva någon annan. En eskalering som bara innebär att fler blir arga är ingen eskalering, den behöver ha en mottagare.

---

## Kemikalieskatt på elektronik och vitvaror

Källa: https://fluit.se/kunskap/ekonomi/kemikalieskatt-pa-elektronik
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

Kemikalieskatt är en punktskatt på elektronik och vitvaror som räknas per kilo nettovikt, inte på varans pris. För 2026 är satsen 12,42 kronor per kilo för vitvaror och 180,71 kronor per kilo för övrig elektronik, med ett tak på 552,27 kronor per vara. Skattskyldig är den som tillverkar, för in eller tar emot varorna yrkesmässigt i Sverige.

**Kemikalieskatten, i dagligt tal elektronikskatten, är en punktskatt på elektronik och vitvaror som räknas på varans nettovikt.** Den infördes 2017 med målet att minska mängden flamskyddsmedel med brom, klor och fosfor i elektronik. Regelverket finns i lagen om skatt på kemikalier i viss elektronik.

Det som gör skatten besvärlig i vardagen är inte satsen. Det är att beloppet inte har något med priset att göra. En billig produkt som väger mycket kan bära mer skatt än en dyr som väger lite.

## Så räknas beloppet fram

Tre uppgifter avgör: varans **kategori**, dess **nettovikt** och årets **skattesats**.

| Kategori | Sats 2026 | Tak per vara |
| --- | --- | --- |
| Vitvaror | 12,42 kr/kg | 552,27 kr |
| Övrig elektronik | 180,71 kr/kg | 552,27 kr |

Räkneexemplet blir kort. En router som väger 0,8 kilo hamnar i övrig elektronik: 0,8 × 180,71 = 144,57 kronor. En tvättmaskin på 70 kilo är vitvara: 70 × 12,42 = 869,40 kronor, men taket kapar beloppet till 552,27 kronor.

Satserna räknas om varje år. Den som lägger in dem på ett ställe i systemet, med giltighetsperiod, slipper leta upp alla artiklar i januari.

## Kategorin sitter i varukoden

Vilken kategori en vara hamnar i, och om den överhuvudtaget är skattepliktig, avgörs av **KN-numret**: varukoden ur tulltaxan, samma kod som används vid import. Det är koden som styr, inte produktnamnet eller vad varan används till.

Det är den vanligaste källan till fel. En produkt som i katalogen ligger bland datortillbehör kan ha en varukod som gör den skattepliktig, och en som känns självklart skattepliktig kan falla utanför. Har artikelregistret rätt varukod från början är resten mekanik.

## Nettovikt, inte bruttovikt

Skatten räknas på varans nettovikt, alltså varan utan emballage. Det är ofta samma viktuppgift som redan finns på artikeln för fraktberäkningen, men inte alltid: fraktvikten kan vara satt inklusive kartong. Är vikten fel med tio procent blir skatten fel med tio procent, och på övrig elektronik är det riktiga pengar.

## Avdragen

Skatten kan sättas ned med 50 eller 95 procent för varor som saknar vissa brom-, klor- och fosforföreningar i angivna delar. Nedsättningen förutsätter att du kan visa vad varan innehåller, vilket i praktiken betyder underlag från leverantören.

Villkoren för avdrag har stramats åt sedan skatten infördes, och betydligt färre produkter kvalificerar i dag än tidigare. Kontrollera vad som gäller hos Skatteverket innan avdraget räknas in i kalkylen.

## Vem som är skattskyldig

Skattskyldig är den som yrkesmässigt tillverkar, för in eller tar emot skattepliktiga varor i Sverige. Det sker i någon av rollerna godkänd lagerhållare, registrerad mottagare eller registrerad EU-handlare, och vilken roll som passar avgör både när skatten ska redovisas och hur mycket kapital som binds.

Köper du in från en svensk grossist som redan är skattskyldig ligger skatten i inköpspriset och du redovisar ingenting själv. Importerar du samma vara direkt blir bilden en annan.

## Vad som gör det hanterbart i ett system

Räknat för hand är kemikalieskatt ett återkommande irritationsmoment: någon ska hålla reda på vilka artiklar som är skattepliktiga, vilken sats som gäller i år och när taket slår in.

I [Fluit](/funktioner/punktskatt) ligger det som data i stället. Ett skatteschema per land håller beräkningsbasen (per kilo nettovikt) och kategorierna, satserna har giltighetsperioder så att nästa års sats kan läggas in i förväg, och artikelns HS-kod avgör vilken kategori den matchar. Skatten läggs på kundordern automatiskt och hamnar som en egen rad på fakturan, så att kunden ser vad som är vara och vad som är skatt.

Vill du bara räkna på ett enskilt fall finns [kalkylatorn för kemikalieskatt](/verktyg/kemikalieskatt), som tar vikt, kategori och antal och visar beloppet med taket inräknat.

### Vanliga frågor

**Hur räknas kemikalieskatten ut?**

Nettovikten i kilo multipliceras med satsen för varans kategori. Vitvaror och övrig elektronik har olika satser, och beloppet begränsas av ett tak per vara. Priset på varan påverkar inte skatten, bara vikten och kategorin.

**Vad är skatten på elektronik 2026?**

12,42 kronor per kilo för vitvaror och 180,71 kronor per kilo för övrig elektronik. Skatten får inte överstiga 552,27 kronor per skattepliktig vara. Satserna räknas om varje år.

**Vem betalar kemikalieskatten?**

Den som yrkesmässigt tillverkar, för in eller tar emot skattepliktig elektronik eller vitvaror i Sverige. Det kan ske som godkänd lagerhållare, registrerad mottagare eller registrerad EU-handlare. Konsumenten betalar den indirekt via priset.

**Vilka varor omfattas?**

Vilka varor som är skattepliktiga avgörs av varans KN-nummer, alltså tulltaxans varukod. Det är koden och inte varans namn som styr, vilket gör att två produkter som liknar varandra kan hamna olika.

**Går det att få avdrag?**

Ja, skatten kan sättas ned med 50 eller 95 procent när varan saknar vissa brom-, klor- eller fosforföreningar. Kraven har skärpts över tid, så kontrollera vad som gäller hos Skatteverket innan avdraget räknas in.

---

## Punktskatt: vad det är och vilka varor som omfattas

Källa: https://fluit.se/kunskap/ekonomi/punktskatt
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

Punktskatt är en skatt som tas ut på vissa utvalda varor utöver momsen, till exempel alkohol, tobak, drivmedel, el och elektronik. Skatten räknas oftast på mängd i stället för på pris: per kilo, per liter eller per styck. Den som tillverkar, för in eller tar emot varorna yrkesmässigt är skattskyldig och redovisar skatten till Skatteverket.

**[Punktskatt](/ordlista/punktskatt) är en skatt på utvalda varor, utöver momsen.** Namnet kommer av att skatten träffar en punkt i sortimentet i stället för att ligga brett över all försäljning. Staten använder den både för att dra in pengar och för att styra: gör det dyrare att sälja något, så säljs det mindre.

## Skillnaden mot moms

Momsen är procentuell och nästan universell. Punktskatten är oftast en mängdskatt och gäller bara det som lagstiftaren pekat ut.

| | Moms | Punktskatt |
| --- | --- | --- |
| Vad den träffar | I princip all försäljning | Utvalda varor |
| Beräkningsgrund | Procent av priset | Oftast mängd: kilo, liter, styck |
| Följer priset | Ja | Nej |
| Syfte | Statsintäkt | Statsintäkt och styrning |

Att skatten inte följer priset är den praktiska poängen. En rabatt sänker momsen men lämnar punktskatten orörd, vilket gör att marginalen krymper snabbare än man tror på lågprisartiklar i en punktskattepliktig kategori.

## De svenska punktskatterna

De största i kronor räknat är energiskatt och koldioxidskatt på drivmedel, elskatt, alkoholskatt och tobaksskatt. Vid sidan av dem finns ett antal mindre, bland annat kemikalieskatt på viss elektronik och vitvaror, skatt på avfallsförbränning och skatt på plastbärkassar.

För ett handels- eller tillverkningsbolag är det oftast [kemikalieskatten](/kunskap/ekonomi/kemikalieskatt-pa-elektronik) som blir aktuell, eftersom den träffar vanliga sortiment: hemelektronik, datortillbehör och vitvaror.

## Varukoden avgör

Vilka varor som omfattas anges i lagtexten med **KN-nummer**, alltså varukoden ur tulltaxan. Det är samma kod som används i tulldeklarationen och i statistiken, och den styr både om skatt ska tas ut och vilken kategori varan hamnar i.

Konsekvensen är att skatteplikten sitter i artikelregistret, inte i huvudet på inköparen. En artikel utan varukod är en artikel som ingen kan avgöra skatteplikten för.

## Skattskyldighet och redovisning

Skattskyldig är den som yrkesmässigt tillverkar, för in eller tar emot skattepliktiga varor i Sverige. Registreringen görs hos Skatteverket, och rollen avgör hur flödet ser ut:

- **Godkänd lagerhållare** redovisar skatten först när varan lämnar lagret, vilket skjuter upp betalningen.
- **Registrerad mottagare** redovisar vid mottagandet.
- **Registrerad EU-handlare** används vid distansförsäljning in i Sverige.

Skillnaden mellan rollerna är i praktiken en kassaflödesfråga. Ett bolag med stort lager av punktskattepliktiga varor binder mycket kapital om skatten betalas redan vid inleveransen.

## Moms på punktskatt

Punktskatten ingår som huvudregel i beskattningsunderlaget för moms. Momsen räknas alltså på varupris plus punktskatt, inte bara på varupriset. Det låter som en detalj tills beloppen blir stora: på en punktskatt om 500 kronor tillkommer 125 kronor moms.

Reglerna skiljer sig mellan skatterna, så det är en inställning per skatt och inte en generell regel att koda in en gång för alla.

## Hur det hanteras i ett affärssystem

Punktskatt räknad för hand blir fel förr eller senare, av samma skäl varje gång: satserna ändras, taket glöms bort och någon missar att varan bytt kategori.

I [Fluit](/funktioner/punktskatt) sätts punktskatt upp som skattescheman per land. Schemat bär beräkningsbasen (per kilo nettovikt, per styck, procent av värde eller per kilo koldioxidekvivalent), kategorierna, satserna med giltighetsperiod, avdragsnivåerna och inställningen för om moms ska räknas på skatten. Artikelns HS-kod matchas mot schemat, beloppet läggs på ordern och redovisas som en egen rad på fakturan.

Systemet räknar alltså fram skatten. Deklarationen till Skatteverket lämnar du fortfarande själv.

### Vanliga frågor

**Vad är skillnaden mellan moms och punktskatt?**

Moms tas ut på nästan all försäljning och räknas i procent av priset. Punktskatt tas bara ut på utvalda varor och räknas oftast på mängd, till exempel per kilo eller per liter. Momsen läggs dessutom normalt ovanpå punktskatten, alltså på ett belopp som redan innehåller den.

**Vilka punktskatter finns i Sverige?**

De största är energiskatt och koldioxidskatt på drivmedel, elskatt, alkoholskatt och tobaksskatt. Därutöver finns bland annat kemikalieskatt på viss elektronik, skatt på avfallsförbränning, plastbärkassar och trängselskatt.

**Räknas moms på punktskatten?**

Ja, som huvudregel. Punktskatten är en del av varans beskattningsunderlag, vilket betyder att momsen räknas på summan av varupris och punktskatt. Undantagen finns, så kontrollera vad som gäller för den enskilda skatten.

**Vem ska registrera sig för punktskatt?**

Den som yrkesmässigt tillverkar, för in eller tar emot skattepliktiga varor. Registreringen sker hos Skatteverket, och rollen (godkänd lagerhållare, registrerad mottagare eller registrerad EU-handlare) styr när skatten ska redovisas.

---

## Omvänd skattskyldighet vid varuhandel

Källa: https://fluit.se/kunskap/ekonomi/omvand-skattskyldighet
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

Omvänd skattskyldighet innebär att köparen, inte säljaren, redovisar momsen på ett köp. Säljaren fakturerar utan moms och köparen tar upp både utgående och ingående moms i sin egen deklaration. Regeln gäller bland annat vid försäljning av varor till momsregistrerade företag i andra EU-länder, vid handel med skrot och vid vissa större elektronikaffärer inom Sverige.

**Omvänd skattskyldighet flyttar momsen från säljarens deklaration till köparens.** Säljaren fakturerar utan moms, och köparen redovisar både utgående och ingående moms på samma affär. Har köparen full avdragsrätt tar de två posterna ut varandra och ingen betalning uppstår, men båda ska ändå redovisas.

Syftet är att stoppa en särskild sorts momsbedrägeri: att en säljare fakturerar med moms, låter köparen dra av den och sedan försvinner utan att betala in sin del. Finns ingen moms på fakturan finns inget att försvinna med.

## De tre vanliga fallen

Regeln känns ofta igen från byggsektorn, men det är bara ett av flera fall.

**Varor till företag i andra EU-länder.** Säljer du varor till en momsregistrerad köpare i ett annat EU-land, och varorna transporteras dit, fakturerar du utan svensk moms. Köparen redovisar förvärvsmoms i sitt land. Det här är det vanligaste fallet för ett handels- eller tillverkningsbolag.

**Skrot och avfall.** Handel med avfall och skrot av vissa metaller omfattas vid försäljning mellan svenska företag.

**Viss elektronik inom Sverige.** Mobiltelefoner, integrerade kretsanordningar, spelkonsoler, bärbara datorer och surfplattor säljs med omvänd skattskyldighet till andra företag när fakturans beskattningsunderlag för dessa varor överstiger gränsvärdet i momslagen. Gränsen räknas per faktura, vilket gör att samma sortiment kan hamna olika beroende på hur ordern delas.

Vid sidan av dessa gäller regeln byggtjänster inom byggsektorn, som har egna avgränsningar och en helt egen praxis.

## Villkoren som måste hålla

Tre saker avgör om du får fakturera utan moms vid EU-försäljning:

1. **Köparen är momsregistrerad i ett annat EU-land.** Det bevisas med ett giltigt VAT-nummer.
2. **Varorna lämnar Sverige.** Transporten till det andra landet ska kunna styrkas med fraktsedel, följesedel eller motsvarande.
3. **Fakturan säger vad som gäller.** Både säljarens och köparens VAT-nummer ska finnas med, tillsammans med en uppgift om att omvänd skattskyldighet tillämpas.

Brister någon av de tre kan Skatteverket kräva svensk moms i efterhand, och den kostnaden blir din och inte kundens.

## VAT-numret är hela grunden

Ett VAT-nummer som såg giltigt ut när kunden lades upp för två år sedan säger ingenting om läget i dag. Bolag avregistreras, fusioneras och byter form. Kontrollen görs mot EU-kommissionens tjänst **VIES**, som svarar på om numret är giltigt vid förfrågningstillfället.

Två saker gör kontrollen praktiskt hanterbar: att den sker automatiskt när numret läggs in eller ändras, och att svaret sparas så att du kan visa vad du visste och när.

I [Fluit](/funktioner/moms-och-skatteregler) valideras kundens VAT-nummer mot VIES, och momsreglerna avgör själva vilken sats som ska gälla utifrån land och kundtyp. En kund i Tyskland med giltigt VAT-nummer får därmed rätt behandling på ordern utan att någon behöver komma ihåg regeln.

Ska du bara kontrollera formatet på ett nummer du fått per mejl finns [verktyget för VAT-nummer](/verktyg/vat-nummer), som kontrollerar landsprefix och struktur direkt i webbläsaren.

## Vad som lätt blir fel

- **Kunden är privatperson.** Då gäller inte omvänd skattskyldighet, utan reglerna för [distansförsäljning](/kunskap/ekonomi/moms-vid-eu-forsaljning).
- **Varan lämnar aldrig landet.** En kund med utländskt VAT-nummer som hämtar varan i Sverige och använder den här uppfyller inte transportvillkoret.
- **Fakturan saknar hänvisningen.** Formalia räknas: uppgiften om omvänd skattskyldighet är ett krav, inte en artighet.
- **Beloppsgränsen för elektronik räknas fel.** Det är beskattningsunderlaget för de aktuella varorna på fakturan som räknas, inte hela orderns värde.

### Vanliga frågor

**Vad betyder omvänd skattskyldighet?**

Att ansvaret för att redovisa momsen flyttas från säljaren till köparen. Säljaren fakturerar beloppet utan moms, och köparen redovisar utgående moms på köpet och drar samtidigt av samma belopp som ingående moms. För en köpare med full avdragsrätt blir nettoeffekten noll.

**När gäller omvänd skattskyldighet?**

Vid varuförsäljning till momsregistrerade företag i andra EU-länder, vid byggtjänster inom byggsektorn, vid handel med avfall och skrot av vissa metaller, och vid försäljning av bland annat mobiltelefoner, bärbara datorer, surfplattor och spelkonsoler inom Sverige när fakturabeloppet överstiger gränsen i lagen.

**Vad ska stå på fakturan?**

Att omvänd skattskyldighet gäller, samt köparens momsregistreringsnummer. Vid EU-försäljning ska både säljarens och köparens VAT-nummer finnas med. Utan giltigt VAT-nummer på köparen faller grunden för att fakturera utan moms.

**Hur kontrollerar jag köparens VAT-nummer?**

Genom EU-kommissionens tjänst VIES, som svarar på om numret är giltigt just då. Kontrollen bör göras och dokumenteras vid affärstillfället, eftersom ett nummer kan vara giltigt i dag och avregistrerat om ett halvår.

---

## Moms vid försäljning till andra EU-länder

Källa: https://fluit.se/kunskap/ekonomi/moms-vid-eu-forsaljning
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

Vid försäljning till momsregistrerade företag i andra EU-länder faktureras varor utan moms och köparen redovisar förvärvsmoms. Vid försäljning till privatpersoner gäller köparlandets momssats så snart den samlade gränsöverskridande försäljningen inom EU passerar 10 000 euro per år, i Sverige 99 680 kronor. Momsen redovisas då enklast i en OSS-deklaration till Skatteverket.

**Vilken moms som ska tas ut vid EU-försäljning avgörs av två frågor: vem köparen är och hur mycket du säljer.** Svaren ger fyra fall, och de skiljer sig så pass mycket att de är värda att hålla isär från början.

## De fyra fallen

| Köpare | Villkor | Moms |
| --- | --- | --- |
| Företag med giltigt VAT-nummer | Varan transporteras ut ur Sverige | Ingen moms, köparen redovisar förvärvsmoms |
| Företag utan giltigt VAT-nummer | | Svensk moms |
| Privatperson | Under tröskeln 99 680 kr per år | Svensk moms |
| Privatperson | Över tröskeln | Köparlandets momssats |

Det är alltså inte kundens adress som avgör, utan kombinationen av kundtyp, VAT-nummer och volym.

## Försäljning till företag

Säljer du varor till ett momsregistrerat företag i ett annat EU-land, och varorna transporteras dit, faktureras utan svensk moms. Köparen redovisar i stället förvärvsmoms i sitt eget land. Detta är [omvänd skattskyldighet](/kunskap/ekonomi/omvand-skattskyldighet), och det förutsätter tre saker: giltigt VAT-nummer, bevisad transport och rätt uppgift på fakturan.

Försäljningen ska dessutom rapporteras i en periodisk sammanställning, där du per kvartal anger hur mycket du sålt till varje VAT-nummer.

## Försäljning till privatpersoner

Här styr tröskeln. Så länge din **samlade** gränsöverskridande försäljning till privatpersoner i EU ligger under 10 000 euro per kalenderår, i Sverige 99 680 kronor, tar du ut svensk moms som vanligt.

Passerar du tröskeln byter allt sådan försäljning karaktär: från och med den transaktion som passerar gränsen ska köparlandets momssats gälla. Säljer du till Danmark blir det 25 procent, till Tyskland 19 och till Frankrike 20.

Två detaljer fäller folk. Tröskeln räknas **totalt över alla länder**, inte per land, och den räknas per kalenderår. Ett bra kvartal i november kan alltså ändra momsen på decemberförsäljningen.

## OSS i stället för registrering i varje land

Utan OSS hade den som passerar tröskeln behövt momsregistrera sig i varje land med kunder. **One Stop Shop** löser det: du redovisar all gränsöverskridande försäljning till privatpersoner i en kvartalsdeklaration till Skatteverket, som fördelar beloppen till respektive land.

Det gör administrationen hanterbar, men flyttar problemet till systemet. Du måste kunna ta ut rätt sats per land vid orderläggning, och du måste kunna redovisa försäljningen per land i efterhand. Räknat i ett kalkylblad blir det snabbt ohållbart.

## Vad det kräver av affärssystemet

Tre saker behöver finnas för att det ska fungera utan handpåläggning:

- **Momssatser per land**, så att en order till Tyskland får 19 procent utan att någon skriver in det.
- **Regler som skiljer på företag och privatperson**, eftersom samma land ger olika utfall beroende på kundtyp.
- **VAT-validering**, så att en företagskund faktiskt har det nummer som befriar från moms.

I [Fluit](/funktioner/moms-och-skatteregler) byggs det av tre delar som samverkar: momsklasser grupperar artiklarna, momsregler avgör när en viss sats gäller (per land och per B2B eller B2C, med sorteringsordning så att den mest specifika regeln vinner) och momssatserna bär procentsatsen med giltighetstid. Kundens VAT-nummer valideras mot VIES. En standardklass fångar upp det som inte matchar någon regel, så att en order aldrig blir stående utan moms.

Ordningen är värd att notera: momsen räknas på priset efter rabatter och på eventuell [punktskatt](/kunskap/ekonomi/punktskatt), inte på listpriset.

### Vanliga frågor

**När ska jag ta ut svensk moms vid EU-försäljning?**

Vid försäljning till privatpersoner i andra EU-länder så länge den samlade gränsöverskridande försäljningen ligger under tröskeln på 10 000 euro per kalenderår, i Sverige 99 680 kronor. Över tröskeln gäller köparlandets momssats i stället.

**Vad är OSS?**

One Stop Shop, EU:s gemensamma redovisningssystem för gränsöverskridande försäljning till privatpersoner. I stället för att momsregistrera sig i varje land redovisas all sådan försäljning i en kvartalsdeklaration till Skatteverket, som fördelar pengarna vidare.

**Räknas tröskeln per land eller totalt?**

Totalt. All gränsöverskridande försäljning till privatpersoner i EU räknas ihop, inte per land. Passerar summan tröskeln gäller köparlandets sats för all sådan försäljning, även till länder där du säljer för några hundra kronor.

**Behöver jag VAT-nummer på företagskunden?**

Ja. Utan giltigt VAT-nummer kan du inte fakturera utan moms. Numret kontrolleras mot VIES och bör kontrolleras vid affärstillfället, inte bara när kunden lades upp.

**Gäller samma regler för tjänster?**

Nej, tjänster har egna regler. Huvudregeln för tjänster till beskattningsbara personer är att de beskattas i köparens land, men det finns undantag för bland annat fastighetstjänster och evenemang.

---

## Moms på frakt och fraktavgifter

Källa: https://fluit.se/kunskap/ekonomi/moms-pa-frakt
Ämne: Ekonomi & skatt
Uppdaterad: 2026-09-29

Moms på frakt följer momssatsen på de varor som fraktas, eftersom frakten är en bikostnad som ingår i varans beskattningsunderlag. Säljer du böcker med 6 procent moms blir momsen på frakten också 6 procent. Innehåller ordern varor med olika momssatser fördelas frakten mellan dem efter deras andel av varuvärdet.

**Frakt har ingen egen momssats.** Den är en kameleont och tar färg av det som ligger i paketet. Formellt är frakten en bikostnad till varan och ingår i varans beskattningsunderlag, men resultatet är detsamma: momsen på frakten är momsen på det som fraktas.

Det gäller när du tar betalt för att skicka varor som du själv säljer. Ett transportföretag som säljer frakt som en egen tjänst tar 25 procent, men det är en annan affär.

## Grundregeln

Skickar du hörlurar med 25 procent moms blir frakten 25 procent. Skickar du böcker med 6 procent blir frakten 6 procent. Och skickar du kaffe blir frakten också 6 procent, åtminstone fram till nyår 2028.

Livsmedelsmomsen är nämligen tillfälligt sänkt från 12 till 6 procent mellan 1 april 2026 och 31 december 2027. Frakten på livsmedel följer med ned, och följer med upp igen när sänkningen löper ut. Restaurang- och cateringtjänster omfattas inte av sänkningen och har kvar 12 procent.

Samma regel gäller andra kostnader som hör till leveransen: expeditionsavgift, emballage och försäkring under transporten. De följer varan och har ingen egen sats.

## Blandade satser på samma order

Här blir det intressant. Hörlurar och kaffe i samma kartong: vilken sats får frakten? Svaret är båda. Frakten delas upp efter varugruppernas andel av varuvärdet, räknat exklusive moms, och varje del får sin grupps sats.

| | Varor | Andel | Frakt | Moms |
| --- | --- | --- | --- | --- |
| Hörlurar 25 % | 700 kr | 70 % | 70 kr | 17,50 kr |
| Kaffe 6 % | 300 kr | 30 % | 30 kr | 1,80 kr |
| **Summa** | **1 000 kr** | | **100 kr** | **19,30 kr** |

Frakten landar alltså på drygt 19 procent, en sats som inte finns i någon momstabell. Läggs hela frakten i stället på 25 procent blir momsen 25 kronor, 5,70 kronor för mycket på en enda order. Med tusen sådana order i månaden är det 68 400 kronor om året som redovisas fel.

Matmomssänkningen gjorde dessutom felet större. Med livsmedel på 12 procent var skillnaden i samma exempel 3,90 kronor per order.

[Prova med dina egna siffror](#rakna) i räknaren längre ner.

## Frakt vid EU-försäljning och export

Frakten följer varan även över gränsen. Säljer du till ett momsregistrerat företag i ett annat EU-land faktureras varorna utan svensk moms, och köparen redovisar förvärvsmoms i sitt land. Frakten åker med och faktureras också utan moms. Detsamma gäller vid export till länder utanför EU.

Säljer du till privatpersoner i andra EU-länder och har passerat tröskeln på 10 000 euro per år, gäller köparlandets momssats på varorna och därmed på frakten. Blandar ordern satser görs fördelningen med köparlandets satser. Hur tröskeln och OSS fungerar står i [moms vid försäljning till andra EU-länder](/kunskap/ekonomi/moms-vid-eu-forsaljning).

## Rabatten först, frakten sedan

Ordningen på ordern spelar roll. En rabatt sänker varuvärdet, och varuvärdet är fördelningsnyckeln för frakten. Dras rabatten först efter att frakten har fördelats blir andelarna fel.

## Frakt och moms i Fluit

I [Fluit](/funktioner/frakt-och-fraktberakning) räknas fraktpriset fram ur fraktprislistor per transportör, tjänst och zon och läggs på ordern som en egen rad. Momssatsen på frakten styrs av fraktartikelns momsklass tillsammans med [momsreglerna](/funktioner/moms-och-skatteregler). Därför får en order till ett företag i ett annat EU-land, en export eller en OSS-försäljning rätt behandling av frakten utan att någon räknar om för hand.

Vad frakten faktiskt kostar hos olika transportörer är en annan fråga än vilken moms den ska ha. Den besvaras av fraktprisjämförelsen, som beskrivs på samma funktionssida.

### Vanliga frågor

**Vilken moms är det på frakt?**

Samma som på varorna som fraktas. Frakten är en bikostnad och har ingen egen momssats. Säljs varor med 25 procent moms blir momsen på frakten 25 procent, och säljs böcker eller livsmedel med 6 procent blir den 6 procent.

**Hur räknas moms på frakt när ordern har flera momssatser?**

Frakten fördelas mellan momssatserna efter varornas andel av varuvärdet exklusive moms. Är 70 procent av ordervärdet varor med 25 procent moms och 30 procent livsmedel med 6 procent, får 70 procent av frakten 25 procent moms och 30 procent av frakten 6 procent.

**Är frakt momsfri vid försäljning till företag i annat EU-land?**

Ja, när varuförsäljningen är det. Säljer du till ett momsregistrerat företag i ett annat EU-land och varorna transporteras dit, faktureras varorna utan svensk moms. Frakten följer med och faktureras också utan moms, eftersom den ingår i samma beskattningsunderlag.

**Gäller samma sak för expeditionsavgift och emballage?**

Ja. Kostnader som hör till leveransen, till exempel expeditionsavgift, emballage och transportförsäkring, behandlas på samma sätt som frakten och följer varornas momssats.

**Påverkar den sänkta matmomsen momsen på frakt?**

Ja. Frakt på livsmedel följer livsmedlens momssats, som är 6 procent mellan 1 april 2026 och 31 december 2027. Därefter går både livsmedlen och frakten på dem tillbaka till 12 procent.

---

## CBAM: gränsjusteringsmekanismen för koldioxid

Källa: https://fluit.se/kunskap/ekonomi/cbam
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

CBAM, Carbon Border Adjustment Mechanism, är EU:s gränsjusteringsmekanism som prissätter koldioxidutsläppen i vissa importerade varor: cement, järn och stål, aluminium, gödselmedel, el och vätgas. Sedan den 1 januari 2026 gäller den definitiva fasen, då importörer över 50 ton per kalenderår måste vara godkända CBAM-deklaranter och köpa certifikat för de inbäddade utsläppen.

**CBAM, Carbon Border Adjustment Mechanism, sätter ett pris på koldioxidutsläppen i varor som importeras till EU.** Tanken är att jämna ut spelplanen: europeisk tillverkning betalar för sina utsläpp genom utsläppshandeln, och utan CBAM skulle import från länder utan motsvarande kostnad bli konstlat billig.

För en importör är det inte en klimatfråga i första hand. Det är ett dataproblem, och det landar i inköp och i artikelregistret.

## Vilka varor det gäller

Sex varugrupper omfattas: cement, järn och stål, aluminium, gödselmedel, el och vätgas. Därtill ett antal varor tillverkade av dessa material, till exempel skruv, rör och profiler i stål eller aluminium.

Avgränsningen görs med **KN-nummer**, alltså varukoden ur tulltaxan. Det är därför en verkstad kan bli berörd utan att köpa in råvara: en förpackning skruv har en varukod, och den kan ligga inom CBAM.

## Vad som gäller sedan 2026

Fram till utgången av 2025 var CBAM en ren rapporteringsövning. Sedan den **1 januari 2026** gäller den definitiva fasen, med två praktiska konsekvenser:

- Importörer som tar in **mer än 50 ton CBAM-varor per kalenderår** måste ha status som **godkänd CBAM-deklarant**. Utan den statusen får varorna inte importeras.
- Certifikat ska köpas och överlämnas som täckning för de inbäddade utsläppen i det som importerats.

Deklarationen är årlig och lämnas i efterhand: uppgifterna för 2026 rapporteras senast under hösten 2027. Genom EU:s förenklingspaket har både gränsen på 50 ton, tidplanen och kraven på hur stor andel av utsläppen som ska täckas av certifikat justerats, och beräkningen av utsläpp i insatsvaror har förenklats.

## Inbäddade utsläpp är det svåra

Det som ska rapporteras är **inbäddade utsläpp**: växthusgaserna som uppstått vid tillverkningen av varan, inklusive utsläppen från insatsvarorna. Beräkningen följer EU:s metod och bygger på uppgifter från tillverkaren, som ofta sitter i ett land utan motsvarande rapporteringskultur.

I praktiken blir det en inköpsfråga. Uppgifterna måste begäras in från leverantören, sparas per artikel och kunna knytas till en specifik import. Ett par konsekvenser följer direkt:

- **Varukoden måste vara rätt på artikeln.** Utan den går det inte att avgöra om varan omfattas.
- **Vikten per artikel måste vara rätt.** Både 50-tonsgränsen och utsläppsberäkningen bygger på kvantitet.
- **Leverantörsuppgifterna behöver en plats.** Ett mejl i någons inkorg räcker inte när deklarationen ska lämnas ett år senare.

## Vad ett affärssystem kan bidra med

CBAM-deklarationen lämnas inte av affärssystemet. Det som systemet kan göra är att hålla underlaget: varukod och nettovikt per artikel, importerad kvantitet per period och leverantör, och de leverantörsuppgifter som utsläppsberäkningen vilar på.

I [Fluit](/funktioner/punktskatt) finns HS-koden och nettovikten på artikeln, samma uppgifter som används för tullhantering och för punktskatt. Punktskattemotorn har dessutom **per kilo koldioxidekvivalent** som beräkningsbas, vid sidan av per kilo nettovikt, per styck och procent av värde, vilket gör att en avgift av CBAM-karaktär kan räknas fram på en orderrad när underlaget finns.

Rapporteringen till myndigheten gör du fortfarande själv, och underlaget om utsläpp per leverantör behöver du fortfarande begära in.

### Vanliga frågor

**Vilka varor omfattas av CBAM?**

Cement, järn och stål, aluminium, gödselmedel, el och vätgas, samt vissa varor tillverkade av dessa material. Exakt vilka varor som ingår avgörs av KN-numret, alltså varukoden i tulltaxan, inte av varans benämning.

**Vad innebär 50-tonsgränsen?**

Den som importerar mindre än 50 ton CBAM-varor per kalenderår omfattas inte av kraven på godkänd deklarantstatus och certifikat. Över gränsen krävs status som godkänd CBAM-deklarant för att få importera varorna.

**Vad är inbäddade utsläpp?**

De växthusgasutsläpp som uppstått vid tillverkningen av varan, inklusive utsläpp från insatsvaror. De ska rapporteras per varuslag och beräknas med EU:s metod, vilket i praktiken kräver uppgifter från tillverkaren utanför EU.

**Är CBAM samma sak som tull?**

Nej. Tull räknas på varans värde och betalas i tulldeklarationen. CBAM prissätter utsläppen i varan och hanteras genom certifikat som köps och överlämnas separat, med en egen deklaration och en egen tidplan.

---

## Lagerbokföring från inleverans till leverantörsfaktura

Källa: https://fluit.se/kunskap/ekonomi/lagerbokforing
Ämne: Ekonomi & skatt
Uppdaterad: 2026-10-06

Lagerbokföring är bokföringen av lagrets värde när varor kommer in och går ut. Vid inleverans debiteras lagerkontot och ett konto för mottagna men ej fakturerade varor, GR/IR, krediteras. När leverantörsfakturan bokförs flyttas beloppet från GR/IR till leverantörsskulder. Vid försäljning flyttas värdet från lagret till kostnad för sålda varor.

Varorna kommer in en tisdag, leverantörsfakturan en vecka senare. Däremellan står godset på hyllan och är bolagets, men ingen skuld är bokförd. Lagerbokföringen löser det med ett konto som bär skulden i väntan på fakturan: **GR/IR**, mottagna varor som inte är fakturerade.

Kontonumren nedan är exempel. Kontoplanen är er egen.

| Konto | Namn |
| --- | --- |
| 1460 | Lager |
| 2440 | Leverantörsskulder |
| 2640 | Ingående moms |
| 2980 | Mottagna varor, ej fakturerade (GR/IR) |
| 4000 | Kostnad för sålda varor |
| 4010 | Prisdifferenser |

## När priset stämmer

Ett bolag tar emot 100 ventiler à 200 kronor. Lagret ökar, och skulden för det mottagna hamnar på GR/IR:

**Inleverans, 100 st à 200 kr**

| Konto | Debet | Kredit |
| --- | ---: | ---: |
| 1460 Lager | 20 000 | |
| 2980 GR/IR | | 20 000 |

Fakturan kommer på 20 000 kronor plus moms. Den bokförs mot GR/IR i stället för mot ett kostnadskonto, eftersom varorna redan ligger i lagret:

**Leverantörsfaktura**

| Konto | Debet | Kredit |
| --- | ---: | ---: |
| 2980 GR/IR | 20 000 | |
| 2640 Ingående moms | 5 000 | |
| 2440 Leverantörsskulder | | 25 000 |

GR/IR står nu på noll för den här leveransen. När ventilerna säljs flyttas värdet från lagret till kostnad för sålda varor: debet 4000, kredit 1460, med det värde lagret bar.

Ordningen kan också vara den omvända. Kommer fakturan före varorna står GR/IR med ett debetsaldo tills inleveransen är gjord.

## När fakturan har ett annat pris

Så rent blir det sällan. Leverantören har höjt priset, glömt en rabatt eller fakturerar i euro till en annan kurs. Då har inleveransen bokat lagret till ett pris och fakturan säger ett annat.

Ett exempel: 50 artiklar togs emot à 100 kronor, alltså 5 000 kronor på lagret och på GR/IR. Innan fakturan kommer har 15 sålts. Fakturan är på 5 375 kronor, 7,50 kronor dyrare per styck.

Fakturan bokförs mot GR/IR med sitt fulla belopp. Då står GR/IR med 375 kronor i debet som ingen inleverans förklarar. De ska ha ett hem, och det finns två:

- **Det som finns kvar i lagret**, 35 av 50 styck. Deras värde var för lågt, och 35 × 7,50 = 262,50 kronor läggs på lagret.
- **Det som redan sålts**, 15 styck. De finns inte längre i lagret, så deras 112,50 kronor går inte att lägga där. Det är en kostnad i perioden.

**Leverantörsfaktura**

| Konto | Debet | Kredit |
| --- | ---: | ---: |
| 2980 GR/IR | 5 375 | |
| 2640 Ingående moms | 1 343,75 | |
| 2440 Leverantörsskulder | | 6 718,75 |

**Prisdifferens**

| Konto | Debet | Kredit |
| --- | ---: | ---: |
| 1460 Lager, kvar i lager | 262,50 | |
| 4010 Prisdifferenser, sålt gods | 112,50 | |
| 2980 GR/IR | | 375 |

Efter prisdifferensen är GR/IR på noll igen, och lagret är värt vad godset faktiskt kostade. Är fakturan billigare än inleveransen blir det tvärtom: lagret skrivs ner och prisdifferenskontot krediteras.

Det är frestande att lägga hela differensen på lagret. Då hamnar 112,50 kronor på artiklar som redan lämnat huset, och snittpriset på de 35 som finns kvar blir för högt. Felet syns först nästa gång någon räknar marginal på artikeln.

## Kontrollen före bokföringen

En prisdifferens ska vara en avvikelse någon har sett, inte ett belopp som slinker igenom. Därför stäms fakturan av mot inköpsordern och inleveransen innan den bokförs, så kallad [three-way matching](/kunskap/inkop/three-way-matching). Små differenser, några ören på avrundning, får passera inom en tolerans. Större ska godkännas av någon som kan svara för dem.

Kontrollen fångar också det som inte är en prisdifferens alls: att samma inleverans faktureras två gånger, eller att fakturan gäller fler än det som togs emot. Sådant ska inte bokas på lagret. Det ska reklameras.

## Månadsavstämningen

Vid månadsskiftet ska lagerkontot i bokföringen stämma med lagervärdet i lagersystemet. GR/IR ska kunna förklaras rad för rad:

- **Inleveranser som väntar på faktura.** Normalt. Saldot ska motsvara dem.
- **Prisdifferenser för sålt gods** som inte bokförts mot prisdifferenskontot.
- **Fakturor som bokförts mot ett kostnadskonto** i stället för mot GR/IR. Då ligger inleveransen kvar på GR/IR och kostnaden tas två gånger.
- **Varor som skickats tillbaka** till leverantören utan att lagret bokats ut.

Ett GR/IR som växer månad för månad är ofta ett tecken på den tredje punkten.

## Så gör Fluit

Fluit bokför lagret som verifikat i Fortnox. Rörelserna samlas till ett verifikat per lager och dag: inleverans mot GR/IR, plock för kund mot kostnad för sålda varor, kassation mot svinnkontot. GR/IR är frivilligt. Utan det bokförs inleveranserna mot kostnad för sålda varor.

Leverantörsfakturans rader matchas mot inleveranserna med ett klick, och direkt när fakturan kommer in via inkorgen. Finns flera lika troliga inleveranser gissar Fluit inte, utan raden säger varför den väntar. En rad som ligger utanför bolagets eller leverantörens tolerans i pris eller antal får en avvikelse, och fakturan bokförs inte förrän en chef godkänt den. Mer om det på sidan om [leverantörsfakturor](/funktioner/leverantorsfakturor).

Med inställningen för prisdifferens påslagen delar Fluit differensen när fakturan bokförs, på samma sätt som exemplet ovan. Dialogen före bokföringen visar tre belopp: differensen mot inleveranserna, vad som läggs på lagervärdet och vad som avser sålt gods. Lagerdelen går med i dagens lagerverifikat, mot GR/IR. Den sålda delen ligger kvar på GR/IR och listas per månad under Lageravstämning, med vad som återstår att bokföra mot ert prisdifferenskonto och en export till CSV. Har bolaget inget GR/IR-konto går lagerdelen i stället mot kostnad för sålda varor, och den sålda delen är redan kostnadsförd. Då finns inget kvar att bokföra. Inställningen är avslagen från början. Utan den ligger lagret kvar på inleveransens pris, och hela differensen bokförs i ekonomisystemet.

Själva leverantörsfakturan registreras i Fortnox som förut. Fluit rör aldrig leverantörsskulden.

### Vanliga frågor

**Vad är ett GR/IR-konto?**

GR/IR står för goods received, invoice received. Det är en skuld för varor som tagits emot men ännu inte fakturerats. Inleveransen krediterar kontot och leverantörsfakturan debiterar det. Saldot visar vad ni tagit emot men ännu inte fått någon faktura på.

**Måste man ha ett GR/IR-konto?**

Nej. Utan det bokförs inleveransen direkt mot ett resultatkonto, till exempel kostnad för sålda varor. Det är enklare, men då går det inte att se i bokföringen vilka varor som tagits emot och fortfarande saknar faktura.

**Vad är en prisdifferens på en leverantörsfaktura?**

Skillnaden mellan vad leverantören fakturerar och vad inleveransen bokades till, oftast inköpsorderns pris. En prishöjning, en glömd rabatt eller en annan valutakurs ger alla en prisdifferens.

**Varför läggs inte hela prisdifferensen på lagret?**

För att en del av varorna redan kan vara sålda. Lagret kan bara bära värdet för det som finns kvar. Differensen för den sålda delen är en kostnad i perioden och bokförs på ett konto för prisdifferenser.

**Varför går inte GR/IR-kontot till noll?**

Ett saldo är normalt så länge det finns inleveranser som väntar på faktura. Det som ska bort är rester: prisdifferenser för sålt gods som inte bokförts, fakturor som bokförts mot fel konto och varor som returnerats utan att lagret bokats ut.

---

## Moms på presentkort

Källa: https://fluit.se/kunskap/ekonomi/moms-pa-presentkort
Ämne: Ekonomi & skatt
Uppdaterad: 2026-09-29

Moms på presentkort redovisas antingen när kortet säljs eller när det löses in, beroende på typ. Ett enfunktionspresentkort, där momssats och beskattningsland är kända redan vid utfärdandet, momsas vid försäljningen av kortet. Ett flerfunktionspresentkort, som kan användas till varor med olika momssatser, momsas först när det löses in mot en vara.

**Ett presentkort är inte en vara, det är en utfästelse.** Kunden betalar i dag för något som ska hämtas ut senare, och frågan momsreglerna svarar på är när den betalningen ska momsas: vid försäljningen av kortet eller vid inlösen.

Svaret beror på om du redan vid försäljningen vet vilken moms som kommer att gälla.

## De två typerna

| | Enfunktionspresentkort | Flerfunktionspresentkort |
| --- | --- | --- |
| Momssats känd vid utfärdandet | Ja | Nej |
| Beskattningsland känt | Ja | Nej eller delvis |
| Moms redovisas | Vid försäljningen av kortet | Vid inlösen |
| Typiskt exempel | Kort som gäller en bestämd tjänst | Kort som gäller hela sortimentet |

Ett presentkort på en massage hos en salong i Sverige är enfunktion: både satsen och landet är givna. Ett presentkort på 500 kronor i en butik som säljer både livsmedel (6 procent, tillfälligt sänkt från 12 procent till och med 2027) och elektronik (25 procent) är flerfunktion, eftersom ingen vet vad kunden kommer att välja.

De flesta presentkort i handeln är flerfunktionspresentkort. Det räcker att sortimentet innehåller två momssatser.

## Vad det betyder i praktiken

**Flerfunktionspresentkort.** Försäljningen av kortet är ingen momspliktig omsättning. Beloppet bokas som en skuld till kunden. Momsen redovisas först när kortet löses in mot varor, med den sats som gäller för de varorna. Löses kortet in mot varor med blandade satser fördelas beloppet mellan dem.

**Enfunktionspresentkort.** Momsen redovisas när kortet säljs, som om varan eller tjänsten hade sålts direkt. Vid inlösen sker ingen ny momsredovisning, eftersom den redan är gjord.

## Kort som förfaller

Ett flerfunktionspresentkort som aldrig löses in har aldrig momsats. När giltighetstiden går ut försvinner skulden till kunden och beloppet intäktsförs, utan moms.

För ett enfunktionspresentkort är läget det motsatta: momsen är redan redovisad och rörs inte av att kortet blir liggande i en byrålåda.

Det gör förfallodatumet till mer än en detalj i villkoren. Det är den händelse som avgör när ett belopp går från skuld till intäkt.

## Vad systemet behöver hålla reda på

Oavsett momsbehandling behöver ett presentkort spåras som ett eget objekt, inte som en rad på en gammal order:

- **Saldo**, eftersom ett kort kan lösas in i flera omgångar.
- **Giltighetstid**, för att veta när skulden upphör.
- **Transaktionshistorik**, så att varje uttag går att härleda till en order.

I [Fluit](/funktioner/presentkort) har presentkortet en kod, ett ursprungligt belopp, ett aktuellt saldo i sin valuta, en status och ett valfritt utgångsdatum, och varje användning registreras som en transaktion mot kortet. Kortet kan knytas till den order som sålde det och till mottagaren, med schemalagd utskick.

Klassificeringen som enfunktions- eller flerfunktionsvoucher, och därmed momstidpunkten, gör du i ekonomiredovisningen. Fluit håller saldot, spårbarheten och kopplingen till ordern, inte bedömningen av vouchertypen.

### Vanliga frågor

**När ska moms redovisas på ett presentkort?**

Vid försäljningen om det är ett enfunktionspresentkort, alltså när det redan då är känt vilken momssats och vilket land som gäller. Vid inlösen om det är ett flerfunktionspresentkort, eftersom momssatsen inte kan avgöras förrän kunden valt vara.

**Vad är skillnaden mellan enfunktions- och flerfunktionsvoucher?**

Ett enfunktionspresentkort kan bara användas till varor eller tjänster med en och samma momssats i ett känt land, till exempel ett kort som gäller en specifik behandling. Ett flerfunktionspresentkort kan användas till ett sortiment med olika momssatser, vilket gör momsen okänd fram till inlösen.

**Vad händer med momsen om presentkortet aldrig löses in?**

För ett flerfunktionspresentkort har ingen moms redovisats, och beloppet intäktsförs utan moms när kortet förfaller. För ett enfunktionspresentkort är momsen redan redovisad vid försäljningen och påverkas inte av att kortet inte används.

**Räknas rabattkuponger som presentkort?**

Nej. En kupong som bara ger prisavdrag är ingen voucher i momslagens mening, utan hanteras som en rabatt på det köp där den används.

---

## Avtalshantering: service, uthyrning och abonnemang

Källa: https://fluit.se/kunskap/ekonomi/avtalshantering
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

Avtalshantering i ett affärssystem handlar om löpande kundavtal som ska faktureras återkommande: service, uthyrning, abonnemang, underhåll och leasing. Avtalet bär rader med pris och period, en faktureringsfrekvens, en giltighetstid och ofta villkor om servicenivå. Det som skiljer det från en vanlig order är att det genererar intäkt om och om igen utan att någon lägger en ny order.

**Ett avtal skiljer sig från en order på en punkt som ändrar allt: det tar inte slut.** En order levereras och faktureras en gång. Ett serviceavtal, ett hyresavtal eller ett abonnemang ska faktureras varje månad eller kvartal, år efter år, utan att någon lägger en ny order.

Det är därför avtal så ofta hamnar i ett kalkylblad vid sidan av systemet, och därför det kalkylbladet så ofta är den enda platsen där någon vet när avtalen går ut.

## Vad avtalet behöver bära

Fem uppgifter räcker för att avtalet ska kunna sköta sig självt:

- **Rader** med vad som ingår och till vilket pris.
- **Frekvens**: hur ofta det ska faktureras.
- **Period**: startdatum, slutdatum och eventuell uppsägningsfrist.
- **Objekt**: vilken utrustning, anläggning eller tjänst avtalet gäller.
- **Servicenivå**: vad kunden har rätt att förvänta sig, om avtalet lovar något.

Saknas frekvensen blir avtalet en anteckning. Saknas perioden blir det en evighetsmaskin.

## Datumen som ska bevakas

Tre datum i varje avtal är värda en påminnelse i förväg:

| Datum | Varför det spelar roll |
| --- | --- |
| Uppsägningsdatum | Passeras det förnyas avtalet, oavsett vad någon tänkt |
| Prisrevision | Missas den löper avtalet vidare på gammalt pris |
| Slutdatum | Utan förnyelse upphör både intäkten och åtagandet |

Uppsägningsdatumet är det som brukar orsaka mest irritation, eftersom det ligger före slutdatumet och därför känns avlägset ända tills det redan passerat.

## Avtalstyperna beter sig olika

Ett hyresavtal faktureras för tid och behöver hålla reda på utrustningen som är utlånad. Ett serviceavtal faktureras för beredskap och behöver hålla reda på vad som ingår när något går sönder. Ett abonnemang faktureras för åtkomst och behöver hålla reda på antal och nivå.

Skillnaden syns tydligast i vad som händer när kunden hör av sig. Vid ett serviceavtal är frågan om det inträffade ryms inom avtalet eller ska faktureras extra, och det svaret behöver finnas på plats innan teknikern åker.

## Kopplingen till arbetet

Ett avtal som bara ligger i ekonomin blir en fakturarutin. Det som gör det användbart är kopplingen åt två håll:

- Mot [underhållsplanerna](/kunskap/produktion/forebyggande-underhall), så att den service som avtalet lovar faktiskt planeras in och utförs.
- Mot [ärendehanteringen](/kunskap/affarssystem/arendehantering-med-ko-och-sla), så att kundens avtalade svarstid styr prioriteringen när ett ärende kommer in.

Utan den kopplingen är servicenivån ett löfte i en pdf.

## I ett system

I [Fluit](/funktioner/kontrakt-och-tillgangar) finns kontrakt av typerna uthyrning, service, abonnemang, underhåll, leasing och övrigt, kopplade till kund och med startdatum och status. Kontraktet bär rader, periodisk fakturering, SLA-villkor och prisrevisioner, och skapas som utkast så att det går att arbeta med innan det aktiveras.

Ett kontrakt i utkast fakturerar ingenting. Det är en liten sak som spar en del obehag.

### Vanliga frågor

**Vad är skillnaden mellan ett avtal och en order?**

En order är en engångshändelse med en leverans och en faktura. Ett avtal löper över tid och genererar återkommande fakturor utan att någon lägger en ny order varje gång. Avtalet behöver därför en period och en frekvens, vilket ordern inte har.

**Vad ska ett serviceavtal innehålla?**

Vad som ingår och vad som faktureras separat, vilken utrustning eller vilka tjänster det omfattar, priset och hur ofta det faktureras, giltighetstid med uppsägningsvillkor, samt eventuella servicenivåer med svars- och åtgärdstider.

**Vad är prisrevision i ett avtal?**

En avtalad justering av priset vid bestämda tidpunkter, ofta årligen och ibland kopplad till ett index. Utan bevakning missas revisionen, och avtalet fortsätter på ett pris som förhandlades under andra förutsättningar.

**Vad händer om avtalet inte sägs upp?**

Det beror på villkoren. Många avtal förnyas automatiskt om ingen säger upp dem inom en viss frist, vilket gör att uppsägningsdatumet är minst lika viktigt att bevaka som slutdatumet.

---

## Projektredovisning och efterkalkyl

Källa: https://fluit.se/kunskap/ekonomi/projektredovisning-och-efterkalkyl
Ämne: Ekonomi & skatt
Uppdaterad: 2026-08-07

Projektredovisning innebär att kostnader och intäkter samlas per projekt i stället för bara per konto, så att varje uppdrag går att följa för sig. Efterkalkylen jämför utfallet med den kalkyl som låg till grund för priset. Underlaget består av rapporterad tid, förbrukat material, inköp som knutits till projektet och fakturerade belopp, och måste samlas löpande för att bli användbart.

**Projektredovisning är att lägga en dimension till bokföringen: vilket uppdrag kostnaden hör till.** Utan den kan ett bolag ha god marginal totalt och samtidigt ha en tredjedel av uppdragen under noll, utan att någon kan peka ut vilka.

Efterkalkylen är det som gör dimensionen användbar. Den ställer utfallet mot den kalkyl som låg till grund för priset, och svarar på om priset var rätt satt.

## Vad som ska samlas

Fyra sorters poster behöver hitta till projektet:

- **Tid**, rapporterad av dem som utfört arbetet, till en känd timkostnad.
- **Material**, taget ur lagret mot projektet, värderat till [hemtagningskostnad](/ordlista/hemtagningskostnad) och inte till listpris.
- **Inköp**, både varor och tjänster som köpts specifikt för uppdraget.
- **Intäkter**, det som fakturerats och det som är upparbetat men ännu inte fakturerat.

Den fjärde punkten är den som oftast fattas. Utan upparbetad men ofakturerad intäkt ser ett projekt olönsamt ut mitt i, bara för att faktureringen sker vid slutet.

## Det ska ske under tiden

Den vanligaste orsaken till att efterkalkyler saknas är inte att ingen vill ha dem. Det är att underlaget aldrig samlades medan arbetet pågick.

Rekonstruktion i efterhand har ett systematiskt fel: den blir för snäll. Tid som ingen minns räknas inte, materialet uppskattas till vad som borde ha gått åt, och timmarna kring en oplanerad krånglig detalj försvinner. Resultatet blir en efterkalkyl som visar att kalkylen höll, vilket gör nästa kalkyl lika optimistisk.

## Tilläggsarbetet avgör

I de flesta uppdragsverksamheter är det inte den ursprungliga omfattningen som spräcker kalkylen. Det är det som lades till på vägen: en ändring kunden bad om, en anpassning som "bara tar en halvtimme", en extra vända för något som visade sig sitta annorlunda.

Det som skiljer ett lönsamt projekt från ett olönsamt är därför sällan skickligheten i utförandet, utan om tilläggen registrerades och fakturerades. Ett system som gör det enkelt att lägga en tilläggsrad medan arbetet pågår tjänar in sig snabbt.

## Vad efterkalkylen ska visa

En användbar efterkalkyl svarar på tre frågor:

| Fråga | Vad den avslöjar |
| --- | --- |
| Stämde tiden? | Om kalkylens timmar är realistiska eller önsketänkande |
| Stämde materialet? | Om spill och kassation räknats med |
| Fakturerades allt? | Om tilläggsarbetet gick fram till fakturan |

Det räcker att göra den på ett urval projekt för att mönstret ska framträda. En viss typ av uppdrag som konsekvent tar tjugo procent längre tid är ett prisproblem, inte en serie olyckor.

## I ett system

I [Fluit](/funktioner/projekt) finns projekt med status och egna uppgifter, och arbetsorder kan vara av typen projekt. Tid rapporteras per operation på [arbetsordern](/kunskap/produktion/arbetsorder), material tas ut mot den och kostnadsrader kan läggas till, vilket ger utfallet per uppdrag ur samma registrering som styr lagersaldot.

Bokföringen sker fortfarande i ekonomisystemet. Det Fluit bidrar med är underlaget: tiden, materialet och inköpen knutna till rätt uppdrag medan de uppstår.

### Vanliga frågor

**Vad är efterkalkyl?**

Jämförelsen mellan vad ett uppdrag kalkylerades kosta och vad det faktiskt kostade. Den visar om priset var rätt satt och var avvikelsen uppstod: i tiden, i materialet eller i omfattningen.

**Vad krävs för att kunna göra en efterkalkyl?**

Att kostnaderna knutits till projektet medan de uppstod. Tid ska rapporteras på projektet, material tas ut mot det och inköp märkas med det. Görs det i efterhand blir efterkalkylen en rekonstruktion, och rekonstruktioner blir systematiskt för snälla.

**Varför blir projekt olönsamma utan att någon märker det?**

För att kostnaderna sprids ut på konton medan intäkten syns per faktura. Utan projektdimension kan ett bolag ha god total marginal och samtidigt ha en tredjedel av uppdragen under noll, utan att det går att se.

**Vad är tilläggsarbete och varför spelar det roll?**

Arbete utöver det som ingick i det ursprungliga åtagandet. Det är den vanligaste orsaken till att en efterkalkyl spricker, och skillnaden mellan ett lönsamt och ett olönsamt projekt är ofta bara om tilläggen fakturerades eller inte.

---

## Vad är en inköpsorder (PO)?

Källa: https://fluit.se/kunskap/inkop/vad-ar-en-inkopsorder
Ämne: Inköp
Uppdaterad: 2026-07-30

En inköpsorder, på engelska purchase order eller PO, är den formella beställning du skickar till en leverantör. Den anger artiklar, antal, pris, valuta och villkor, och blir ett bindande avtal när leverantören accepterar den. Därefter är den dokumentet som både inleveransen och leverantörsfakturan stäms av mot.

En **inköpsorder** (purchase order, ofta förkortat **PO**) är beställningen du skickar till en leverantör. Den säger vad du vill köpa, till vilket pris, hur mycket och på vilka villkor. Accepterar leverantören ordern har ni ett avtal.

Utan en inköpsorder blir det svårt att hålla ordning. Vad beställdes egentligen, till vilket pris, och kom allt fram? Med en order finns svaret på papper, eller i systemet.

## Vad innehåller en inköpsorder?

Det mesta är sig likt mellan leverantörer. En order brukar ha:

- Ett **ordernummer** som följer beställningen hela vägen.
- Vem du köper av.
- **Orderrader** med artikel, beskrivning, antal, pris per enhet och radsumma.
- **Valuta**, vilket blir viktigt så fort du köper utomlands.
- **Leveransvillkor** som Incoterms, leveransadress och önskat datum.
- **Betalningsvillkor**, alltså kredittid och betalsätt.
- **Totalbelopp**, oftast både med och utan moms.

I Fluit skapar du ordern med rader, villkor och valuta direkt i systemet. Kopplar du varje rad till en artikel i registret håller sig inköpspriser och artikelnummer uppdaterade av sig själva.

## Inte att förväxla med rekvisition, bekräftelse och faktura

Dokumenten i ett inköp är lätta att blanda ihop. De kommer i den här ordningen:

1. **Rekvisition**: ett internt önskemål ("vi behöver beställa 200 enheter") som går till någon för godkännande.
2. **Inköpsorder**: den godkända beställningen som går till leverantören.
3. **Orderbekräftelse**: leverantörens svar, ibland med justerade antal eller datum.
4. **Inleverans / följesedel**: kvitto på att varorna kommit.
5. **Leverantörsfaktura**: betalningskravet.

Håller du isär dem kan du senare göra **three-way matching**, alltså stämma av fakturan mot order och inleverans innan du betalar.

## Därför ger ordern dig kontroll

Med en order på plats kan du kräva godkännande innan pengarna lämnar bolaget. I Fluit styr behörigheterna vem som får skapa och skicka order. Du ser också var varje beställning befinner sig, från beställd till mottagen, och kan stämma av leverantörsfakturan mot det du faktiskt beställde och fick. Är det fel pris eller antal upptäcker du det innan betalningen, inte efter.

## Inköpsorder i Fluit

Inköpsordern är startpunkten för allt som följer. Du skapar den för hand, eller låter [MRP-motorn](/funktioner/mrp) räkna fram vad som behöver köpas och göra om förslaget till en färdig order. När godset kommer registrerar du en [inleverans](/kunskap/inkop/inleverans-och-godsmottagning) mot ordern, och de reservationer som låg mot inköpsordern flyttas automatiskt över till lagersaldot.

### Vanliga frågor

**Är en inköpsorder juridiskt bindande?**

Ja. När leverantören accepterar inköpsordern uppstår ett bindande avtal om pris, kvantitet och villkor. Därför bör ordern vara korrekt och godkänd innan den skickas.

**Vad är skillnaden mellan en inköpsorder och en rekvisition?**

En rekvisition är ett internt önskemål om att köpa något och används för att begära godkännande. En inköpsorder är det externa, bindande dokument som skickas till leverantören efter att inköpet godkänts.

**Behöver små företag inköpsorder?**

Ja. Även små företag tjänar på inköpsorder: de skapar spårbarhet, gör det möjligt att stämma av leverantörsfakturor mot beställning och inleverans, och ger kontroll över utgifter innan pengarna lämnar bolaget.

---

## Inköpsprocessen steg för steg (purchase-to-pay)

Källa: https://fluit.se/kunskap/inkop/inkopsprocessen-steg-for-steg
Ämne: Inköp
Uppdaterad: 2026-07-30

Inköpsprocessen, på engelska purchase-to-pay, täcker allt från att ett behov uppstår till att leverantörsfakturan är betald. Stegen är behov, leverantörsval, inköpsorder, godkännande, utskick och orderbekräftelse, inleverans, fakturakontroll mot order och mottagning, samt betalning och uppföljning. Ju tydligare stegen är, desto färre fel hinner nå fakturan.

**Inköpsprocessen**, på engelska *purchase-to-pay* eller *procure-to-pay*, täcker allt från att ett behov dyker upp till att leverantörsfakturan är betald. Ju mer ordnad den är, desto mindre tid lägger du på att jaga fakturor och reda ut vad som egentligen beställdes.

## 1. Behovet uppstår

Allt börjar med ett behov. Lagret närmar sig beställningspunkten, en kund har lagt en order som kräver inköp, eller produktionen behöver material. Behovet kan upptäckas för hand eller räknas fram. I Fluit analyserar [MRP-motorn](/funktioner/mrp) lagernivåer, efterfrågan och ledtider och lägger fram [beställningsförslag](/kunskap/inkop/bestallningspunkt-och-sakerhetslager).

## 2. Leverantörsval

Vem ska du köpa av? Pris, ledtid, kvalitet och tillgänglighet styr valet. Har du en leverantörskatalog där artiklarna redan är mappade mot rätt leverantör går steget snabbt, för pris och artikelnummer ligger på plats.

## 3. Inköpsorder skapas

Behovet blir en [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder) med rader, antal, pris, valuta och villkor. I Fluit kan ett beställningsförslag från MRP bli en färdig order med ett klick.

## 4. Godkännande

Innan ordern går iväg passerar den ett godkännandeflöde. Här fångas utgiften medan den fortfarande går att stoppa, och du kan styra med regler vem som får godkänna vad. Ofta är det det här steget som skiljer ordnade inköp från fri spendering.

## 5. Order skickas och bekräftas

Den godkända ordern går till leverantören, som svarar med en [orderbekräftelse](/kunskap/inkop/orderbekraftelse-vs-inkopsorder). Bekräftelsen kan innehålla justerade antal eller leveransdatum. Avviker den från din order vill du se det direkt, så att du hinner agera.

## 6. Inleverans / godsmottagning

När varorna anländer registrerar du en [inleverans](/kunskap/inkop/inleverans-och-godsmottagning) mot inköpsordern. Antal och kvalitet kontrolleras och godset styrs till rätt lagerplats. I Fluit flyttas reservationerna som låg mot inköpsordern automatiskt över till lagersaldot, och kundordrar som väntat på varan får sina reservationer uppdaterade.

## 7. Fakturakontroll (three-way matching)

Leverantörsfakturan stäms av mot inköpsordern och inleveransen. Det kallas [three-way matching](/kunskap/inkop/three-way-matching). Stämmer pris och antal kan fakturan godkännas; annars syns avvikelsen innan pengarna betalas ut.

## 8. Betalning och uppföljning

Fakturan betalas enligt avtalade villkor, och inköpet följs upp. Höll leverantören ledtiden? Stämde priset? Kom rätt antal? Svaren blir underlag nästa gång du ska välja leverantör.

## Översikt

| Steg | Vad händer | Nyckeldokument |
| --- | --- | --- |
| 1 | Behov upptäcks | Beställningsförslag |
| 2 | Leverantör väljs | Leverantörskatalog |
| 3 | Order skapas | Inköpsorder |
| 4 | Order godkänns | Godkännandeflöde |
| 5 | Order bekräftas | Orderbekräftelse |
| 6 | Gods tas emot | Inleverans / följesedel |
| 7 | Faktura kontrolleras | Three-way matching |
| 8 | Faktura betalas | Leverantörsfaktura |

I [Fluit](/funktioner/inkop) hänger kedjan ihop i ett och samma system, från behov och inköpsorder till inleverans och fakturakontroll, så informationen följer med utan att skrivas in på nytt.

### Vanliga frågor

**Vad betyder purchase-to-pay?**

Purchase-to-pay (P2P), ibland kallat procure-to-pay, är hela kedjan från att ett inköpsbehov uppstår till att leverantörsfakturan är betald. Det omfattar behov, beställning, godkännande, mottagning och fakturahantering.

**Vad är skillnaden mellan purchase-to-pay och procure-to-pay?**

Termerna används oftast synonymt. Procure-to-pay betonar ibland även de tidigare stegen som leverantörsval och avtal, medan purchase-to-pay fokuserar på den operativa kedjan från order till betalning.

**Hur automatiserar man inköpsprocessen?**

Genom att låta systemet räkna fram behov (MRP), skapa inköpsorder från förslag, styra godkännanden enligt regler, ta emot gods mot order och matcha fakturan mot order och inleverans. Då minskar det manuella arbetet i varje steg.

---

## Orderbekräftelse vs inköpsorder: vad är skillnaden?

Källa: https://fluit.se/kunskap/inkop/orderbekraftelse-vs-inkopsorder
Ämne: Inköp
Uppdaterad: 2026-07-30

En inköpsorder är beställningen du skickar till leverantören, och en orderbekräftelse är leverantörens svar på den. Ordern säger vad du vill köpa, bekräftelsen vad leverantören åtar sig att leverera och när. Avviker bekräftelsen i antal eller datum behöver det upptäckas direkt, eftersom det är leverantörens datum som styr vad du kan lova dina egna kunder.

I varje inköp möts två dokument som lätt förväxlas: **inköpsordern** du skickar och **orderbekräftelsen** du får tillbaka. De handlar om samma affär, fast sedd från var sitt håll. Och det är ofta i glappet mellan dem som problem hinner upptäckas i tid.

## Inköpsordern

[Inköpsordern](/kunskap/inkop/vad-ar-en-inkopsorder) är din beställning. Den säger vad *du* vill köpa: artiklar, antal, priser, valuta och villkor. Den skapas och godkänns hos dig och skickas sedan till leverantören.

## Orderbekräftelsen

Orderbekräftelsen är leverantörens svar. Här säger leverantören vad *de* åtar sig: hur mycket de kan leverera, till vilket pris och vilket datum. Det är deras accept av affären, men inte alltid en exakt kopia av din order.

## När bekräftelsen inte stämmer med ordern

Det är just när bekräftelsen avviker från ordern som den blir värd att läsa noga. Vanliga avvikelser:

- **Antal**: leverantören kan bara skicka 180 av 200 beställda enheter.
- **Pris**: priset har ändrats sedan din förra order.
- **Leveransdatum**: leveransen dröjer två veckor längre än du räknat med.

Upptäcker du det redan vid bekräftelsen kan du planera om, leta en annan leverantör eller acceptera ändringen med öppna ögon. Dyker avvikelsen upp först vid [inleverans](/kunskap/inkop/inleverans-och-godsmottagning) eller på fakturan är det oftast för sent. Då är varan på väg eller pengarna redan utlovade.

## Så hanterar du det i Fluit

I Fluit registrerar du leverantörens orderbekräftelse mot inköpsordern. Avvikelser i antal och leveransdatum blir synliga direkt, så du ser var bekräftelsen skiljer sig från din beställning innan något hinner kosta pengar.

Bekräftelsen är dessutom en pusselbit i [three-way matching](/kunskap/inkop/three-way-matching). Tillsammans med inleverans och faktura ger den dig ett kvitto på att du får, och betalar för, precis det du beställde.

### Vanliga frågor

**Vad är en orderbekräftelse?**

En orderbekräftelse är leverantörens svar på din inköpsorder. Den bekräftar att leverantören accepterar beställningen och anger vilka kvantiteter, priser och leveransdatum de förbinder sig till. Ibland skiljer de sig från din ursprungliga order.

**Måste leverantören skicka en orderbekräftelse?**

Det är inte alltid lagstadgat, men det är god praxis. Orderbekräftelsen gör att båda parter är överens om villkoren och ger dig en chans att fånga avvikelser mot din order innan varorna skickas.

**Vad gör jag om orderbekräftelsen avviker från min inköpsorder?**

Granska avvikelsen direkt. Skiljer sig pris, kvantitet eller leveransdatum kan du antingen acceptera den nya förutsättningen medvetet eller kontakta leverantören. Ett system som visar avvikelser automatiskt sparar tid och förhindrar överraskningar vid inleverans och fakturering.

---

## Inleverans och godsmottagning, så fungerar det

Källa: https://fluit.se/kunskap/inkop/inleverans-och-godsmottagning
Ämne: Inköp
Uppdaterad: 2026-07-30

Inleverans, eller godsmottagning, är när beställda varor anländer och tas emot mot en inköpsorder. Godset identifieras mot ordern, antal och kvalitet kontrolleras, varorna placeras på lagerplats och det faktiskt mottagna antalet registreras. Det är här beställningen blir riktigt lagersaldo, och sista tillfället att fånga fel innan fakturan godkänns.

**Inleverans**, eller **godsmottagning**, är när beställda varor anländer och tas emot mot en [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder). Det är ögonblicket då en beställning blir riktigt lagersaldo, och därför en av de viktigaste kontrollpunkterna i hela inköpsflödet.

## Vad händer vid en inleverans?

När godset kommer in brukar det gå till så här:

1. **Identifiering.** Vilken inköpsorder hör leveransen till? Följesedeln matchas mot ordern.
2. **Antalskontroll.** Stämmer antalet kollin och enheter mot det beställda?
3. **Kvalitetskontroll.** Är varorna hela och felfria?
4. **Inplacering.** Godset styrs till rätt lagerplats.
5. **Registrering.** Det mottagna antalet bokförs och lagersaldot uppdateras.

Är något fel, för få enheter, skadat gods eller fel artikel, fångas det redan här. Innan varorna blandas in i lagret, och innan fakturan godkänns.

## Kontrollen vid mottagning

Mottagningen är din chans att stoppa fel innan de sprider sig vidare. I Fluit validerar du antal och kvalitet vid inleverans, kopplar okända streckkoder på plats och styr gods till rätt platstyp. Avvikelser dokumenteras i samma stund som de upptäcks, inte i efterhand när orsaken är borttappad.

Du registrerar det **faktiskt mottagna** antalet, inte det beställda. Därför stämmer lagersaldot även vid delleveranser, och inköpsordern kan stå kvar som delvis levererad tills resten kommer.

## Automatisk omallokering mot kundordrar

Här gör det skillnad att inköp och försäljning bor i samma system. När du saknar en vara i lager men har lagt en inköpsorder för den, kan en kundorder reserveras mot den **inkommande** ordern. Vid inleverans måste den kopplingen lösas upp.

I Fluit sköts det åt dig. När du gör inleveransen flyttas reservationerna som låg mot inköpsordern över till verkligt lagersaldo, och kundordern som väntat på varan får sin reservation uppdaterad mot det nya saldot. Rätt kund får alltså rätt vara så fort den kommer in, utan att någon behöver minnas vilken order som hörde till vilken.

## Inleveransen i three-way matching

Inleveransen är också en av tre delar i [three-way matching](/kunskap/inkop/three-way-matching). När leverantörsfakturan kommer stäms den av mot inköpsordern (vad du beställde) och inleveransen (vad du fick). Stämmer alla tre kan du betala utan att gissa.

### Vanliga frågor

**Vad är skillnaden mellan inleverans och godsmottagning?**

Termerna används oftast synonymt och betyder att gods tas emot mot en inköpsorder. Godsmottagning betonar den fysiska hanteringen i lagret, medan inleverans även omfattar den systemmässiga registreringen som uppdaterar lagersaldot.

**Vad händer om jag får fel kvantitet vid inleverans?**

Då registrerar du den faktiskt mottagna kvantiteten, inte den beställda. Differensen mot inköpsordern blir synlig, och inköpsordern kan stå kvar som delvis levererad. Det säkerställer att lagersaldot stämmer och att fakturan kan kontrolleras korrekt.

**Kan en kundorder få sina varor automatiskt vid inleverans?**

Ja, i ett system som binder ihop inköp och försäljning. I Fluit övergår allokeringar som låg mot inköpsordern automatiskt till lagersaldo vid inleverans, och kundordrar som väntade på varan reserveras om mot det nya saldot.

---

## Three-way matching, så slipper du betala fel

Källa: https://fluit.se/kunskap/inkop/three-way-matching
Ämne: Inköp
Uppdaterad: 2026-10-06

Three-way matching, på svenska trevägsmatchning, är kontrollen som stämmer av leverantörsfakturan mot både inköpsordern och inleveransen innan den betalas. Ordern visar vad du beställde, inleveransen vad du faktiskt fick och fakturan vad leverantören vill ha betalt. Stämmer alla tre kan fakturan godkännas, annars syns avvikelsen innan pengarna lämnar företaget.

**Three-way matching** (trevägsmatchning) är en enkel kontroll som fångar dyra fel. Regeln är kort: betala aldrig en leverantörsfaktura förrän den stämmer mot både vad du **beställde** och vad du faktiskt **fick**.

## De tre dokumenten

Matchningen jämför tre källor:

1. **Inköpsordern**: vad du beställde: artiklar, antal och priser.
2. **Inleveransen**: vad du tog emot vid [godsmottagningen](/kunskap/inkop/inleverans-och-godsmottagning).
3. **Leverantörsfakturan**: vad leverantören vill ha betalt för.

Överensstämmer de i pris och antal är fakturan trygg att betala. Gör de inte det har du fångat ett fel medan pengarna fortfarande är kvar i bolaget.

## Vad matchningen fångar

Några av de vanligaste och dyraste felen stoppas direkt:

- **Du faktureras för mer än du fick.** Ordern sa 200, du tog emot 180, fakturan gäller 200.
- **Fel pris.** Fakturan har ett högre styckpris än det som avtalades på ordern.
- **Dubbelfakturering.** Samma leverans faktureras två gånger.
- **Varor du aldrig beställt.** Det finns ingen inköpsorder bakom raden.

Med enbart *two-way matching* (faktura mot order) glider det första fallet igenom. Ordern säger 200 och fakturan säger 200, men ingen vet att bara 180 kom in. Det är inleveransen som täpper till den luckan.

## Varför ett sammanhållet system gör skillnad

Ligger de tre dokumenten i olika system, eller i pärmar, blir matchningen ett tråkigt detektivarbete. Någon måste leta upp ordern, följesedeln och fakturan för varje rad.

När de i stället finns på samma ställe sköter systemet det mesta. I Fluit registreras [orderbekräftelse](/kunskap/inkop/orderbekraftelse-vs-inkopsorder) och inleverans mot inköpsordern, och leverantörsfakturans rader matchas mot inleveranserna, automatiskt när det finns en enda trolig inleverans. Varje rad stäms av mot en tolerans i pris och antal. Det som ligger utanför får en avvikelse som en chef godkänner innan fakturan kan bokföras, så den som attesterar ser bara de rader som behöver en närmare titt. Hur en godkänd prisdifferens sedan bokförs mot lagret står i guiden om [lagerbokföring](/kunskap/ekonomi/lagerbokforing).

### Vanliga frågor

**Vad är three-way matching?**

Three-way matching är en kontroll där leverantörsfakturan jämförs mot två andra dokument: inköpsordern (vad du beställde) och inleveransen (vad du faktiskt fick). Stämmer alla tre godkänns fakturan för betalning.

**Vad är skillnaden mot two-way matching?**

Two-way matching jämför bara faktura mot inköpsorder. Three-way matching lägger till inleveransen, vilket fångar fall där du faktureras för varor du beställt men inte mottagit, eller fått i fel kvantitet.

**Måste man matcha alla fakturor manuellt?**

Nej. När inköpsorder, inleverans och faktura finns på samma ställe kan matchningen göras automatiskt, och bara fakturor med avvikelser behöver granskas för hand. Det sparar tid och minskar risken för felbetalningar.

---

## Incoterms 2020: alla 11 leveransvillkor förklarade

Källa: https://fluit.se/kunskap/inkop/incoterms-forklarade
Ämne: Inköp
Uppdaterad: 2026-10-02

Incoterms är standardiserade leveransvillkor från Internationella handelskammaren (ICC) som fördelar ansvaret för transport, försäkring, tull och risk mellan säljare och köpare. Tre bokstäver och en plats på ordern, till exempel FCA Göteborg, pekar ut var ansvaret går över. Gällande version är Incoterms 2020, med elva villkor: sju för alla transportsätt och fyra för sjöfrakt.

Köper du från utlandet dyker frågorna upp på en gång. Vem betalar frakten, vem försäkrar godset, vem tar smällen om något skadas på vägen och vem sköter tullen? Det är precis det här **Incoterms** reder ut. Gällande version är Incoterms 2020.

## Vad är Incoterms?

Incoterms (*International Commercial Terms*) är standardiserade leveransvillkor från Internationella handelskammaren (ICC). De fördelar ansvaret för transport, försäkring, tull och risk mellan köpare och säljare. Det viktigaste de gör är att peka ut **var i transportkedjan ansvaret går över** från säljare till köpare.

Skriver du en Incoterm på din [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder), till exempel "FCA Göteborg" eller "DAP Stockholm", slipper ni tvista om vem som betalar för vad. Villkoret säger däremot ingenting om när äganderätten går över eller om betalningen. Det regleras i resten av avtalet.

## Alla 11 Incoterms 2020 i en tabell

ICC delar villkoren i två grupper efter transportsätt. De sju första gäller alla transportsätt, de fyra sista bara sjöfrakt och transport på inre vattenvägar. Inom varje grupp står de i ordning från minst till mest ansvar för säljaren.

| Villkor | Transportsätt | Risken går över | Säljaren betalar transport till | Exportklarering | Importklarering |
| --- | --- | --- | --- | --- | --- |
| **EXW** Ex Works | Alla | Hos säljaren, när varan står till köparens förfogande | Ingen transport | Köparen | Köparen |
| **FCA** Free Carrier | Alla | När varan lämnas till köparens transportör | Den avtalade leveransplatsen | Säljaren | Köparen |
| **CPT** Carriage Paid To | Alla | När varan lämnas till den första transportören | Destinationen | Säljaren | Köparen |
| **CIP** Carriage and Insurance Paid To | Alla | När varan lämnas till den första transportören | Destinationen, och försäkrar | Säljaren | Köparen |
| **DAP** Delivered at Place | Alla | På destinationen, klar för lossning | Destinationen | Säljaren | Köparen |
| **DPU** Delivered at Place Unloaded | Alla | På destinationen, lossad | Destinationen, med lossning | Säljaren | Köparen |
| **DDP** Delivered Duty Paid | Alla | På destinationen, klar för lossning | Destinationen, med tull och importavgifter | Säljaren | Säljaren |
| **FAS** Free Alongside Ship | Sjö | Bredvid fartyget i avgångshamnen | Avgångshamnen | Säljaren | Köparen |
| **FOB** Free on Board | Sjö | Ombord på fartyget i avgångshamnen | Avgångshamnen, lastat ombord | Säljaren | Köparen |
| **CFR** Cost and Freight | Sjö | Ombord på fartyget i avgångshamnen | Destinationshamnen | Säljaren | Köparen |
| **CIF** Cost, Insurance and Freight | Sjö | Ombord på fartyget i avgångshamnen | Destinationshamnen, och försäkrar | Säljaren | Köparen |

Lägg märke till de fyra C-villkoren: CPT, CIP, CFR och CIF. Där betalar säljaren transporten ända fram, men risken går över redan vid avsändningen. Det är den vanligaste källan till missförstånd, se [risk och kostnad](#risk-och-kostnad-följs-inte-alltid-åt) nedan.

## Villkoren för alla transportsätt

### EXW: Ex Works

Säljaren ställer fram varan i sin egen lokal och gör inget mer, inte ens lastningen. Köparen står för allt därefter: lastning, transport, risk, exportklarering och import. EXW ser enkelt ut men passar dåligt i internationell handel, eftersom köparen sällan kan sköta exportklareringen i säljarens land. Där är FCA det bättre valet.

### FCA: Free Carrier

Säljaren klarerar varan för export och lämnar den till den transportör som köparen har anvisat. Sker leveransen hos säljaren ansvarar säljaren för lastningen. Sker den på en annan plats, till exempel en terminal, levererar säljaren när varan står klar för lossning på sitt eget fordon. FCA är det vanligaste valet för containergods och flygfrakt när köparen bokar transporten.

### CPT: Carriage Paid To

Säljaren betalar transporten till den avtalade destinationen, men risken går över redan när varan lämnas till den första transportören. Skadas godset på vägen bär köparen risken, trots att säljaren bokade frakten. Ingen part är skyldig att försäkra godset.

### CIP: Carriage and Insurance Paid To

Som CPT, men säljaren tecknar också en transportförsäkring som gäller till destinationen. Sedan Incoterms 2020 ska försäkringen motsvara Institute Cargo Clauses (A), alltså allriskskydd. Det är en högre nivå än vid CIF.

### DAP: Delivered at Place

Säljaren levererar till en avtalad plats hos köparen och bär risken hela vägen dit. Varan ska stå klar för lossning, och lossningen sköter köparen. Importklareringen, tullen och importmomsen står köparen för. DAP är det vanligaste villkoret när säljaren ordnar transporten ända fram.

### DPU: Delivered at Place Unloaded

Som DAP, men säljaren lossar också varan på destinationen. DPU är det enda villkoret där säljaren ansvarar för lossningen. Det ersatte DAT (Delivered at Terminal) i Incoterms 2020, och platsen behöver inte längre vara en terminal.

### DDP: Delivered Duty Paid

Säljaren levererar ända fram, klarerad för import och med tull och importavgifter betalda. Det är mest ansvar för säljaren och minst för köparen. DDP kräver att säljaren kan agera importör i köparens land. Utländska säljare kan ofta inte det, och då är DAP det realistiska alternativet.

## Villkoren för sjöfrakt

### FAS: Free Alongside Ship

Säljaren levererar varan bredvid fartyget i avgångshamnen, till exempel på kajen. Risken går över där, och köparen står för lastningen och sjötransporten. FAS används främst för bulk och stora enheter som lastas direkt från kaj.

### FOB: Free on Board

Säljaren ansvarar tills varan är lastad ombord på fartyget i avgångshamnen. Därefter bär köparen risken och kostnaden. FOB är ett av de mest använda villkoren, och ett av de mest felanvända: se avsnittet om containergods nedan.

### CFR: Cost and Freight

Säljaren betalar sjöfrakten till destinationshamnen, men risken går över när varan är ombord i avgångshamnen. Som CPT, fast för sjöfrakt. Ingen part är skyldig att försäkra.

### CIF: Cost, Insurance and Freight

Som CFR, men säljaren tecknar också en sjöförsäkring till destinationshamnen. Försäkringen behöver bara motsvara Institute Cargo Clauses (C), ett grundskydd för de största skadorna. Vill köparen ha mer måste det avtalas särskilt.

## Sjötermer hör inte hemma på containergods

FAS, FOB, CFR och CIF är **sjötermer**. Riskövergången sker vid fartyget. För containergods som lämnas på en terminal långt före lastning rekommenderar ICC i stället **FCA** respektive **CIP**. Att slentrianmässigt skriva FOB på containerfrakt är ett av de vanligaste Incoterms-misstagen, och det lämnar en lucka i risktäckningen mellan terminalen och fartyget.

## Risk och kostnad följs inte alltid åt

En vanlig fälla är att tro att den som betalar transporten också bär risken. Så är det inte alltid. Vid **CIF** betalar säljaren frakten, men **risken** går över till dig redan när godset lastas i avgångshamnen. Skadas godset under sjöresan är det alltså ditt problem, trots att säljaren bokade transporten. Samma sak gäller CPT, CIP och CFR. Läs därför villkoret ord för ord. Det avgör vem som måste agera när något går fel.

## Vanliga förväxlingar

### DAP eller DDP?

Båda levererar ända fram. Skillnaden är vem som sköter importen. Vid DAP gör köparen det och betalar tull och importmoms. Vid DDP gör säljaren det. Som svensk köpare av en utländsk leverantör är DAP oftast det villkor som fungerar i praktiken.

### FCA eller EXW?

EXW lämnar exportklareringen och lastningen till köparen. FCA lägger dem på säljaren, som är den som faktiskt kan sköta dem. Vill du som köpare hämta själv är FCA med säljarens adress som plats nästan alltid det bättre villkoret.

### CIF eller CIP?

Båda innebär att säljaren betalar frakt och försäkring medan risken går över vid avsändningen. CIF gäller bara sjöfrakt och kräver grundskydd. CIP gäller alla transportsätt och kräver allriskskydd. För containergods är CIP rätt villkor.

## Så skriver du en Incoterm rätt

Ett villkor utan plats är halvt. Skriv alltid tre delar: **villkoret, platsen och versionen**, till exempel *FCA Göteborg (Skandiahamnen), Incoterms 2020*. Platsen avgör exakt var risken går över, och en stad räcker sällan: en terminal, ett lager och en hamn i samma stad är tre olika riskövergångar. Versionen avgör vilka regler som gäller, eftersom parterna fritt kan välja en äldre version.

## Vad ändrades i Incoterms 2020?

Jämfört med Incoterms 2010 är skillnaderna få men viktiga:

- **DAT blev DPU.** Leveransplatsen behöver inte längre vara en terminal.
- **CIP kräver högre försäkring.** Allriskskydd enligt Institute Cargo Clauses (A) i stället för grundskydd. CIF ligger kvar på grundskyddet.
- **FCA och konossement.** Parterna kan avtala att köparens transportör ska utfärda ett konossement med ombordnotering till säljaren, något bankerna ofta kräver vid remburs.
- **Egen transport.** Vid FCA, DAP, DPU och DDP får säljaren eller köparen sköta transporten med egna fordon.
- **Säkerhetskrav.** Kostnaderna för säkerhetskontroller i transportkedjan är tydligare fördelade.

Incoterms 2020 gäller fortfarande. ICC har inte satt något datum för nästa utgåva. Reglerna har hittills reviderats ungefär vart tionde år.

## Därför hör Incoterm hemma på inköpsordern

Incoterm påverkar både totalkostnad och ansvar, så den bör stå med på varje internationell beställning. I Fluit sätter du Incoterms, med den namngivna platsen, leveranstid och betalningsvillkor per leverantör och order. Köper du i [utländsk valuta](/kunskap/inkop/inkopsprocessen-steg-for-steg) håller systemet dessutom inköpspriser och kostnader rätt med automatiska växelkurser.

Det gör också att offerter går att jämföra rättvist. Två priser blir jämförbara först när de gäller samma Incoterm. Annars ställer du ett pris med dold frakt mot ett pris där allt redan ingår. Vad varan faktiskt kostar när frakt och tull är med räknar du fram med [kalkylatorn för hemtagningskostnad](/verktyg/landed-cost).

### Vanliga frågor

**Vad är Incoterms?**

Incoterms är internationella leveransvillkor som fastställs av Internationella handelskammaren (ICC). De definierar vem av köpare och säljare som ansvarar för transport, försäkring, tull och risk, och var ansvaret går över mellan parterna. Gällande version är Incoterms 2020.

**Vad är skillnaden mellan DAP och DDP?**

Båda levererar ända fram till köparen, och risken går över först på destinationen. Skillnaden är importen. Vid DAP sköter och betalar köparen importklareringen, tullen och importmomsen. Vid DDP gör säljaren det, och köparen får varan förtullad och klar.

**Vad är skillnaden mellan FCA och EXW?**

Vid EXW ställer säljaren bara fram varan i sin lokal, och köparen sköter lastning och exportklarering. Vid FCA klarerar säljaren varan för export och lämnar den till köparens transportör, lastad om leveransen sker hos säljaren. FCA är därför oftast det bättre valet när köparen inte själv kan sköta exporten från säljarens land.

**Vad är skillnaden mellan EXW och DDP?**

EXW (Ex Works) lägger nästan allt ansvar på köparen: du hämtar varorna hos säljaren och står för transport, risk och tull. DDP (Delivered Duty Paid) är motsatsen. Säljaren levererar ända fram, betald och förtullad, och köparen tar över först vid leverans.

**Gäller Incoterms 2010 fortfarande?**

Bara om avtalet säger det. Incoterms gäller när parterna hänvisar till dem, och parterna väljer själva vilken version. Skriv därför alltid ut versionen, till exempel FCA Göteborg Incoterms 2020. Saknas versionen kan det uppstå tvist om vilken som avses.

**Kommer det en ny version av Incoterms?**

Incoterms 2020 gäller, och ICC har inte satt något datum för nästa utgåva. Reglerna har hittills reviderats ungefär vart tionde år, med versioner 2000, 2010 och 2020.

**Påverkar Incoterms priset?**

Ja, indirekt. En term där säljaren står för mer av transport, försäkring och tull ger normalt ett högre pris, men färre dolda kostnader för dig. Därför bör du jämföra priser mot samma Incoterm.

---

## Beställningspunkt och säkerhetslager, så räknar du rätt

Källa: https://fluit.se/kunskap/inkop/bestallningspunkt-och-sakerhetslager
Ämne: Inköp
Uppdaterad: 2026-07-30

Beställningspunkten är den lagernivå där en ny order måste läggas för att varan ska hinna fram innan lagret tar slut. Den räknas som förbrukningen under ledtiden plus säkerhetslagret, alltså bufferten som täcker att efterfrågan blir högre eller leveransen senare än väntat. Båda nivåerna behöver räknas om mot faktisk historik för att hålla.

Det finns två sätt att ha fel om inköpstiming. För sent ger tomma hyllor och tappade order. För tidigt binder kapital och proppar lagret. Var den rätta tidpunkten ligger styrs av beställningspunkt, säkerhetslager och ledtid, och de går att räkna ut.

## Ledtid: hur länge tar leveransen?

**Ledtiden** är tiden från att du lägger en [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder) tills varan står på hyllan, redo att användas. Den rymmer leverantörens hantering, transporten och din egen [inleverans](/kunskap/inkop/inleverans-och-godsmottagning). Är ledtiden tio dagar måste du beställa minst tio dagars förbrukning innan lagret tar slut.

## Säkerhetslager: bufferten mot det oväntade

Verkligheten håller sig sällan till snittet. Efterfrågan kan rusa och leveransen kan dröja. **Säkerhetslagret** är den buffert du håller för att inte stå tomhänt när det händer.

En enkel formel:

```
Säkerhetslager = genomsnittlig dagsförbrukning × antal buffertdagar
```

Säljer du i snitt 20 enheter per dag och vill vara skyddad i 5 extra dagar blir säkerhetslagret 100 enheter. Ju mer efterfrågan och ledtid svänger, desto större behöver bufferten vara.

## Beställningspunkt: tröskeln som säger "köp nu"

**Beställningspunkten** (orderpunkten) är den lagernivå där du ska lägga en ny order för att hinna fylla på innan lagret når säkerhetslagret. Formeln knyter ihop de tre begreppen:

```
Beställningspunkt = (dagsförbrukning × ledtid i dagar) + säkerhetslager
```

Med 20 enheter per dag, 10 dagars ledtid och 100 enheters säkerhetslager:

```
Beställningspunkt = (20 × 10) + 100 = 300 enheter
```

När saldot når 300 är det dags att beställa. Under de tio dagar leveransen tar förbrukar du 200 enheter och landar på 100, alltså säkerhetslagret, precis när påfyllningen kommer in.

## Från tröskel till beställningsförslag

Att hålla reda på beställningspunkten för hundratals artiklar för hand är ohållbart. Det är den sortens räknande som MRP, materialbehovsplanering, gör åt dig.

Fluits [MRP-motor](/funktioner/mrp) väger in efterfrågan, lagernivåer, ledtider och säkerhetslager och lägger fram **beställningsförslag**: konkreta rekommendationer om vad, hur mycket och när du bör köpa. Den flaggar också för saker som saknad leverantör, saknad ledtid, nivå under säkerhetslager och brådskande order. Du godkänner förslagen och gör om dem till färdiga inköpsorder.

Skillnaden mellan en beställningspunkt och ett beställningsförslag är alltså skillnaden mellan att själv bevaka tröskeln och att få den bevakad åt dig.

### Vanliga frågor

**Vad är en beställningspunkt?**

Beställningspunkten är den lagernivå där du behöver lägga en ny inköpsorder för att hinna fylla på innan lagret tar slut. Den beräknas som förbrukning under ledtiden plus säkerhetslager.

**Hur räknar man ut säkerhetslager?**

Säkerhetslagret är en buffert mot variation i efterfrågan och ledtid. En enkel metod är att ta den genomsnittliga dagsförbrukningen gånger det antal extra dagar du vill vara skyddad. Mer avancerade metoder väger in hur mycket efterfrågan och ledtid varierar.

**Vad är skillnaden mellan beställningspunkt och beställningsförslag?**

Beställningspunkten är en tröskel, alltså en nivå. Ett beställningsförslag är den konkreta rekommendationen som ett system genererar när lagret når eller passerar tröskeln, ofta med förslag på kvantitet, leverantör och tidpunkt.

---

## Leverantörshantering: välj rätt och följ upp

Källa: https://fluit.se/kunskap/inkop/leverantorshantering
Ämne: Inköp
Uppdaterad: 2026-07-30

Leverantörshantering är arbetet med att välja leverantörer, hålla deras uppgifter ordnade och följa upp hur de faktiskt presterar. Grunden är en leverantörskatalog där leverantörens artikelnummer, priser och villkor är mappade mot dina egna artiklar, så att rätt uppgifter följer med automatiskt när en inköpsorder skapas.

Dina leverantörer avgör en stor del av vad inköpen kostar, hur säkert det levereras och vilken kvalitet du får. **Leverantörshantering** handlar om att välja rätt leverantörer, hålla deras uppgifter ordnade och följa upp hur de faktiskt presterar.

## Leverantörskatalog och artikelmappning

Grunden är en **leverantörskatalog**: en förteckning där leverantörernas produkter, artikelnummer, priser och villkor är mappade mot dina egna artiklar.

Med katalogen på plats följer rätt pris och artikelnummer med automatiskt när du skapar en [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder). Du slipper bläddra i prislistor och skriva av artikelnummer för hand. I Fluit importerar och matchar du leverantörers produktdata mot dina artiklar och håller inköpspriserna aktuella utan att pilla manuellt.

**Artikelmappningen**, kopplingen mellan leverantörens artikelnummer och ditt eget, är det som gör att leverantörens prislistor och [orderbekräftelser](/kunskap/inkop/orderbekraftelse-vs-inkopsorder) tolkas rätt av sig själva.

Ger du leverantören en egen inloggning kan den föreslå nya priser och villkor direkt i en [leverantörsportal](/kunskap/inkop/leverantorsportal) i stället för att skicka en uppdaterad prislista som ska matas in för hand.

## Flera leverantörer för samma vara

Många artiklar köps från mer än en leverantör. Det ger dig förhandlingsläge och en backup om en leverantör får problem. Då vill du veta, per artikel, vem som är förstahandsval, vilka priser som gäller och vilka ledtider du kan räkna med. Samma uppgifter använder [MRP-motorn](/funktioner/mrp) när den föreslår vad som ska köpas och från vem.

## Villkor som styr förväntan

Varje leverantörsrelation bär på sina villkor: [Incoterms](/kunskap/inkop/incoterms-forklarade), leveranstid, betalningsvillkor och valuta. I Fluit sätter du dem per leverantör och order, och köp i utländsk valuta hålls rätt med automatiska växelkurser.

## Uppföljning: bedöm leverantören på fakta

En leverantör är ungefär så bra som den senaste leveransen. Därför är uppföljningen kärnan i leverantörshantering. Efter varje order finns det några saker värda att titta på:

- **Pris**: stämde fakturan mot det avtalade priset på ordern?
- **Ledtid**: höll leverantören utlovat leveransdatum?
- **Kvantitet och kvalitet**: kom rätt mängd, och felfritt gods, vid [inleveransen](/kunskap/inkop/inleverans-och-godsmottagning)?

Ligger order, orderbekräftelse, inleverans och faktura i samma system faller den uppföljningen ut nästan av sig själv. [Three-way matching](/kunskap/inkop/three-way-matching) ger utfallet på pris och antal, och avvikelser mot bekräftade datum visar hur pålitliga leveranserna är. Nästa gång du ska välja leverantör har du då riktiga siffror att luta dig mot, inte en känsla.

### Vanliga frågor

**Vad är en leverantörskatalog?**

En leverantörskatalog är en strukturerad förteckning över leverantörers produkter med deras artikelnummer, priser och villkor, mappade mot dina egna artiklar. Den gör att rätt pris och artikelnummer automatiskt följer med när du skapar en inköpsorder.

**Vad är artikelmappning?**

Artikelmappning kopplar leverantörens artikelnummer till ditt eget artikelnummer för samma vara. Det gör att du kan ta emot leverantörens prislistor och orderbekräftelser och automatiskt veta vilken av dina artiklar de avser.

**Hur bedömer man en leverantör?**

Genom att följa upp pris, ledtid, leveranssäkerhet och kvalitet över tid. Stämde priset mot ordern? Höll leverantören utlovat datum? Kom rätt kvantitet och felfritt gods? Den historiken blir underlag för framtida leverantörsval.

---

## Ramavtal och avrop

Källa: https://fluit.se/kunskap/inkop/ramavtal-och-avrop
Ämne: Inköp
Uppdaterad: 2026-08-07

Ett ramavtal är en överenskommelse som låser pris, villkor och volym för en period, utan att i sig utlösa någon leverans. Leveranserna sker i stället genom avrop: enskilda order som hämtar hem delar av den avtalade volymen till det avtalade priset. Systemet behöver därför hålla isär avtalad volym, avropad volym och kvarvarande restvolym.

**Ett ramavtal förhandlas en gång och används många.** Det låser pris, villkor och ofta en volym för en period, men beställer ingenting i sig. Varorna hämtas hem genom **avrop**: enskilda order som pekar tillbaka på avtalet.

Uppdelningen är hela poängen. Priset behöver inte förhandlas per leverans, och volymen behöver inte tas hem på en gång.

## Vad avtalet respektive avropet bär

| | Ramavtal | Avrop |
| --- | --- | --- |
| Pris | Ja, avtalat | Hämtas från avtalet |
| Villkor | Ja | Hämtas från avtalet |
| Volym | Avtalad total | Det som tas hem nu |
| Leveransdatum | Nej | Ja |
| Utlöser leverans | Nej | Ja |

Att avropet hämtar pris från avtalet är mer än en bekvämlighet. Det är den enda mekanism som garanterar att det förhandlade priset faktiskt används, i stället för att någon råkar lägga en vanlig order till listpris.

## De tre talen som måste hållas isär

Ett ramavtal som följs upp behöver tre volymtal per rad:

1. **Avtalad volym**: vad som förhandlats.
2. **Avropad volym**: vad som beställts hittills.
3. **Restvolym**: skillnaden, alltså vad som återstår att ta hem.

Följer man bara det första och det andra går det att avropa förbi taket utan att någon märker det förrän avstämningen. Följer man inget av dem har avtalet i praktiken bara ett pris, inte en volym.

Ofta behövs ett fjärde och femte tal också: levererad och fakturerad volym. De skiljer sig från den avropade så snart något ligger i restorder.

## Var det brukar gå fel

**Giltighetstiden glöms bort.** Avtalet löper ut, men ordrarna fortsätter läggas med gamla priser. Antingen fakturerar leverantören listpris och ingen märker det, eller så fakturerar de avtalspriset och du får en obehaglig förhandling nästa år.

**Min- och maxvolym per avrop ignoreras.** Många avtal har gränser per avrop. Utan kontroll i systemet upptäcks överträdelsen när fakturan kommer.

**Prisrevisionen missas.** Avtal med indexklausul eller årlig revision behöver nya priser vid rätt datum, inte när någon råkar tänka på det.

## Ramavtal åt båda hållen

Begreppet används både mot leverantör och mot kund. Mot leverantör låser du ditt inköpspris. Mot kund låser du ditt försäljningspris och binder upp en volym som kan användas i [planeringen](/kunskap/produktion/produktionsplanering).

Det andra fallet är det som ofta saknas i mindre system. En kund som avropar mot ett årsavtal ska få avtalspriset automatiskt, och den avropade volymen ska räknas av mot avtalet.

## I ett system

Mot leverantör håller [inköpsramavtalet](/funktioner/inkopsramavtal) pris och volym per artikel över perioden. En avropsplan lägger ut volymen i omgångar, till exempel per kvartal, och en bekräftad rad räknas som inkommande leverans redan i MRP-beräkningen. Är avtalet aktivt får varje inköpsorder mot leverantören avtalspriset automatiskt, och orderraden visar vilket avtal som satte det.

Mot kund håller [ramavtalet](/funktioner/ramavtal) samma sak åt andra hållet: rader med avtalad kvantitet, avtalat styckpris i både avtalsvaluta och basvaluta, samt min- och maxkvantitet per avrop. Per rad följs beställd, levererad och fakturerad kvantitet, vilket ger restvolymen utan att någon för ett eget kalkylblad.

Båda avtalstyperna har ett statusflöde, så att ett utkast går att arbeta med innan det aktiveras och ett utgånget avtal slutar användas i prissättningen. Priset från ett kundavtal går in i samma [prisberäkning](/kunskap/order/prislistor-i-b2b) som prislistor och rabattregler, med avtalet högst i prioritet.

### Vanliga frågor

**Vad är ett ramavtal?**

Ett avtal som fastställer pris, villkor och ofta en volym för en bestämd period, utan att beställa något direkt. Det ger båda parter förutsägbarhet: köparen ett känt pris, säljaren en känd volym att planera för.

**Vad är ett avrop?**

En enskild beställning mot ett befintligt ramavtal. Avropet anger antal och leveransdatum, medan pris och villkor hämtas från avtalet. Det är avropet som utlöser leverans, inte ramavtalet.

**Vad händer om den avtalade volymen inte avropas?**

Det beror på avtalet. Ibland är volymen ett åtagande med prisjustering eller ersättning om den inte nås, ibland en uppskattning utan bindande verkan. Skillnaden bör framgå av avtalet och inte av vad parterna trodde.

**Kan ett avrop överstiga avtalad volym?**

Om avtalet tillåter det. Många avtal har en maximivolym per avrop eller totalt, och då ska systemet hindra eller varna. Utan den kontrollen upptäcks överavrop först vid avstämningen, när priset redan är fakturerat.

---

## Leverantörsportal: så sköter leverantören sitt eget

Källa: https://fluit.se/kunskap/inkop/leverantorsportal
Ämne: Inköp
Uppdaterad: 2026-09-08

En leverantörsportal är en inloggad självbetjäningsyta där en leverantör sköter sina egna inköpsordrar, artikeluppgifter och företagsinformation utan att mejla er. I Fluit bekräftar leverantören ordrar, föreslår nya priser och villkor, aviserar leveranser och skickar meddelanden, allt kopplat till samma data som ert eget inköpssystem.

En leverantör som ska bekräfta en order, föreslå ett nytt pris eller berätta att godset är på väg gör det oftast som mejl: någon läser det, letar upp rätt inköpsorder och skriver in det för hand. En **leverantörsportal** är en inloggad yta där leverantören gör det själv, direkt mot samma data som ert inköpssystem använder.

## Vad leverantören faktiskt kan göra

- **Inköpsordrar.** Se sina order, bekräfta dem, och ladda ner ordern som PDF på sitt eget språk.
- **Mina artiklar.** Se sina artikelnummer, inköpspriser, minsta orderkvantitet och avsändningstid mot era, och föreslå nya värden.
- **Företagsuppgifter.** Uppdatera adress, telefon, e-post för order, webbplats och kontaktpersoner själv.
- **Meddelanden.** Skriva till er direkt på inköpsordern, eller på en allmän tråd för frågor som inte hör till en specifik order.
- **Leveransavisering.** Tala om att gods är på väg, med transportslag, spårningsnummer och beräknad ankomst.

## Förslag går aldrig direkt på priset

Föreslår leverantören ett nytt pris eller en ny avsändningstid skrivs det **inte** på leverantörsraden direkt. Förslaget hamnar i en katalog av typen Leverantörsportal, samma slags mellanlager som en produktfeed använder, och blir gällande först när en inköpare granskar det och trycker **Applicera**. Inköparen kan också avvisa förslaget med en motivering, som leverantören ser och kan rätta utifrån.

Samma försiktighet gäller leveransavisering: en avisering är ett besked, inte en inleverans. Kvantiteten reserveras som "på väg" på inköpsorderns rader, men ingenting bokas in i lagret förrän godset faktiskt tas emot hos er. En leverantör kan därför aldrig avisera mer än det som återstår att skicka på ordern.

## Så ger ni en leverantör åtkomst

Öppna **Inställningar → Leverantörer → *leverantören* → Kontakter**. Kolumnen Portalåtkomst visar om kontakten redan har en inloggning, och knappen **Ge åtkomst** kräver bara att kontakten har en e-postadress, eftersom adressen blir användarnamnet.

Leverantörens roller är egna och skiljer sig från kundrollerna: **Läsare**, **Administratör**, **Orderhanterare** och **Produktionsrapportör**, i stället för Beställare, Godkännare och Ekonomi som gäller kundkontakter. Att skapa en inloggning, ändra roll eller stänga av den kräver TenantAdmin.

## Avvikelser går till rätt person automatiskt

Bekräftar leverantören en order med annan kvantitet, annat pris, eller ett senare leveransdatum än ni bad om, går ett mejl till leverantörens ansvariga inköpare med det ändrade värdet markerat. Ämnesraden säger redan **Bekräftad med avvikelse**, och inköpslobbyn samlar raderna i en egen ruta så att ingen avvikelse hänger kvar obemärkt i en lång orderlista.

## Vad som har ändrats

Portalen har byggts ut i flera steg under sommaren och hösten 2026. Det som tidigare krävde ett mejl eller ett sökande i inställningarna ligger nu där leverantören och inköparen faktiskt är:

| Funktion | Tidigare | Nu |
| --- | --- | --- |
| Ge en leverantör inloggning | Sökte upp kontakten under Inställningar → Extern portal | Knappen Ge åtkomst direkt på leverantörens kontaktflik |
| Vad leverantören kan göra | Bara se och bekräfta inköpsordrar | Även se sina artiklar, föreslå pris och villkor, sköta företagsuppgifter |
| Orderlistan i portalen | Hela orderhistoriken i ett svep, ingen sökning | Sök, statusfilter, öppna-order-läge och sidbrytning |
| Avvikelse vid bekräftelse | Upptäcktes om någon råkade läsa igenom bekräftelsen | Mejl till ansvarig inköpare, märkt redan i ämnesraden |
| Gods på väg | Väntade på ett mejl eller ringde själva | Leverantören aviserar leveransen direkt på ordern |

## Begränsningar

Leverantörsdokument och certifikat, bankuppgifter, staffelpriser och redigering av fraktsätt går inte att hantera i portalen. En skickad leveransavisering går inte att ändra eller dra tillbaka, bara komplettera i meddelandetråden på ordern. Kör ni Fortnox-synk med riktningen från Fortnox för leverantörer blir företagsuppgifterna låsta för redigering i portalen, eftersom de underhålls i ekonomisystemet i stället.

## I Fluit

[Fluit](/funktioner/kundportal) har en leverantörsportal på samma data som resten av inköpssystemet, så en bekräftad order, ett applicerat prisförslag eller en leveransavisering syns direkt hos er utan synk eller mellansteg. Behöver support eller en inköpare se exakt vad en leverantör ser, går det att öppna portalen som den kontakten, utan att fråga efter lösenordet: besöket syns i en banderoll och loggas.

### Vanliga frågor

**Vad är en leverantörsportal?**

En leverantörsportal är en inloggad yta där en leverantör själv ser och hanterar sina inköpsordrar, artikeluppgifter och kontaktinformation, i stället för att skicka det som mejl till er inköpare.

**Kan leverantören ändra priset direkt på inköpsordern?**

Nej. Ett förslag på nytt pris, minsta orderkvantitet eller avsändningstid hamnar i en kö som er inköpare granskar och applicerar eller avvisar. Öppna inköpsordrar påverkas aldrig av ett förslag som ligger och väntar.

**Behöver leverantören ett eget lösenord?**

Har ni en webbutik uppsatt kan kontakten bjudas in via mejl och sätta lösenordet själv. Har ni ingen webbutik anger eller genererar ni lösenordet i dialogen och förmedlar det, eftersom leverantörer inte har någon butik att bjudas in till.

**Ser leverantören våra andra leverantörer eller kunder?**

Nej. En leverantörskontakt når bara sina egna inköpsordrar och sin egen leverantörs uppgifter. En order utanför den räckvidden svarar systemet på precis som om den inte fanns.

---

## Punchout: så fungerar OCI och cXML

Källa: https://fluit.se/kunskap/inkop/punchout-oci-cxml
Ämne: Inköp
Uppdaterad: 2026-09-27

Punchout är en koppling där köparen startar i sitt eget inköpssystem, handlar i leverantörens webbutik och får tillbaka varukorgen som en rekvisition i inköpssystemet. Där går den genom köparens attest innan inköpsordern skickas till leverantören. De vanligaste standarderna är OCI, som kommer från SAP, och cXML, som Ariba tog fram.

**Med punchout handlar köparen i leverantörens webbutik utan att lämna sitt eget inköpssystem.** Köparen klickar på leverantören i inköpssystemet, till exempel SAP Ariba, Coupa eller Visma Proceedo, och hamnar inloggad i leverantörens butik med sina avtalade priser. När varukorgen är klar går den inte till kassan. Den skickas tillbaka till inköpssystemet, där den attesteras som vilket inköp som helst.

Båda parter får något de annars saknar. Köparen behåller sin attest, sin budgetkontroll och sina avtal på ett ställe. Leverantören visar aktuella priser, lagersaldon och produktval direkt, i stället för att skicka en katalogfil som är inaktuell när den läses in.

## Så går en punchout till

1. **Köparen startar i inköpssystemet** och väljer leverantören.
2. **Inköpssystemet öppnar leverantörens butik.** Det skickar med vem köparen är och vart varukorgen ska tillbaka.
3. **Köparen handlar i butiken** med sina egna priser, sitt sortiment och leverantörens aktuella lager.
4. **Varukorgen skickas tillbaka** till inköpssystemet i stället för att gå till kassan.
5. **Köparen attesterar internt.** Varukorgen är nu en rekvisition, och ingen order finns ännu hos leverantören.
6. **Inköpsordern skickas till leverantören** som ett eget meddelande, ofta dagar efter att varukorgen fylldes.

Steg 4 och 6 är två olika händelser, och det är den viktigaste skillnaden mot vanlig e-handel. Leverantören ser en varukorg som lämnar butiken, men vet inte om, eller när, den blir en order.

## OCI och cXML

| | OCI | cXML |
| --- | --- | --- |
| Ursprung | SAP | Ariba |
| Hur varukorgen skickas | Formulärfält via köparens webbläsare | XML-meddelande, också via webbläsaren |
| Inloggning | Användarnamn och lösenord i anropet | Delad hemlighet och parternas identiteter i meddelandet |
| Ordern | Ingår inte, skickas på annat sätt | Kan skickas som cXML (`OrderRequest`) |
| Bekräftelse, leveransavisering, faktura | Ingår inte | Kan skickas som cXML |
| Vanligt hos | SAP-baserade inköpssystem | Ariba, Coupa och många andra |

OCI är enklare att komma igång med, eftersom det bara handlar om att fylla och skicka ett formulär. cXML kräver mer men täcker hela flödet, och det är ofta det som avgör vilket av dem köparen kräver. Många inköpssystem stöder båda.

## Punchout jämfört med andra sätt att ta emot B2B-order

| Sätt | Vem håller sortimentet aktuellt | Köparens attest | Passar när |
| --- | --- | --- | --- |
| Punchout | Leverantören, i sin butik | I köparens inköpssystem | Köparen har ett inköpssystem och ett stort eller rörligt sortiment |
| Statisk katalog | Köparen läser in leverantörens katalogfil | I köparens inköpssystem | Sortimentet är litet och priserna ändras sällan |
| EDI | Ingen, EDI skickar dokument och inget sortiment | Före ordern, utanför EDI | Köparen vet redan vad som ska beställas, i stora volymer |
| Inloggad B2B-butik eller kundportal | Leverantören | Ingen, eller en attest i butiken | Köparen saknar inköpssystem |

Punchout och EDI konkurrerar inte. Punchout tar hand om urvalet och varukorgen, och EDI eller cXML tar ofta hand om ordern, orderbekräftelsen och fakturan som följer.

## Åt båda hållen

Samma teknik används från två håll, och ett företag som både köper och säljer möter ofta båda.

**Som leverantör** tar du emot köpare som kommer från sina inköpssystem. Butiken måste känna igen köparen som en kontakt hos rätt kund, visa den kundens priser och sortiment och skicka varukorgen tillbaka i det format köparen kräver. Sedan ska den inkommande ordern kunna matchas mot det köparen såg.

**Som köpare** går du själv ut till dina leverantörers butiker från ditt eget system. Varukorgen som kommer tillbaka ska bli rader på en inköpsorder, och leverantörens artikelnummer behöver matchas mot dina egna artiklar. Annars står raderna som fritext, och då fungerar varken lagerstyrning eller uppföljning.

## Var det brukar gå fel

**Priset hinner ändras.** Varukorgen bär ett pris, men ordern kommer först efter attesten. Ändrar leverantören priset under tiden finns två sanningar: priset köparen godkände och priset i butiken nu. Bestäm i förväg vilket som gäller och hur länge ett varukorgspris håller.

**Artikelnummer och enheter matchar inte.** Leverantören skickar sitt artikelnummer och sin enhet, köparens system förväntar sig sina. Styck, förpackning och kartong måste översättas, och ofta krävs en varuklassning som UNSPSC för att inköpssystemet ska kunna kontera raden.

**Ordern går inte att knyta till varukorgen.** Ordern kommer som ett separat meddelande, ibland med ändrade antal eller strukna rader. Utan en referens tillbaka till varukorgen blir den en order bland andra, och en konfigurerad produkt tappar sina val.

**Användaren är inte kunden.** I OCI delar ofta alla köpare hos en kund samma tekniska inloggning. Då vet leverantören vilket företag som handlar men inte vilken person, och det syns i orderhistorik och ansvar.

**Testet tar längre tid än bygget.** Varje köpare har sitt eget inköpssystem, med egna fältkrav och en testmiljö som ska godkännas innan produktion. Räkna med att varje ny kund är ett eget litet projekt, även när standarden är densamma.

### Vanliga frågor

**Vad är skillnaden mellan OCI och cXML?**

OCI skickar varukorgen tillbaka som formulärfält via köparens webbläsare och täcker bara själva punchouten. Ordern skickas på annat sätt, till exempel med EDI eller e-post. cXML är XML-meddelanden som kan täcka hela kedjan: sessionen, varukorgen, inköpsordern och ofta orderbekräftelse, leveransavisering och faktura.

**Är punchout samma sak som EDI?**

Nej. Punchout gäller urvalet, alltså att köparen handlar i leverantörens butik med aktuella priser och lagersaldon. EDI gäller dokumenten som följer, som order, orderbekräftelse och faktura. Många kopplingar använder båda: punchout för varukorgen och EDI eller cXML för ordern.

**Blir det en order när varukorgen skickas tillbaka?**

Nej. Varukorgen blir en rekvisition i köparens system. Ordern kommer först när köparen attesterat internt, ibland flera dagar senare, och skickas då som ett eget meddelande till leverantören.

**Vad är punchout på nivå 2?**

På nivå 1 hamnar köparen på leverantörens startsida och söker där. På nivå 2 finns leverantörens artiklar redan sökbara i inköpssystemets katalog, och en träff leder direkt till rätt produktsida i leverantörens butik. Köparen söker på ett ställe, men pris och tillgänglighet hämtas fortfarande från leverantören.

**När lönar sig punchout?**

När köparen har ett inköpssystem med attestflöde, köper återkommande från samma leverantör och sortimentet är för stort eller ändras för ofta för en statisk katalog. En köpare utan inköpssystem har mer nytta av en inloggad B2B-butik eller kundportal.

---

## Vad är ett WMS (Warehouse Management System)?

Källa: https://fluit.se/kunskap/lager/vad-ar-ett-wms
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

Ett WMS, Warehouse Management System eller lagerhanteringssystem, är mjukvaran som styr det fysiska arbetet i lagret. Affärssystemet vet att du har 200 enheter av en artikel; WMS:et vet var de står, vem som ska hämta dem och i vilken ordning. Det lägger till adressering ned till lagerplats, arbetsordning och kvittens via skanning.

Ett **WMS** (Warehouse Management System), på svenska **lagerhanteringssystem**, är mjukvaran som styr det fysiska arbetet i ett lager. Affärssystemet vet *att* du har 200 enheter av en artikel. WMS:et vet *var* de ligger, alltså på vilken hylla och i vilken zon, och i vilken ordning de ska plockas.

## Det här gör ett WMS

Ett WMS täcker hela flödet, från att gods kommer in tills det skickas ut:

1. **Inleverans och godsmottagning.** Du tar emot mot inköpsorder, kontrollerar kvantitet och styr godset till rätt plats.
2. **Inlagring (putaway).** Varorna placeras på rätt hyllplats utifrån platstyp och kapacitet.
3. **Plockning.** Systemet genererar plocklistor och plockrutter, ofta med streckkodsskanning som tar bort felplocken.
4. **Packning och utleverans.** Packa, väg och boka frakt.
5. **Inventering.** Räkna saldot löpande, till exempel med [ABC-cykelräkning](/kunskap/lager/abc-analys-lager).

## Hyllplatser och platstyper

Hjärtat i ett WMS är en strukturerad lagerkarta: zon, gång, ställ, nivå och position. Varje plats har en typ, som plock, bulk, mottagning, karantän eller retur. Typen styr hur varorna rör sig genom lagret. Det är det som gör att en ny medarbetare kan plocka rätt utan att kunna lagret utantill.

## Korrekt saldo och spårbarhet

Ett bra WMS håller saldot rätt och kan följa varje vara via serienummer eller batch. Det är avgörande när du ska göra återkallelser, hålla ordning på spårbarheten och värdera lagret enligt [FIFO eller FEFO](/kunskap/lager/fifo-fefo-lagervardering).

## När behöver du ett WMS?

Några tecken på att du vuxit ur Excel och det manuella jobbet:

- Du plockar fel, eller står och letar efter varor.
- Inventeringen tar dagar, och saldot stämmer ändå inte.
- Det tar lång tid att lära upp nya medarbetare.
- Du har flera lager eller lagerplatser att hålla reda på.

I Fluit ingår WMS-funktionerna i [lagersystemet](/funktioner/lager-och-logistik) och [WMS-appen](/funktioner/wms-app). Du får alltså hyllplatser, skanning och inventering utan att behöva integrera ett separat system. Så här ser [Fluits WMS-system](/wms-system) ut i sin helhet.

### Vanliga frågor

**Vad betyder WMS?**

WMS står för Warehouse Management System, på svenska lagerhanteringssystem. Det är mjukvaran som styr det fysiska arbetet i ett lager: var varorna ligger, hur de plockas och hur du håller saldot rätt.

**Vad är skillnaden mellan WMS och affärssystem?**

Ett affärssystem (ERP) hanterar hela verksamheten, alltså order, inköp, ekonomi och lagersaldo på en övergripande nivå. Ett WMS är specialiserat på det fysiska lagret med hyllplatser, plockrutter och streckkodsskanning. I moderna system ingår WMS-funktionerna i affärssystemet, så du slipper integrera två separata system.

**Behöver ett litet företag ett WMS?**

När antalet artiklar, lagerplatser och ordrar växer blir det manuella jobbet en flaskhals. Ett WMS lönar sig när du börjar tappa koll på var varorna finns, plockar fel eller lägger för mycket tid på inventering. Det gäller oavsett hur stort företaget är.

---

## WMS vs affärssystem (ERP): vad är skillnaden?

Källa: https://fluit.se/kunskap/lager/wms-vs-affarssystem
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

Ett affärssystem styr hela verksamheten mot en gemensam databas, medan ett WMS styr det fysiska arbetet i lagret. Affärssystemet svarar på hur mycket som finns och vad som är sålt, WMS:et på var varan står och i vilken ordning den ska plockas. Många bolag klarar sig länge på affärssystemets lagerdel innan platsstyrning behövs.

Begreppen **WMS** och [**affärssystem (ERP)**](/kunskap/affarssystem/vad-ar-ett-affarssystem) blandas lätt ihop, men de löser olika problem. Kort sagt: affärssystemet styr hela verksamheten, WMS:et styr det fysiska lagret. Ett tredje begrepp som ofta hamnar i samma diskussion är [orderhanteringssystem (OMS)](/kunskap/order/vad-ar-ett-orderhanteringssystem), som styr orderflödet.

## Vad skiljer dem åt?

| | Affärssystem (ERP) | WMS (lagerhanteringssystem) |
|---|---|---|
| Syfte | Styr hela bolaget: order, inköp, ekonomi, lager | Optimerar det fysiska lagerarbetet |
| Lagervy | Saldo per artikel och lagerställe | Exakt plats: zon, hylla, position |
| Typiska funktioner | Försäljning, inköp, fakturering, MRP | Inlagring, plockrutter, skanning, inventering |
| Användare | Hela organisationen | Lagerpersonal |

## Där de överlappar

Ett affärssystem håller alltid ett **lagersaldo**, annars kan det inte räkna på inköp, order och ekonomi. Frågan är hur djupt det går. Stannar det vid "antal per artikel", eller styr det också *var* varorna ligger och *hur* de plockas? Det senare är WMS-funktionalitet.

## Inbyggt WMS eller separat system?

Förr var WMS ett separat, specialiserat system som integrerades mot ERP:et. Men varje integration är en risk. Saldon glider isär, ordrar fastnar, och du betalar för två system i stället för ett.

Därför har moderna affärssystem, Fluit inräknat, **WMS-funktionerna inbyggda**: [hyllplatser och platstyper](/funktioner/lager-och-logistik), [mobil skanning](/funktioner/wms-app) och [inventering](/funktioner/inventering) i samma system som order och inköp. Hela uppsättningen finns beskriven på sidan om [Fluits WMS-system](/wms-system). För de flesta små och medelstora bolag är det både enklare och billigare än ett fristående WMS.

Behöver du ändå ett fristående WMS kan Fluit synka mot [Ongoing WMS](/funktioner/ongoing-wms). Det gäller två lägen: lagret drivs av en 3PL-partner som redan kör Ongoing, eller ni driver lagret själva men har krav som automation och avancerad plockstyrning som motiverar ett eget system för just lagret. I båda fallen är det ett aktivt val, inte något som beror på att affärssystemet saknar lagerfunktioner.

### Vanliga frågor

**Kan ett affärssystem ersätta ett WMS?**

Ja, om affärssystemet har riktiga WMS-funktioner inbyggda, alltså hyllplatser, plockrutter, streckkodsskanning och inventering. För många små och medelstora bolag är ett affärssystem med inbyggt lager både enklare och billigare än att driva ett separat WMS som måste integreras.

**När behöver man ett separat WMS?**

Ett fristående, specialiserat WMS lönar sig framför allt för mycket stora eller automatiserade lager med avancerade behov, som styrning av truckar, transportband eller komplexa plockstrategier. För de flesta SME-bolag räcker lagerfunktionerna i ett modernt affärssystem.

**Vad är risken med två separata system?**

Varje integration mellan ERP och WMS är en punkt där data kan glida isär. Saldon som inte stämmer, ordrar som fastnar och dubbel administration. Ett system med lagret inbyggt slipper den synkroniseringsrisken.

---

## ABC-analys i lager: så klassar du dina artiklar

Källa: https://fluit.se/kunskap/lager/abc-analys-lager
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

ABC-analys av lagret delar in artiklarna i tre klasser efter hur stor del av det totala förbrukningsvärdet de står för. A-artiklarna är de få som svarar för merparten av värdet, C-artiklarna de många som svarar för en liten del. Poängen är att styra klasserna olika: tät uppföljning där kapitalet finns, låg administration där det inte gör det.

**ABC-analys** är ett enkelt sätt att prioritera i lagret. Grundtanken är att alla artiklar inte är lika viktiga, och därför ska de inte styras lika. Genom att klassa artiklarna i **A**, **B** och **C** lägger du din tid och dina inköpskronor där de gör mest nytta.

## Paretoprincipen i lagret

ABC-analys bygger på **80/20-regeln** (Paretoprincipen): en liten andel av artiklarna står för en stor andel av värdet. Så här brukar det se ut:

- **A-artiklar.** Ungefär 20 procent av artiklarna, men runt 80 procent av värdet. Dina viktigaste varor.
- **B-artiklar.** Mellanskiktet, med måttlig betydelse.
- **C-artiklar.** Många artiklar, men liten andel av värdet.

## Så gör du analysen

1. Lista alla artiklar med **årlig förbrukning i kronor** (antal sålda gånger styckpris).
2. Sortera fallande på värde.
3. Summera uppifrån och sätt gränser, till exempel 80 procent på A, nästa 15 procent på B och sista 5 procent på C.

Gränserna är inte heliga. Anpassa dem efter din verksamhet.

## Vad du gör med klasserna

| Klass | Inventering | Säkerhetslager | Uppföljning |
|---|---|---|---|
| A | Räkna ofta (cykelräkning) | Noggrant beräknat | Tät |
| B | Räkna ibland | Måttligt | Periodisk |
| C | Räkna sällan | Generöst, beställ stora partier | Låg |

A-artiklarna får tät kontroll, så att du varken binder onödigt kapital eller riskerar att bli utan. C-artiklarna kan du köpa in mer sällan och i större kvantiteter. Det är helt enkelt inte värt administrationen att finstyra dem.

## ABC i praktiken

I Fluit kan du köra [ABC-inventering](/funktioner/inventering): cykelräkning klass för klass, där A-artiklarna räknas oftare än C. Klassningen är också ett bra underlag när du sätter [beställningspunkt och säkerhetslager](/kunskap/inkop/bestallningspunkt-och-sakerhetslager).

### Vanliga frågor

**Vad är ABC-analys?**

ABC-analys är en metod för att dela in lagrets artiklar i tre klasser efter betydelse. A-artiklarna står för störst andel av värdet eller omsättningen, C-artiklarna för minst. Tanken är att lägga mest styrning och uppföljning på de artiklar som betyder mest.

**Hur räknar man ut ABC-klasser?**

Sortera artiklarna efter årlig förbrukning i kronor (antal gånger styckpris), summera uppifrån och sätt gränser. Ofta hamnar man runt 80 procent av värdet på A, nästa 15 procent på B och sista 5 procent på C. Procentsatserna kan du anpassa efter din egen verksamhet.

**Vad är kopplingen till 80/20-regeln?**

ABC-analys bygger på Paretoprincipen, alltså 80/20-regeln: en liten andel av artiklarna står för en stor andel av värdet. Typiskt utgör cirka 20 procent av artiklarna runt 80 procent av lagervärdet, och det är A-artiklarna.

---

## Lagervärdering och plockprinciper: FIFO, FEFO och vägt genomsnitt

Källa: https://fluit.se/kunskap/lager/fifo-fefo-lagervardering
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

FIFO och FEFO styr i vilken ordning varor lämnar lagret. FIFO tar det som kom in först, FEFO det som går ut på datum först. För varor med hållbarhet är de sällan samma sak, eftersom ett sent inlevererat parti kan ha kortare hållbarhet. FIFO används dessutom som värderingsprincip i bokföringen, oberoende av plockordningen.

**FIFO** och **FEFO** är två principer för i vilken ordning varorna ska lämna lagret. FIFO används dessutom som värderingsprincip i bokföringen, men de två sakerna är oberoende: du kan värdera enligt FIFO utan att plocka fysiskt i exakt den ordningen, och FEFO är en ren plockprincip utan bokföringsmotsvarighet.

## FIFO, First In First Out

Den vara som kom in **först** plockas och säljs **först**. FIFO är standard i de flesta verksamheter, eftersom det speglar ett naturligt varuflöde och minskar risken att varor blir liggande och föråldras.

I bokföringen innebär FIFO att de äldsta inköpspriserna används som kostnad när varor säljs, medan det kvarvarande lagervärdet speglar de senaste priserna.

## FEFO, First Expired First Out

FEFO utgår inte från *när varan kom in* utan från **utgångsdatum**. Den vara som går ut snabbast plockas först, även om den kom in senare. FEFO är ett måste för:

- Livsmedel och färskvaror
- Läkemedel och kosmetika
- Kemikalier och annat med bäst-före- eller utgångsdatum

## LIFO, och varför det sällan används

LIFO (Last In, First Out) plockar den senast inkomna varan först. Det är **inte tillåtet** för lagervärdering enligt svensk redovisning (eller IFRS), och används i praktiken inte i svenska bolag.

## Vägt genomsnittspris: det vanligaste i praktiken

För själva värderingen är **vägt genomsnittspris** den vanligaste metoden i svenska SME-system: varje inleverans räknas in i ett genomsnittligt anskaffningsvärde per artikel, och det genomsnittet används som kostnad vid försäljning. Metoden är enklare att hantera systemmässigt än strikt FIFO-värdering och ger ett jämnare kostnadsutfall när inköpspriserna varierar. Både FIFO och vägt genomsnitt är tillåtna enligt svensk redovisning. Välj en metod och var konsekvent.

## Vad det betyder i praktiken

| Princip | Plockordning | Används för |
|---|---|---|
| FIFO | Äldst in plockas först | Generellt, minskar inkurans |
| FEFO | Kortast hållbarhet först | Färskvaror, läkemedel |
| LIFO | Senast in plockas först | Ej tillåtet i SE |

Plockar du i fel ordning får du [inkurans](/kunskap/lager/vad-ar-inkurans), alltså varor som blir för gamla att sälja. I Fluit kan du sätta **plockprioritet** per plats för att styra FIFO- och FEFO-flöden, och spåra varor via batch med utgångsdatum.

### Vanliga frågor

**Vad är skillnaden mellan FIFO och FEFO?**

FIFO utgår från när varan kom in, så att äldst plockas först. FEFO (First Expired, First Out) utgår i stället från utgångsdatum, så att den vara som går ut snabbast plockas först, oavsett när den kom in. FEFO används för färskvaror, läkemedel och annat med bäst-före-datum.

**Hur påverkar FIFO lagervärdet?**

Med FIFO ligger de äldsta, ofta billigare, inköpspriserna kvar som kostnad när du säljer, medan lagervärdet speglar de senaste inköpspriserna. Vid stigande priser ger FIFO därför ett högre lagervärde och en lägre kostnad än LIFO.

---

## Inkurans: vad det är och hur du minskar det

Källa: https://fluit.se/kunskap/lager/vad-ar-inkurans
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

Inkurans är den värdeminskning som uppstår när varor i lagret inte längre kan säljas till fullt pris. Orsaken är sällan dramatisk: en modell ersätts, en säsong tar slut, ett datum närmar sig, eller artikeln slutade helt enkelt säljas medan lagret fylldes på som förut. Bokföringsmässigt hanteras det som en nedskrivning enligt lägsta värdets princip.

**Inkurans** är ett av lagrets tysta värdeläckage: varor som står kvar i hyllan men som tappat värde eller blivit omöjliga att sälja till fullt pris. Pengarna är redan utlagda, men intäkten kommer aldrig.

## Vad räknas som inkurans?

- **Föråldrade varor.** Modet eller tekniken har gått vidare.
- **Utgångna varor.** Bäst-före- eller utgångsdatum har passerats.
- **Skadade varor.** Trasigt eller defekt gods.
- **Långsamrörliga artiklar.** Varor som inte sålts på länge och sannolikt inte kommer att säljas.

## Inkurans i bokföringen

Vid bokslut ska lagret värderas till det **lägsta av anskaffningsvärde och nettoförsäljningsvärde**. Har varornas verkliga värde sjunkit ska lagret skrivas ned, och det är inkuransavdraget.

Skattemässigt finns en schablon: lagret får tas upp till **97 procent av det samlade anskaffningsvärdet** (97-procentsregeln). Schablonen gäller i så fall hela lagret. Den kan inte kombineras med individuell nedskrivning av enskilda artiklar. Vill du i stället skriva ned specifika varor måste du kunna visa den faktiska värdeminskningen, artikel för artikel.

## Så minskar du inkurans

1. **Plocka i rätt ordning.** [FIFO och FEFO](/kunskap/lager/fifo-fefo-lagervardering) ser till att äldsta varan går först.
2. **Håll rätt lagernivåer.** [Beställningspunkt och säkerhetslager](/kunskap/inkop/bestallningspunkt-och-sakerhetslager) hindrar att du bygger upp överlager.
3. **Följ upp det långsamrörliga.** [ABC-analys](/kunskap/lager/abc-analys-lager) lyfter fram artiklar som binder kapital utan att sälja.
4. **Agera tidigt.** Rea ut eller kör kampanj innan varan blir helt osäljbar.

I Fluit ger [saldo och spårbarhet](/funktioner/lager-och-logistik) dig koll på liggtid och batch-datum, så att inkuransen syns innan den blir en bokslutskostnad.

### Vanliga frågor

**Vad betyder inkurans?**

Inkurans är när varor i lager har sjunkit i värde eller blivit osäljbara, på grund av ålder, skador, utgånget datum eller att de blivit omoderna. Lagret är då värt mindre än vad det bokförts till, och mellanskillnaden är en kostnad.

**Hur fungerar inkuransavdrag?**

Vid bokslut värderas lagret till det lägsta av anskaffningsvärde och nettoförsäljningsvärde. Skattemässigt finns dessutom en schablon: lagret får tas upp till 97 procent av det samlade anskaffningsvärdet (97-procentsregeln). Väljer du schablonen gäller den hela lagret. Den kan inte kombineras med individuell nedskrivning av enskilda artiklar.

**Hur minskar man inkurans?**

Genom att plocka i rätt ordning (FIFO eller FEFO), hålla rätt lagernivåer med beställningspunkt och säkerhetslager, följa upp långsamrörliga artiklar via ABC-analys och agera tidigt med kampanjer eller utförsäljning innan varorna blir osäljbara.

---

## Inventering av lager: så gör du, steg för steg

Källa: https://fluit.se/kunskap/lager/inventering-av-lager
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

Inventering av lager är att räkna det fysiska lagret och stämma av resultatet mot saldot i systemet. Arbetet går i fem steg: avgränsa vad som ska räknas, frys rörelserna, räkna blint, granska differenserna och godkänn justeringen. Det avgörande steget är granskningen, eftersom det är där orsaken bakom avvikelsen går att hitta.

Räkningen är den enkla delen av en inventering. Det som avgör om dagen var värd sitt pris är vad som händer med differenserna efteråt, och det är också där de flesta inventeringar tappar sitt värde: siffrorna förs in, saldot justeras, och nästa år står samma artiklar fel igen.

En inventering har två mottagare med olika behov. Ekonomiavdelningen vill ha ett verifierat lagervärde till bokslutet. Lagret vill ha ett saldo som går att lita på när en order ska lovas på tisdag. Den första behöver ett korrekt slutresultat, den andra behöver veta varför det blev fel.

## 1. Avgränsa vad som ska räknas

Skriv ned omfånget innan någon börjar: vilka lager, vilka zoner, vilka artikelgrupper. Utan en tydlig gräns går resultatet inte att stämma av, eftersom en artikel som saknas i listan lika gärna kan ha legat utanför omfånget som ha missats.

Fyra saker brukar vara oklara och bör bestämmas i förväg:

- **Gods i transit.** Varor som lämnat leverantören men inte kommit in räknas inte, men ska stämmas av mot inleveranserna.
- **Kundägt eller konsignationslager.** Finns fysiskt hos dig men tillhör någon annan. Räkna det separat, och ta inte med det i lagervärdet.
- **Reklamationer och returer.** Gods som väntar på beslut ligger ofta i ett hörn utan lagerplats. Bestäm om det ingår.
- **Kasserat men inte utbokat.** Det som står kvar på pallen fast det är skrotat ska bort ur saldot, inte räknas in i det.

## 2. Frys rörelserna

Ett saldo går bara att stämma av mot en tidpunkt. Plockas det medan räkningen pågår mäter du mot ett rörligt mål, och differenserna blir omöjliga att tolka.

Full frysning av hela lagret krävs bara vid full inventering. Räknar du zon för zon räcker det att stänga zonen som räknas. Gods som kommer in under tiden läggs på en märkt yta utanför omfånget och registreras när räkningen är klar. Detsamma gäller plock som måste ut: dokumentera vad som togs och från vilken plats, så att raden går att korrigera i efterhand.

## 3. Räkna blint

Vid **blindräkning** ser räknaren inte det förväntade antalet. Det låter som en detalj men ändrar resultatet: den som vet att det ska vara 48 slutar räkna vid 48. Effekten är inte slarv utan hur uppmärksamhet fungerar, och den är störst i höga staplar och stora kollin, alltså precis där felen kostar mest.

Några saker gör räkningen mer tillförlitlig:

- **Sortera underlaget på lagerplats.** Listan ska följa gången man går, inte artikelnummerordningen. En hylla räknas klart innan nästa börjar, och en missad plats syns direkt.
- **Lämna tomma rader sist.** De är till för varor som står på platsen men inte finns på listan. Ofta är det där förklaringen till differenserna sitter.
- **Skanna hellre än att bocka av.** Streckkoden tar bort artikelförväxlingen, som annars är den vanligaste orsaken till att två artiklar avviker med exakt samma antal åt olika håll.

Underlaget gör du i verktyget [inventeringslista](/verktyg/inventeringslista), antingen från en Excelexport ur affärssystemet eller som en blank mall att fylla i för hand.

## 4. Granska differenserna

Nu börjar det som faktiskt är värt tid. Ställ upp räknat mot system, räkna ut avvikelsen i både antal och kronor, och sortera på belopp.

Två mått säger olika saker. **Nettodifferensen** är summan med tecken och visar hur lagervärdet påverkas. **Bruttodifferensen** är summan av avvikelsernas belopp utan tecken och visar hur mycket som låg fel. Ett lager där femton artiklar ligger över och fjorton under kan ha en nettodifferens nära noll och ändå ha nästan trettio felaktiga saldon. Följer du bara nettot ser processen bättre ut än den är.

[Inventeringsdifferens-verktyget](/verktyg/inventeringsdifferens) räknar fram båda talen plus lagerprecisionen, och rangordnar artiklarna efter avvikelse i kronor.

Leta sedan efter mönster i stället för att beta av rad för rad. De vanligaste orsakerna lämnar tydliga spår:

| Mönster i differensen | Trolig orsak |
|---|---|
| Stabilt minus på artiklar som plockas ofta | Plockat men inte avrapporterat |
| Två artiklar avviker lika mycket åt olika håll | Fel plockplats, eller förväxlade artiklar |
| Avvikelsen är en jämn multipel av förpackningen | Enhetsförväxling: styck mot förpackning |
| Ett engångshopp som sedan ligger kvar | Inleverans registrerad på fel antal |
| Utspritt minus utan annan förklaring | Svinn |

## 5. Godkänn och justera

Avvikelser över en viss gräns ska räknas om innan de godkänns, och omräkningen ska göras av någon annan än den som räknade första gången. Sätt gränsen i kronor snarare än i procent: tio procents avvikelse på en artikel för sju kronor är inte värd en andra vända, medan två procent på ett dyrt kullager är det.

Godkännandet bör ligga hos någon annan än räknaren. Det är inte misstroende utan samma princip som gäller i övriga ekonomiflöden, och den enda anledningen till att differensen får ett spår som går att följa upp.

Notera orsaken till varje bekräftad avvikelse. Utan den noteringen är nästa inventering en upprepning av den här.

## Bokslut, revisor och inventeringsintyg

Varulagret ska vara inventerat vid räkenskapsårets slut, och räkningen ska dokumenteras. Lagen om inventering av varulager för inkomstbeskattningen säger att den som är bokföringsskyldig ska inventera varje post i lagret och upprätta en förteckning där posten tas upp med sitt värde. På förteckningen ska sedan **den skattskyldige** teckna en på heder och samvete avgiven försäkran om att ingen lagertillgång har undantagits vid inventeringen.

Det är den försäkran som i dagligt tal kallas **inventeringsintyg**. Notera vem som skriver under: ansvaret ligger på den skattskyldige, inte på den i lagret som höll i räkningen. Förteckningen ingår i räkenskapsmaterialet och ska sparas.

Värderingen är ett eget steg efter räkningen. Huvudregeln är lägsta värdets princip, alltså det lägsta av anskaffningsvärdet och nettoförsäljningsvärdet, med [inkurans](/kunskap/lager/vad-ar-inkurans) hanterad artikel för artikel. Vilken metod som gäller för just ditt lager, och hur schablonregeln får användas, är en fråga för din redovisningskonsult. Skatteverket har de aktuella reglerna.

Är revisorn på plats vid räkningen gör hen egna stickprov. Det underlättar om räknelistorna är daterade, sorterade på plats och går att koppla till de justeringar som sedan bokförts.

## Alternativet: räkna löpande i stället

Den stora årliga inventeringen har ett inbyggt problem. En differens som upptäcks i december kan lika gärna ha uppstått i februari, och då finns ingen spårbarhet kvar. Orsaken går inte att fastställa, så justeringen blir det enda som händer.

[Rullande inventering](/ordlista/cykelrakning), även kallad cykelräkning, delar upp arbetet i stället. En liten del av sortimentet räknas åt gången, löpande under året, med frekvensen satt efter artikelns betydelse. En vanlig indelning bygger på [ABC-analys](/kunskap/lager/abc-analys-lager): A-artiklarna räknas varje kvartal, B-artiklarna halvårsvis och C-artiklarna en gång om året.

Fördelen är att felen hittas nära i tiden, när det fortfarande går att se vad som hände. Lagret slipper dessutom stå still, och räkningen kan läggas i luckor när det ändå är lugnt. För de flesta lager med rimlig precision fungerar löpande räkning som underlag också vid bokslutet, förutsatt att täckningen är dokumenterad och justeringarna godkända.

## I Fluit

Inventeringen läggs upp med ett omfång: hela lagret, en plats, en kategori, en ABC-klass för cykelräkning, ett slumpmässigt stickprov, eller en enskild artikel som räknas om direkt i appen. Räkningen görs med skanner i WMS-appen, med blindräkning påslagen.

Variansen visas per rad i både antal och belopp, och summeras till antal avvikande rader och total varians i kronor. Lagersaldot ändras först när inventeringen godkänts i ett eget steg, och den som godkände sparas på inventeringen. Se [inventering i Fluit](/funktioner/inventering).

### Vanliga frågor

**Hur ofta ska man inventera lagret?**

Minst en gång per räkenskapsår, eftersom varulagret ska vara inventerat vid bokslutet. Många räknar oftare än så, men då som löpande cykelräkning av delar av sortimentet i stället för fler heldagsstopp. Ett lager med låg precision behöver räkna tätare tills orsakerna till differenserna är åtgärdade.

**Måste lagret stängas under inventeringen?**

Rörelserna måste vara frysta för det som räknas, men inte nödvändigtvis för hela lagret. Räknas en zon i taget kan resten av verksamheten rulla vidare, förutsatt att gods som kommer in under tiden läggs på en märkt yta utanför omfånget och registreras först efteråt.

**Vad är blindräkning?**

Att den som räknar inte ser det förväntade antalet. Syns siffran blir räkningen lätt en bekräftelse av den i stället för en mätning av verkligheten. Blindräkning ger fler differenser att gå igenom, vilket är avsikten: en avvikelse som inte hittas vid räkningen dyker upp senare som en utebliven leverans.

**Vad gör man med differenserna?**

Sortera dem efter belopp, räkna om de största och leta efter mönster innan något justeras. Återkommande minus på samma plats beror sällan på slump utan på fel plockplats, saknad avrapportering eller svinn. Justeras avvikelsen utan att orsaken noteras kommer samma differens tillbaka nästa gång.

**Vad är ett inventeringsintyg?**

Inventeringsförteckningen med den skattskyldiges försäkran tecknad på den. Enligt lagen om inventering av varulager för inkomstbeskattningen ska förteckningen ta upp varje post i lagret med sitt värde, och den skattskyldige ska på förteckningen teckna en på heder och samvete avgiven försäkran om att ingen lagertillgång har undantagits vid inventeringen. Förteckningen ingår i räkenskapsmaterialet och ska sparas.

---

## Inventering i butik: så räknar du utan att tappa en säljdag

Källa: https://fluit.se/kunskap/lager/inventering-i-butik
Ämne: Lager & WMS
Uppdaterad: 2026-07-30

Inventering i butik är att räkna varorna i butiksytan och baklagret och stämma av mot saldot i kassa- eller affärssystemet. Skillnaden mot ett renodlat lager är att varorna står framme bland kunder: samma artikel finns på flera platser samtidigt, och en del av differensen är svinn i stället för registreringsfel.

En butiksinventering liknar en lagerinventering i allt utom det som gör den svår. Varorna står framme, kunderna rör dem, samma artikel finns på tre ställen samtidigt, och en del av differensen kommer aldrig att gå att förklara med ett registreringsfel.

Det påverkar hur räkningen bör läggas upp. Ordningen på ytan måste vara återställd innan någon börjar räkna, sektionerna måste vara tydligt avgränsade, och baklagret måste räknas i samma omgång som hyllan.

## Dela butiken i sektioner

Rita upp butiken och numrera varje yta: hyllsektioner, gondoler, väggar, kassaområde, skyltfönster, baklager, lastkaj. Varje sektion får en egen lista och en ansvarig.

Poängen är gränsdragningen. Utan numrerade sektioner uppstår båda felen samtidigt: en yta räknas av två personer medan en annan hoppas över, och ingen av dem syns förrän differenserna dyker upp. Med sektioner räcker det att bocka av listan för att veta att allt är täckt.

Märk sektionen som klar när den är räknad. Butiksinventeringar avbryts oftare än lagerinventeringar, och då ska ingen behöva minnas var arbetet stannade.

## Städa upp innan räkningen börjar

Det mesta som blir en differens går att förhindra innan räkningen ens har börjat:

- **Ställ tillbaka varor som hamnat fel.** Artikeln som ligger i fel hylla räknas som överskott på ett ställe och underskott på ett annat.
- **Samla ihop samma artikel.** Ligger den på tre platser i butiken blir det tre chanser att räkna fel och en att missa en av dem.
- **Kassera det som är trasigt eller osäljbart först.** Bokas kassationen ut efter räkningen blandas den ihop med svinnet, och då går de två inte att skilja åt i efterhand.
- **Bestäm vad som gäller för varor i kundvagnar och reservationer.** De ska antingen vara ute ur saldot eller räknas, inte båda delarna.

## Räkna blint, sektion för sektion

Skriv ut listan utan det förväntade antalet. Ser räknaren att det ska stå tolv på hyllan slutar räkningen vid tolv, och det är just i högar av likadana varor som effekten är störst.

Räkna en sektion färdigt innan nästa börjar, och räkna uppifrån och ned, vänster till höger, i samma ordning varje gång. Ordningen låter petig men är det som gör att en avbruten räkning går att återuppta utan att något dubbelräknas.

Underlaget gör du i [inventeringslistan](/verktyg/inventeringslista): en lista per sektion, sorterad så att den följer hyllan, med några tomma rader sist för varor som står där men inte finns på listan.

## Baklagret hör till samma saldo

Det vanligaste felet i en butiksinventering är att bara butiksytan räknas. Saldot i systemet gäller allt du äger på adressen, så kartongen i baklagret och pallen på lastkajen ingår.

Räkna dem som egna sektioner, men i samma omgång som butiken. Räknas baklagret en annan dag hinner varor flyttas ut i hyllan däremellan, och då dubbelräknas de.

## Skilj svinn från felregistrering

I ett renodlat lager beror nästan alla differenser på hur något registrerats. I butik finns en orsak till, och de två ska inte hanteras likadant. Mönstret i avvikelsen skiljer dem oftast åt:

| Mönster i differensen | Trolig orsak |
|---|---|
| Stadigt underskott på små, stöldbegärliga varor | Svinn |
| Avvikelse i jämna multiplar av förpackningen | Fel enhet vid inleverans eller i kassan |
| Två snarlika artiklar avviker lika mycket åt olika håll | Fel artikel skannad i kassan |
| Överskott på kampanjvaror | Multipack sålt som styck, eller tvärtom |
| Ett hopp vid ett enda tillfälle | Leverans registrerad på fel antal |

Svinnet i procent räknar du som värdet av det som saknas delat med försäljningen under perioden mellan två räkningar. Talet är bara användbart om felregistreringarna först är rensade bort. Annars mäter du administrativa fel och stöld i samma siffra och kan inte åtgärda någon av dem.

[Inventeringsdifferens-verktyget](/verktyg/inventeringsdifferens) rangordnar avvikelserna efter belopp och skiljer på nettodifferensen, alltså hur lagervärdet påverkas, och bruttodifferensen, alltså hur mycket som faktiskt låg fel. Det andra talet är det som rör sig när rutinerna i butiken förbättras.

## Räkna oftare på det som rör sig

Ett årligt stopp där hela sortimentet räknas ger ett korrekt lagervärde till bokslutet och väldigt lite annat. En differens som upptäcks i december kan ha uppstått i mars, och då finns ingenting kvar att spåra.

De mest sålda och mest stöldbegärliga varorna tjänar på att räknas betydligt oftare, gärna varje månad, medan svansen klarar sig med en gång om året. Det är [rullande inventering](/ordlista/cykelrakning) i sin enklaste form, och den kräver varken stängd butik eller övertid: en sektion i taget under en lugn timme räcker.

## Systemet bakom butiken

Fluit är inte ett kassasystem. Kassan i butiken behåller du. Fluit är navet bakom den, där artiklar, priser, lager och order ligger på samma data, och där inventeringen läggs upp per plats, per kategori eller som cykelräkning med räkning i mobilappen. Blindräkning och godkännande innan saldot ändras ingår i flödet. Läs mer om [affärssystem för handel och detaljhandel](/bransch/handel-och-detaljhandel) eller om [inventering i Fluit](/funktioner/inventering).

### Vanliga frågor

**Måste butiken stängas för att inventera?**

Nej, men den sektion som räknas behöver stå still. Många butiker räknar före öppning eller efter stängning, eller tar några sektioner i taget under lugna timmar. Säljs en vara ur en sektion som redan räknats blir saldot fel, så antingen räknas sektionen om eller så noteras försäljningen separat.

**Hur ofta bör en butik inventera?**

Hela sortimentet minst en gång per räkenskapsår, eftersom varulagret ska vara inventerat vid bokslutet. Utöver det räknar många butiker de mest stöldbegärliga och mest sålda varorna betydligt oftare, ibland varje månad, eftersom det är där differenserna hinner växa mellan de stora räkningarna.

**Hur räknar man ut svinnet i procent?**

Ta värdet av det som saknas vid inventeringen och dela med försäljningen under perioden mellan två räkningar. Talet blir bara meningsfullt om felregistreringar först är rensade bort, annars mäter du administrativa fel och stöld i samma siffra.

**Räcker det att räkna butiksytan?**

Nej. Baklager, lastkaj, skyltfönster och varor som står i kassaområdet hör till samma saldo. Räknas bara hyllan blir allt som ligger i kartong bakom en differens, och den differensen ser ut som svinn trots att varorna finns kvar.

**Vad gör man med varor som är trasiga eller osäljbara?**

Ta ut dem ur saldot som kassation innan räkningen börjar, i stället för att räkna dem och justera efteråt. Blandas kassation ihop med inventeringsdifferensen går det inte att se hur mycket av avvikelsen som var svinn och hur mycket som var medvetet bortplockat.

---

## Konsignationslager: så fungerar det

Källa: https://fluit.se/kunskap/lager/konsignationslager
Ämne: Lager & WMS
Uppdaterad: 2026-08-07

Konsignationslager innebär att varor placeras hos kunden eller återförsäljaren men ägs av leverantören tills de förbrukas eller säljs. Ägandet övergår först vid förbrukningen, som rapporteras och ligger till grund för faktureringen. Upplägget ger kunden tillgång utan kapitalbindning och leverantören en plats nära förbrukningen, mot att lagerrisken stannar hos leverantören.

**I ett konsignationslager står varan hos kunden men ägs av leverantören.** Ägandet flyttar först när varan faktiskt förbrukas, och det är också då den faktureras.

Upplägget är vanligt där tillgänglighet är avgörande och förbrukningen svår att förutse: reservdelar hos en industrikund, förbrukningsmaterial i vården, komponenter hos en tillverkare som inte vill stå still för att en skruv tog slut.

## Vad var och en får ut av det

**Kunden** får varorna på plats utan att binda kapital i dem, och slipper stå för inkuransrisken. Det som inte används kan i regel returneras.

**Leverantören** får en plats nära förbrukningen, vilket i praktiken låser ute konkurrenterna, och ofta en tätare relation genom att påfyllningen sköts av dem. Priset är att kapitalet och risken stannar hos leverantören ända fram till förbrukningen.

Det är alltså inte en generös gest utan en affärsuppgörelse där båda vet vad de betalar med.

## Det som måste fungera

Hela upplägget står och faller med förbrukningsrapporteringen. Rapporteras den inte vet ingen vad som finns kvar, påfyllningen blir gissningar och faktureringen släpar.

Tre saker behöver därför finnas på plats:

1. **En rapporteringsrutin** som är enkel nog att bli av. Sker rapporteringen genom ett mejl en gång i månaden kommer den att missas.
2. **Avtalade nivåer** för min och max, så att påfyllningen kan utlösas av ett tal och inte av en känsla.
3. **Avstämning mot fysiskt saldo**, eftersom rapporterad förbrukning och faktisk förbrukning glider isär över tid.

## Faktureringsrytmen

Frekvensen är en avvägning mellan administration och kassaflöde. Fakturering vid varje rapportering ger snabbast betalning och flest fakturor. Samlad fakturering per vecka eller månad ger färre fakturor och längre kredittid i praktiken.

För en leverantör med många konsignationslager är skillnaden i administrativ börda betydande, medan skillnaden i kassaflöde ofta är mindre än den ser ut.

## Redovisningen följer ägandet

Eftersom varorna ägs av leverantören ligger de i leverantörens lagervärde och inte i kundens, trots att de står i kundens lokal. Det påverkar båda parters nyckeltal: leverantörens [lageromsättningshastighet](/verktyg/lageromsattningshastighet) blir lägre och kundens bättre än vad varuflödet i sig motiverar.

Det gör också att inventeringen behöver täcka konsignationslagren, även om de fysiskt står någon annanstans.

## I ett system

I [Fluit](/funktioner/konsignation) finns konsignationsavtal med status utkast, aktivt, pausat och avslutat, där bara ett aktivt avtal tillåter förbrukningsrapportering. Avtalet har rader med de artiklar som omfattas, en faktureringsfrekvens (vid varje förbrukning, veckovis eller månadsvis) och ett påfyllningsläge: manuell påfyllning där någon skapar en överföringsorder, automatisk påfyllning eller påfyllning när saldot understiger min-nivån.

Förbrukningen registreras som egna poster mot avtalet, vilket gör att både faktureringsunderlaget och påfyllningsbehovet kommer ur samma händelse.

### Vanliga frågor

**Vem äger varorna i ett konsignationslager?**

Leverantören, ända fram till att varan förbrukas eller säljs vidare. Det innebär att varorna ligger i leverantörens lagervärde trots att de fysiskt står hos kunden, och att kunden inte binder kapital i dem.

**När sker faktureringen?**

Vid förbrukning, inte vid leverans. Kunden rapporterar vad som förbrukats och faktureras för det, antingen vid varje rapportering eller samlat per vecka eller månad beroende på avtal.

**Vad är skillnaden mot vanlig lagerhållning hos kund?**

Vid vanlig försäljning övergår ägandet vid leverans och kunden binder kapital direkt. Vid konsignation stannar ägandet hos leverantören, vilket flyttar både kapitalbindningen och risken för inkurans dit.

**Hur fylls konsignationslagret på?**

Antingen manuellt, genom att någon lägger en påfyllnadsorder, eller automatiskt utifrån min- och maxnivåer. Automatisk påfyllning kräver att förbrukningen rapporteras löpande, eftersom det är den som avslöjar när nivån passerats.

---

## Vad är ett orderhanteringssystem (OMS)?

Källa: https://fluit.se/kunskap/order/vad-ar-ett-orderhanteringssystem
Ämne: Order
Uppdaterad: 2026-07-30

Ett orderhanteringssystem, på engelska order management system eller OMS, följer en kundorder genom hela dess liv: från att den tas emot tills den är levererad, fakturerad och betald. Systemet samlar order från alla försäljningskanaler i samma flöde och håller reda på vad som är reserverat, skickat och kvar att leverera.

Ett **orderhanteringssystem** (på engelska *order management system*, ofta förkortat **OMS**) är programvara som följer en kundorder genom hela dess liv. Från att ordern tas emot tills den är levererad, fakturerad och betald. Systemet håller reda på status, lagertillgång och dokument i varje led, så att alla som jobbar med ordern ser samma sak.

Utan ett OMS hamnar orderinformationen i mejl, kalkylark och folks huvuden. Med ett OMS samlas allt på ett ställe.

## Vad gör ett orderhanteringssystem?

Ett OMS täcker hela kedjan, från inkommen order till klar leverans:

- **Tar emot order** från webbshop, säljare, EDI, telefon och marknadsplatser, och samlar dem i ett gemensamt flöde.
- **Kontrollerar kund och pris** mot prislista, rabattavtal, betalvillkor och kreditgräns innan ordern går vidare.
- **Allokerar lager** mot ordern så att samma vara inte säljs två gånger. Läs mer om [allokering av lager](/kunskap/order/vad-ar-allokering).
- **Skapar plockunderlag** och styr plock och pack på lagret.
- **Hanterar leveranser**, inklusive [delleverans och samleverans](/kunskap/order/delleverans-och-samleverans) samt frakthandlingar.
- **Fakturerar** den levererade ordern och stänger flödet.

På så vis blir OMS:et navet i hela [order to cash-processen](/kunskap/order/order-to-cash-steg-for-steg).

Det systemet framför allt tillför är en gemensam sanning. Säljaren, lagret och ekonomiavdelningen tittar på samma orderrad, och när lagret plockar den uppdateras saldot och fakturaunderlaget utan att någon skriver av siffror i ett andra system.

## Orderhanteringssystem, ordersystem eller OMS?

De tre orden används om vartannat och betyder i praktiken samma sak.

| Ord | Vad det brukar syfta på |
| --- | --- |
| **Ordersystem** | Vardagligt svenskt ord. Används ofta om enklare lösningar som registrerar och följer order. |
| **Orderhanteringssystem** | Samma sak, men antyder att även lager, leverans och fakturering ingår. |
| **OMS** | Engelska *order management system*. Vanligast i e-handel och bland internationella leverantörer. |

"OMS-system" är egentligen en dubblering, eftersom S:et redan står för *system*. Uttrycket är ändå så vanligt i svenskt tal att det knappast är värt att rätta.

Skilj däremot på **orderhantering** och **orderhanteringssystem**. Orderhantering är arbetet: registrera, kontrollera, reservera, plocka, leverera och fakturera. Orderhanteringssystemet är verktyget som driver det arbetet. Man kan ha ordning på orderhanteringen med papper och pärm, men det slutar fungera ungefär när volymen börjar växa.

## OMS, ERP och WMS, hur hänger de ihop?

Begreppen överlappar, men de löser olika problem:

| System | Fokus | Styr |
| --- | --- | --- |
| **OMS** | Orderflödet | Order, allokering, leverans, fakturering över kanaler |
| **ERP** | Hela verksamheten | Ekonomi, inköp, produktion, ofta inkl. orderhantering |
| **WMS** | Det fysiska lagret | Lagerplatser, plockvägar, godsmottagning |

I praktiken är gränsen flytande. Ett [affärssystem](/kunskap/affarssystem/vad-ar-ett-affarssystem) innehåller nästan alltid en orderdel, och ett OMS måste känna till lagersaldot för att kunna lova leveransdatum. Frågan är mindre vilken etikett systemet bär och mer var gränssnitten går, alltså hur många integrationer du behöver underhålla för att en order ska bli en faktura.

I ett samlat affärssystem som Fluit ligger orderhanteringen inbäddad i ERP:et, med koppling till lager, [inköp](/funktioner/inkop) och ekonomi. Då hänger ordern, lagersaldot och fakturan alltid ihop. Vill du gräva djupare i gränsdragningen mot lagersidan, läs [WMS vs affärssystem](/kunskap/lager/wms-vs-affarssystem).

## Orderhantering i flera kanaler

Det är oftast flera säljkanaler som gör att kalkylarken går sönder. Samma artikel ligger till försäljning i webbshoppen, hos en B2B-säljare och kanske på en marknadsplats. Utan ett gemensamt system räknas lagret på tre ställen, och det är en tidsfråga innan samma sista exemplar säljs två gånger.

Ett orderhanteringssystem löser det genom att äga saldot. Kanalerna frågar systemet vad som finns, ordern reserverar mot samma pool oavsett var den kom in, och alla order plockas i samma flöde på lagret. För e-handel tillkommer ofta krav på snabb orderbekräftelse, [restorderhantering](/kunskap/order/restorderhantering) och returer, som alla blir betydligt enklare när order och lager bor i samma system. Så fungerar [e-handelsdelen i Fluit](/funktioner/ehandel).

## Vad kan automatiseras?

Mycket av orderhanteringen är regelstyrt arbete som ett system kan ta över:

- **Reservation av lager** när ordern läggs, i stället för manuell avstämning mot saldolistan.
- **Orderbekräftelse** som skickas automatiskt när ordern registrerats.
- **Leveransskapande** när ordern frisläpps till lagret.
- **Kreditkontroll** mot kundens gräns och förfallna fakturor.
- **Fakturering** mot det som faktiskt levererats, inte mot vad som beställdes.
- **Inköpsförslag** när en order skapar brist som inte täcks av befintligt lager.

Poängen är inte att ta bort människor ur flödet, utan att låta dem hantera undantagen. Ordern som är helt normal ska kunna gå igenom utan att någon rör den, medan den som har brist, kreditspärr eller avvikande leveransdatum lyfts fram för ett beslut.

## När behöver du ett OMS?

Du har vuxit ur kalkylarken om något av det här känns igen:

- Många order per dag, eller försäljning i flera kanaler samtidigt.
- Återkommande lagerfel. Varor säljs som inte finns, eller blir liggande.
- Behov av delleveranser, [restorderhantering](/kunskap/order/restorderhantering) och spårbarhet per leverans.
- Krav på att se orderstatus direkt, både internt och mot kund.
- Fakturaunderlag som stäms av manuellt mot följesedlar efter leverans.

## Att byta orderhanteringssystem

Byter du från ett befintligt system, eller från Excel, är det sällan funktionslistan som avgör om det går bra. Det här väger tyngre:

**Vad som ska flyttas.** Artiklar, kunder, prislistor och öppna order behöver in i det nya systemet. Historiska order kan ofta ligga kvar i det gamla, men saldon och pågående flöden måste stämma på bytesdagen.

**Hur ordertyperna ser ut.** De flesta bolag har fler varianter än de tror: webborder, B2B-order, direktleverans från leverantör, serviceorder. Kartlägg vilka regler som gäller för var och en innan uppsättningen börjar.

**Vilka integrationer som verkligen behövs.** Webbshop och ekonomisystem är nästan alltid med. Frakt och eventuellt EDI mot större kunder tillkommer ofta. Varje koppling är något som ska underhållas, så färre är bättre. Fluit synkar exempelvis mot [Fortnox](/lagersystem/fortnox) för ekonomin, medan lager och order ligger kvar i affärssystemet.

**När ni byter.** Lägg bytet till en period med lägre ordervolym, och räkna med parallelldrift under en kort tid.

## Orderhantering i Fluit

I Fluit hänger orderhanteringen ihop med lager, inköp och ekonomi i samma system. Ordern följer ett fast flöde från utkast till klar, lagret reserveras i två steg (mjukt vid orderläggning, hårt vid plockning), och faktureringen sker mot det som faktiskt skickats. Restorder och leveranser styrs från ordern, medan returer har en egen vy med koppling tillbaka till ursprungsordern.

Läs vidare om [Fluits orderhantering](/funktioner/orderhantering), eller [boka en demo](/kontakt) så går vi igenom flödet mot era egna ordertyper.

### Vanliga frågor

**Vad är ett orderhanteringssystem?**

Ett orderhanteringssystem (OMS) är programvara som följer en kundorder hela vägen, från att den tas emot tills den allokeras, plockas, levereras och faktureras. Det blir en gemensam plats där alla ser samma orderstatus, oavsett vilken kanal ordern kom in genom.

**Vad gör ett orderhanteringssystem?**

Det tar emot order från alla säljkanaler, reserverar lager mot varje order, skapar plockunderlag till lagret, styr leveranser och frakthandlingar och fakturerar det som faktiskt skickats. Under tiden håller det orderstatus, lagersaldo och dokument uppdaterade i samma flöde.

**Vad innebär orderhantering?**

Orderhantering är arbetet med att ta en kundorder från mottagen till levererad och betald. Det omfattar registrering, kreditkontroll, lagerreservation, plock, pack, leverans och fakturering. Orderhantering är alltså processen, medan ett orderhanteringssystem är verktyget som driver den.

**Vad är ett ordersystem?**

Ordersystem är ett vardagligare svenskt ord för samma sak som orderhanteringssystem. Båda syftar på programvaran som håller reda på kundorder från registrering till leverans och fakturering. Ordersystem används oftare om enklare lösningar, medan orderhanteringssystem antyder att även lager och leveranser ingår.

**Vad är ett OMS-system?**

OMS står för order management system och är den engelska förkortningen för orderhanteringssystem. Att säga OMS-system blir alltså en dubblering, men uttrycket är vanligt i svenskt tal. Det betyder samma sak som ett orderhanteringssystem.

**Vad är skillnaden mellan ett OMS och ett ERP?**

Ett OMS är specialiserat på orderflödet och ger överblick över order och lager, ofta över flera säljkanaler. Ett ERP är bredare och täcker även ekonomi, inköp och produktion. I många affärssystem, som Fluit, är orderhanteringen en integrerad del av ERP:et.

**Vad är skillnaden mellan ett OMS och ett WMS?**

Ett OMS styr ordern och avgör vad som ska levereras och när. Ett WMS (lagerhanteringssystem) styr det fysiska arbetet på lagret, alltså var varan står, hur den plockas och hur lagerplatserna används. De jobbar tillsammans men löser olika problem.

**När behöver ett företag ett orderhanteringssystem?**

När orderflödet blir för stort eller för spritt för att hanteras i kalkylark. Det kan handla om många ordrar per dag, försäljning i flera kanaler, delleveranser, restorder eller krav på spårbarhet. Då ger ett OMS kontroll och färre fel.

**Vad kostar ett orderhanteringssystem?**

Priset sätts oftast per användare och månad, ibland med tillägg för antal order eller kanaler. Räkna också med införandet: datamigrering, uppsättning av ordertyper och integrationer mot webbshop och ekonomisystem. Ett system där lagret redan ingår slipper kostnaden för en separat lagerintegration.

---

## Order to cash: säljflödet steg för steg

Källa: https://fluit.se/kunskap/order/order-to-cash-steg-for-steg
Ämne: Order
Uppdaterad: 2026-07-30

Order to cash, ofta förkortat O2C, är hela säljflödet från att en kundorder tas emot tills betalningen är bokförd. Stegen är ordermottagning, kreditkontroll, allokering av lager, plock och pack, leverans, fakturering och slutligen betalning med avstämning. Det är säljsidans motsvarighet till inköpets purchase-to-pay.

**Order to cash** (ofta förkortat **O2C**) är hela säljflödet, från att en kundorder tas emot tills betalningen är bokförd. Det är säljsidans motsvarighet till inköpets purchase-to-pay. När processen sitter ihop ordentligt levererar du snabbare, gör färre fel och får betalt tidigare.

Här är processen, uppdelad i sju steg.

## 1. Order tas emot

Kunden lägger en order, via webbshop, säljare, EDI eller telefon. Ordern registreras med kund, artiklar, kvantiteter, priser och leveransvillkor. I ett samlat [orderhanteringssystem](/kunskap/order/vad-ar-ett-orderhanteringssystem) hamnar order från alla kanaler i samma flöde.

## 2. Kreditkontroll

Innan ordern bekräftas kollar du att kunden får handla, mot kreditgräns, kreditupplysning eller krav på förskott. Steget skyddar dig från att leverera till någon som inte kan betala. Order som passerar går vidare. Order som fastnar parkeras för manuell bedömning.

## 3. Allokering av lager

Lagret reserveras mot ordern så att samma vara inte säljs två gånger. Det kan ske mot fritt lagersaldo eller mot en inkommande [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder). Skillnaden förklarar vi i [allokering av lager](/kunskap/order/vad-ar-allokering).

## 4. Plock och pack

Ett plockunderlag skapas, och godset plockas och packas på lagret. Här blir den logiska allokeringen ett fysiskt uttag. Varorna lämnar lagerplatsen och görs i ordning för leverans.

## 5. Leverans

Godset skickas. En följesedel följer med leveransen, och en fraktsedel går till transportören. Räcker inte lagret kan ordern ge en [delleverans](/kunskap/order/delleverans-och-samleverans), och resten hanteras som [restorder](/kunskap/order/restorderhantering).

## 6. Fakturering

Den levererade ordern faktureras, normalt mot det som faktiskt skickats och inte mot det beställda. Vid delleverans faktureras varje leverans för sig, eller samlat enligt avtal. Fakturerar du snabbt efter leverans får du betalt tidigare.

## 7. Betalning och avstämning

Kunden betalar enligt avtalade villkor, inbetalningen matchas mot fakturan och affären stängs. Eventuella avvikelser, som restbelopp eller kreditnotor, reds ut här. Sen är cykeln fullbordad.

## Sammanfattning

| Steg | Vad händer | Nyckeldokument |
| --- | --- | --- |
| 1 | Order tas emot | Kundorder |
| 2 | Kreditkontroll | Kreditgräns / förskott |
| 3 | Lager allokeras | Reservation |
| 4 | Plock och pack | Plockunderlag |
| 5 | Leverans | Följesedel / fraktsedel |
| 6 | Fakturering | Kundfaktura |
| 7 | Betalning | Inbetalning |

När varje steg sker i samma system flyter informationen mellan stegen utan dubbelarbete. Se hur det fungerar i [Fluits orderhantering](/funktioner/orderhantering) eller [boka en demo](/kontakt).

### Vanliga frågor

**Vad betyder order to cash?**

Order to cash (O2C) är hela kedjan från att en kundorder tas emot tills betalningen är bokförd. Den omfattar kreditkontroll, allokering, plock och pack, leverans, fakturering och betalning. Det är säljsidans motsvarighet till inköpets purchase-to-pay.

**Vad är skillnaden mellan order to cash och purchase to pay?**

Order to cash är säljflödet, alltså från kundorder till inbetalning. Purchase to pay är inköpsflödet, från behov till betald leverantörsfaktura. Det ena ger intäkter, det andra kostnader, men logiken med order, leverans och faktura är spegelvänd.

**Vad är kreditkontroll i order to cash?**

Kreditkontroll är steget där du kollar att kunden har utrymme att handla på kredit innan ordern bekräftas. Det kan vara en kreditgräns, en kreditupplysning eller krav på förskott. Poängen är att slippa leverera till en kund som inte kan betala.

**Hur lång är en order to cash-cykel?**

Det beror på bransch och betalningsvillkor, men cykeln mäts ofta i dagar från order till inbetalning. Ju kortare cykel, desto snabbare frigörs kapital. Automatiserade flöden och snabb fakturering efter leverans kortar tiden.

---

## Allokering av lager: soft vs hard allocation

Källa: https://fluit.se/kunskap/order/vad-ar-allokering
Ämne: Order
Uppdaterad: 2026-07-30

Allokering är att reservera ett antal av en artikel mot en bestämd order, så att samma vara inte kan säljas eller plockas till någon annan. En mjuk allokering bokar antalet utan att peka ut en lagerplats, en hård binder det till plats, batch eller serienummer. Skillnaden mellan fysiskt och tillgängligt saldo är just allokeringarna.

**Allokering** av lager är när ett lagersaldo reserveras mot en specifik order, så att samma vara inte kan säljas eller plockas till någon annan. Allokeringen skiljer det som är fritt tillgängligt från det som redan är utlovat. Det är alltså det som hindrar att lagret översäljs.

Utan allokering ser alla samma totala saldo, och två säljare kan lova bort den sista varan var för sig. Med allokering vet systemet exakt hur mycket som faktiskt går att lova nästa kund.

## Tillgängligt saldo och fysiskt saldo

Det finns två saldon att hålla isär:

- **Fysiskt saldo** är allt som faktiskt står på lagret just nu.
- **Tillgängligt saldo** är fysiskt saldo minus det som redan är allokerat.
- **ATP** (available-to-promise) räknar dessutom in inkommande inköpsordrar per datum. Läs mer i [ordlistan om ATP](/ordlista/atp).

Det är det tillgängliga saldot du kan lova nya kunder. Säljer du 100 enheter och allokerar dem mot ordern minskar det tillgängliga saldot direkt, även om varorna fortfarande står kvar på sin plats.

## Soft allocation och hard allocation

Allokering sker i två nivåer, vid olika tidpunkter i [order to cash-flödet](/kunskap/order/order-to-cash-steg-for-steg):

| | Soft allocation | Hard allocation |
| --- | --- | --- |
| **När** | Vid orderläggning | Vid plock |
| **Mot vad** | Totalt saldo eller inkommande inköpsorder | Specifik lagerplats / batch |
| **Innebär** | Ett löfte om att varan finns | En låsning av fysiskt gods |
| **Flexibilitet** | Lätt att flytta om | Bunden till plats |

**Soft allocation** reserverar en kvantitet mot lagersaldot, eller mot en inkommande [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder), redan när ordern läggs. Den pekar inte ut var varan står. Den skapar löftet och håller det tillgängliga saldot rätt.

**Hard allocation** låser en bestämd kvantitet på en bestämd lagerplats, normalt när plocket startar. Nu är ordern knuten till fysiskt gods, inklusive vilken batch enligt [FIFO eller FEFO](/kunskap/lager/fifo-fefo-lagervardering). I ett [WMS](/kunskap/lager/vad-ar-ett-wms) är det hard allocation som styr själva plockarbetet.

## Allokering mot inköp

En av de mest användbara finesserna är att kunna allokera mot något som ännu inte finns. När det tillgängliga saldot inte räcker kan en kundorder soft-allokeras mot en inkommande inköpsorder. När godset inlevereras övergår reservationen automatiskt till lagersaldo, och kundordern är täckt. Ingen behöver hålla reda på det för hand.

## Allokering i Fluit

I Fluit allokeras lagret automatiskt när en order läggs, och det tillgängliga saldot hålls uppdaterat löpande. En soft allocation heter **Reserverad** i Fluit och en hard allocation heter **Platsbokad**, så att namnet säger om en lagerplats är utpekad eller inte. Reservationer kan ligga mot både lagersaldo och inkommande inköpsorder, och de övergår av sig själva vid inleverans. Läs mer om [Fluits orderhantering](/funktioner/orderhantering) eller [boka en demo](/kontakt).

### Vanliga frågor

**Vad är allokering av lager?**

Allokering är när lagersaldo reserveras mot en specifik order, så att samma vara inte kan säljas eller plockas till någon annan. Det skiljer fritt tillgängligt saldo från det som redan är utlovat, och hindrar att lagret översäljs.

**Vad är skillnaden mellan soft allocation och hard allocation?**

Soft allocation reserverar en kvantitet mot det totala lagersaldot eller mot en inkommande inköpsorder redan vid orderläggning, utan att peka ut var varan står. Hard allocation låser en specifik kvantitet på en specifik lagerplats, normalt vid plock. Soft skapar löftet, hard knyter det till fysiskt gods.

**Vad är skillnaden mellan tillgängligt saldo och fysiskt saldo?**

Fysiskt saldo är allt som faktiskt finns på lagret. Tillgängligt saldo är det fysiska saldot minus det som redan är allokerat till andra order. ATP (available-to-promise) går ett steg längre och räknar även in inkommande inköpsordrar per datum. Det är ATP du kan lova nya kunder mot.

**Kan man allokera mot en inköpsorder som inte levererats?**

Ja. Med soft allocation kan en kundorder reserveras mot en inkommande inköpsorder. När godset sedan inlevereras övergår reservationen automatiskt till lagersaldo, och kundordern är täckt utan manuellt arbete.

---

## Delleverans och samleverans: flera leveranser per order

Källa: https://fluit.se/kunskap/order/delleverans-och-samleverans
Ämne: Order
Uppdaterad: 2026-07-30

En delleverans är när en kundorder skickas i flera omgångar i stället för allt på en gång, typiskt när lagret inte räcker till hela ordern. En samleverans är det omvända: flera order till samma kund slås ihop och skickas tillsammans. Valet styr både fraktkostnaden och när ordern kan faktureras.

En **delleverans** är när en och samma kundorder levereras i flera omgångar i stället för allt på en gång. En **samleverans** är det omvända, alltså att flera order till samma kund slås ihop och skickas tillsammans. Båda handlar om att frikoppla ordern från leveransen, så att verkligheten på lagret och kundens önskemål får styra hur godset går iväg.

I en värld där allt alltid fanns på lager och kunden alltid ville ha allt på samma gång vore varje order exakt en leverans. Så ser det sällan ut.

## Delleverans, en order och flera leveranser

Delleverans uppstår oftast när:

- Hela kvantiteten inte finns på lager just nu, men en del kan skickas direkt.
- Kunden vill ha varorna vid olika tidpunkter.
- Olika artiklar på ordern har olika ledtid.

Då skickas det som finns nu, och resten kommer senare, ofta som [restorder](/kunskap/order/restorderhantering). Varje delleverans blir en egen leverans med eget leveransnummer och egen [följesedel](/kunskap/order/foljesedel-vs-packsedel).

### Radsplittring

Mekaniken bakom delleverans är **radsplittring**. En orderrad delas upp i flera delar med olika kvantiteter eller leveransdatum. En rad på 100 enheter kan splittras i 60 som skickas nu och 40 senare, utan att du behöver skapa en ny order. Den ursprungliga ordern hålls intakt, men leveranserna kan ske oberoende av varandra.

## Samleverans, flera order och en leverans

Samleverans går åt andra hållet. Har en kund lagt tre order under veckan kan de buntas ihop till en enda leverans. Vinsterna:

- **Lägre fraktkostnad**, en sändning i stället för tre.
- **Mindre administration**, en följesedel och en frakthandling.
- **Bättre kundupplevelse**, ett paket att ta emot.

Förutsättningen är att systemet kan koppla flera order till samma leverans och ändå hålla spårbarheten per order.

## Spårning per leverans

| Begrepp | Förhållande order ↔ leverans | Typiskt skäl |
| --- | --- | --- |
| **Hel leverans** | 1 order → 1 leverans | Allt finns, allt skickas |
| **Delleverans** | 1 order → flera leveranser | Lager räcker inte / olika datum |
| **Samleverans** | Flera order → 1 leverans | Spara frakt och admin |

Oavsett vilket behöver varje fysisk leverans en egen identitet, med eget leveransnummer, egen följesedel och egen [fraktsedel](/kunskap/order/foljesedel-vs-packsedel), samtidigt som kopplingen till ursprunglig order finns kvar. Då vet du alltid vad som skickats, vad som återstår och i vilken sändning det åkte.

## Delleverans och samleverans i Fluit

I Fluit kan en order ge flera leveranser, och flera order kan samlas i en, med radsplittring och egen spårning per leverans. Restkvantiteter hanteras vidare som restorder, och varje leverans får sina egna handlingar. Läs mer om [Fluits orderhantering](/funktioner/orderhantering) eller [boka en demo](/kontakt).

### Vanliga frågor

**Vad är en delleverans?**

En delleverans är när en kundorder levereras i flera omgångar i stället för allt på en gång. Det händer till exempel när hela kvantiteten inte finns på lager, eller när kunden vill ha varorna vid olika tidpunkter. Varje delleverans har egen följesedel och egen spårning.

**Vad är skillnaden mellan delleverans och samleverans?**

Delleverans betyder att en order ger flera leveranser. Samleverans är det omvända, alltså att flera order till samma kund slås ihop till en gemensam leverans. Delleverans delar upp, samleverans buntar ihop.

**Vad är radsplittring?**

Radsplittring innebär att en orderrad delas upp i flera delar med olika leveransdatum eller kvantiteter. En rad på 100 enheter kan till exempel splittras i 60 som levereras nu och 40 som levereras senare, utan att du behöver skapa en ny order.

**Hur spårar man gods vid delleverans?**

Varje delleverans får en egen leverans med eget leveransnummer, egen följesedel och egen frakthandling. Då kan du följa vad som skickats, vad som återstår och vilken fraktsändning varje del tillhör, även om de går iväg vid olika tidpunkter.

---

## Restorder: så hanterar du varor som inte räcker till

Källa: https://fluit.se/kunskap/order/restorderhantering
Ämne: Order
Uppdaterad: 2026-07-30

En restorder är den del av en kundorder som inte kunde levereras direkt, och som ligger kvar som ett åtagande tills varan finns i lager igen. Alternativen är att skicka det som finns och restnotera resten, hålla hela ordern tills allt kan gå samlat, eller avbryta raden.

En **restorder** (på engelska *backorder*) är den del av en kundorder som inte kan levereras direkt, eftersom lagret inte räcker till. Den resterande kvantiteten hålls kvar och levereras senare, oftast när varan finns på lager igen efter en inleverans från leverantör.

Restorder är svårt att undvika så fort efterfrågan kan överstiga tillgängligt saldo. Frågan är inte om det händer, utan hur du tar hand om det när det gör det.

## Restorder och delleverans hänger ihop

När en order bara delvis kan levereras händer två saker samtidigt:

- Den del som skickas blir en [delleverans](/kunskap/order/delleverans-och-samleverans).
- Den del som väntar blir en restorder.

Delleveransen beskriver det som gått ut, restordern det som återstår. Båda pekar tillbaka på samma ursprungliga order, så att kunden får en sammanhängande affär även om varorna kommer i omgångar.

## Tre strategier för restorder

Det finns sällan ett rätt svar. Välj strategi medvetet, gärna som en regel per artikel eller kund:

1. **Skapa restorder.** Skicka det som finns, behåll resten och leverera senare. Bäst när kunden vill ha varan och är beredd att vänta, och när varan kommer tillbaka i lager.
2. **Avbryt resterande.** Leverera det som finns och stryk resten. Lämpligt för utgående artiklar, eller när kunden hellre beställer om än väntar.
3. **Parkera ordern.** Vänta med hela leveransen tills allt finns, och skicka komplett. Bra när kunden vill ha en samlad leverans och inte vill ha delleveranser.

| Strategi | Skickas nu | Resterande | Passar när |
| --- | --- | --- | --- |
| Skapa restorder | Ja, delvis | Levereras senare | Kunden kan vänta |
| Avbryt resterande | Ja, delvis | Stryks | Utgående artikel |
| Parkera ordern | Nej | Hela ordern väntar | Kund vill ha allt samlat |

## Koppling till inköp och MRP

En restorder är i grunden ett behov. När den skapas uppstår en efterfrågan på en vara som inte finns, och det behovet bör inte ligga och glömmas bort. I ett samlat system fångas det automatiskt. Behovet driver ett beställningsförslag eller en [inköpsorder](/kunskap/inkop/vad-ar-en-inkopsorder), och MRP-motorn räknar med restordern när den föreslår vad som ska köpas in.

När godset sedan inlevereras kan restordern [allokeras](/kunskap/order/vad-ar-allokering) mot det nya saldot och levereras, i bästa fall utan att någon behöver röra ett finger.

## Restorderhantering i Fluit

I Fluit blir restkvantiteter restorder som hålls kopplade till ursprungsordern, och behovet matas in i MRP så att inköp kan täcka det. Vid inleverans allokeras restordern automatiskt och kan levereras. Läs mer om [Fluits orderhantering](/funktioner/orderhantering) eller [boka en demo](/kontakt).

### Vanliga frågor

**Vad är en restorder?**

En restorder (på engelska backorder) är den del av en kundorder som inte kan levereras direkt eftersom lagret inte räcker till. Den resterande kvantiteten hålls kvar och levereras senare när varan finns igen, ofta efter en inleverans från leverantör.

**Vad är skillnaden mellan restorder och delleverans?**

De hänger ihop. När en order delvis levereras blir den skickade delen en delleverans, och den kvarvarande delen blir en restorder. Delleverans beskriver det som gått ut, restorder det som väntar.

**Hur kopplas restorder till inköp?**

En restorder skapar ett behov som inköp eller MRP-motorn kan fånga upp. Behovet driver ett beställningsförslag eller en inköpsorder, och när godset inlevereras kan restordern allokeras och levereras automatiskt.

**Ska man alltid skapa en restorder?**

Nej. Ibland är det bättre att avbryta den resterande kvantiteten, till exempel vid utgående artiklar eller om kunden inte vill vänta. Valet beror på artikel, kund och avtal, och bör helst vara en medveten regel snarare än en slump.

---

## Följesedel, packsedel och fraktsedel: vad är skillnaden?

Källa: https://fluit.se/kunskap/order/foljesedel-vs-packsedel
Ämne: Order
Uppdaterad: 2026-07-30

Följesedel, packsedel och fraktsedel följer samma leverans men fyller olika syften. Följesedeln redovisar för kunden vad sändningen innehåller, utan priser. Packsedeln är underlaget som styr plock och pack på lagret, och i Sverige används orden ofta synonymt. Fraktsedeln är transportörens dokument och styr hur godset hanteras, spåras och debiteras.

**Följesedel**, **packsedel** och **fraktsedel** är tre dokument som följer en leverans, men de fyller olika syften och vänder sig till olika mottagare. Följesedeln beskriver vad sändningen innehåller, packsedeln styr själva packarbetet och fraktsedeln beskriver transporten. De blandas ofta ihop, men i ett strukturerat orderflöde har var och en sin roll.

## Följesedel, vad finns i leveransen

En **följesedel** följer med godset till kunden och listar vad sändningen innehåller: artiklar, artikelnummer och kvantiteter, men normalt inga priser. Mottagaren använder den för att stämma av att rätt varor och rätt antal kommit fram. Vid en [delleverans](/kunskap/order/delleverans-och-samleverans) visar följesedeln vad som ingår i just den leveransen, inte hela ordern.

## Packsedel, underlag för plock och pack

En **packsedel** (packlista) är i grunden underlaget för att plocka och packa rätt. I Sverige används orden följesedel och packsedel ofta synonymt om samma fysiska dokument. När man gör en skillnad syftar packsedeln på den interna listan som styr lagerpersonalen i plocket, medan följesedeln är exemplaret som följer med till kunden. Innehållet är i praktiken detsamma: artiklar och kvantiteter, inga priser.

## Fraktsedel, dokument för transporten

En **fraktsedel** är transportörens dokument och handlar om själva transporten, inte om varornas detaljinnehåll. Den anger avsändare, mottagare, antal kollin, vikt och en spårningsreferens, och fungerar som bevis på transportavtalet och underlag för spårning. Fraktsedeln skapas ofta automatiskt vid [fraktberäkning](/funktioner/frakt-och-fraktberakning) och bokning av transport.

## Översikt

| Dokument | Beskriver | Till för | Priser? |
| --- | --- | --- | --- |
| **Följesedel** | Leveransens innehåll | Mottagaren | Nej |
| **Packsedel** | Plock- och packunderlag | Lagerpersonalen | Nej |
| **Fraktsedel** | Transporten (kollin, vikt, spårning) | Transportören | Nej |

Gemensamt för alla tre: inga priser. Betalningskravet hör hemma på **fakturan**, som är ett fjärde dokument. Håller du isär dem kan lager, transport och ekonomi jobba var för sig, och kunden får rätt information på rätt papper.

## Leveransdokument i Fluit

I Fluit skapas följesedel och frakthandlingar direkt från leveransen, med koppling till order, lager och [fraktberäkning](/funktioner/frakt-och-fraktberakning). Varje leverans får sina egna dokument, även vid delleverans. Läs mer om [Fluits orderhantering](/funktioner/orderhantering) eller [boka en demo](/kontakt).

### Vanliga frågor

**Vad är skillnaden mellan följesedel och packsedel?**

Orden används ofta synonymt i Sverige och beskriver i praktiken samma dokument, en specifikation av leveransens innehåll utan priser. När man gör en skillnad syftar packsedel oftast på den interna packlistan som styr plock och pack, medan följesedeln är dokumentet som följer med till kunden.

**Vad är skillnaden mellan följesedel och fraktsedel?**

Följesedeln beskriver vad som finns i sändningen och vänder sig till mottagaren. Fraktsedeln är transportörens dokument och beskriver själva transporten, alltså avsändare, mottagare, kollin, vikt och en spårningsreferens. Följesedeln gäller innehållet, fraktsedeln transporten.

**Innehåller en följesedel priser?**

Normalt inte. Följesedeln visar artiklar och kvantiteter så att mottagaren kan kontrollera leveransen, medan priser och betalningskrav hör hemma på fakturan. Att hålla isär dokumenten gör att lager och ekonomi kan jobba var för sig utan att blanda ihop leverans och betalning.

---

## RMA och returhantering

Källa: https://fluit.se/kunskap/order/rma-och-returhantering
Ämne: Order
Uppdaterad: 2026-08-07

RMA, Return Merchandise Authorization, är det godkännande och nummer som en kund får innan en vara skickas i retur. Numret gör att paketet kan kopplas till rätt kund och rätt ursprungsorder när det kommer in. Returflödet går sedan från godkänd retur via mottagning och bedömning till beslut om kreditering, ersättningsleverans eller reparation.

**Returer är omvänd logistik, och de kostar mer än de flesta tror.** Varje retur innebär ett ärende, en fraktkostnad, en bedömning, en lagerplats och ofta en kreditnota. Att flödet är genomtänkt märks inte i goda tider, men syns direkt i marginalen när returandelen stiger.

## Numret är hela mekanismen

**RMA-numret** är det som gör returen möjlig att hantera. Kunden får numret vid godkännandet och märker paketet med det. När paketet kommer in går det att koppla direkt till rätt kund, rätt ursprungsorder och rätt returorsak.

Utan numret blir mottagningen detektivarbete. Ett paket med en produkt och en handskriven lapp kräver att någon letar i orderhistoriken, och under tiden ligger varan på golvet och kunden väntar på sina pengar.

## Bedömningen bestämmer allt annat

Det viktigaste steget är också det som oftast hoppas över: att avgöra vad varan faktiskt duger till.

| Bedömning | Vad som händer |
| --- | --- |
| Säljbar som ny | Tillbaka till plocklagret |
| Behöver rekonditionering | Till åtgärd, sedan tillbaka eller till B-sortiment |
| Fel från leverantör | Retur till leverantör, kräv kreditering |
| Kasseras | Ur lagret, kostnaden bokas |

Läggs returer tillbaka i plocklagret utan bedömning skickas förr eller senare en skadad vara vidare till nästa kund. Då har ett returärende blivit två, och det andra är dyrare eftersom det också kostar förtroende.

## Orsaken är data, inte formalia

Returorsaken är ofta det enda systematiska felmeddelandet en verksamhet får från sina kunder. Registreras den som fritext blir den oanvändbar. Registreras den som en kod går den att summera.

Några återkommande mönster värda att kunna se:

- **En artikel med hög returandel** har ofta en produktbeskrivning som lovar fel sak.
- **Fel vara levererad** pekar på plockprocessen, inte på kunden.
- **Transportskada koncentrerad till en transportör eller en emballagetyp** är ett inköpsbeslut, inte otur.

## Kopplingen till reklamation mot leverantör

En vara som är felaktig från leverantören ger två ärenden som lätt tappar kontakten: kundens retur och din egen reklamation uppåt. Hålls de isär helt riskerar du att kreditera kunden och glömma att kräva leverantören.

Därför behöver returflödet finnas åt båda hållen, med kopplingen mellan dem bevarad.

## I ett system

I [Fluit](/funktioner/returer-och-rma) finns returer både mot kund och mot leverantör. Kundreturen följer ett statusflöde från utkast via godkänd och mottagen till krediterad och avslutad, med rader som pekar tillbaka på ursprungsordern.

Kopplingen till [ärendehanteringen](/kunskap/affarssystem/arendehantering-med-ko-och-sla) gör att returen kan börja som ett kundärende och bli en registrerad retur utan att någon skriver av uppgifterna på nytt. Mottagningen registreras mot returen, och kreditnotan skapas ur den i stället för att skrivas fritt.

### Vanliga frågor

**Vad betyder RMA?**

Return Merchandise Authorization, alltså ett godkännande att returnera en vara. I praktiken används ordet både om godkännandet och om numret som kunden märker paketet med.

**Varför behövs ett RMA-nummer?**

För att ett paket utan referens är omöjligt att koppla till rätt kund och rätt order. Utan numret får någon gissa utifrån avsändaradressen, och krediteringen dröjer tills gissningen bekräftats.

**Vad är skillnaden mellan retur och reklamation?**

En retur är att varan skickas tillbaka, oavsett skäl. En reklamation är ett påstående om att varan är felaktig. En retur kan alltså ske utan reklamation, till exempel vid öppet köp, och en reklamation kan lösas utan retur.

**Ska returnerad vara läggas tillbaka i lager direkt?**

Nej. Den ska först bedömas. Läggs den direkt i plocklagret riskerar en skadad eller ofullständig vara att skickas vidare till nästa kund, vilket förvandlar ett returärende till två.

---

## Prislistor och prissättning i B2B

Källa: https://fluit.se/kunskap/order/prislistor-i-b2b
Ämne: Order
Uppdaterad: 2026-08-07

Prissättning i B2B bygger på flera nivåer som prövas i tur och ordning: kundspecifikt avtalat pris först, därefter volympris i kundens prislista, sedan baspriset i prislistan och sist artikelns standardpris. Rabattregler läggs ovanpå det pris som vunnit. Ordningen är det som avgör att en förhandlad rabatt faktiskt slår igenom på orderraden.

**I B2B har samma artikel sällan ett pris.** Den har ett listpris, ett återförsäljarpris, ett avtalspris för den där kunden som förhandlade hårt i våras, och ett annat pris över hundra enheter. Frågan systemet ska svara på är vilket av dem som gäller just nu.

## Nivåerna och deras ordning

Prisberäkningen prövar nivåerna uppifrån och ned, och den första som träffar vinner:

1. **Kundspecifikt avtalat pris.** Det som förhandlats med just den kunden för just den artikeln.
2. **Volympris i kundens prislista.** Ett annat pris vid en viss kvantitet.
3. **Baspris i kundens prislista.** Prislistan som kunden eller kundgruppen är kopplad till.
4. **Artikelns standardpris.** Skyddsnätet när inget annat matchar.

Ordningen är inte en teknisk detalj utan hela poängen. Utan den skulle en förhandlad rabatt kunna slås ut av en generell prislista, och säljaren skulle upptäcka det först när kunden ringer.

## Rabatter ligger ovanpå

När priset är valt kan rabattregler läggas på: procent, belopp per styck eller volymrabatt vid en viss kvantitet. Reglerna kan gälla per kund, kundgrupp eller artikelkategori.

Den vanliga fällan är dubbelrabattering. Ett volympris i prislistan innehåller redan en volymrabatt, och läggs en generell volymrabattregel ovanpå har kunden fått den två gånger. Det syns sällan på en enskild order och tydligt i årets marginal.

## Vad rabatten faktiskt kostar

En rabatt på tio procent låter blygsam och är det sällan. Vid 30 procents täckningsgrad krävs ungefär femtio procent högre volym bara för att gå jämnt ut.

Det är därför värt att räkna innan man ger den. [Kalkylatorn för rabattens pris](/verktyg/rabattens-pris) visar hur mycket volymen behöver öka vid en given täckningsgrad, och [marginalräknaren](/verktyg/marginal-och-palagg) hur pris, marginal och pålägg hänger ihop.

## Giltighetstid är inte valfritt

En prislista utan slutdatum blir kvar. Efter ett par år finns tre listor med överlappande innehåll och ingen vet vilken som gäller, vilket i praktiken betyder att den lägsta gäller.

Ge listorna giltighetstid från början, och lägg in nästa års priser i förväg i stället för att uppdatera dem i januari. Samma sak gäller kundspecifika priser, som annars lever kvar långt efter att avtalet gjort det.

## Prissättning är inte bara pris

Två saker hör ihop med priset men räknas efter det: [frakten](/kunskap/ekonomi/moms-pa-frakt), som kan vara fri över ett visst ordervärde, och skatterna. Momsen räknas på priset efter rabatt, och en eventuell [punktskatt](/kunskap/ekonomi/punktskatt) läggs på utan att påverkas av rabatten alls.

Det sista är värt att komma ihåg vid kampanjer på punktskattepliktiga varor: skatten står kvar när priset sjunker, och marginalen faller snabbare än rabatten antyder.

## I ett system

I [Fluit](/funktioner/prishantering) finns prislistor med valuta och giltighetsdatum, kundspecifika priser, volympriser och rabattregler per kund, kundgrupp eller artikelkategori. Prisberäkningen följer prioriteringen ovan, och priset från ett [ramavtal](/kunskap/inkop/ramavtal-och-avrop) går in i samma kedja.

Beräkningen sker vid orderläggning, vilket betyder att en säljare ser det pris kunden faktiskt får redan när raden läggs in, inte när fakturan skapas.

### Vanliga frågor

**Vad är en prislista?**

En uppsättning priser för artiklar, i en valuta och ofta med giltighetstid, som kopplas till en kund eller kundgrupp. Den gör att återförsäljare, slutkund och exportkund kan ha olika priser utan att någon räknar om per order.

**I vilken ordning gäller priserna?**

Kundspecifikt avtalat pris går före volympris i kundens prislista, som går före baspriset i prislistan, som går före artikelns standardpris. Den mest specifika nivån vinner, vilket är det som gör att en förhandling får genomslag.

**Vad är skillnaden mellan volympris och rabatt?**

Volympris är ett annat pris vid en viss kvantitet och ligger i prislistan. Rabatt är ett avdrag som läggs ovanpå det pris som redan valts. Blandas de ihop är det lätt att rabattera ett pris som redan innehåller volymrabatten.

**Bör rabatten synas på fakturan?**

Ofta ja i B2B. En kund som ser listpris och rabatt separat uppfattar värdet av avtalet. Ett nettopris utan förklaring gör rabatten osynlig, och osynliga rabatter är svåra att ta bort vid nästa förhandling.

---

## B2B-e-handel och kundportal

Källa: https://fluit.se/kunskap/order/b2b-ehandel-och-kundportal
Ämne: Order
Uppdaterad: 2026-08-07

B2B-e-handel skiljer sig från konsumenthandel genom att varje kund har sina egna priser, sin kreditgräns och sina villkor. Kunden är inloggad och känd redan från första sidvisningen, betalar mot faktura i stället för i kassan, och beställer ofta om samma saker. En kundportal löser dessutom det som inte är beställning: orderstatus, dokument och restnoteringar.

**En B2B-webbutik som byggs som en konsumentbutik med inloggning löser fel problem.** Konsumenthandelns svåra delar är att locka besökare, presentera sortimentet och få kassan att konvertera. I B2B är kunden redan kund, vet vad hen vill ha, och det svåra ligger någon helt annanstans.

## Vad som faktiskt skiljer

| | Konsument | B2B |
| --- | --- | --- |
| Kund vid ankomst | Okänd | Inloggad och känd |
| Pris | Publikt och lika för alla | Kundspecifikt, ofta förhandlat |
| Betalning | I kassan | Mot faktura, inom kreditgräns |
| Köpmönster | Enstaka köp | Återkommande, ofta samma rader |
| Beslutsfattare | En person | Flera roller på samma kund |
| Efter köpet | Spårningslänk | Orderstatus, restnoteringar, dokument |

Sista raden är den som brukar underskattas. I B2B står en betydande del av kundens frågor efter beställningen, inte före.

## Priset måste vara kundens eget

En B2B-kund som ser listpris på nätet och ett annat pris på fakturan slutar använda nätbutiken. Priset måste komma ur samma [prisberäkning](/kunskap/order/prislistor-i-b2b) som en order lagd av en säljare: kundspecifikt pris först, sedan volympris, sedan prislista.

Detsamma gäller [ramavtal](/kunskap/inkop/ramavtal-och-avrop). Ligger avtalet i affärssystemet men inte i butiken kommer avropet läggas till fel pris, och sedan får någon rätta det manuellt.

## Tillgänglighet i stället för exakt saldo

B2B-kundens fråga är oftast när, inte om. Kan hen se att varan finns läggs ordern direkt, annars ringer hen och frågar, och då har poängen med självbetjäningen gått förlorad.

Många väljer att visa tillgänglighet grovt: i lager, fåtal kvar, beräknad leverans ett visst datum. Det räcker för beslutet och undviker att exponera exakta saldon för konkurrenter som råkar ha ett kundkonto.

## Portalen är mer än beställning

En del av det som ger mest nytta är inte att lägga order utan att slippa ringa om dem:

- **Orderstatus** på pågående order, inklusive vad som är restnoterat.
- **Orderhistorik** att beställa om ifrån, vilket är den vanligaste vägen till en ny order i B2B (se [snabborder och beställ igen](/kunskap/order/snabborder-och-bestall-igen)).
- **Dokument**: orderbekräftelser, följesedlar, fakturor.
- **Egna artikelnummer**, så att kunden kan söka på sin egen benämning i stället för din.

Det sista är en liten sak som ger stor effekt hos kunder som har en egen artikelstruktur.

## Samma saldo, inte en kopia

Den vanligaste tekniska fällan är att butiken får en kopia av artiklar och saldon som synkas med jämna mellanrum. Då uppstår översäljning, prisdifferenser och en ständig fråga om vilket system som har rätt.

Ligger butiken på samma data som ordersystemet försvinner hela den kategorin av problem. Det är också det som gör att en order från portalen kan gå direkt till plock utan mellansteg.

## I Fluit

[Fluit](/funktioner/kundportal) har en portal för både kunder och [leverantörer](/kunskap/inkop/leverantorsportal), på samma data som resten av systemet. Kunden ser sina order, sin historik och sina dokument, och priser hämtas ur samma prisberäkning som gäller när en säljare lägger ordern.

Vid sidan av portalen finns [e-handel](/funktioner/ehandel) med kanaler, kundvagnar och innehållssidor, där samma artikelregister och samma lagersaldo används. Det är alltså inte två sortiment som ska hållas i takt, utan ett.

### Vanliga frågor

**Vad skiljer B2B-e-handel från vanlig e-handel?**

Kunden är inloggad och känd, priserna är kundspecifika i stället för publika, betalningen sker mot faktura inom en kreditgräns, och beställningarna är ofta återkommande. Dessutom beställer flera personer på samma kund, ibland med olika behörighet.

**Vad är en kundportal?**

En inloggad yta där kunden ser sina egna uppgifter: pågående order och deras status, orderhistorik, fakturor, följesedlar och restnoterade rader. Den kan finnas med eller utan möjlighet att lägga nya order.

**Varför behöver B2B-kunden se lagersaldo?**

För att beslutet ofta är när, inte om. En B2B-kund som ser att artikeln finns kan lägga order direkt, medan den som inte ser det ringer och frågar. Många väljer att visa tillgänglighet grovt i stället för exakt saldo.

**Ska priserna visas publikt?**

Sällan i B2B. Priserna är kundspecifika och ofta förhandlade, vilket gör att de bara ska synas efter inloggning. Ett publikt listpris kan finnas, men det är inte det priset kunden ska betala.

---

## Snabborder och beställ igen i B2B

Källa: https://fluit.se/kunskap/order/snabborder-och-bestall-igen
Ämne: Order
Uppdaterad: 2026-09-29

Snabborder är en beställningsväg där B2B-kunden klistrar in eller laddar upp en lista med artikelnummer och antal i stället för att bläddra i katalogen. Beställ igen lägger raderna från en tidigare order i varukorgen. Båda prissätter varje rad med kundens egna villkor och visar vilka rader som inte gick att beställa, och varför.

**Den som beställer varje månad har sällan behov av en katalog.** Listan finns redan: en Excel-fil, ett mejl från verkstaden eller förra månadens order. Snabborder och beställ igen är de två vägar som går direkt från listan till varukorgen.

## Två vägar, två situationer

| | Snabborder | Beställ igen |
| --- | --- | --- |
| Utgångspunkt | En lista med artikelnummer och antal | En tidigare order |
| Passar | Nya behov som redan står i ett dokument | Återkommande inköp |
| Pris | Dagens pris för kunden, vid det antal som står på raden | Dagens pris, med förra priset som jämförelse |
| Kunden ser innan varukorgen | Vad varje rad blev, eller varför den stoppades | Vilka rader som fått ett nytt pris |

Snabborder är ett svar på hur B2B-kunder faktiskt köper. Beställ igen är den vanligaste vägen till en ny order i B2B, och den blir bättre av att kunden ser prisändringen innan hen bekräftar i stället för på fakturan.

## Så matchas ett nummer mot en artikel

Kunden skriver en artikel per rad, med nummer och antal åtskilda av mellanslag, tab eller semikolon. Två kolumner kopierade ur Excel fungerar direkt. Ett nummer kan vara fyra saker, och de prövas i följande ordning:

1. Kundens eget artikelnummer, om säljaren lagt upp det på kunden.
2. Leverantörens artikelnummer.
3. Artikelns streckkod.
4. En korsreferens, till exempel EAN, ett leverantörsnummer eller ett OEM-nummer.

Ordningen är viktig. En kund som kallar en artikel "100" ska få sin artikel och inte den som råkar ha nummer 100 hos leverantören. Därför vinner kundens eget nummer över alla andra träffar.

Har kundens artikelnummer en egen enhet och en omräkningsfaktor räknas antalet om. Kunden beställer i sin enhet, och ordern läggs i leverantörens.

## Räknat exempel

Exemplet är påhittat och visar hur en lista blir varukorgsrader hos en leverantör som säljer i styck. Kunden klistrar in:

```
BX-500 4
NV-88213 12
```

| Rad | Träff | Antal i varukorgen | Pris per styck | Radsumma |
| --- | --- | --: | --: | --: |
| BX-500 | Leverantörens artikelnummer | 4 st | 85,00 kr | 340,00 kr |
| NV-88213 | Kundens eget nummer, enhet karton, faktor 10 | 12 kartonger blir 120 st | 12,50 kr | 1 500,00 kr |
| Summa | | | | 1 840,00 kr |

Priserna gäller kundens villkor och räknas exklusive moms. Tolv kartonger med faktor 10 blir 120 styck, och raden visar båda talen så att kunden kan se att omräkningen stämmer. Rad två kostar 120 × 12,50 = 1 500 kr, och 340 + 1 500 blir 1 840 kr.

## Beställ igen: tidigare pris mot dagens

På en tidigare order visas raderna med förra priset och dagens pris. Rader där priset ändrats är markerade, och kunden bockar i de som ska med. Exemplet nedan är påhittat.

| Rad | Förra priset | Dagens pris | Markerad |
| --- | --: | --: | --- |
| Skruv M8, förpackning om 100 | 62,00 kr | 62,00 kr | Nej |
| Packning 40 mm | 18,50 kr | 21,00 kr | Ja |
| Utgången artikel | 140,00 kr | Går inte att beställa | Kan inte väljas |

Det som läggs i varukorgen är alltid dagens pris. Förra priset följer aldrig med, det finns bara för jämförelsen.

## Vad som stoppar en rad

Innan något läggs i varukorgen får varje rad ett besked. Raderna som gick att hitta kan läggas i varukorgen med en knapp, och de övriga ligger kvar i rutan så att kunden kan rätta och slå upp igen.

| Orsak | Vad det betyder |
| --- | --- |
| Hittar ingen artikel | Numret finns inte som kundens nummer, artikelnummer, streckkod eller korsreferens |
| Numret passar flera artiklar | Samma korsreferens ligger på två artiklar. Rätta referenserna eller ange leverantörens artikelnummer |
| Går inte att beställa | Artikeln finns men ingår inte i det kunden får köpa där, till exempel för att den inte är publicerad |
| Konfigureras på produktsidan | Artikeln har tillval som kunden måste välja själv |
| Välj variant på produktsidan | Numret pekar på en huvudartikel med varianter |
| Antalet går inte att läsa | Antalet är noll eller innehåller något annat än siffror. Antal ska vara hela tal, och en rad utan antal räknas som 1 |

Filuppladdning tar CSV, text eller Excel (.xlsx) med samma två kolumner, högst 2 MB och 500 rader.

## Att bygga en sådan väg

Tre saker avgör om funktionen blir använd. Priset ska vara detsamma som säljaren skulle ha lagt på ordern, alltså komma ur samma [prisberäkning](/kunskap/order/prislistor-i-b2b) och inte en separat lista. Kundens egna artikelnummer måste vara upplagda, annars matchar hälften av raderna aldrig. Och stoppade rader måste förklaras: en tyst bortfiltrerad rad ger en order som saknar något, och det märks först när varan inte kommer.

Punchout löser ett annat problem. Där handlar köparen i leverantörens butik från sitt eget inköpssystem, se [punchout](/kunskap/inkop/punchout-oci-cxml). Snabborder är för kunden som inte har något inköpssystem att koppla mot.

## I Fluit

I [kundportalen](/funktioner/kundportal) och i webbshoppens Mitt konto finns **Snabborder** som menyval, och **Beställ igen** som knapp på en tidigare orders sida. Båda följer samma regler för vad kunden får köpa och till vilket pris som resten av portalen.

Kontakten behöver behörigheten **Lägga order (kassan)**, via sin portalroll eller en portalgrupp. Utan den syns varken menyvalet eller knappen. Beställ igen gäller bara order som kontakten får se: de egna, eller företagets alla med behörigheten **Se företagets alla ordrar**. Kundens eget artikelnummer, enhet och omräkningsfaktor läggs upp på kunden av er.

### Vanliga frågor

**Vad är snabborder?**

En beställningsväg för kunder som redan vet vad de vill ha. Kunden anger artikelnummer och antal per rad, inklistrat eller i en fil, och ser innan beställning vad varje rad blev och vad den kostar.

**Vilka artikelnummer kan kunden använda?**

Kundens eget artikelnummer, leverantörens artikelnummer, artikelns streckkod eller en korsreferens som EAN eller OEM-nummer. De prövas i den ordningen, så kundens eget nummer vinner om det krockar med ett annat.

**Vilket pris får raderna vid beställ igen?**

Dagens pris. Förra ordinarie priset visas bara som jämförelse, och rader där priset ändrats är markerade. Priset räknas dessutom om när raderna läggs i varukorgen, så en prisändring mellan uppslag och klick följer med.

**Vad händer med rader som inte går att beställa?**

De visas med orsak, till exempel att artikeln saknas, att numret passar flera artiklar eller att artikeln kräver val av variant eller tillval på produktsidan. Rader som gick att hitta läggs i varukorgen, och resten ligger kvar så att kunden kan rätta dem.

---

## Proformafaktura: vad det är och när den behövs

Källa: https://fluit.se/kunskap/order/proformafaktura
Ämne: Order
Uppdaterad: 2026-10-02

En proformafaktura är ett underlag till tullen för varor som skickas utan att säljas, eller där värdet behöver redovisas separat: prover, gåvor, returer, reparationer och varor till mässor. Den visar vad sändningen innehåller och vad varorna är värda, men den är inte ett betalningskrav. Det är den stora skillnaden mot en vanlig faktura.

Skickar du varor ut ur EU utan att sälja dem, som ett prov till en kund i Norge eller en maskin som ska repareras i USA, vill tullen veta vad som skickas och vad det är värt. Eftersom ingen faktura finns tar du fram en **proformafaktura**.

## Vad är en proformafaktura (pro forma invoice)?

En proformafaktura är ett särskilt underlag med information om en sändning. Den ser ut som en faktura, med rader, kvantiteter och värden, men den är inte ett betalningskrav. Tullverket beskriver det som den största skillnaden mot en vanlig faktura: proformafakturan är inte ett underlag för betalning.

Den används när varorna inte har sålts, eller när uppgifter och värde behöver redovisas separat för tulländamål.

## När används den?

Tullverket ger exempel på sändningar där en proformafaktura är rätt underlag:

- ersättnings- och garantivaror
- prover, gratisprover och reklamföremål
- gåvor
- returvaror
- varor som ska förädlas eller repareras
- del- och efterleveranser
- verktyg för att utföra ett arbete
- varor till utställningar och mässor

Gemensamt för dem är att ingen betalar för varan i sändningen, men att tullen ändå behöver veta vad den är värd.

## Vad ska en proformafaktura innehålla?

Tullverket listar uppgifter som en proformafaktura kan innehålla när den används som styrkande handling:

| Uppgift | Kommentar |
| --- | --- |
| Rubriken "Pro Forma Invoice" | Dokumentet läses av tullen i mottagarlandet, därför på engelska |
| Avsändarens och mottagarens namn och adress | |
| Datum | Dagen den upprättas |
| Kolli: antal, typ och märkning | Till exempel 2 kartonger |
| Bruttovikt och nettovikt | |
| Varukod | Tulltaxans nummer för varan |
| Varubenämning och kvantitet | |
| Värde för tulländamål per varuslag | Får inte vara 0 kronor |
| Leveransvillkor | Till exempel DAP Oslo, se [Incoterms](/kunskap/inkop/incoterms-forklarade) |
| Texten "No charge. Value for customs purposes only." | Visar att ingen ska betala |
| Syftet med sändningen | Prov, reparation, retur, utställning |

Ursprungsland och valuta står inte i Tullverkets lista, men är praktiska att ha med. Ska varorna få förmånsbehandling i ett frihandelsavtal deklareras ursprunget separat, med en avtalsbestämd text på fakturan eller ett annat kommersiellt dokument.

## Proformafaktura eller vanlig faktura?

| | Faktura | Proformafaktura |
| --- | --- | --- |
| Betalningskrav | Ja | Nej |
| Betalningsvillkor | Ja | Nej |
| Värde | Pris och rabatter | Värde för tulländamål |
| Moms | Momssats och momsbelopp, eller skälet till 0 % | Ingen moms |
| Används när | Varan säljs | Varan skickas utan att säljas |

Det är innehållet som avgör om en handling är en faktura i momslagens mening, inte vad den heter. En proformafaktura ska därför inte se ut som ett betalningskrav: inget momsbelopp, inga betalningsvillkor och texten om att ingen betalning ska ske.

## Proformafaktura vid förskott?

Ordet används ibland om ett förskottskrav som skickas innan leveransen, för att kunden ska betala i förväg. Det är fel dokument. Momslagen kräver faktura även för förskotts- och a conto-betalningar mellan företag, så ett förskott ska faktureras med en **förskottsfaktura**, med moms, som bokförs som vanligt. Proformafakturan hör hemma hos tullen, inte i kundreskontran.

## Hur länge ska den sparas?

Proformafakturan är en styrkande handling till tulldeklarationen. Den behöver inte bifogas en digital deklaration, men den ska kunna visas upp. Vid export ska den sparas i fem år, räknat från och med året efter det år då deklarationen lämnades. Kräver annan lagstiftning längre tid gäller den.

## Proformafaktura i Fluit

I Fluit skapas proformafakturan från leveransen, som en PDF med samma rader som sändningen. Den visar artikelnummer, varukod och ursprungsland per rad, nettovikt per rad och totalt, bruttovikten för sändningen, värdet i orderns valuta, transportsättet och leveransvillkoret enligt Incoterms 2020 med plats. I inställningarna kan ni lägga till en signeringsruta med namn, titel och signatur.

För en enstaka sändning räcker [fakturamallen](/verktyg/fakturamall): byt läge till proformafaktura, fyll i raderna och spara som PDF.

### Vanliga frågor

**Vad är en proformafaktura?**

Ett underlag med uppgifter om en sändning och värdet på varorna, som används när varorna inte är sålda eller när värdet behöver redovisas separat för tullen. Tullverket beskriver den största skillnaden mot en vanlig faktura som att proformafakturan inte är ett underlag för betalning.

**Kan man betala en proformafaktura?**

Nej, den är inte ett betalningskrav. Ska kunden betala innan leveransen är det en förskottsfaktura som behövs. Momslagen kräver faktura även för förskottsbetalningar mellan företag.

**Vad betyder pro forma?**

Pro forma är latin och betyder ungefär för formens skull. En proformafaktura ser ut som en faktura och har samma rader, men finns för att dokumentera sändningen, inte för att någon ska betala.

**Vad är skillnaden mellan proformafaktura och handelsfaktura?**

Handelsfakturan, den vanliga fakturan, är underlag för betalning och har pris, rabatter och betalningsvillkor. Proformafakturan saknar betalningskrav. I stället har den värdet för tulländamål, varukod, vikter, texten No charge. Value for customs purposes only och syftet med sändningen.

**Får värdet på en proformafaktura vara 0 kronor?**

Nej. Även gratisprover och gåvor har ett värde, och Tullverket anger att värdet för tulländamål per varuslag inte får vara 0 kronor.

**Måste proformafakturan bifogas tulldeklarationen?**

Nej, men den ska kunna visas upp. Styrkande handlingar behöver inte bifogas en digital tulldeklaration. Vid export ska de sparas i fem år, räknat från året efter det år deklarationen lämnades.

---

## Arbetsorder: från planering till avrapportering

Källa: https://fluit.se/kunskap/produktion/arbetsorder
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

En arbetsorder är ett internt uppdrag som samlar allt som hör till ett avgränsat jobb: vad som ska tillverkas eller utföras, i vilket antal, med vilket material, i vilka operationer och av vilken resurs. Den följer ett statusflöde från utkast till avslutad, och det som rapporteras tillbaka på vägen blir underlaget för både lagersaldo och efterkalkyl.

**En arbetsorder är beställningen internt.** Kundordern säger vad kunden ska få. Arbetsordern säger vad verkstaden ska göra för att det ska bli av: vilket material som går åt, vilka moment som ska utföras, av vem och till när.

Den är också den enda plats där man i efterhand kan svara på frågan vad jobbet kostade. Allt som inte rapporteras på arbetsordern är förlorat för kalkylen.

## Vad den håller ihop

En arbetsorder samlar fyra saker som annars lever på olika ställen:

- **Materialet.** Vad som ska förbrukas, hämtat ur [stycklistan](/ordlista/stycklista). Billiga komponenter utan spårningskrav kan flaggas för [backflush](/ordlista/backflush) och räknas då av automatiskt vid färdigrapportering i stället för att kvitteras rad för rad.
- **Operationerna.** Momenten i ordning, med [ställtid](/ordlista/stalltid) och stycktid per moment.
- **Resurserna.** Vilken maskin, station eller person som ska utföra varje operation, eller vilken kompetens som krävs.
- **Utfallet.** Nedlagd tid, förbrukat material, färdiga och kasserade antal.

Saknas operationerna blir arbetsordern en anteckning. Det är operationerna som gör den planeringsbar.

## Statusflödet

Ordern rör sig genom ett antal lägen, och varje övergång betyder något konkret:

| Status | Vad som gäller |
| --- | --- |
| Utkast | Fritt att ändra, ingenting är reserverat |
| Planerad | Operationer och datum satta, material allokerat |
| Väntar | Stoppad i väntan på material, resurs eller beslut |
| Pågående | Minst en operation är startad |
| Pausad | Tillfälligt stoppad, tiden räknas inte |
| Klar | Utfallet rapporterat, produkten inlevererad |
| Avslutad | Kalkylen låst, kvarvarande reservationer släppta |

Skillnaden mellan **väntar** och **pausad** är värd att hålla isär. Väntar betyder att något saknas utifrån, pausad att arbetet avbrutits inifrån. Blandas de ihop går det inte att se vad som faktiskt bromsar produktionen.

## Arbetsorder är inte bara tillverkning

Samma struktur fungerar för fler sorters jobb än tillverkning: en servicetekniker ute hos kund, ett underhållsjobb på en egen maskin, ett avgränsat projektuppdrag. Det gemensamma är att arbetet har ett avgränsat mål, förbrukar material och tid, och ska kunna följas upp.

I [Fluit](/funktioner/arbetsorder) skiljer arbetsordern på just de typerna: tillverkning, projekt, service och underhåll. En operation kan dessutom läggas ut på en leverantör med extern referens, vilket gör att legobearbetning blir en operation i kedjan i stället för ett hål i den.

## Avrapportering är hela poängen

Det som skiljer en arbetsorder från en lapp på en anslagstavla är att den rapporteras tillbaka. Tre saker behöver in:

1. **Tid per operation**, gärna genom start och stopp i stället för en uppskattning i efterhand.
2. **Förbrukat material**, inklusive det som gick åt utöver stycklistan.
3. **Färdiga och kasserade antal**, med orsak till kassationen.

Först då kan efterkalkylen jämföras med förkalkylen, och först då stämmer lagersaldot. En verkstad som rapporterar en gång i veckan har i praktiken ett saldo som är en vecka gammalt.

## Vad som gör det hanterbart

Rapporteringen ska ske där arbetet utförs. Ska en operatör gå till ett kontor och logga in i ett system blir det inte gjort, och då faller hela kedjan.

Fluit har arbetsorder även i mobilappen, med skanning, så att start, stopp, materialuttag och avrapportering görs vid maskinen. Kopplingen till lagret finns i samma system, vilket gör att materialuttaget uppdaterar saldot direkt i stället för vid nästa avstämning.

### Vanliga frågor

**Vad är skillnaden mellan arbetsorder och tillverkningsorder?**

Tillverkningsorder är en arbetsorder som avser tillverkning. Arbetsorder är det bredare begreppet och används även för service, fältarbete, underhåll och projektuppdrag, alltså jobb där resultatet inte är en artikel i lager.

**Vad ska en arbetsorder innehålla?**

Vad som ska göras och i vilket antal, vilket material som går åt, vilka operationer som ska utföras och i vilken ordning, vilken resurs eller kompetens som krävs, samt när det ska vara klart. Utan operationer går det inte att planera kapacitet.

**Vad menas med att rapportera en arbetsorder?**

Att registrera vad som faktiskt hänt: nedlagd tid per operation, förbrukat material, färdiga antal och eventuell kassation. Utan avrapportering blir både lagersaldot och efterkalkylen gissningar.

**Vad händer med material som inte gick åt?**

Det som reserverats men inte förbrukats släpps när ordern avslutas och blir tillgängligt igen. Rapporteras förbrukningen aldrig ligger materialet kvar som låst, och lagret ser mindre ut än det är.

---

## Produktionsplanering med MRP och arbetsorder

Källa: https://fluit.se/kunskap/produktion/produktionsplanering
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

Produktionsplanering är arbetet med att omvandla efterfrågan till konkreta tillverknings- och inköpsbeslut. Utgångspunkten är kundorder och prognoser, som via stycklistan bryts ned till materialbehov per nivå. MRP räknar fram nettobehovet genom att dra bort lagersaldo och inplanerad tillförsel, och backar sedan ledtiderna för att få fram när varje order behöver startas.

**Produktionsplanering svarar på tre frågor: vad ska tillverkas, av vad, och när ska det startas.** De två första är räknearbete. Den tredje är där planeringen brukar spricka, eftersom den kräver att ledtider och kapacitet stämmer med verkligheten.

## Kedjan från behov till order

Planeringen går alltid åt samma håll, oavsett hur avancerat systemet är:

1. **Efterfrågan samlas.** Kundorder, avrop mot [ramavtal](/kunskap/inkop/ramavtal-och-avrop) och prognoser för det som inte är sålt än.
2. **Stycklistan bryter ned.** En färdig produkt blir komponenter, som i sin tur kan vara halvfabrikat med egna stycklistor.
3. **Nettobehovet räknas.** Bruttobehovet minus lagersaldo, minus inplanerade inköp och tillverkningsorder.
4. **Ledtiden backas.** Startdatumet räknas bakåt från behovsdatumet, nivå för nivå.
5. **Förslagen blir order.** Inköpsförslag blir inköpsorder, tillverkningsförslag blir [arbetsorder](/kunskap/produktion/arbetsorder).

Det är i steg fyra multinivåberäkningen får sin poäng. Ett halvfabrikat som behövs om åtta veckor, med två veckors tillverkningstid, behöver sitt material om sex veckor, och det materialet kan ha fyra veckors leveranstid från leverantören.

## Vad som gör beräkningen fel

MRP räknar rätt på de data den får. Fyra fält avgör om resultatet går att lita på:

- **Ledtid per artikel.** En optimistisk ledtid ger förslag som kommer för sent.
- **Stycklistan.** En komponent som saknas i listan planeras aldrig in.
- **Lagersaldot.** Räknas inte kassation och svinn bort blir nettobehovet för lågt.
- **Säkerhetslager och beställningspunkt.** De avgör hur stor bufferten mot variation blir.

Det här är också anledningen till att MRP-projekt sällan misslyckas på beräkningen. De misslyckas på artikeldatan.

## Förslagen behöver granskas, inte godkännas blint

En körning ger ofta hundratals förslag. Det som gör dem hanterbara är att de kommer sorterade och med varningar, så att planeraren kan gå på det som avviker i stället för att läsa allt.

I [Fluit](/funktioner/mrp) ger en MRP-körning både inköpsförslag och tillverkningsförslag, med varningar för de vanliga fallen: artikeln saknar leverantör eller ledtid, saldot ligger under säkerhetslagret, behovet är brådskande, priset har gått ut eller orderdagen ligger långt fram. Godkända förslag blir inköpsorder eller arbetsorder direkt.

Beräkningen tar hänsyn till efterfrågan, lagernivåer, ledtider och säkerhetslager. Nivåerna själva sätter du: Fluit håller beställningspunkt och säkerhetslager per artikel och lager, och räknar med dem, men bestämmer dem inte åt dig.

## Kapaciteten är det andra ledet

MRP svarar på materialfrågan. Den svarar inte på om det finns tid i maskinen. En plan som är materialmässigt perfekt och kapacitetsmässigt omöjlig är fortfarande omöjlig.

Därför är [kapacitetsplaneringen](/kunskap/produktion/kapacitetsplanering) ett eget steg: operationerna på arbetsorderna läggs mot resursernas tillgängliga tid, och där belastningen överstiger kapaciteten måste något flyttas. Det är sällan systemet som avgör vad. Det är en prioriteringsfråga.

## Planera i rätt takt

En vanlig missuppfattning är att MRP ska köras en gång och sedan gälla. I praktiken är planen färskvara: en försenad inleverans, en kasserad batch eller en ändrad kundorder gör om förutsättningarna.

Kör därför beräkningen regelbundet och jämför förslagen mot vad som redan är beställt, i stället för att betrakta varje körning som en ny sanning. Det är avvikelserna mellan körningarna som är informationen.

### Vanliga frågor

**Vad är skillnaden mellan MRP och produktionsplanering?**

MRP är beräkningen: den räknar fram vad som behövs, i vilken mängd och när. Produktionsplanering är det bredare arbetet, där MRP-förslagen vägs mot kapacitet, prioriteringar och verkligheten på golvet innan de blir order.

**Vad är nettobehov?**

Bruttobehovet minus det som redan finns eller är på väg. Behövs 500 enheter, finns 120 i lager och 200 är inbeställda, är nettobehovet 180. Det är den siffran som blir ett förslag.

**Varför får jag brådskande förslag med startdatum bakåt i tiden?**

För att MRP backar ledtiden från behovsdatumet. Är ledtiden längre än tiden fram till behovet hamnar startdatumet i det förflutna. Det är inte ett fel i beräkningen utan en signal om att behovet inte hinner täckas i tid.

**Behöver jag prognoser för att planera produktion?**

Inte om ledtiderna är korta och du bara tillverkar mot order. Så snart ledtiden mot kund är kortare än ledtiden för material måste något planeras innan ordern finns, och då krävs en prognos eller en policy för lagerhållning.

---

## Kapacitetsplanering och ställtid

Källa: https://fluit.se/kunskap/produktion/kapacitetsplanering
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

Kapacitetsplanering handlar om att ställa den tid som arbetet kräver mot den tid resurserna faktiskt har. Behovet per operation räknas som ställtid plus stycktid gånger antal, och summeras per resurs och period. Ställtiden är fast oavsett seriestorlek, vilket gör att både orderstorlek och den ordning jobben körs i påverkar hur mycket som ryms i en vecka.

**Kapacitetsplanering är att jämföra två tal: hur mycket tid arbetet kräver och hur mycket tid som finns.** Räkningen är enkel. Det svåra är att båda talen förändras hela tiden, och att det ena av dem beror på i vilken ordning jobben körs.

## Så räknas behovet

Varje operation på en [arbetsorder](/kunskap/produktion/arbetsorder) bär två tider:

- **Ställtid**: förberedelsen. Verktygsbyte, inställning, materialhämtning, körning fram till godkänd första detalj.
- **Stycktid**: tiden per enhet när maskinen väl går.

Behovet blir då:

| Serie | Ställtid | Stycktid | Total tid | Per enhet |
| --- | --- | --- | --- | --- |
| 20 st | 45 min | 1,5 min | 75 min | 3,75 min |
| 200 st | 45 min | 1,5 min | 345 min | 1,73 min |
| 2 000 st | 45 min | 1,5 min | 3 045 min | 1,52 min |

Tabellen visar varför små serier är dyra. Ställtiden är densamma oavsett antal, så styckkostnaden faller snabbt i början och planar sedan ut. Det är precis den avvägningen som [ekonomisk seriestorlek](/verktyg/epq) sätter ett tal på.

## Så räknas kapaciteten

Tillgänglig tid är inte samma sak som klocktid. Från kalendertiden dras skiftschema, raster, planerat [underhåll](/kunskap/produktion/forebyggande-underhall), semester och frånvaro. Det som blir kvar är kapaciteten.

Ett vanligt misstag är att räkna med hundra procents utnyttjande. Ingen resurs går att belägga fullt, eftersom variation i tillflöde och små störningar äter upp marginalen. En plan lagd på full kapacitet är i praktiken en plan som redan är försenad.

## Resursgrupper och kompetens

Två maskiner som kan samma sak bör planeras som en grupp, inte var för sig. Då kan belastningen fördelas dit det finns tid, och planen behöver inte göras om varje gång en enskild maskin stökar.

Personal fungerar likadant men med ett extra villkor: alla kan inte allt. En operation som kräver svetsbehörighet kan inte fördelas till vem som helst i gruppen, och det är den sortens krav som avgör om planen är genomförbar eller bara ser fin ut.

I [Fluit](/funktioner/resurser-och-kapacitet) finns resurser med kapacitet per period, resursgrupper med medlemmar, kompetenskrav per operation och möjlighet att lägga in kapacitetsöverstyrningar för perioder som avviker. Operationer kan ha ställtid, stycktid per enhet, överlappning i procent och en föregående operation som måste vara klar först.

## Sekvensen påverkar kapaciteten

Det som gör kapacitetsplanering svårare än en summering är att belastningen beror på ordningen. Körs fem jobb som kräver samma verktygsuppsättning efter varandra behövs en ställtid. Sprids de ut över veckan behövs fem.

Det betyder att en plan kan bli genomförbar utan att någonting tas bort, bara genom att jobben grupperas om. Det är också därför en helt automatisk sekvensering sällan slår en planerare som känner maskinparken.

## Flaskhalsen styr

I de flesta verkstäder är det en eller två resurser som avgör hur mycket som kommer ut. Kapacitet som frigörs någon annanstans ökar inte genomflödet, den bygger bara upp mellanlager framför flaskhalsen.

Planera därför flaskhalsen först och låt resten följa. Det är en enklare regel än den låter, och den gör skillnaden mellan en plan som håller och en som ser komplett ut i systemet.

### Vanliga frågor

**Hur räknar man ut kapacitetsbehovet för en operation?**

Ställtid plus stycktid gånger antal. En operation med 45 minuters ställtid och 1,5 minuters stycktid tar 45 + 1,5 × 200 = 345 minuter för en serie på 200, alltså knappt sex timmar.

**Vad är ställtid?**

Tiden det tar att förbereda en resurs för ett jobb: byta verktyg, ställa in maskinen, hämta material och köra fram till godkänd första detalj. Den är oberoende av seriestorleken, vilket gör att den slår hårdare ju mindre serien är.

**Vad är skillnaden mellan kapacitet och belastning?**

Kapacitet är den tid som finns tillgänglig i en period, efter avdrag för skift, raster, planerat underhåll och frånvaro. Belastning är den tid det planerade arbetet kräver. Överstiger belastningen kapaciteten kommer planen inte att hålla.

**Vad menas med överlappning mellan operationer?**

Att nästa operation börjar innan den föregående är helt klar, till exempel när halva serien är färdig. Det kortar genomloppstiden utan att minska kapacitetsbehovet, eftersom samma antal timmar fortfarande ska utföras.

---

## Kvalitetskontroll och mottagningskontroll

Källa: https://fluit.se/kunskap/produktion/kvalitetskontroll
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

Kvalitetskontroll är de kontroller som görs för att verifiera att material och produkter uppfyller ställda krav. Den byggs som kontrollplaner med kontrollpunkter, där varje punkt anger vad som ska kontrolleras, hur svaret registreras och vilka toleranser som gäller. Kontrollen kan ske vid mottagning, under processen, som slutkontroll eller före utleverans.

**Kvalitetskontroll är att bestämma i förväg vad som ska kontrolleras, och sedan göra det.** Det låter trivialt, men skillnaden mellan en verksamhet som har kontroll och en som har åsikter om kvalitet ligger nästan alltid i om kraven är nedskrivna som mätbara punkter.

## Kontrollplanen

En kontrollplan beskriver vad som ska kontrolleras på en artikel eller i en process. Den består av kontrollpunkter, och varje punkt behöver tre saker:

1. **Vad som kontrolleras.** Ett mått, en funktion, ett utseende, ett dokument.
2. **Hur svaret registreras.** Ett mätvärde, ett godkänt eller underkänt, ett val ur en lista, ett foto, en signatur.
3. **Vad som är godkänt.** Toleranser för mätvärden, förväntat val för listor.

Skillnaden mellan en mätning och en bedömning är viktigare än den verkar. Ett mätvärde mot en tolerans kan systemet bedöma automatiskt. Ett godkänt eller underkänt kräver att en människa tar ställning, och därmed att någon är ansvarig.

## Var i flödet kontrollen sitter

Fyra lägen täcker det mesta:

| Läge | Fångar | Kostnad om felet slinker igenom |
| --- | --- | --- |
| Mottagning | Fel från leverantör | Fel material i färdig produkt |
| I process | Inställningsfel, drift | Hela serien blir fel |
| Slutkontroll | Monteringsfel | Reklamation från kund |
| Före utleverans | Fel vara, fel antal, transportskada | Returfrakt och trovärdighet |

Ju tidigare kontrollen sitter, desto billigare blir felet. Det är hela argumentet för [mottagningskontroll](/kunskap/inkop/inleverans-och-godsmottagning): en avvikelse som upptäcks på lastkajen är en reklamation till leverantören, samma avvikelse upptäckt i en levererad produkt är en kundreklamation plus en utredning.

## Hur mycket ska kontrolleras

Full kontroll av allt är sällan rimligt. Tre nivåer räcker långt:

- **Varje enhet**, för kritiska egenskaper där ett enda fel är oacceptabelt.
- **Stickprov**, för det mesta. Ett urval kontrolleras och utfallet får representera partiet.
- **Första bit**, när en serie startas eller en maskin ställts om. Fångar inställningsfel innan de multipliceras.

Valet är en avvägning mellan kontrollkostnad och felkostnad, och det bör göras per artikel snarare än som en generell policy.

## Beslutet efter kontrollen

En kontroll som inte leder till ett beslut är bara dokumentation. Efter kontrollen ska partiet få ett uttalat utfall: godkänt, underkänt eller godkänt med avvikelse. Det sista är vanligare än man tror, och behöver vara ett medvetet beslut med någon som står bakom det, inte en tyst praxis.

Underkänt material ska dessutom spärras fysiskt. Ligger det kvar på en vanlig lagerplats kommer det förr eller senare att plockas.

## Så ser det ut i ett system

I [Fluit](/funktioner/kvalitetskontroll) byggs kontroller som kvalitetskontrollplaner med kontrollpunkter. En punkt kan besvaras som mätvärde mot tolerans (systemet bedömer), som godkänt eller underkänt (människan bedömer), som kvittering av ett utfört moment, som val ur en kodkatalog, som fritext, som foto eller som signatur.

Kontrollen kan knytas till mottagning, process, slutkontroll eller utleverans, och urvalet sättas till varje enhet, stickprov eller första bit. Inspektionen får ett uttalat beslut: godkänn, avvisa eller godkänn med avvikelse. Blir utfallet underkänt går det vidare till [avvikelsehanteringen](/kunskap/produktion/avvikelsehantering), och lagerplatser med typen karantän gör att spärrat material inte kan plockas av misstag.

### Vanliga frågor

**Vad är mottagningskontroll?**

Kontrollen av inkommande material innan det tas in i lagret eller används i produktionen. Syftet är att fånga fel hos leverantören medan det fortfarande går att reklamera, i stället för att upptäcka dem i en färdig produkt hos kund.

**Måste allt kontrolleras?**

Nej. Kontroll kostar tid, och full kontroll av allt är sällan motiverat. Vanligt är stickprov på det mesta, full kontroll på kritiska egenskaper och första-bit-kontroll när en ny serie startas eller en maskin ställts om.

**Vad är första-bit-kontroll?**

Att den första detaljen ur en ny uppsättning kontrolleras och godkänns innan resten av serien körs. Den fångar inställningsfel medan bara en detalj är gjord, i stället för när hela serien ligger på pallen.

**Vad är skillnaden mellan kontroll och avvikelse?**

Kontrollen är mätningen och bedömningen. Blir utfallet underkänt uppstår en avvikelse, som är en egen process med orsaksutredning och beslut om vad som ska hända med det som inte höll måttet.

---

## Avvikelsehantering steg för steg

Källa: https://fluit.se/kunskap/produktion/avvikelsehantering
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

Avvikelsehantering är processen från att något inte uppfyller kraven till att det är omhändertaget och orsaken åtgärdad. Avvikelsen registreras med beskrivning och allvarlighetsgrad, materialet spärras, och ett dispositionsbeslut fattas om vad som ska hända med det: användas som det är, omarbetas, kasseras, returneras eller omklassas. Orsaksutredningen är det som avgör om felet återkommer.

**En avvikelse är något som inte uppfyller kraven.** Fel mått på en detalj, fel artikel i en leverans, en skadad förpackning, en saknad certifikatkopia. Storleken varierar enormt, men hanteringen ser likadan ut, och det är just därför den går att göra till en process i stället för en serie improvisationer.

## Två beslut som ofta blandas ihop

Den viktigaste distinktionen i avvikelsehantering är mellan **vad som händer med materialet** och **vad som händer med orsaken**.

Det första är brådskande: hundra detaljer ligger i vägen och någon ska bestämma vad som görs med dem. Det andra är viktigt: om orsaken står kvar kommer nästa hundra att bli likadana.

Verksamheter som bara gör det första har en avvikelsehantering som fungerar och en kvalitet som inte förbättras.

## Dispositionsbeslutet

Vad som händer med det avvikande materialet är ett val mellan ett fåtal alternativ:

| Beslut | När det är rimligt |
| --- | --- |
| Använd som det är | Avvikelsen påverkar inte funktionen och kunden accepterar den |
| Omarbeta | Går att rätta till godkänt skick till en rimlig kostnad |
| Kassera | Går inte att rädda, eller kostar mer än det smakar |
| Returnera | Leverantörens fel, och reklamationsfristen håller |
| Omklassa | Duger till en lägre kvalitetsnivå eller ett annat användningsområde |

Beslutet **använd som det är** förtjänar särskild uppmärksamhet. Det är fullt legitimt, men bara som ett uttalat beslut med någon bakom sig. Blir det en tyst vana har toleranserna i praktiken flyttats utan att någon bestämt det.

## Spärra först, besluta sedan

Mellan upptäckt och beslut är materialet i farozonen. Ligger det kvar på en vanlig lagerplats kommer det att plockas, eftersom plockaren följer plocklistan och inte den senaste diskussionen.

Därför är fysisk eller systemmässig spärr det första som ska ske. En egen karantänplats, eller ett spärrat läge på batchen, gör att saldot inte är tillgängligt förrän någon aktivt släpper det.

## Allvarlighetsgraden styr takten

Alla avvikelser förtjänar inte samma uppmärksamhet. En tredelad skala räcker:

- **Mindre**: påverkar inte funktion eller säkerhet. Hanteras i normal takt.
- **Större**: påverkar funktion, kundleverans eller kostnad. Kräver beslut snabbt.
- **Kritisk**: rör säkerhet, regelefterlevnad eller ett större parti. Kräver beslut nu och ofta att leveranser stoppas.

Graden avgör också vilka som behöver vara med. En kritisk avvikelse på en levererad produkt är inte ett verkstadsbeslut.

## Orsaken sitter sällan där felet syns

Den vanligaste avslutningen på en bristfällig utredning är att någon gjorde fel. Det är nästan alltid ett symptom. Frågan som tar utredningen vidare är varför processen tillät felet: fanns instruktionen, gick den att följa under tidspress, hade avvikelsen upptäckts om ingen råkat titta.

En användbar test på om rätt orsak hittats: hade den föreslagna åtgärden förhindrat felet? Är svaret nej är utredningen inte klar.

## Vad systemet ska hålla

I [Fluit](/funktioner/kvalitetskontroll) registreras avvikelser med beskrivning, allvarlighetsgrad (mindre, större eller kritisk) och koppling till det som berörs. Dispositionen sätts som ett eget beslut med alternativen använd som det är, omarbeta, kassera, returnera och omklassa, och avvikelsen följer ett statusflöde från öppen via granskning och dispositionerad till stängd.

Kopplingen till [spårbarheten](/kunskap/produktion/sparbarhet) är det som gör avgränsningen möjlig. Vet du vilken batch som berörs vet du också vilka order som fått material ur den, och därmed hur stort problemet är.

### Vanliga frågor

**Vad är en avvikelse?**

Något som inte uppfyller ett ställt krav: fel mått, fel material, skadad förpackning, saknad dokumentation. Avvikelsen är själva iakttagelsen, medan dispositionen är beslutet om vad som ska hända med det som avviker.

**Vad betyder disposition?**

Beslutet om vad som ska ske med det avvikande materialet. De vanliga alternativen är att använda som det är, omarbeta, kassera, returnera till leverantör eller omklassa till en annan kvalitet. Beslutet ska fattas av någon med befogenhet och dokumenteras.

**Vad är skillnaden mellan korrigerande och förebyggande åtgärd?**

En korrigerande åtgärd tar bort orsaken till ett fel som redan inträffat. En förebyggande åtgärd tar bort orsaken till ett fel som ännu inte inträffat men bedöms kunna göra det. Båda skiljer sig från själva omhändertagandet av materialet.

**Hur vet jag att jag hittat rätt orsak?**

En rimlig test är om åtgärden hade förhindrat felet. Landar utredningen i att någon var slarvig är orsaken oftast inte funnen, eftersom slarv är ett symptom på en process som tillåter fel.

---

## Spårbarhet med batch och serienummer

Källa: https://fluit.se/kunskap/produktion/sparbarhet
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

Spårbarhet är förmågan att följa en vara bakåt till sitt ursprung och framåt till sin mottagare. Den byggs med batchnummer för partier eller serienummer för enskilda individer, registrerade vid inleverans, förbrukning och utleverans. Är kedjan obruten kan en återkallelse avgränsas till de partier som faktiskt berörs i stället för hela sortimentet.

**Spårbarhet är förmågan att svara på två frågor snabbt.** Bakåt: vad består den här produkten av och varifrån kom materialet? Framåt: vem har fått något ur det här partiet?

Den första frågan ställs vid felsökning. Den andra ställs vid en återkallelse, och då är svarstiden skillnaden mellan att dra in tre pallar och att dra in ett halvårs produktion.

## Batch eller serienummer

Valet handlar om vad som är den meningsfulla enheten.

| | Batch | Serienummer |
| --- | --- | --- |
| Identifierar | Ett parti | En individ |
| Typiskt för | Råvara, komponenter, livsmedel, kemikalier | Maskiner, elektronik, allt med garanti |
| Registrering | Per parti vid in och ut | Per exemplar vid in och ut |
| Arbetsinsats | Låg | Hög |
| Precision vid återkallelse | Partiet | Exakt exemplar |

En del produkter behöver båda: ett serienummer på den färdiga maskinen och batchnummer på de komponenter som byggts in i den. Då kan en komponentavvikelse översättas till en lista över exakt vilka maskiner som berörs.

## Var kedjan bryts

Spårbarheten är aldrig starkare än sitt svagaste registreringstillfälle. Det finns fyra ställen där numret måste fångas:

1. **Vid inleverans.** Batchnumret från leverantörens följesedel knyts till det mottagna antalet.
2. **Vid uttag.** Vilken batch som togs ut till vilken arbetsorder eller kundorder.
3. **Vid tillverkning.** Vilka ingående batcher som byggts in i vilket utgående parti.
4. **Vid utleverans.** Vilket parti eller vilken individ som gick till vilken kund.

Missas steg två spelar det ingen roll hur noga steg ett och fyra sköts. Kedjan är bruten, och det märks först när någon frågar.

## Hållbarhet och uttagsordning

Har partierna utgångsdatum räcker det inte att veta vilken batch som finns. Uttagen behöver också ske i rätt ordning, annars byggs det upp gamla partier längst in i hyllan.

Det är skillnaden mellan [FIFO och FEFO](/kunskap/lager/fifo-fefo-lagervardering): först in först ut, eller först utgången först ut. För varor med hållbarhet är FEFO det enda rimliga, och det förutsätter att utgångsdatumet finns registrerat på batchen och inte bara på kartongen.

## Spärrat material

Spårbarhet och spärr hör ihop. När en batch visar sig avvikande ska den kunna spärras så att saldot inte längre är plockbart, utan att någon behöver leta rätt på var kartongerna står.

Det görs på två sätt som kompletterar varandra: en status på batchen som spärrar saldot systemmässigt, och en lagerplats av typen karantän dit materialet flyttas fysiskt. Det första hindrar plocklistan, det andra hindrar den som plockar utan lista.

## Hur mycket är lagom

Full spårbarhet på allt låter ansvarsfullt och blir i praktiken ohållbart. Varje registrering kostar tid, och tid som läggs på att skanna batchnummer på packtejp tas från något annat.

En rimlig avgränsning är att spåra det som är kritiskt för funktion eller säkerhet, det som omfattas av regelkrav och det som har begränsad hållbarhet. Resten hanteras på saldonivå.

## I ett system

Fluit har spårningstyp per artikel, och även per artikel och lager: ingen spårning, full serienummerspårning in och ut, serienummer bara vid utleverans, eller batchspårning. Batcher bär status och utgångsdatum, vilket ger både FEFO-uttag och möjlighet att spärra ett parti.

Registreringen sker i WMS-appen med skanning, vilket är avgörande. En spårbarhet som kräver att någon skriver av nummer för hand blir en spårbarhet som är ungefär rätt, och ungefär rätt duger inte när frågan väl ställs.

### Vanliga frågor

**Vad är skillnaden mellan batch och serienummer?**

Ett batchnummer identifierar ett parti som tillverkats eller mottagits tillsammans och som delar egenskaper. Ett serienummer identifierar en enskild individ. Batch används när partiet är den meningsfulla enheten, serienummer när varje exemplar behöver följas för sig, till exempel vid garanti och service.

**Vad menas med spårning framåt och bakåt?**

Bakåt betyder att gå från en färdig produkt till vilket material den innehåller och vilken leverantör det kom från. Framåt betyder att gå från ett parti till alla kunder som fått något ur det. Vid en återkallelse behövs framåtspårningen, vid en felsökning bakåtspårningen.

**Måste allt spåras?**

Nej. Spårbarhet kostar tid vid varje registrering, och full spårbarhet på skruvar och packtejp ger sällan något. Vanligt är att spåra det som är kritiskt för funktion, säkerhet eller regelefterlevnad, och det som har begränsad hållbarhet.

**Vad krävs för att spårbarheten ska hålla?**

Att registreringen sker vid varje överlämning: inleverans, uttag till order, tillverkning och utleverans. Ett enda steg där numret inte registreras bryter kedjan, och då är det inte längre möjligt att avgränsa vilka enheter som berörs.

---

## Förebyggande underhåll och underhållsplan

Källa: https://fluit.se/kunskap/produktion/forebyggande-underhall
Ämne: Produktion & kvalitet
Uppdaterad: 2026-08-07

Förebyggande underhåll är underhåll som utförs enligt plan innan något går sönder, till skillnad från avhjälpande underhåll som sker efter ett haveri. Planen anger vilka åtgärder som ska utföras på vilken utrustning och hur ofta, med intervall satta antingen på kalendertid eller på mätarställning som drifttimmar. Vid intervallets slut genereras en arbetsorder.

**Förebyggande underhåll är att välja när maskinen står still.** Alternativet är inte att den aldrig står still, utan att den gör det vid ett tillfälle som någon annan bestämt, oftast under högsäsong och alltid utan reservdelar hemma.

Kostnaden för ett oplanerat stopp ligger sällan i reparationen. Den ligger i produktionsbortfallet, i expressfrakten på delen och i de order som får flyttas.

## Kalender eller mätare

Intervallet kan sättas på två sätt, och valet beror på vad som faktiskt sliter.

**Kalenderintervall** passar när nedbrytningen sker med tiden: gummidetaljer som torkar, olja som åldras, kontroller som ska ske en gång per år oavsett hur mycket utrustningen använts. Uttrycks i dagar, veckor, månader eller år.

**Mätarintervall** passar när slitaget följer användningen: drifttimmar, antal cykler, körda kilometer. En maskin som går treskift ska servas oftare än en likadan maskin som går halvtid, och kalendern kan inte se skillnaden.

**Båda** behövs oftare än man tror. En kompressor som går 3 000 timmar om året och en som går 300 behöver samma oljebyte vid samma timtal, men den som står mest behöver det ändå med jämna mellanrum. Regeln blir då att det som inträffar först utlöser åtgärden.

## Planen ska bli en arbetsorder

Skillnaden mellan en underhållsplan som fungerar och en som ligger i en pärm är om den genererar något.

En plan som når fram gör tre saker: den skapar en [arbetsorder](/kunskap/produktion/arbetsorder) när intervallet löper ut, den lägger jobbet i samma kö som allt annat arbete så att det syns i [kapacitetsplaneringen](/kunskap/produktion/kapacitetsplanering), och den listar de reservdelar som behövs så att bristen upptäcks före och inte under.

Ligger underhållsjobben i ett eget system som ingen planerare tittar i konkurrerar de om samma timmar utan att någon vet om det. Då förlorar underhållet varje gång, eftersom produktionen har ett leveransdatum och underhållet bara har en rekommendation.

## Checklistan avgör kvaliteten

Ett underhållsjobb formulerat som "service av press 3" blir vad teknikern minns att det brukar vara. Formulerat som konkreta moment att kvittera ett och ett blir det samma varje gång, oavsett vem som utför det.

Momenten ska vara möjliga att svara på: ett mätvärde med en tolerans, ett utfört moment att kvittera, ett foto på ett slitage. Då blir underhållsrapporten också data om utrustningens tillstånd över tid, inte bara en signatur på att någon var där.

## Följ upp intervallet

Ett intervall satt vid införandet är en gissning grundad på tillverkarens rekommendation. Efter ett år finns bättre underlag:

- Inträffade haverier mellan servicetillfällena betyder att intervallet är för långt.
- Delar som byts men visar sig hela betyder att det är för kort.
- Åtgärder som konsekvent skjuts upp betyder antingen att de är onödiga eller att tiden aldrig planerats in.

## I ett system

I [Fluit](/funktioner/underhall) sätts underhållsplaner per utrustning med intervall på kalender, på mätarställning eller på båda, där det som inträffar först utlöser. Kalenderintervallet anges i dagar, veckor, månader eller år. Planen har status aktiv, pausad eller arkiverad, och det är den aktiva planen som genererar arbetsordrar.

Arbetsordern som skapas är av typen underhåll och hamnar i samma flöde som tillverknings- och serviceorder, med material, operationer, tid och avrapportering. Kopplingen till [kontrakt och tillgångar](/funktioner/kontrakt-och-tillgangar) gör att underhåll som utförs enligt ett serviceavtal med kund kan följas mot avtalet, inte bara mot maskinen.

### Vanliga frågor

**Vad är skillnaden mellan förebyggande och avhjälpande underhåll?**

Förebyggande underhåll utförs enligt plan innan något går sönder, vid en tidpunkt du valt. Avhjälpande underhåll utförs efter ett haveri, vid en tidpunkt maskinen valt. Skillnaden i kostnad ligger sällan i själva reparationen utan i produktionsbortfallet.

**Kalenderintervall eller mätarintervall?**

Kalender för det som åldras oavsett användning, till exempel gummidetaljer och oljor som bryts ned över tid. Mätare för det som slits av användning, som drifttimmar eller antal cykler. Utrustning som utsätts för båda bör ha båda, där det som inträffar först utlöser åtgärden.

**Vad ska en underhållsplan innehålla?**

Vilken utrustning den gäller, vilka åtgärder som ska utföras, med vilket intervall, hur lång tid de tar och vilka reservdelar och verktyg som behövs. Åtgärderna ska vara formulerade så att de går att kvittera en och en.

**Hur vet jag om intervallet är rätt?**

Genom att följa upp. Inträffar haverier mellan servicetillfällena är intervallet för långt. Byts delar som visar sig vara i gott skick är det för kort. Det är ett tal som ska justeras med erfarenhet, inte sättas en gång.

---

# Ordlista

## 3PL (tredjepartslogistik)

Källa: https://fluit.se/ordlista/3pl
Kategori: Lager
Uppdaterad: 2026-08-31

3PL, tredjepartslogistik, innebär att lagerhållning och distribution läggs ut på en extern logistikpartner i stället för att drivas i eget lager. Partnern tar emot godset, lagrar det, plockar, packar och skickar i ditt namn. Kontrollen behålls genom en integration mellan affärssystemet och partnerns WMS.

**3PL, eller tredjepartslogistik, innebär att du lägger ut lagerhållning och distribution på en extern logistikpartner i stället för att driva ett eget lager.** Partnern tar emot godset, lagrar det, plockar, packar och skickar i ditt namn.

Skälen att gå den vägen är oftast ekonomiska. Du slipper binda kapital i lokaler och får lägre fasta kostnader. Lika viktigt är att en bra partner kan skala upp och ner med dig vid säsongstoppar eller tillväxt, och att du får tillgång till logistikkompetens och flera utlämningspunkter geografiskt.

Det som blir svårare är kontrollen. När varorna fysiskt står hos någon annan måste lagersaldo och leveranser ändå stämma i dina system. Lösningen är en integration mellan affärssystemet och partnerns WMS (Warehouse Management System): order skickas över, och saldon och leveransbekräftelser kommer tillbaka i realtid.

I Fluit kan order och saldon utbytas med en 3PL-partners system, så att lagerflödet hänger ihop även när själva lagret ligger utanför huset. Se [3PL-lager i praktiken](/3pl) för hur flödet ser ut, eller [lagerhantering och logistik i Fluit](/funktioner/lager-och-logistik) för hur saldona hålls ihop.

### Vanliga frågor

**Vad står 3PL för?**

Tredjepartslogistik: att lagerhållning och distribution läggs ut på en extern logistikpartner i stället för att drivas i eget lager. Partnern tar emot godset, lagrar det, plockar, packar och skickar i ditt namn.

**Hur behåller man kontroll över saldot med 3PL?**

Genom en integration mellan affärssystemet och partnerns WMS: order skickas över, och saldon och leveransbekräftelser kommer tillbaka i realtid.

---

## Agentic ERP

Källa: https://fluit.se/ordlista/agentic-erp
Kategori: AI
Uppdaterad: 2026-07-31

Agentic ERP är ett affärssystem där en AI-agent kan utföra arbete i systemet, inte bara svara på frågor om det. Agenten har systemets egna funktioner som verktyg: den söker fram underlaget, väljer åtgärd och kör den med den inloggade användarens behörigheter, märkt i loggen som agentens och inte som människans. Skillnaden mot en vanlig AI-chatt är att svaret blir en ändring i systemet, inte en text att kopiera.

**Agentic ERP är ett affärssystem där en AI-agent kan utföra arbete i systemet, inte bara svara på frågor om det.** Agenten har systemets egna funktioner som verktyg och kör dem med den inloggade användarens behörigheter.

Begreppet växte fram när språkmodeller fick verktyg. En modell som bara kan läsa och skriva text kan förklara hur man lägger en inköpsorder. En modell som kan anropa funktioner kan lägga den. Det är hela skillnaden mellan generativ och agentic AI, och den märks direkt i vardagen: det ena sparar dig ett Google-sök, det andra sparar dig arbetsmomentet.

Därför är det värt att fråga vad en leverantör menar med ordet. Ett affärssystem med en chattruta som söker i hjälpartiklarna är inte agentic. Ett system där AI:n kan skapa en offert, allokera en order eller stänga ett ärende är det, förutsatt att åtgärderna går genom systemets vanliga regler och inte en gräddfil förbi dem.

Det är också där de verkliga frågorna ligger. Vad kommer agenten åt? Om den kör med en egen servicebehörighet ser den allt, och då blir en fråga från en säljare en väg till inköpspriserna. Vad händer om den gör fel? En åtgärd som inte syns i aktivitetsloggen går inte att felsöka i efterhand. Och vem godkände? Ett orderförslag som landar i granskning är något annat än en order som redan är lagd.

Ett ERP är dessutom räkenskapsinformation, vilket gör spårbarheten till mer än en bekvämlighet. Revisionen utgår från att varje förändring går att härleda till en ansvarig. En agent som ändrar priser eller annullerar ordrar utan att lämna ett spår som skiljer sig från en människas är därför inte en skavank i gränssnittet, utan ett revisionsproblem. Det är också den vanligaste orsaken till att agentprojekt stannar av: inte att modellen är för svag, utan att ingen vågar släppa fram den.

Den andra halvan av begreppet handlar om vem som får agera. En agent inne i systemet är ett bra första steg, men bolag använder redan assistenter i sitt övriga arbete. Att kunna koppla in dem mot affärssystemet kräver ett protokoll, och i praktiken är det [MCP](/ordlista/mcp) som gäller i dag.

I Fluit finns båda delarna: en assistent i systemet som kör mot era egna uppslag och åtgärder, och en MCP-server som låter en assistent ni redan använder göra samma sak. Vad AI:n får och inte får göra står på [AI i Fluit](/ai), och den längre genomgången finns på [agentic ERP](/agentic-erp). Var Fluit ligger på branschens mognadsskala, och vad som saknas, står på [AI-mognad](/ai/mognadsmodell).

### Vanliga frågor

**Vad är skillnaden mellan agentic ERP och en AI-chatt i affärssystemet?**

En AI-chatt svarar på frågor och sammanfattar. En agent utför åtgärder: skapar ordern, bokar frakten, stänger ärendet. Gränsen går vid om AI:n har tillgång till systemets funktioner som verktyg eller bara till dess data. Många system har bara det senare och kallar det ändå agentic.

**Tar agenten beslut på egen hand?**

Den utför det den blir ombedd att utföra, inom den inloggade användarens behörigheter. Ett välbyggt agentic ERP håller tre saker isär: att läsa, att föreslå och att verkställa. Läsning kan vara fri, förslag ska gå att granska innan de blir poster, och varje verkställd åtgärd ska synas i loggen efteråt.

**Vad krävs för att ett affärssystem ska kunna vara agentic?**

Fem saker. Att systemets funktioner går att anropa som verktyg, inte bara som skärmar. Att behörighetsmodellen gäller även för agenten. Att loggen skiljer agentens ändringar från människans, så att en revisor kan se vem som gjorde vad och på vems mandat. Att gränserna sitter på servern, så att en klient inte kan strunta i dem. Och att kopplingen går att öppna utåt, i praktiken via MCP, så att en assistent företaget redan använder kan arbeta mot systemet.

---

## ATP (Available-to-Promise)

Källa: https://fluit.se/ordlista/atp
Kategori: Order
Uppdaterad: 2026-07-30

ATP, Available-to-Promise, anger hur mycket av en artikel som faktiskt kan lovas en kund till ett visst datum. Beräkningen väger samman fritt lagersaldo i dag, inkommande inleveranser med sina datum och det som redan är reserverat mot andra order. Därför kan ATP vara noll i dag och betydande om två veckor.

**ATP, Available-to-Promise, anger hur mycket av en artikel du faktiskt kan lova en kund till ett visst datum.** Frågan ATP svarar på är "kan vi lova leverans, och i så fall när?", och svaret blir mer precist än om du bara tittar på dagens lagersaldo.

Beräkningen väger samman tre saker över tid: vad som finns tillgängligt i lager i dag, vilka inköp som är på väg in och med vilka inleveransdatum, samt hur mycket som redan är reserverat mot andra order. Lägger man det på en tidsaxel framträder hur mycket som är fritt att lova vid varje framtida datum, även för antal som ännu inte finns på hyllan men som är beställda.

Vinsten är konkret. Säljaren kan ge ett leveranslöfte som håller, och risken för översäljning eller alltför optimistiska leveranstider minskar.

I Fluit används ATP för att ge realistiska leveransbesked redan när ordern läggs. Hur fritt saldo räknas påverkas av faktorer som [beställningspunkt och säkerhetslager](/kunskap/inkop/bestallningspunkt-och-sakerhetslager). Se även [Orderhantering](/funktioner/orderhantering).

### Vanliga frågor

**Vad är skillnaden mellan ATP och lagersaldo?**

Lagersaldo är antalet som finns i lager just nu. ATP räknar framåt i tiden och väger in vad som redan är reserverat mot andra order och vilka inköp som är på väg in. Ett lagersaldo på 40 kan alltså betyda ATP 0 i dag och ATP 200 om två veckor.

**Räknar ATP med inkommande inköpsorder?**

Ja. Bekräftade inleveranser ingår i beräkningen med sina leveransdatum, vilket gör att antal som ännu inte finns på hyllan går att lova bort till ett framtida datum.

**Varför skiljer sig ATP mellan två datum?**

För att beräkningen läggs på en tidsaxel. Vid varje framtida datum är ATP det som är fritt efter att inleveranser lagts till och reservationer dragits bort, vilket gör att siffran stiger när ett inköp landar och sjunker när order allokeras.

---

## Backflush (bakåtrapportering)

Källa: https://fluit.se/ordlista/backflush
Kategori: Produktion
Uppdaterad: 2026-09-23

Backflush, på svenska bakåtrapportering, är en metod där en komponents materialuttag räknas av automatiskt när tillverkningsordern färdigrapporteras, i stället för att kvitteras rad för rad under produktionen. Kvantiteten räknas fram ur stycklistan och det rapporterade antalet. Metoden passar billiga komponenter utan spårningskrav, som skruv, lim och emballage, där manuell kvittering bara är extraarbete.

**Backflush drar materialet åt dig.** I stället för att någon kvitterar varje skruv, varje klick lim eller varje meter emballage för hand under tillverkningen, räknar systemet ut åtgången automatiskt när ordern färdigrapporteras: rapporterat antal gånger åtgång per styck enligt stycklistan.

Flaggan sätts per komponent, inte per produkt. En produkt kan blanda: skruv och lim backflushas, medan en motor med serienummer kvitteras för hand som förut. Standard är av, ingenting ändras för den som inte slår på det.

## Före och efter

| | Utan backflush | Med backflush |
| --- | --- | --- |
| Kvittering | Varje uttag registreras för hand under tillverkningen | Räknas av automatiskt vid färdigrapportering |
| Risk vid glömska | Lagersaldot blir för högt, felet upptäcks först vid inventering | Uttaget följer alltid det rapporterade antalet |
| Lämplig för | Dyra eller spårade komponenter, där uttaget behöver ett medvetet val | Billiga komponenter utan spårning: skruv, lim, emballage |

## Kasserat räknas med

Avräkningen ser på godkänt **och** kasserat antal tillsammans. Rapporteras 7 godkända och 3 kasserade dras material för 10, inte för 7. De kasserade enheterna förbrukade komponenten precis som de godkända: skruvarna sitter i skrotlådan, inte kvar på hyllan.

Räknade backflushen bara på det godkända antalet skulle [tillverkningskostnaden](/ordlista/stycklista) per enhet se billigare ut än den är, och lagersaldot skulle sakta driva isär från verkligheten utan att någon lade märke till det förrän vid nästa inventering.

## Spårade komponenter är undantaget

En komponent med parti- eller serienummerspårning kan inte flaggas för backflush, kryssrutan är utgråad. [Spårbarhet](/kunskap/produktion/sparbarhet) finns för att kunna svara på vilket råvaruparti som sitter i en levererad produkt, och en automatisk avräkning har ingen som väljer parti åt den. Ett svar som ser rätt ut men är tomt är värre än att fråga varje gång.

Blir komponenten spårad i efterhand hoppas den över vid nästa avräkning och lämnas till manuell kvittering, i stället för att bokföras utan parti.

## Så sätts det i Fluit

Flaggan ligger på komponentraden i stycklistan: **Artikel → fliken Tillverkning → komponentraden → kryssrutan Bakåtrapportering**. Uttaget som backflushen gör använder samma plockupplösning, samma lagerbokföring och samma kostnadsberäkning som en manuell kvittering, så [arbetsorderns](/kunskap/produktion/arbetsorder) lagerhistorik och efterkalkyl ser likadana ut oavsett vem, eller vad, som tryckte på knappen.

### Vanliga frågor

**Vad är skillnaden mellan backflush och manuell kvittering?**

Vid manuell kvittering registrerar någon varje materialuttag för hand, komponent för komponent, medan tillverkningen pågår. Med backflush räknas uttaget fram automatiskt när ordern färdigrapporteras: rapporterat antal gånger åtgång per styck enligt stycklistan.

**Varför räknas kasserade enheter med i avräkningen?**

En kasserad enhet har redan förbrukat sin del av komponenten, den sitter i skrotet i stället för i hyllan. Räknades avräkningen bara på godkänt antal skulle lagersaldot bli för högt utan att någon märkte det förrän vid nästa inventering.

**Vilka komponenter kan inte backflushas?**

Komponenter med parti- eller serienummerspårning. Spårningen ska kunna svara på vilket råvaruparti som sitter i en levererad produkt, och en automatisk avräkning har ingen som väljer vilket parti det gäller. De kvitteras därför fortsatt för hand.

---

## Batch (partinummer)

Källa: https://fluit.se/ordlista/batch
Kategori: Lager
Uppdaterad: 2026-08-07

En batch, även kallad parti eller lot, är en mängd av en artikel som tillverkats eller mottagits tillsammans och som delar egenskaper. Batchnumret gör att partiet kan följas genom lager och produktion, vilket krävs vid spårbarhet och vid varor med begränsad hållbarhet. Batchen bär normalt också utgångsdatum och en status som kan spärra saldot.

**En batch är ett parti som hör ihop.** Det tillverkades i samma körning eller kom in med samma leverans, och delar därför egenskaper: samma råvara, samma inställningar, samma hållbarhet.

Det är just den gemensamma egenskapen som gör batchnumret användbart. Visar sig något vara fel gäller felet sannolikt hela partiet, och då behöver man veta vilka enheter som ingick.

## Vad batchen bär

Utöver numret själv bär batchen normalt tre uppgifter:

- **Utgångsdatum eller bästföredatum**, för varor med begränsad hållbarhet.
- **Status**, som avgör om saldot är fritt, i karantän eller spärrat.
- **Ursprung**, alltså vilken tillverkningsorder eller inleverans partiet kom från.

Statusen är den som gör batchen till mer än en etikett. En batch som spärras försvinner ur plockbart saldo direkt, utan att någon behöver flytta kartonger.

## Uttagsordningen

Har partierna hållbarhet räcker det inte att veta vilka som finns. Uttagen behöver ske i rätt ordning, annars byggs det upp gamla partier bakom de nya.

Det är skillnaden mellan [FIFO](/ordlista/fifo) och [FEFO](/ordlista/fefo): först in först ut, eller först utgången först ut. För varor med utgångsdatum är FEFO det enda rimliga, och det förutsätter att datumet finns registrerat på batchen och inte bara tryckt på kartongen.

## Var kedjan bryts

Batchspårbarhet är aldrig starkare än sitt svagaste registreringstillfälle. Numret måste fångas vid inleverans, vid uttag till order eller [arbetsorder](/kunskap/produktion/arbetsorder), vid tillverkning och vid utleverans.

Missas uttagssteget spelar det ingen roll hur noga in och ut registreras. Kedjan är bruten, och det upptäcks först när någon frågar vilka kunder som fått material ur ett visst parti.

### Vanliga frågor

**Vad är skillnaden mellan batch och serienummer?**

Ett batchnummer identifierar ett parti, ett serienummer identifierar en enskild individ. Batch används när partiet är den meningsfulla enheten, till exempel för råvara och komponenter. Serienummer används när varje exemplar behöver följas för sig.

**Varför behöver batchen ett utgångsdatum?**

För att uttagen ska kunna ske i rätt ordning. Utan datum på batchen går det inte att plocka enligt FEFO, och då byggs det upp gamla partier längst in i hyllan medan de nya plockas först.

**Vad innebär att spärra en batch?**

Att sätta batchen i ett läge där saldot inte längre är plockbart, till exempel i väntan på ett kvalitetsbeslut. Det hindrar plocklistan från att föreslå materialet, utan att någon behöver leta rätt på var kartongerna står.

---

## Checkout

Källa: https://fluit.se/ordlista/checkout
Kategori: E-handel
Uppdaterad: 2026-08-18

Checkout, på svenska kassan, är stegen i en webbutik där varukorgen blir en order: mottagarens uppgifter, val av fraktsätt, betalning och orderbekräftelse. Det är butikens känsligaste yta, eftersom varje extra fält och varje oväntad kostnad kostar avslut. Moms och fraktpris räknas fram här, inte i varukorgen.

**Checkout, på svenska kassan, är stegen i en webbutik där varukorgen blir en order.** Mottagarens uppgifter, val av fraktsätt, betalning och orderbekräftelse, i den ordningen.

Sekvensen ser enkel ut men innehåller allt som är svårt i en butik. Adressen styr momsen och avgör vilka fraktsätt som går att erbjuda. Vikten och måtten på det som ligger i korgen styr fraktpriset. Kundtypen avgör om priserna ska visas med eller utan moms, och om faktura ska erbjudas över huvud taget. Det är därför totalsumman rör sig sent, och det är därför sena överraskningar är kassans största läckage.

Kraven skiljer sig mellan B2C och B2B mer än något annat i en webbutik. En konsumentkassa ska ha så få fält som möjligt, tillåta gästköp och erbjuda de betalsätt kunden känner igen. En företagskassa ska i stället känna igen den inloggade kunden, hämta avtalade priser, kontrollera kreditgränsen, tillåta inköpsordernummer på ordern och skicka den vidare för godkännande när beloppet kräver det. En kassa som försöker vara båda samtidigt blir sällan bra på något av det.

Det tekniska valet står mellan en kassa som körs i butiken och en checkoutleverantörs egen. Den senare tar hand om betalningen, kundidentifieringen och en del av det juridiska ansvaret, men tar också över en del av utseendet.

Fluit levereras med en egen kassa och med Klarna Checkout (Kustom) som färdig integration. Momsen räknas per rad, fraktpriset hämtas från fraktsätten du satt upp i systemet, och när ordern är lagd allokeras saldot direkt så att lagret ser den. Se [Betalningar](/funktioner/betalningar) och [Frakt och fraktberäkning](/funktioner/frakt-och-fraktberakning).

### Vanliga frågor

**Vad är skillnaden mellan varukorg och checkout?**

Varukorgen är en lista som går att ändra fritt och som inte kräver några uppgifter. Checkout är den låsta sekvensen där ordern faktiskt skapas: mottagare, frakt, betalning och bekräftelse. Varukorgen kan visa ett ungefärligt pris, kassan visar det riktiga.

**Varför ändras totalsumman i kassan?**

För att frakt och moms beror på mottagarens adress. Innan kunden fyllt i vart varan ska går fraktpriset inte att räkna, och vid försäljning utanför Sverige kan momsen bli en annan. En kassa som visar en fraktuppskattning tidigt slipper överraskningen.

**Ska man tvinga kunden att skapa konto i kassan?**

Sällan i konsumenthandel. Gästköp med möjlighet att skapa konto efter köpet ger fler avslut. I B2B är det tvärtom: där bygger hela upplägget på en inloggad kund med avtalade priser, kreditgräns och leveransadresser.

---

## Click and collect

Källa: https://fluit.se/ordlista/click-and-collect
Kategori: E-handel
Uppdaterad: 2026-08-18

Click and collect betyder att kunden beställer och betalar på nätet men hämtar varan själv i butik eller på lager. Ordern plockas som vanligt men ingen frakt bokas, och kunden får besked när paketet står klart för avhämtning. Modellen kräver att saldot per hämtställe stämmer, eftersom kunden väljer plats redan i kassan.

**Click and collect betyder att kunden beställer och betalar på nätet men hämtar varan själv** i butik eller på lager.

Modellen är billig att införa jämfört med det mesta annat i e-handel, eftersom den inte ändrar mitten av flödet. Ordern kommer in, plockas och packas precis som vanligt. Det som skiljer är början och slutet: kunden väljer hämtställe i kassan i stället för fraktsätt, och i slutet bokas ingen transport utan varan ställs undan och kunden får besked.

Det som gör den svår är saldot. Ett gemensamt saldo som inte skiljer på plats fungerar utmärkt så länge allt skickas från samma lager, men i det ögonblick kunden får välja hämtställe måste systemet veta vad som finns var. Utan det får du kunder som åker till en butik efter en vara som ligger tolv mil bort, och det är en sämre upplevelse än att bara ha betalat frakten.

Nyttan är tydligast där frakten är en tröskel. Kunder som hoppar av i kassan på grund av fraktkostnaden lägger ofta ordern ändå när hämtning är ett alternativ, och för den som redan är på väg förbi är det snabbare. För B2B är varianten minst lika användbar: hantverkaren som beställer på morgonen och hämtar på vägen till bygget.

I Fluit kopplas lager till en säljkanal med egna inställningar per lager: om det ska synas i butiken, om det är tillgängligt för avhämtning, vilket namn kunden ser och vilken ledtidstext som ska visas. När ordern är plockad markeras den som klar för avhämtning, och kunden får besked. Se [Lager och logistik](/funktioner/lager-och-logistik) och [E-handel](/funktioner/ehandel).

### Vanliga frågor

**Vad krävs för att erbjuda click and collect?**

Att saldot är korrekt per plats, inte bara totalt. Kunden väljer hämtställe redan i kassan, och ett gemensamt saldo över alla lager leder till att någon kör till butiken efter en vara som ligger på centrallagret.

**Vad tjänar man på click and collect?**

Fraktkostnaden försvinner, avhoppen i kassan minskar för kunder som tycker frakten är dyr, och för butik med fysiskt läge blir hämtningen ett extra besök som ofta ger merförsäljning. Nackdelen är att en yta måste avsättas och att personal behöver ha koll på undanställda ordrar.

**Hur länge ska en order stå och vänta?**

Sätt en tydlig gräns, ofta sju till fjorton dagar, och ett automatiskt besked till kunden innan tiden går ut. Utan gräns växer hyllan med ordrar som ingen hämtar, och varorna är låsta från försäljning under tiden.

---

## Composable ERP

Källa: https://fluit.se/ordlista/composable-erp
Kategori: Arkitektur
Uppdaterad: 2026-07-31

Composable ERP är en strategi där affärssystemet sätts ihop av utbytbara delar i stället för att köpas som en enda svit från en leverantör. Varje förmåga (lager, ekonomi, frakt, e-handel) kan bytas ut för sig, förutsatt att delarna kan prata med varandra över öppna API:er. Begreppet drivs framför allt av analysföretaget Gartner.

**Composable ERP är en strategi där affärssystemet sätts ihop av utbytbara delar i stället för att köpas som en enda svit.** Varje förmåga ska kunna bytas ut för sig, vilket förutsätter att delarna kan prata med varandra över öppna API:er.

Bakgrunden är gamla ERP-projekt som tog år, kostade mer än beräknat och sedan låste bolaget i en version som ingen vågade uppgradera. Svaret blev att sluta se affärssystemet som en produkt och börja se det som en uppsättning förmågor, där varje förmåga kan ersättas när något bättre dyker upp.

I praktiken hamnar de flesta bolag någonstans i mitten. Kärnan, alltså artiklar, lager, order och inköp, hålls ihop i ett system, eftersom det är där data delas mest och gränserna gör mest skada. Runt om kompletteras det med det som redan är specialiserat: ekonomi och bokföring, fraktbokning, 3PL-lager, betalningar. Det är composable i praktiken, även om ingen kallar det så på mötet.

Det som brukar underskattas är kostnaden för gränserna. Två system som ska hålla samma artikelregister uppdaterat kräver att någon bestämmer vilket som är källan, vad som händer när synken stannar och hur en dubblett ska rättas. Den kostnaden syns inte i någon licensrad, men den finns varje månad.

För ett bolag med 5–100 anställda är slutsatsen oftast den motsatta mot vad ordet antyder: färre gränser, inte fler. Fluit är byggt utifrån den hållningen: lager, order, inköp, e-handel och CRM i samma kärna, och färdiga kopplingar mot [Fortnox](/lagersystem/fortnox), nShift och Ongoing WMS där en egen del gör mer nytta. Att kärnan dessutom är [headless](/headless-erp) betyder att ni kan komponera vidare den dag ni vill.

### Vanliga frågor

**Vad är skillnaden mellan composable ERP och headless ERP?**

Headless beskriver ett system: går funktionerna att nå utan gränssnittet? Composable beskriver landskapet: går delarna att byta ut var för sig? Ett headless ERP är en förutsättning för en composable uppsättning, men ett bolag kan mycket väl ha ett headless affärssystem och ändå köra allt i det.

**Är composable ERP samma sak som best of breed?**

Nästan. Best of breed är den gamla varianten av samma tanke: välj bästa systemet per område. Composable lägger till kravet att delarna ska gå att byta ut löpande, inte bara väljas en gång vid upphandlingen, och därmed också kravet på öppna API:er mellan dem.

**Passar composable ERP ett mindre bolag?**

Sällan i sin renodlade form. Varje gräns mellan två system är något någon måste äga: felsökning när synken stannar, uppdateringar som bryter ett fält, och två sanningar om samma saldo. Ett bolag utan egen IT-funktion tjänar oftast mer på att ha lager, order och inköp i samma system och komponera i utkanterna: ekonomi, frakt och 3PL.

---

## D2C

Källa: https://fluit.se/ordlista/d2c
Kategori: E-handel
Uppdaterad: 2026-08-18

D2C står för direct-to-consumer och betyder att en tillverkare eller ett varumärke säljer direkt till slutkunden i stället för via återförsäljare. Marginalen och kunddatan stannar hos varumärket. Med den följer också ansvaret för lager, plock, frakt, returer, betalningar och kundtjänst, funktioner som återförsäljaren tidigare skötte.

**D2C står för direct-to-consumer och betyder att en tillverkare eller ett varumärke säljer direkt till slutkunden** i stället för via grossist och återförsäljare.

Argumentet för är starkt och lätt att räkna på. Mellanledets marginal stannar i huset, priset mot kund går att styra, och för första gången vet varumärket vem som faktiskt köper produkten. Det sista är ofta det som väger tyngst: en tillverkare som säljer via handeln har historiskt haft ingen aning om slutkunden.

Det som brukar underskattas är att mellanledet gjorde arbete, inte bara tog betalt. Återförsäljaren höll lager nära kunden, plockade enstyck, svarade i telefon när leveransen var sen, tog emot returer och bar kreditrisken. Går ledet bort landar allt det hos varumärket, i en organisation som är byggd för att skicka pallar och inte paket. Det första D2C-året handlar därför oftare om plockning, fraktavtal och returflöde än om varumärkesbyggande.

Den andra frågan är kanalkonflikten. Att sälja samma vara billigare i egen butik än återförsäljaren kan är ett effektivt sätt att förlora återförsäljaren. Lösningarna är sällan tekniska utan kommersiella: eget sortiment i den egna kanalen, hållna priser, eller en butik som fokuserar på reservdelar, tillbehör och förbrukning.

Det som krävs i systemet är kanalspecifika sortiment och prislistor, ett saldo som räcker till både pallordrar och enstycksordrar, och ett returflöde som klarar privatpersoner. I Fluit ligger de tre i samma system som produktionen och inköpen, vilket är själva poängen när samma artikel ska säljas i två affärsmodeller samtidigt. Se [Tillverkning](/bransch/tillverkning) och [E-handel](/funktioner/ehandel).

### Vanliga frågor

**Vad är skillnaden mellan D2C och B2C?**

B2C beskriver vem du säljer till: en konsument. D2C beskriver att du gör det utan mellanhand, trots att din vanliga försäljning går via återförsäljare. En detaljhandelskedja är B2C men inte D2C, eftersom den säljer andras varumärken.

**Vad är svårast när en tillverkare börjar sälja D2C?**

Volymen av små ordrar. En tillverkare som är van vid pallar till tio grossister ska plötsligt plocka enstyck till tusen adresser, hantera returer från privatpersoner och svara på frågor om leveranser. Det är ett logistik- och kundtjänstproblem långt före det blir ett marknadsföringsproblem.

**Hur undviker man konflikt med sina återförsäljare?**

Vanligast är att skilja på sortiment eller pris: egna exklusiva varianter i den egna butiken, rekommenderat pris utan underbudsförsäljning, eller att den egna butiken främst säljer reservdelar och förbrukningsvaror. Ett kanalspecifikt sortiment och egna prislistor per kanal är förutsättningen.

---

## Dropshipping

Källa: https://fluit.se/ordlista/dropshipping
Kategori: Lager
Uppdaterad: 2026-07-30

Dropshipping är en leveransmodell där leverantören skickar varan direkt till slutkunden i stället för att den passerar säljarens eget lager. Säljaren sköter ordern och kundrelationen men håller inget eget saldo för artikeln. Modellen kräver en tät koppling mellan kundorder och inköpsorder, så att rätt vara når rätt slutkund.

**Dropshipping är en leveransmodell där leverantören skickar varan direkt till slutkunden i stället för att den passerar säljarens eget lager.** Säljaren sköter ordern och kundrelationen men håller inget eget saldo för artikeln.

I praktiken går det till så här: kunden lägger en order hos säljaren, säljaren skapar i sin tur en inköpsorder mot leverantören med leverans direkt till kundens adress, och leverantören packar, skickar och rapporterar tillbaka leveransuppgifterna.

Fördelarna är låg kapitalbindning och inga egna lagerkostnader. Baksidan är att du tappar en del kontroll över leveranstid, förpackning och saldo, eftersom det sker hos någon annan. Modellen kräver därför en tät koppling mellan kundorder och inköpsorder, så att rätt artikel hamnar hos rätt slutkund.

I Fluit kan en orderrad markeras för direktleverans. Då skapas en kopplad inköpsorder mot leverantören med kundens adress som leveransadress. Se [Orderhantering](/funktioner/orderhantering) och [Inköp](/funktioner/inkop).

### Vanliga frågor

**Hur fungerar dropshipping rent praktiskt?**

Kunden lägger en order hos säljaren, säljaren skapar en inköpsorder mot leverantören med leverans direkt till kundens adress, och leverantören packar, skickar och rapporterar tillbaka leveransuppgifterna.

**Vad är nackdelen med dropshipping?**

Du tappar kontroll över leveranstid, förpackning och saldo, eftersom det sker hos någon annan. Modellen kräver därför en tät koppling mellan kundorder och inköpsorder så att rätt artikel hamnar hos rätt slutkund.

---

## EDI

Källa: https://fluit.se/ordlista/edi
Kategori: Inköp
Uppdaterad: 2026-07-30

EDI, Electronic Data Interchange, är elektroniskt utbyte av strukturerade affärsdokument direkt mellan företags system, utan manuell inmatning. Order, orderbekräftelser, leveransaviseringar och fakturor skickas i format som systemen läser automatiskt. Det förutsätter att parterna kommit överens om en meddelandestandard, till exempel EDIFACT eller Peppol.

**EDI (Electronic Data Interchange) är elektroniskt utbyte av strukturerade affärsdokument direkt mellan företags system, utan manuell inmatning.** I stället för att skicka order och fakturor som papper eller PDF överförs de i standardiserade format som systemen läser automatiskt.

Bland det som typiskt skickas via EDI finns order och orderbekräftelser, leveransaviseringar (ASN) och följesedlar, samt fakturor och prislistor.

Eftersom dokumenten tolkas maskinellt försvinner mycket manuellt arbete, inmatningsfelen blir färre och ledtiderna kortare. Det förutsätter att parterna kommit överens om en meddelandestandard, till exempel EDIFACT eller Peppol, så att avsändare och mottagare tolkar fälten likadant.

Mest utbrett är EDI mellan leverantörer och större kunder med höga transaktionsvolymer, där automatiken sparar ordentligt. Fluit har inget klassiskt EDI-gränssnitt. Motsvarande automatik byggs i stället med det öppna API:et och Integration Center, och ordrar som ändå kommer via mejl kan tolkas av AI-inkorgen. Se [inköp](/funktioner/inkop) och [orderhantering](/funktioner/orderhantering).

### Vanliga frågor

**Vad skickas typiskt via EDI?**

Order och orderbekräftelser, leveransaviseringar (ASN) och följesedlar, samt fakturor och prislistor.

**Vad krävs för att EDI ska fungera mellan två företag?**

Att parterna kommit överens om en meddelandestandard, till exempel EDIFACT eller Peppol, så att avsändare och mottagare tolkar fälten likadant.

---

## FEFO

Källa: https://fluit.se/ordlista/fefo
Kategori: Lager
Uppdaterad: 2026-08-31

FEFO står för First Expired, First Out: det parti som går ut på datum först lämnar lagret först, oavsett när det levererades in. Principen gäller allt med hållbarhet, som livsmedel, läkemedel och kemikalier. Förutsättningen är batchspårning, eftersom det krävs ett partinummer med utgångsdatum att sortera på.

**FEFO står för First Expired, First Out: det parti som går ut först lämnar lagret först, oavsett när det levererades in.** Principen gäller allt som har ett datum: livsmedel, läkemedel, kemikalier, kosmetik, lim och tätningsmedel.

Skillnaden mot FIFO är inte akademisk. Ett parti som kom in sent kan mycket väl ha kortare hållbarhet än ett som stått längre, till exempel för att leverantören själv skickade äldre lager eller för att partierna kommer från olika tillverkningsomgångar. Plockar lagret då efter inleveransdatum blir det nyare partiet kvar och hinner bli för gammalt.

Förutsättningen för FEFO är batchspårning. Utan partinummer med utgångsdatum på varje inleverans finns ingen information att sortera på, och plockaren får förlita sig på vad som råkar stå längst fram på hyllan.

Vinsten är mätbar i svinn. I branscher med korta hållbarheter är skillnaden mellan FIFO och FEFO ofta flera procent av lagervärdet per år och för läkemedel och livsmedel är spårbarheten dessutom ett krav, inte en optimering.

I Fluit bär varje batch sitt utgångsdatum, och inkommande gods kan läggas på karantänplats tills kvalitetskontrollen släpper det för plock. Se guiden om [FIFO och FEFO i lagervärdering](/kunskap/lager/fifo-fefo-lagervardering), eller [FIFO](/ordlista/fifo) för jämförelsen. Karantänplatser och frisläpp av inkommande gods hanteras i [kvalitetskontrollen](/funktioner/kvalitetskontroll).

### Vanliga frågor

**När ska man använda FEFO i stället för FIFO?**

När varorna har ett utgångsdatum: livsmedel, läkemedel, kemikalier, kosmetik, lim och tätningsmedel. Plockar lagret efter inleveransdatum i stället kan ett nyare parti med kortare hållbarhet bli kvar och hinna bli för gammalt.

**Vad krävs för att kunna köra FEFO?**

Batchspårning. Utan partinummer med utgångsdatum på varje inleverans finns ingen information att sortera på, och plockaren får förlita sig på vad som råkar stå längst fram på hyllan.

---

## FIFO

Källa: https://fluit.se/ordlista/fifo
Kategori: Ekonomi
Uppdaterad: 2026-07-30

FIFO står för First In, First Out: det som kom in i lagret först plockas och kostnadsförs först. Principen har en fysisk sida, att de äldsta enheterna lämnar hyllan först, och en bokföringsmässig, att det äldsta inköpspriset följer med varan ut. FIFO ska inte förväxlas med FEFO, som sorterar på utgångsdatum.

**FIFO står för First In, First Out: det som kom in i lagret först är också det som plockas och kostnadsförs först.** Principen har två sidor som ofta blandas ihop, en fysisk och en bokföringsmässig.

Fysiskt handlar FIFO om att de äldsta enheterna lämnar hyllan först, så att inget parti blir liggande längst in i stället. Det minskar risken för inkurans, och för artiklar med hållbarhet är det skillnaden mellan svinn och sålt.

Bokföringsmässigt handlar FIFO om vilket inköpspris som följer med varan ut. Har du köpt 100 stycken för 120 kronor och sedan 100 för 140, kostnadsförs de första hundra utleveranserna till 120 kronor. Kvar i lagret ligger de senast inköpta, vilket gör att lagervärdet speglar dagens prisnivå, medan det redovisade resultatet bygger på gårdagens.

Det är också där skillnaden mot vägt genomsnitt uppstår. Genomsnittsmetoden jämnar ut prissvängningar och är enklare att förklara, medan FIFO ger en mer korrekt bild artikel för artikel men kräver att systemet håller reda på varje inleverans för sig.

FIFO ska inte förväxlas med [FEFO](/ordlista/fefo), som sorterar på utgångsdatum i stället för inleveransdatum. För varor med hållbarhet är de sällan samma sak.

I Fluit styrs uttagsordningen med plockprioritet per lagerplats, medan lagervärdet beräknas löpande som vägt genomsnittspris per artikel och lager. Läs mer i guiden om [FIFO och FEFO i lagervärdering](/kunskap/lager/fifo-fefo-lagervardering).

### Vanliga frågor

**Vad är skillnaden mellan FIFO och FEFO?**

FIFO sorterar på inleveransdatum, FEFO på utgångsdatum. För varor med hållbarhet är de sällan samma sak: ett parti som kom in sent kan ha kortare hållbarhet än ett som stått längre.

**Är FIFO en fysisk eller bokföringsmässig princip?**

Båda, och de blandas ofta ihop. Fysiskt handlar FIFO om att de äldsta enheterna lämnar hyllan först. Bokföringsmässigt handlar det om vilket inköpspris som följer med varan ut.

**Vad är skillnaden mellan FIFO och vägt genomsnitt?**

Genomsnittsmetoden jämnar ut prissvängningar och är enklare att förklara. FIFO ger en mer korrekt bild artikel för artikel, men kräver att systemet håller reda på varje inleverans för sig.

---

## Fraktsedel

Källa: https://fluit.se/ordlista/fraktsedel
Kategori: Order
Uppdaterad: 2026-07-30

En fraktsedel är transportdokumentet som följer godset och styr hur transportören ska hantera försändelsen. Den identifierar sändningen och ligger till grund för både spårning och fraktdebitering. Till skillnad från följesedeln, som riktar sig till mottagaren och listar artiklar, handlar fraktsedeln om kollin, vikt och transportuppgifter.

**En fraktsedel är det transportdokument som följer med godset och styr hur transportören ska hantera försändelsen.** Den identifierar sändningen och ligger till grund för både spårning och fraktdebitering.

På en fraktsedel hittar du normalt avsändare och mottagare, antal kolli med vikt och volym, kollislag och eventuellt farligt gods, samt ett sändnings-id och kollietiketter med streckkod.

Här är det lätt att blanda ihop två dokument. Fraktsedeln riktar sig till transportören och handlar om kollin och transportuppgifter. Följesedeln (eller packsedeln) riktar sig i stället till mottagaren och listar vilka artiklar som ingår i leveransen. De kan följa samma försändelse men fyller alltså olika syften.

I Fluit skapas fraktsedlar och kollietiketter i samband med leverans via fraktintegrationen, så att rätt transportuppgifter följer godset hela vägen. Se [Frakt och fraktberäkning](/funktioner/frakt-och-fraktberakning).

### Vanliga frågor

**Vad är skillnaden mellan fraktsedel och följesedel?**

Fraktsedeln riktar sig till transportören och handlar om kollin och transportuppgifter. Följesedeln riktar sig till mottagaren och listar vilka artiklar som ingår i leveransen. De kan följa samma försändelse men fyller olika syften.

**Vad står på en fraktsedel?**

Avsändare och mottagare, antal kolli med vikt och volym, kollislag och eventuellt farligt gods, samt ett sändnings-id och kollietiketter med streckkod.

---

## Följesedel

Källa: https://fluit.se/ordlista/foljesedel
Kategori: Order
Uppdaterad: 2026-07-30

En följesedel är dokumentet som följer med en leverans och redovisar vad som faktiskt skickats. Den listar artiklar och antal men normalt inga priser. Syftet är avstämning: kunden ska kunna jämföra det som kom med det som beställdes redan vid mottagningen. Referensen till kundens ordernummer är det viktigaste fältet.

**En följesedel är dokumentet som följer med en leverans och redovisar vad som faktiskt skickats.** Den listar artiklar och antal, men innehåller normalt inga priser. Den ska kunna hanteras av alla som rör godset utan att era marginaler följer med på köpet.

Syftet är avstämning. Kunden ska kunna jämföra det som kom med det som beställdes, och notera avvikelser direkt vid mottagningen i stället för att upptäcka dem när fakturan kommer en månad senare. Därför är referensen till kundens ordernummer det viktigaste fältet på hela sedeln: utan den vet mottagarens godsmottagning inte vad leveransen hör till.

En bra följesedel redovisar också det som *inte* kom med. Står restnoterade rader kvar med noll i levererat antal slipper kunden gissa om resten är glömd eller på väg.

I praktiken avgörs mycket av var i flödet sedeln skapas. Skrivs den ut från ordern innan plocket är den ett önsketänkande. Skapas den när plocket är kvitterat speglar den vad som verkligen ligger i lådan.

I Fluit genereras följesedeln från den kvitterade plockningen, så att den visar plockade antal och inte beställda. Guiden [följesedel vs packsedel](/kunskap/order/foljesedel-vs-packsedel) reder ut begreppen, och [fraktsedeln](/ordlista/fraktsedel) är transportörens motsvarighet.

### Vanliga frågor

**Ska priser stå på en följesedel?**

Nej, normalt inte. Följesedeln ska kunna hanteras av alla som rör godset utan att era marginaler följer med på köpet.

**Vilket fält är viktigast på en följesedel?**

Referensen till kundens ordernummer. Utan den vet mottagarens godsmottagning inte vad leveransen hör till.

**Ska restnoterade rader stå med på följesedeln?**

Ja. Redovisas de med noll i levererat antal slipper kunden gissa om resten är glömd eller på väg.

---

## GTIN/EAN

Källa: https://fluit.se/ordlista/gtin-ean
Kategori: Identifiering
Uppdaterad: 2026-08-31

GTIN, Global Trade Item Number, är en global standardiserad artikelidentifierare som pekar ut en handelsvara entydigt oavsett vem som säljer den. EAN är den europeiska benämningen, och EAN-13 med tretton siffror är det vanligaste formatet. Numret tilldelas via GS1 och kodas i regel i en streckkod.

**GTIN (Global Trade Item Number) är en global, standardiserad artikelidentifierare som pekar ut en handelsvara entydigt, oavsett vem som säljer den.** EAN (European Article Number) är den europeiska benämningen, och formatet EAN-13 med tretton siffror är det du oftast stöter på i handeln.

Tre saker definierar numret. Det är globalt unikt och tilldelas via organisationen GS1. Det är standardiserat, så samma nummer betyder samma vara hos alla parter. Och det kodas i regel i en streckkod för maskinell avläsning.

Skillnaden mot ett internt SKU, som du sätter själv, är att GTIN/EAN är gemensamt för hela handelskedjan. Just därför fungerar det så bra för utbyte mellan företag, e-handel och kassasystem. EAN-13 dominerar i Europa, medan UPC är vanligare i Nordamerika.

I Fluit kan GTIN/EAN lagras per artikel i [artikelhanteringen](/funktioner/artikelhantering) och användas vid skanning i lagret. Hur streckkoderna sedan används vid plock och inlagring beskrivs under [lagerhantering och logistik](/funktioner/lager-och-logistik).

### Vanliga frågor

**Vad är skillnaden mellan GTIN och EAN?**

GTIN (Global Trade Item Number) är det formella namnet på den globala artikelidentifieraren. EAN (European Article Number) är den europeiska benämningen, och EAN-13 med tretton siffror är formatet du oftast stöter på i handeln.

**Var får man ett GTIN?**

Numret tilldelas via organisationen GS1. Det är globalt unikt och betyder samma vara hos alla parter i handelskedjan.

**Vad är skillnaden mellan EAN och UPC?**

Det är två format av samma sorts nummer. EAN-13 dominerar i Europa, medan UPC är vanligare i Nordamerika.

---

## Headless ERP

Källa: https://fluit.se/ordlista/headless-erp
Kategori: Arkitektur
Uppdaterad: 2026-07-31

Headless ERP är ett affärssystem där affärslogiken och datan är åtskilda från gränssnittet och nås via ett API. Systemets eget gränssnitt är då en klient bland flera och kan kompletteras med en egen storefront, en mobilapp eller en integration utan att kärnan byggs om. Ordet headless syftar på huvudet som lyfts bort: kroppen fungerar ändå.

**Headless ERP är ett affärssystem där affärslogiken och datan är åtskilda från gränssnittet och nås via ett API.** Systemets eget gränssnitt blir då en klient bland flera, och kan kompletteras utan att kärnan byggs om.

Ordet kommer från webbvärlden. Ett headless CMS lagrar och strukturerar innehåll men bestämmer inte hur det visas. Den delen, huvudet, byggs separat. Samma tanke flyttad till affärssystem: order, artiklar, lagersaldon och priser ligger kvar i ett system, medan de kan visas och användas i flera.

Det låter tekniskt, men frågan bakom är sällan teknisk. Den kommer upp när verksamheten behöver en kanal som affärssystemet inte har: en B2B-portal där återförsäljarna lägger sina egna order, en storefront med eget utseende, en app i produktionen, en integration mot en kunds inköpssystem. I ett traditionellt system blir varje sådan sak ett projekt hos leverantören. I ett headless system är det ett anrop mot ett API som redan finns.

Det som avgör om ett system förtjänar ordet är inte om det har ett API (det har de flesta), utan hur mycket av funktionaliteten som ligger bakom det. Ett API som kan läsa artiklar och skicka in fakturor är en integrationsyta. Ett API som kan skapa en order, allokera den, boka frakten och läsa tillbaka vad som faktiskt går att lova en kund är en väg in i systemet.

Kostnaden är också värd att nämna, för den brukar hoppas över. Varje gränssnitt någon bygger själv är ett gränssnitt någon måste underhålla, testa och laga när API:et ändras. Ett bolag som inte har utvecklare, egna eller inhyrda, får sällan igen den investeringen.

Fluit är byggt med kärnan i mitten och flera API-ytor runt om: den publika [API-dokumentationen](/api-docs) beskriver den öppna vägen in, och Fluits egen webbshop, B2B-portal och Android-app konsumerar samma kärna som webbappen. Läs mer om vad det innebär i praktiken på [headless ERP](/headless-erp).

### Vanliga frågor

**Vad är skillnaden mellan headless ERP och ett vanligt affärssystem?**

I ett vanligt affärssystem sitter gränssnittet ihop med logiken, och API:et är en påbyggnad för att flytta data ut och in. I ett headless ERP går all funktionalitet via API:et, och systemets eget gränssnitt använder samma väg som alla andra klienter. Praktiskt märks det när ni vill ha en egen webbshop, kundportal eller app på samma data: i det ena fallet är det ett utvecklingsprojekt hos leverantören, i det andra ett anrop.

**Måste vi bygga vårt eget gränssnitt om vi väljer headless ERP?**

Nej. Rena headless-plattformar levereras utan gränssnitt och kräver att någon bygger det, men de flesta system som beskriver sig som headless har ett färdigt gränssnitt och en öppen väg förbi det. Skillnaden är att ni kan bygga vid sidan av när ni vill, inte att ni måste börja med det.

**Är headless ERP samma sak som composable ERP?**

Nej, men de hänger ihop. Headless handlar om ett system: går funktionerna att nå utan gränssnittet? Composable handlar om systemlandskapet: går delarna att byta ut var för sig? Ett headless ERP är en förutsättning för en composable uppsättning, eftersom delarna annars inte kan prata med varandra.

---

## Hemtagningskostnad

Källa: https://fluit.se/ordlista/hemtagningskostnad
Kategori: Ekonomi
Uppdaterad: 2026-08-07

Hemtagningskostnad, på engelska landed cost, är den totala kostnaden för att få en vara på plats i lagret: leverantörens pris plus frakt, tull, försäkring, hanteringsavgifter och valutaeffekt. Kostnaderna fördelas över raderna i sändningen efter värde, antal eller vikt, och resultatet blir det inköpspris som marginalen faktiskt ska räknas mot.

**Hemtagningskostnad är vad varan kostar när den står på hyllan, inte vad det stod på leverantörsfakturan.** På engelska heter samma sak *landed cost*. Skillnaden mellan de två talen är sällan liten. Vid import från Asien ligger påslaget ofta mellan tjugo och trettio procent, och ibland högre för skrymmande gods.

## Vad som läggs på

Utöver fakturapriset tillkommer typiskt:

- **Frakt**, både huvudtransporten och inrikes transport från hamn eller terminal.
- **Tull**, som räknas på tullvärdet utifrån varans [varukod](/ordlista/hs-kod).
- **Försäkring** av godset under transporten.
- **Avgifter**: speditörsarvode, terminalhantering, dokumentavgifter.
- **Punktskatt**, när varan är skattepliktig.
- **Valutaeffekt**, när inköpet gjorts i annan valuta än den du redovisar i.

## Fördelningsnyckeln avgör

De flesta av kostnaderna kommer per sändning, inte per artikel. Någon måste därför fördela dem över raderna, och valet av nyckel ändrar utfallet:

- **Värde** passar när sändningen blandar dyra och billiga varor.
- **Vikt** passar när frakten drivs av tyngd, till exempel vid sjöfrakt av tungt gods.
- **Antal** passar när kollina är likartade.

En sändning med både en tung men billig komponent och en lätt men dyr elektronikartikel ger helt olika resultat beroende på nyckel. Poängen är att välja den som speglar vad som faktiskt orsakar kostnaden.

## Varför det påverkar mer än inköp

Hemtagningskostnaden är det tal som lagervärdet, marginalen och prissättningen bygger på. Används fakturapriset i stället blir tre saker fel samtidigt: lagret värderas för lågt, bruttomarginalen ser för hög ut och prissättningen sätts på ett underlag som inte håller.

I Fluit registreras kostnaderna på inleveranssändningen och fördelas över raderna efter vald nyckel, så att artikelns kostpris uppdateras när sändningen tas emot. Vill du räkna på ett enskilt fall finns [kalkylatorn för hemtagningskostnad](/verktyg/landed-cost), som tar fakturarader och tillägg och visar påslaget per artikel.

### Vanliga frågor

**Vad ingår i hemtagningskostnaden?**

Leverantörens fakturapris plus allt som krävs för att få varan på hyllan: sjö- eller flygfrakt, inrikes transport, tull, försäkring, speditörsarvode, terminalavgifter och eventuell punktskatt. Valutakursen på betalningsdagen räknas också in när inköpet sker i annan valuta.

**Hur fördelas frakten mellan artiklarna i en sändning?**

Efter en fördelningsnyckel: värde, antal eller vikt. Värde passar när sändningen innehåller varor med stor prisskillnad, vikt när frakten drivs av tyngd och antal när kollina är likartade. Nyckeln ska väljas efter vad som faktiskt orsakar kostnaden.

**Varför räcker inte fakturapriset?**

För att tillägg på tjugo till trettio procent är vanliga vid import. Räknas marginalen mot fakturapriset ser varje affär bättre ut än den är, och det syns först när lagervärdet stäms av mot resultatet.

---

## HS-kod (varukod)

Källa: https://fluit.se/ordlista/hs-kod
Kategori: Ekonomi
Uppdaterad: 2026-08-07

En HS-kod är det internationella varunummer som klassificerar en vara i tulltaxan. De sex första siffrorna är gemensamma i hela världen genom Harmonized System, och EU lägger till två siffror till ett åttasiffrigt KN-nummer. Koden avgör tullsats, om varan omfattas av punktskatt eller importrestriktioner, och hur den räknas i handelsstatistiken.

**En HS-kod är varunumret som talar om vad en vara är i tullens ögon.** Systemet heter Harmonized System, förvaltas av Världstullorganisationen och används av över tvåhundra länder. Det gör att samma produkt får samma sex första siffror oavsett var i världen den deklareras.

EU bygger på med två siffror till ett åttasiffrigt **KN-nummer**, som används vid export och i statistiken. Vid import tillkommer ytterligare siffror i Taric, EU:s tulltaxedatabas, för att fånga antidumpningstullar och andra åtgärder.

## Vad koden styr

Koden avgör mer än tullsatsen:

- **Tull och avgifter** vid import från länder utanför EU.
- **Punktskatt.** [Kemikalieskatten](/kunskap/ekonomi/kemikalieskatt-pa-elektronik) pekar ut skattepliktiga varor med KN-nummer, och koden avgör dessutom om varan räknas som vitvara eller övrig elektronik.
- **CBAM.** Vilka varor som omfattas av gränsjusteringsmekanismen anges också med KN-nummer.
- **Restriktioner och licenser** för allt från livsmedel till produkter med dubbla användningsområden.
- **Statistiken**, både Intrastat inom EU och tulldeklarationer utanför.

## Klassificering är inte namngivning

Klassificeringen utgår från vad varan består av och vad den gör, inte från vad den kallas. En "smart högtalare" kan hamna som högtalare, som datamaskin eller som telekommunikationsutrustning beroende på funktion, och skillnaden får konsekvenser för både tull och skatt.

Är fallet oklart går det att begära ett bindande klassificeringsbesked från Tullverket, som gäller i hela EU.

## Koden hör hemma på artikeln

Eftersom flera regelverk hänger på varukoden är den ett artikelfält, inte något som slås upp per sändning. Ligger den på artikeln kan systemet avgöra skatteplikt, räkna hemtagningskostnad och lämna underlag till statistiken utan att någon letar.

I Fluit ligger HS-koden på artikeln tillsammans med nettovikten, och punktskattemotorn matchar just den koden mot skatteschemat för att hitta rätt kategori och sats. Samma uppgift används alltså två gånger, i stället för att underhållas på två ställen.

### Vanliga frågor

**Vad är skillnaden mellan HS-kod, KN-nummer och varukod?**

HS-koden är de sex första siffrorna och är internationell. KN-numret är EU:s åttasiffriga variant, som används vid export och i statistik. Varukod är det svenska ordet och används oftast om KN-numret eller om den längre Taric-koden vid import.

**Var hittar jag rätt varukod?**

I tulltaxan hos Tullverket, som är sökbar på varuslag. Klassificeringen utgår från vad varan är gjord av och vad den gör, inte från vad den heter i din katalog. Vid osäkerhet går det att begära ett bindande klassificeringsbesked.

**Varför spelar varukoden roll utanför tullen?**

För att flera regelverk hänvisar till den. Kemikalieskatt, CBAM och olika importrestriktioner pekar ut vilka varor som omfattas med KN-nummer, vilket gör koden avgörande även för en vara som aldrig passerar en tullgräns.

**Vad händer om koden är fel?**

Fel kod kan ge fel tullsats, missad punktskatt eller uteblivna kontroller. Rättelse i efterhand innebär att skillnaden ska betalas, ofta med ränta, och ansvaret ligger hos importören även när koden kommit från leverantören.

---

## Inköpsrekvisition

Källa: https://fluit.se/ordlista/rekvisition
Kategori: Inköp
Uppdaterad: 2026-07-30

En inköpsrekvisition är en intern begäran om att få köpa in varor eller tjänster, som godkänns innan någon inköpsorder skickas. Den innebär ingen förbindelse mot leverantören. Poängen är att inköpet ska vara behovsprövat och attesterat innan pengar binds, och att kedjan blir spårbar hela vägen fram till fakturan.

**En inköpsrekvisition är en intern begäran om att få köpa in varor eller tjänster, som skapas och godkänns innan en formell inköpsorder skickas till leverantören.** Den är ett internt dokument och innebär ingen förbindelse utåt mot leverantören.

Poängen är att få kontroll och spårbarhet tidigt i processen. En medarbetare anger behovet med antal och eventuellt önskad leverantör. Rekvisitionen attesteras enligt företagets attestordning, och först efter godkännande omvandlas den till en inköpsorder.

På så sätt vet du att inköpet är både behovsprövat och budgeterat innan några pengar binds. Rekvisitionen blir dessutom startpunkten i en spårbar kedja som senare kan stämmas av mot order, godsmottagning och faktura i three-way matching.

Fluit har ingen separat rekvisitionsmodul. Behoven fångas i stället som beställningsförslag via [MRP](/funktioner/mrp), som granskas innan de blir inköpsorder. Om kontrollen vid fakturering läser du i [three-way matching](/kunskap/inkop/three-way-matching). Se även [Inköp](/funktioner/inkop).

### Vanliga frågor

**Har Fluit en rekvisitionsmodul?**

Nej. Behoven fångas i stället som beställningsförslag via MRP, som granskas innan de blir inköpsorder.

**Varför använda rekvisition innan inköpsorder?**

För att inköpet ska vara behovsprövat och attesterat innan några pengar binds. Rekvisitionen blir dessutom startpunkten i en spårbar kedja som senare kan stämmas av mot order, godsmottagning och faktura.

---

## Intrastat

Källa: https://fluit.se/ordlista/intrastat
Kategori: Ekonomi
Uppdaterad: 2026-08-07

Intrastat är EU:s system för statistik över varuhandeln mellan medlemsländerna. Företag vars in- eller utförsel av varor till andra EU-länder överstiger ett tröskelvärde ska varje månad rapportera kvantitet, värde, varukod, partnerland och transaktionstyp. I Sverige samlas uppgifterna in av SCB, och rapporteringen är statistik och inte beskattning.

**Intrastat är statistikrapporteringen av varuhandel mellan EU-länder.** När den inre marknaden infördes försvann tulldeklarationerna vid gränserna inom EU, och därmed också det underlag som handelsstatistiken byggde på. Intrastat är ersättningen: företagen rapporterar själva vad som förts in och ut.

Rapporteringen är alltså statistik, inte beskattning. Ingen skatt betalas på grundval av en Intrastat-uppgift, men uppgiftsskyldigheten är obligatorisk och kan förenas med vite.

## Vad som ska lämnas

Rapporten lämnas månadsvis och delas i två flöden, införsel och utförsel, med separata tröskelvärden. Per rad anges bland annat:

- **varukod** (KN-nummer),
- **partnerland**, alltså avsändnings- eller destinationsland,
- **kvantitet och nettovikt**,
- **fakturerat värde**,
- **transaktionstyp** och **transportsätt**,
- **köparens momsregistreringsnummer** vid utförsel.

Tröskelvärdena fastställs av SCB och kan skilja sig mellan flödena. Det gör att ett företag som importerar mycket och exporterar lite kan vara skyldigt att rapportera det ena men inte det andra.

## Skillnaden mot periodisk sammanställning

De två blandas ofta ihop, men mäter olika saker. Intrastat följer **varornas rörelse** och går till SCB. Den periodiska sammanställningen följer **försäljningsvärdet per kunds VAT-nummer**, går till Skatteverket och används för att kontrollera att köparen redovisar sin förvärvsmoms.

Ett bolag som säljer varor till företag i andra EU-länder kan därför behöva lämna båda, med olika innehåll och olika perioder.

## Var uppgifterna kommer ifrån

Underlaget finns redan i affärssystemet: varukod och nettovikt på artikeln, mottagarland på ordern och fakturerat värde på raden. Det som avgör om rapporteringen blir enkel eller plågsam är om [varukoden](/ordlista/hs-kod) och vikten faktiskt är ifyllda på artiklarna, eller om någon får leta upp dem i efterhand.

Fluit har varukod och nettovikt på artikeln och landsuppgifter på order och kunder, vilket ger underlaget. Själva Intrastat-rapporten byggs och lämnas i dag utanför systemet.

### Vanliga frågor

**Vem är skyldig att lämna Intrastat?**

Företag vars införsel eller utförsel av varor till andra EU-länder passerar tröskelvärdet för flödet. Trösklarna sätts av SCB och kan skilja sig mellan införsel och utförsel, vilket gör att ett företag kan vara skyldigt att rapportera det ena men inte det andra.

**Vad ska rapporteras?**

Per varukod och partnerland: kvantitet, nettovikt, fakturerat värde, transaktionstyp och transportsätt. Vid utförsel ska också köparens momsregistreringsnummer anges.

**Är Intrastat samma sak som periodisk sammanställning?**

Nej. Intrastat är handelsstatistik till SCB och avser varornas rörelse. Den periodiska sammanställningen är en momsrapport till Skatteverket och avser försäljningsvärde per kunds VAT-nummer. Ett företag kan behöva lämna båda.

**Räknas tjänster in?**

Nej. Intrastat avser bara varor som fysiskt rör sig mellan EU-länder. Tjänster rapporteras inte här, men kan omfattas av den periodiska sammanställningen.

---

## Kanonisk URL

Källa: https://fluit.se/ordlista/kanonisk-url
Kategori: E-handel
Uppdaterad: 2026-08-18

En kanonisk URL är den adress som en sida pekar ut som sin riktiga, när samma innehåll går att nå på flera adresser. Sökmotorn samlar då rankningen på en adress i stället för att dela upp den på dubbletter. I en webbutik uppstår dubbletterna av filter, sortering, sökparametrar och produkter som ligger i flera kategorier.

**En kanonisk URL är den adress som en sida pekar ut som sin riktiga**, när samma innehåll går att nå på flera adresser. Sökmotorn samlar då rankningen på en adress i stället för att dela upp den.

Webbutiker drabbas hårdare av det här än nästan alla andra sajter, och det beror inte på slarv utan på hur en katalog fungerar. Produkter ska gå att filtrera, sortera och bläddra i, och varje kombination ger en ny adress. En produkt som ligger under både "verktyg" och "kampanj" nås på två vägar. Lägg till spårningsparametrar från nyhetsbrev och annonser, och en butik med tusen produkter kan ha tiotusentals adresser som visar i praktiken samma sak.

Konsekvensen är sällan en katastrof men nästan alltid en dämpning. Sökmotorn måste välja vilken av dubbletterna som ska visas, och den väljer inte alltid samma som du hade valt. Länkar utifrån pekar på olika varianter, så styrkan sprids ut i stället för att samlas. Och kryper roboten igenom tiotusen filterkombinationer hinner den mindre av det som faktiskt spelar roll.

Skilj canonical från omdirigering. Canonical säger "de här adresserna fungerar, men räkna den här". En 301 säger "adressen har flyttat, gå hit i stället". Har en produkt bytt slug ska det bli en omdirigering, annars tappas både besökarna och rankningen.

Fluit sätter kanoniska adresser automatiskt i butiken, håller kassa, konto och varukorg utanför indexering, och skapar en 301 automatiskt när en produkt eller sida byter adress. Egna omdirigeringar går att lägga upp per kanal med 301 eller 302, med räknare på hur många gånger var och en använts, och att importera en hel lista på en gång vid en flytt från en annan plattform. Se [Innehåll och SEO i webbutiken](/funktioner/webshop-innehall).

### Vanliga frågor

**Varför får en webbutik dubbletter av sig själv?**

För att katalogen är byggd för att filtreras. Varje kombination av filter, sortering och sidnummer ger en ny adress med i stort sett samma innehåll, och en produkt som ligger i tre kategorier kan nås på tre vägar. Ingen av dem är fel, men bara en ska räknas.

**Är canonical samma sak som en omdirigering?**

Nej. En 301-omdirigering skickar besökaren vidare, den gamla adressen slutar fungera. En canonical låter alla adresser fungera men talar om vilken som ska räknas. Har innehållet flyttat permanent ska du omdirigera, inte sätta canonical.

**Vad händer om man byter adress på en produkt?**

Utan omdirigering tappar du den rankning adressen byggt upp, och alla länkar utifrån går till en 404. Med en 301 följer både besökarna och det mesta av rankningen med till den nya adressen. Därför ska ett slugbyte alltid skapa en omdirigering automatiskt.

---

## Konverteringsgrad

Källa: https://fluit.se/ordlista/konverteringsgrad
Kategori: E-handel
Uppdaterad: 2026-08-18

Konverteringsgrad är andelen besök i en webbutik som leder till en lagd order, räknad som antal ordrar delat med antal sessioner. Talet beskriver hur väl butiken förvandlar trafik till försäljning. Det är känsligt för trafikens sammansättning: en kampanj som drar in många nyfikna besökare sänker konverteringsgraden utan att en enda krona har försvunnit.

**Konverteringsgrad är andelen besök i en webbutik som leder till en lagd order.** Talet räknas som antal ordrar delat med antal sessioner, och beskriver hur väl butiken förvandlar trafik till försäljning.

Måttet är lätt att räkna och lätt att missförstå. Det är en kvot, vilket betyder att den kan röra sig utan att något i butiken har ändrats. En annonskampanj, ett omnämnande i ett nyhetsbrev eller en säsong där folk jämför priser långt innan de köper trycker ned procenttalet samtidigt som försäljningen står stilla eller ökar. Därför är konverteringsgrad ett dåligt mål i sig, men ett bra larm: när den faller utan att trafiken ändrat karaktär har något gått sönder, oftast i kassan.

Skillnaden mellan B2C och B2B är så stor att talen inte hör hemma i samma tabell. En konsumentbutik lever med att de flesta besökare tittar, jämför och lämnar. En inloggad B2B-butik har besökare som redan är kunder, som vet vad de ska ha och som handlar om igen varje månad. Där är låg konverteringsgrad ett tecken på att sortimentet, priserna eller sökfunktionen inte fungerar, inte på att besökarna var nyfikna.

Det tal som säger mest är sällan butikens totala siffra utan konverteringsgraden per trafikkälla. Organisk sökning, direkttrafik, nyhetsbrev och betald annonsering konverterar olika, och medelvärdet döljer vilken av dem som bär försäljningen.

I Fluit finns konverteringsgrad och andelen övergivna varukorgar som widgetar på dashboarden, och per kanal under kanalens egen översikt. Trafikkällorna mäts cookiefritt i butiken, så siffrorna finns utan att besökaren behöver klicka i en samtyckesruta. Se [E-handel](/funktioner/ehandel) och [Innehåll och SEO i webbutiken](/funktioner/webshop-innehall).

### Vanliga frågor

**Vad är en normal konverteringsgrad?**

I konsumenthandel ligger den ofta mellan 1 och 3 procent, men spannet är stort mellan branscher och trafikkällor. I en inloggad B2B-butik är talet ett annat: där är besökarna kunder som redan har avtal, och 20 till 30 procent är inte ovanligt. Att jämföra de två talen med varandra säger ingenting.

**Varför sjunker konverteringsgraden när försäljningen ökar?**

För att nämnaren växer snabbare än täljaren. Annonser, ett viralt inlägg eller en kampanj drar in besökare som inte var på väg att köpa något. Försäljningen kan öka i kronor samtidigt som andelen sjunker. Titta på antalet ordrar och omsättningen bredvid procenttalet, aldrig på procenttalet ensamt.

**Var i butiken tappas flest kunder?**

Nästan alltid i kassan. Fraktkostnaden, betalsättet och kravet på att skapa konto är de tre vanligaste orsakerna, och de syns först i sista steget. En kassa som visar frakten tidigt får färre avhopp, även när frakten kostar lika mycket.

---

## Lagerplats

Källa: https://fluit.se/ordlista/lagerplats
Kategori: Lager
Uppdaterad: 2026-08-31

En lagerplats är en specifik fysisk position i lagret, ofta kallad bin eller location, där en artikel förvaras. Platserna byggs upp hierarkiskt: zon, gång, ställ, nivå och fackposition. Beroende på funktion får de olika typer, som plockplats, buffertplats eller karantänplats, vilket styr både plockrutter och var gods lagras in.

**En lagerplats är en specifik fysisk position i lagret, ofta kallad bin eller location, där en artikel förvaras.** Att varje artikel har en känd plats är själva förutsättningen för att kunna plocka effektivt och inventera rätt.

Platserna byggs vanligen upp hierarkiskt så att de pekar ut exakt var i lagret en vara står. En zon är ett område, till exempel höglager eller plockzon. Inom zonen finns gångar, och i gångarna pallställ eller hyllor. Varje ställ har sina höjdnivåer, och längst ut sitter den enskilda fackpositionen.

Beroende på funktion får platser olika typer, exempelvis plockplats, buffertplats, inleveransplats eller karantänplats. Den indelningen styr i sin tur både plockrutterna och var gods lagras in vid mottagning.

I Fluit definieras lagerplatser med den här strukturen och kopplas till artiklar och saldon. Det gör att [WMS-appen](/funktioner/wms-app) kan dirigera plock och inlagring till rätt position. Multi-lager, saldon och överföringar mellan platser beskrivs under [lagerhantering och logistik](/funktioner/lager-och-logistik).

### Vanliga frågor

**Hur byggs lagerplatser upp?**

Hierarkiskt: en zon är ett område som höglager eller plockzon, inom zonen finns gångar, i gångarna pallställ eller hyllor, varje ställ har höjdnivåer och längst ut sitter den enskilda fackpositionen.

**Vilka typer av lagerplatser finns?**

Bland annat plockplats, buffertplats, inleveransplats och karantänplats. Indelningen styr både plockrutterna och var gods lagras in vid mottagning.

---

## Lagersaldo

Källa: https://fluit.se/ordlista/lagersaldo
Kategori: Lager
Uppdaterad: 2026-07-30

Lagersaldo är antalet av en artikel som finns i lager vid en given tidpunkt. I praktiken behövs tre siffror: det fysiska saldot på lagerplatserna, det allokerade som är knutet till order, och det tillgängliga som är skillnaden dem emellan. Det är det tillgängliga saldot en säljare ska titta på.

**Lagersaldo är antalet av en artikel som finns i lager vid en given tidpunkt.** Det är utgångspunkten för att veta vad som faktiskt kan säljas, plockas och levereras.

I praktiken räcker det sällan med en enda siffra. Det fysiska saldot är det som står på lagerplatserna. Det allokerade saldot är knutet till order men ännu inte plockat. Och det tillgängliga saldot är det fysiska minus allokeringarna, alltså det som är fritt att sälja.

Allokeringar kan dessutom vara mjuka eller hårda. En mjuk allokering reserverar ett antal mot en order utan att peka ut någon särskild lagerplats, medan en hård allokering binder saldot till en bestämd plats eller batch. I Fluit heter de Reserverad och Platsbokad. Det är så saldot kan styra både orderlöften och plockning.

Ett korrekt saldo i realtid är helt avgörande för att slippa översäljning och felaktiga leveranstider. I Fluit uppdateras lagersaldot löpande vid inleverans, plockning och justeringar, så att det tillgängliga saldot speglar verkligheten. Se [Lager och logistik](/funktioner/lager-och-logistik) för hur saldon hanteras.

### Vanliga frågor

**Vad är skillnaden mellan fysiskt och tillgängligt lagersaldo?**

Det fysiska saldot är det som står på lagerplatserna. Det tillgängliga saldot är det fysiska minus allokeringarna, alltså det som är fritt att sälja. Det är den senare siffran en säljare ska titta på.

**Varför räcker det inte med en enda saldosiffra?**

För att en del av saldot kan vara reserverat mot order som ännu inte plockats. Utan uppdelning i fysiskt, allokerat och tillgängligt saldo går det inte att se vad som faktiskt är fritt att lova en kund.

---

## Lagervärde

Källa: https://fluit.se/ordlista/lagervarde
Kategori: Lager
Uppdaterad: 2026-07-30

Lagervärde är det bokförda värdet av varorna i lager vid en given tidpunkt, och en post i balansräkningen. Det räknas fram ur lagersaldot och artiklarnas anskaffningsvärde enligt vald värderingsmetod: FIFO, vägt genomsnitt eller standardpris. Valet av metod märks framför allt när inköpspriserna rör sig.

**Lagervärde är det bokförda värdet av de varor som ligger i lager vid en given tidpunkt.** Det är en post i balansräkningen och en central siffra både i den löpande uppföljningen och i bokslutet.

Värdet räknas fram utifrån lagersaldot och artiklarnas anskaffningsvärde, men hur det bestäms beror på vilken värderingsmetod du använder. Med FIFO (först in, först ut) förbrukas det äldsta inköpspriset först. Med vägt genomsnitt uppdateras ett snittpris vid varje inleverans. Med standardpris sätts ett fast värde och avvikelserna bokförs separat.

Valet av metod märks framför allt när inköpspriserna rör sig, eftersom det påverkar både kostnaden för sålda varor och det kvarvarande lagervärdet. Ibland behöver värdet också skrivas ned, exempelvis vid inkurans eller när nettoförsäljningsvärdet sjunkit.

I Fluit beräknas lagervärdet löpande som vägt genomsnittspris, utifrån saldot och lagerhändelserna. Hur metoderna skiljer sig åt går vi igenom i artikeln om [FIFO och FEFO i lagervärdering](/kunskap/lager/fifo-fefo-lagervardering).

### Vanliga frågor

**Hur beräknas lagervärde?**

Utifrån lagersaldot och artiklarnas anskaffningsvärde, enligt vald värderingsmetod. Med FIFO förbrukas det äldsta inköpspriset först, med vägt genomsnitt uppdateras ett snittpris vid varje inleverans, och med standardpris sätts ett fast värde där avvikelserna bokförs separat.

**Vilken värderingsmetod använder Fluit?**

Fluit beräknar lagervärdet löpande som vägt genomsnittspris, utifrån saldot och lagerhändelserna.

**När spelar valet av värderingsmetod störst roll?**

När inköpspriserna rör sig. Då påverkar metoden både kostnaden för sålda varor och det kvarvarande lagervärdet.

---

## Ledtid

Källa: https://fluit.se/ordlista/ledtid
Kategori: Inköp
Uppdaterad: 2026-08-31

Ledtid är tiden från att en beställning läggs till att varorna är levererade och tillgängliga. Den rymmer flera delar: att skapa och skicka ordern, leverantörens tillverkning och hantering, frakten, samt inleverans och inlagring hos dig. Variationen i ledtid är minst lika viktig att planera för som längden.

**Ledtid är tiden från att en beställning läggs till att varorna är levererade och tillgängliga.** Det är en av de viktigaste parametrarna i inköp och materialplanering, eftersom den avgör hur tidigt du måste beställa för att inte hamna i brist.

Den totala ledtiden består oftast av flera delar. Det tar tid att skapa och skicka själva beställningen (orderledtid). Sedan kommer leverantörens egen tid för tillverkning och hantering, frakttiden fram till lagret, och till sist inleverans och inlagring hos dig.

Längden styr direkt hur du sätter beställningspunkt och säkerhetslager: ju längre och mer osäker ledtid, desto högre måste nivåerna ligga för att gardera mot brist. Och variationen i ledtid är minst lika viktig att hantera som själva längden. En jämn ledtid på tio dagar är lättare att planera kring än en som hoppar mellan fem och tjugo.

I Fluit används artikelns ledtid i [MRP](/funktioner/mrp) och inköpsförslag. Mer om hur ledtid spelar in finns i [beställningspunkt och säkerhetslager](/kunskap/inkop/bestallningspunkt-och-sakerhetslager). Hela vägen från behov till inleverans beskrivs under [inköp och inköpsorder i Fluit](/funktioner/inkop).

### Vanliga frågor

**Vad ingår i ledtiden?**

Tiden att skapa och skicka beställningen, leverantörens egen tid för tillverkning och hantering, frakttiden fram till lagret, samt inleverans och inlagring hos dig.

**Varför är variationen i ledtid viktigare än längden?**

En jämn ledtid på tio dagar är lättare att planera kring än en som hoppar mellan fem och tjugo. Ju mer osäker ledtiden är, desto högre måste beställningspunkt och säkerhetslager ligga för att gardera mot brist.

---

## Leveransprecision

Källa: https://fluit.se/ordlista/leveransprecision
Kategori: Inköp
Uppdaterad: 2026-08-07

Leveransprecision mäter hur stor andel av leveranserna som kom fram inom överenskommen tid. Måttet kräver tre beslut för att bli användbart: vilket datum som räknas som lovat, hur brett toleransfönstret är och om precisionen mäts per order eller per orderrad. Mäts det mot ett datum som flyttats i efterhand blir siffran alltid god och alltid oanvändbar.

**Leveransprecision mäter om leveransen kom när den var lovad.** Måttet används både uppåt mot leverantörer och nedåt mot egna kunder, och i båda riktningarna avgörs användbarheten av tre beslut som fattas innan mätningen börjar.

## Mot vilket datum

Det viktigaste beslutet är vilket datum som är referens. Mäts precisionen mot ett leveransdatum som uppdaterats varje gång leveransen skjutits fram kommer siffran alltid att vara hög, eftersom referensen följer med.

Mät mot det **först lovade** datumet. Det är det datumet planeringen byggde på, och det är avvikelsen från det som orsakade problem längre fram i kedjan.

## Hur brett fönstret är

Exakt på dagen är strängt och sällan meningsfullt för sjöfrakt. Ett par dagars tolerans är rimligt i många branscher. Det viktiga är att fönstret är bestämt i förväg och lika för alla leverantörer, annars går siffrorna inte att jämföra.

Fönstret bör ha en gräns även åt det tidiga hållet. En leverans som kommer tre veckor för tidigt binder kapital och tar plats.

## Per order eller per rad

En order där nio av tio rader kom i tid kan räknas som en försenad order eller som nio i tid och en försen. Båda är försvarbara. Radnivå ger en rättvisare bild av leverantören, ordernivå en rättvisare bild av vad kunden upplevde.

## Vad siffran ska användas till

Precision är inte bara ett omdöme om leverantören. Den är indata till [säkerhetslagret](/kunskap/inkop/bestallningspunkt-och-sakerhetslager): det är spridningen i [ledtid](/ordlista/ledtid), inte medelvärdet, som avgör hur stor bufferten behöver vara.

En leverantör med lång men jämn ledtid är därför lättare att planera för än en med kort men oberäknelig. [Verktyget för leveransprecision](/verktyg/leveransprecision) räknar fram både medelvärde och standardavvikelse ur utlovade och faktiska datum.

### Vanliga frågor

**Hur räknas leveransprecision ut?**

Antal leveranser som kom inom toleransfönstret delat med totalt antal leveranser i perioden. Fönstret kan vara noll dagar, alltså exakt på dagen, eller tillåta en eller ett par dagars avvikelse åt vardera hållet.

**Vilket datum ska mätas mot?**

Det först lovade datumet. Mäts det mot ett datum som flyttats i efterhand blir precisionen alltid hög, eftersom referensen följer med varje försening. Då mäter måttet administrativ disciplin i stället för leveransförmåga.

**Vad är skillnaden mot servicegrad?**

Servicegrad mäter om det gick att leverera alls. Leveransprecision mäter om leveransen kom när den var lovad. En leverantör kan ha hög servicegrad och usel precision, om lovade datum sätts optimistiskt.

**Ska för tidiga leveranser räknas som fel?**

Ofta ja. En leverans som kommer tre veckor för tidigt binder kapital och tar plats, och är ur planeringssynpunkt lika mycket en avvikelse som en försening. Därför bör fönstret ha en gräns åt båda hållen.

---

## Marknadsplats

Källa: https://fluit.se/ordlista/marknadsplats
Kategori: E-handel
Uppdaterad: 2026-08-18

En marknadsplats är en handelsplats där flera säljare erbjuder varor under samma varumärke och kassa, till exempel Amazon, CDON eller Fyndiq. Säljaren når marknadsplatsens trafik utan att bygga den själv, men betalar provision per order, konkurrerar på pris i en delad produktlista och äger sällan kundrelationen efter köpet.

**En marknadsplats är en handelsplats där flera säljare erbjuder varor under samma varumärke och kassa.** Amazon, CDON och Fyndiq är de vanligaste på den svenska marknaden.

Bytet är rakt: du får tillgång till trafik du inte behöver bygga, och betalar med marginal och kundrelation. För ett nytt varumärke eller ett brett lager som behöver omsättning är det ofta en bra affär. Volymen kommer snabbt, och den kommer utan att någon behöver lära sig annonsköp.

Priset står i tre delar. Provisionen är den synliga, mellan fem och tjugo procent beroende på kategori. Den andra är att produktlistan är delad: säljer flera samma artikel hamnar ni i samma vy, och då återstår priset och leveranstiden att konkurrera med. Den tredje är att kunden är plattformens. Återköpet, e-postadressen och möjligheten att bygga en relation följer inte med ordern.

Arbetet efteråt underskattas nästan alltid. Sortiment, priser och saldon ska hållas aktuella, ordrarna ska in i det egna systemet och plockas som alla andra, och plattformarnas krav på leveranstid och svarstid är hårda. En marknadsplats som sköts manuellt i ett kalkylblad blir dyr långt innan provisionen räknats.

Fluit har marknadsplats som egen kanaltyp, med eget sortiment och egen prislista skilt från den egna butiken, så att marginalen går att styra per kanal. Färdiga kopplingar mot Amazon och CDON, och det publika API:et för sortimentssynk och orderimport, är under arbete. Se [E-handel](/funktioner/ehandel).

### Vanliga frågor

**Vad kostar det att sälja på en marknadsplats?**

Provisionen ligger typiskt mellan 5 och 20 procent av ordervärdet beroende på kategori och plattform, ibland med en månadsavgift utöver. Räkna även med kostnaden för att hålla sortiment, priser och saldon uppdaterade, som är löpande arbete och inte en engångsinsats.

**Vad är risken med att sälja på marknadsplats?**

Att du hamnar i samma produktlista som alla andra säljare av samma vara, där priset ofta är den enda skillnaden. Lägg till att kundrelationen tillhör plattformen och att villkoren kan ändras ensidigt, så är beroendet den verkliga risken, inte provisionen.

**Hur håller man saldot rätt när man säljer i flera kanaler?**

Genom att bara ha ett saldo. Så länge marknadsplatsen har en egen kopia som uppdateras i intervall kommer du att sälja samma sista vara två gånger. Antingen delar kanalerna saldo, eller så avsätts en buffert per kanal, med den försäljning det kostar.

---

## MCP

Källa: https://fluit.se/ordlista/mcp
Kategori: AI
Uppdaterad: 2026-07-31

MCP står för Model Context Protocol och är en öppen standard för hur en AI-assistent kopplas mot ett system. Systemet kör en MCP-server som beskriver vad som går att läsa och göra som verktyg, och assistenten anropar dem. Poängen är att kopplingen byggs en gång och sedan fungerar mot varje assistent som talar protokollet.

**MCP står för Model Context Protocol och är en öppen standard för hur en AI-assistent kopplas mot ett system.** Systemet kör en MCP-server som beskriver sina verktyg, och assistenten anropar dem när den behöver något.

Problemet protokollet löser är gammalt och tråkigt: varje AI-klient hade sitt eget sätt att prata med omvärlden, så en koppling mot ett affärssystem fick byggas om för varje klient. MCP gör den delen till en standard. Systemet publicerar en gång vad som går att göra, och alla assistenter som talar protokollet kan använda det.

För ett affärssystem betyder det att gränsen mellan "vår data" och "vår assistent" blir en behörighetsfråga i stället för ett integrationsprojekt. Assistenten får inte en kopia av databasen; den ställer frågor när den behöver svar och kör åtgärder när någon ber om det. Det som avgör vad den kommer åt är inloggningen, inte protokollet.

Två saker skiljer bra MCP-servrar från snabbt hopsatta. Den första är att läsa och skriva godkänns var för sig, så att en assistent kan hjälpa till med uppslag utan att kunna ändra något. Den andra är att åtgärderna går genom systemets vanliga funktioner i stället för rakt mot databasen, så att valideringar, behörigheter och aktivitetslogg fungerar som de ska.

Fluit körs som MCP-server på `https://api.fluit.cloud/mcp`. Inloggningen sker med det vanliga Fluit-kontot via OAuth, utan API-nyckel, och läsning och åtgärder godkänns i två separata steg. Hela genomgången finns på [MCP-koppling](/ai/mcp), och vad det innebär för systemet i stort på [agentic ERP](/agentic-erp).

### Vanliga frågor

**Vad används MCP till i ett affärssystem?**

Till att låta en AI-assistent som företaget redan använder arbeta direkt mot affärssystemet: söka fram kunder och order, läsa lagersaldon och utföra åtgärder som att skapa en offert eller en uppgift. Utan ett sådant protokoll måste varje assistent kopplas in för sig, med en egen integration per klient.

**Är MCP säkert?**

Protokollet i sig avgör inte det. Det gör hur servern är byggd. De frågor som avgör är hur inloggningen sker, om läsning och skrivning godkänns var för sig, om systemets vanliga behörigheter gäller för assistenten och om åtgärderna hamnar i loggen. En MCP-server som kör med en delad servicebehörighet ger assistenten mer än användaren har.

**Behöver vi en utvecklare för att koppla en assistent via MCP?**

Nej, om leverantören kör en färdig MCP-server. Då lägger ni till en URL som connector i assistenten, loggar in med ert vanliga konto och godkänner vad den får göra. Utvecklararbetet ligger hos den som byggt servern.

---

## Merförsäljning och korsförsäljning

Källa: https://fluit.se/ordlista/merforsaljning-och-korsforsaljning
Kategori: E-handel
Uppdaterad: 2026-08-18

Merförsäljning, på engelska upselling, betyder att kunden erbjuds en dyrare eller större variant av det hen redan tittar på. Korsförsäljning, cross-selling, betyder att kunden erbjuds något som kompletterar köpet, som tillbehör eller förbrukningsvaror. Skillnaden ligger i riktningen: uppåt i samma produktfamilj, eller åt sidan mot något annat.

**Merförsäljning betyder att kunden erbjuds en dyrare variant av det hen redan tittar på. Korsförsäljning betyder att kunden erbjuds något som kompletterar köpet.** Riktningen skiljer dem åt: uppåt i samma produktfamilj, eller åt sidan mot tillbehör och förbrukningsvaror.

Båda har dåligt rykte, och det är förtjänat i den form de oftast tar: en modul längst ned på sidan som visar fem produkter ingen bad om. Skillnaden mellan en hjälpsam rekommendation och en irriterande sådan sitter sällan i tekniken utan i om förslaget faktiskt hör ihop med det kunden tittar på.

Det som gör förslagen relevanta är relationer som någon har bestämt, inte gissningar. Att en borrmaskin tar ett visst batteri är ett faktum i produktdatan. Att en skrivare kräver en viss toner likaså. De sortens kopplingar går att lita på och de är alltid rätt. Statistiska förslag av typen "andra köpte också" fungerar bra som komplement men blir slumpartade i ett smalt sortiment eller i ett nystartat sortiment utan köphistorik.

Timingen avgör resten. Merförsäljning hör hemma på produktsidan, medan kunden fortfarande jämför och en dyrare variant är ett rimligt övervägande. Korsförsäljning hör hemma i korgen, när valet är gjort och tillbehöret bara är ett hak till. Vänder man på det får man tvivel i kassan i stället för ett större snittordervärde.

I Fluit sätts relationerna på artikeln i systemet, med typ: relaterad produkt, tillbehör, korsförsäljning, uppgradering eller reservdel. Butiken hämtar dem därifrån och visar tillbehör, relaterade produkter och korsförsäljning på produktsidan, samt kompletterande varor i varukorgen, utan att något behöver konfigureras i butiken separat. Egna widgetar går att placera på produktsidan för kampanjer och budskap. Se [E-handel](/funktioner/ehandel) och [Artikelhantering](/funktioner/artikelhantering).

### Vanliga frågor

**Vad är skillnaden mellan merförsäljning och korsförsäljning?**

Merförsäljning byter ut produkten mot en dyrare variant av samma sak. Korsförsäljning lägger till en annan produkt vid sidan av. Köper kunden en större modell är det merförsäljning, köper hen ett tillbehör till modellen är det korsförsäljning.

**Var i butiken hör de hemma?**

Merförsäljning på produktsidan, medan kunden fortfarande väljer. Korsförsäljning i varukorgen eller kassan, när valet är gjort och tillbehöret blir ett självklart tillägg. Byter man plats på dem stör de i stället för att hjälpa.

**Fungerar det i B2B?**

Ja, men annorlunda. En inköpare vill sällan bli uppsåld, däremot är påminnelser om förbrukningsvaror, reservdelar och det kunden brukar beställa tillsammans genuint hjälpsamma. Det som fungerar i B2B ligger närmare en beställningshistorik än en rekommendation.

---

## MRP

Källa: https://fluit.se/ordlista/mrp
Kategori: Produktion
Uppdaterad: 2026-08-07

MRP, Material Requirements Planning eller materialbehovsplanering, är beräkningen som omvandlar efterfrågan till konkreta inköps- och tillverkningsbehov. Den bryter ned färdiga produkter i komponenter via stycklistan, drar bort lagersaldo och redan inplanerad tillförsel, och backar ledtiderna för att räkna fram när varje order behöver läggas.

**MRP är beräkningen som svarar på vad som behöver beställas och tillverkas, i vilken mängd och när.** Den utgår från efterfrågan, bryter ned den i komponenter och räknar baklänges genom ledtiderna tills den landar i ett startdatum för varje order.

Styrkan ligger i nedbrytningen över flera nivåer. En färdig produkt som ska levereras om åtta veckor kan innehålla ett halvfabrikat med två veckors tillverkningstid, som i sin tur kräver en komponent med sex veckors leveranstid. Den kedjan betyder att inköpet måste ske nu, och det är inte uppenbart för någon som tittar på leveransdatumet.

## Vad beräkningen bygger på

Fyra uppgifter avgör kvaliteten på resultatet: ledtid per artikel, [stycklistan](/ordlista/stycklista), lagersaldot och [säkerhetslagret](/kunskap/inkop/bestallningspunkt-och-sakerhetslager). Är någon av dem fel blir förslagen fel på ett sätt som ser trovärdigt ut, vilket är värre än ett uppenbart fel.

Det är därför MRP-införanden sällan misslyckas på beräkningen. De misslyckas på artikeldatan.

## Från förslag till order

En körning ger förslag, inte order. Att de granskas är själva poängen: planeraren ser vad som avviker och tar ställning, i stället för att systemet lägger hundra order av sig självt.

I Fluit ger en MRP-körning både inköpsförslag och tillverkningsförslag, med varningar för artiklar utan leverantör eller ledtid, saldon under säkerhetslager, brådskande behov och utgångna priser. Godkända förslag blir inköpsorder eller [arbetsorder](/kunskap/produktion/arbetsorder).

### Vanliga frågor

**Vad står MRP för?**

Material Requirements Planning, på svenska materialbehovsplanering. Det bredare begreppet MRP II omfattar även kapacitet och ekonomi, och är i praktiken förfadern till dagens affärssystem.

**Vad krävs för att MRP ska ge rätt svar?**

Korrekta ledtider, kompletta stycklistor och ett lagersaldo som stämmer. Beräkningen är enkel, men den gör bara det den blir tillsagd, vilket gör att ett fel i artikeldatan blir ett fel i varje förslag.

**Vad är skillnaden mot beställningspunkt?**

Beställningspunkt reagerar på att saldot sjunkit under en nivå och tittar bakåt. MRP räknar framåt utifrån känd och prognostiserad efterfrågan, och kan därför planera för behov som ännu inte syns i saldot.

---

## Nettobehov

Källa: https://fluit.se/ordlista/nettobehov
Kategori: Produktion
Uppdaterad: 2026-08-07

Nettobehov är den mängd som faktiskt behöver anskaffas efter att tillgängligt lagersaldo och redan inplanerad tillförsel räknats bort från bruttobehovet. Behövs 500 enheter, finns 120 i lager och 200 är inbeställda, är nettobehovet 180. Ska ett säkerhetslager upprätthållas läggs det till, eftersom saldot inte får ätas upp ned till noll.

**Nettobehovet är det som återstår att skaffa fram.** Bruttobehovet säger hur mycket som krävs totalt. Nettobehovet säger hur mycket av det som inte redan är löst.

Uträkningen är enkel, men de två avdragsposterna är värda att titta närmare på, eftersom det är där felen sitter.

## Tillgängligt saldo, inte allt saldo

Det som får dras av är det som faktiskt går att använda. Saldo som är allokerat till en annan kundorder, spärrat i karantän efter en [avvikelse](/kunskap/produktion/avvikelsehantering) eller reserverat för ett projekt ska inte räknas som tillgängligt.

Räknas hela saldot av blir nettobehovet för lågt, och bristen upptäcks först när någon ska plocka.

## Inplanerad tillförsel

Hit hör bekräftade inköpsorder och pågående tillverkningsorder, med de datum de faktiskt förväntas landa. En inköpsorder som skulle ha kommit förra veckan ska inte räknas som om den redan är här.

Det är också anledningen till att bekräftade leveransdatum från leverantören är mer värda än beställningsdatumen: beräkningen blir bara så bra som datumen den vilar på.

## Säkerhetslagret hör till

Den vanligaste förenklingen är att utelämna [säkerhetslagret](/kunskap/inkop/bestallningspunkt-och-sakerhetslager). Då planeras saldot ned mot noll, och varje avvikelse i ledtid eller efterfrågan blir en brist.

Läggs säkerhetslagret till i formeln blir målet i stället att sluta perioden med bufferten intakt.

### Vanliga frågor

**Vad är skillnaden mellan bruttobehov och nettobehov?**

Bruttobehovet är den totala mängd som krävs för att täcka efterfrågan. Nettobehovet är det som återstår när befintligt saldo och redan beställda kvantiteter dragits av, alltså det som faktiskt behöver anskaffas.

**Räknas allt lagersaldo som tillgängligt?**

Nej. Saldo som är allokerat till andra order, spärrat i karantän eller reserverat för ett specifikt projekt ska inte räknas. Görs det blir nettobehovet för lågt och bristen upptäcks vid plockningen.

**Varför ingår säkerhetslagret i beräkningen?**

För att målet inte är att nå noll utan att behålla en buffert mot variation. Räknas säkerhetslagret inte in planeras saldot ned till botten, och då slår varje avvikelse i ledtid eller efterfrågan igenom direkt som brist.

---

## Omnikanal

Källa: https://fluit.se/ordlista/omnikanal
Kategori: E-handel
Uppdaterad: 2026-08-18

Omnikanal betyder att en kund kan röra sig mellan fysisk butik, webbutik, telefon och app utan att börja om, eftersom kanalerna delar samma sortiment, priser, saldo och orderhistorik. Skillnaden mot flerkanal är att kanalerna hänger ihop i stället för att bara finnas parallellt. Kravet ligger på datan bakom, inte på gränssnitten.

**Omnikanal betyder att en kund kan röra sig mellan butik, webbutik, telefon och app utan att börja om**, eftersom kanalerna delar samma sortiment, priser, saldo och orderhistorik.

Ordet används ofta som om det handlade om att finnas på många ställen. Det gör det inte. Att sälja i tre kanaler är flerkanal, och det är enkelt. Omnikanal börjar först när de tre delar data, och det är där kostnaden ligger.

Testet är enkelt att göra själv. Kan en kund som beställt på webben lämna tillbaka varan i butiken och få pengarna tillbaka på samma order? Ser säljaren på telefon vad kunden har i sin korg? Visar butiken samma leveranstid som webben när varan ligger på centrallagret? Är svaret nej på någon av dem är kanalerna parallella, inte sammankopplade, oavsett vad marknadsmaterialet säger.

Det som gör detta svårt är sällan gränssnitten. Det är att varje kanal i en typisk uppsättning har sin egen kopia av sanningen: kassasystemet ett saldo, webbutiken ett annat, affärssystemet ett tredje, synkade med varandra i intervall. Fördröjningen mellan kopiorna är precis det som ger överförsäljning på en kampanjdag och en returdisk som inte hittar ordern.

I Fluit är en säljkanal en konfiguration ovanpå samma data, inte ett eget system. Varje kanal har egna priser, fraktsätt, betalsätt, sortiment och lager, men saldot, artikeln, kunden och ordern är gemensamma. En order som kommer in via butiken, portalen eller API:et blir samma sorts order i systemet. Se [E-handel](/funktioner/ehandel) och [Orderhantering](/funktioner/orderhantering).

### Vanliga frågor

**Vad är skillnaden mellan omnikanal och flerkanal?**

Flerkanal betyder att du säljer på flera ställen. Omnikanal betyder att de ställena delar data. Ett bolag med webbutik, butik och Amazon säljer i tre kanaler, men blir omnikanal först när saldo, priser och orderhistorik är desamma i alla tre.

**Vad krävs tekniskt för omnikanal?**

En gemensam källa för artiklar, saldo, priser och order. Så länge varje kanal har sin egen kopia synkad i efterhand får du fördröjningar och konflikter, och det är de som skapar överförsäljning och besvärliga returer.

**Måste man ha fysisk butik för att omnikanal ska betyda något?**

Nej. En B2B-säljare som tar order per telefon och en kund som lägger samma order i portalen är två kanaler. Att säljaren ser korgen kunden byggt, och kunden ser ordern säljaren lagt, är omnikanal i praktiken.

---

## Operation

Källa: https://fluit.se/ordlista/operation
Kategori: Produktion
Uppdaterad: 2026-08-07

En operation är ett enskilt moment i tillverkningen av en produkt, till exempel kapning, svetsning, montering eller lackering. Varje operation har en plats i sekvensen, en resurs eller resursgrupp som utför den, en ställtid för förberedelse och en stycktid per enhet. Det är operationerna som gör en arbetsorder planeringsbar.

**En operation är ett moment i tillverkningen.** Kapning, svetsning, lackering, montering, kontroll. Tillsammans utgör operationerna vägen från material till färdig produkt, och det är de som gör en [arbetsorder](/kunskap/produktion/arbetsorder) möjlig att planera.

En arbetsorder utan operationer kan startas och avslutas, men den kan inte läggas mot en kapacitet, eftersom ingen vet hur lång tid den tar eller vilken resurs den upptar.

## Vad operationen bär

- **Sekvens**: i vilken ordning momenten ska utföras, och vilket som måste vara klart innan nästa kan börja.
- **Resurs eller resursgrupp**: vilken maskin, station eller person som utför momentet.
- **[Ställtid](/ordlista/stalltid)**: förberedelsen, oberoende av antal.
- **Stycktid**: tiden per enhet när körningen väl är igång.
- **Kompetenskrav**: vilken behörighet som krävs, när alla i gruppen inte kan allt.

## Överlappning

Standardantagandet är att en operation måste vara helt klar innan nästa börjar. I verkligheten gäller det sällan: så snart de första detaljerna passerat kapen kan svetsen börja.

Överlappning uttrycks som en andel av serien och kortar genomloppstiden rejält på långa serier. Det den inte gör är att minska kapacitetsbehovet. Samma timmar ska utföras, bara mer parallellt.

## Externa operationer

Ett moment som utförs av en underleverantör, till exempel ythärdning eller lackering, är fortfarande en operation i sekvensen. Skillnaden är att tiden inte belastar en egen resurs utan består av transport och leverantörens ledtid.

I Fluit kan en operation ha en leverantör och en extern referens, vilket gör legobearbetning till ett synligt steg i kedjan med en egen ledtid, i stället för ett hopp i planeringen.

### Vanliga frågor

**Vad är skillnaden mellan operation och arbetsorder?**

Arbetsordern är hela jobbet. Operationen är ett moment i det. En arbetsorder har normalt flera operationer som utförs i en bestämd ordning, var och en på sin resurs.

**Vad är överlappning mellan operationer?**

Att nästa operation startar innan den föregående är helt klar, till exempel när halva serien passerat. Det kortar genomloppstiden men minskar inte kapacitetsbehovet, eftersom samma antal timmar fortfarande ska utföras.

**Varför numreras operationer i tiotal?**

För att lämna plats. Behöver ett moment skjutas in mellan 20 och 30 kan det bli 25, utan att hela sekvensen numreras om och utan att gamla underlag blir missvisande.

---

## Orderbekräftelse

Källa: https://fluit.se/ordlista/orderbekraftelse
Kategori: Order
Uppdaterad: 2026-07-30

En orderbekräftelse är dokumentet där säljaren bekräftar att en kundorder tagits emot och accepterats. Den slår fast vilka artiklar som ska levereras, till vilka priser, när och på vilka villkor. En inköpsorderbekräftelse är samma sorts dokument sett från andra hållet: där är det leverantören som bekräftar din inköpsorder.

**En orderbekräftelse är det dokument där säljaren bekräftar att en kundorder tagits emot och accepterats.** Den slår fast vad som ska levereras och på vilka villkor, och fungerar som en överenskommelse mellan parterna.

Innehållet är oftast detsamma: orderns artiklar med antal och priser, överenskommen leveranstid och leveransvillkor, samt betalningsvillkor och referenser.

Det finns två begrepp som är lätta att blanda ihop. En orderbekräftelse går från säljaren till kunden, som svar på en inkommen kundorder. En inköpsorderbekräftelse går åt andra hållet: då är det leverantören som bekräftar en inköpsorder ditt företag har lagt. Samma sorts dokument, men rollerna byter plats beroende på var i kedjan du står. Skillnaden mot själva inköpsordern är utförligare beskriven i [Orderbekräftelse vs inköpsorder](/kunskap/inkop/orderbekraftelse-vs-inkopsorder).

Avtalsmässigt är bekräftelsen mer än en artighet, men vilken roll den har beror på hur affären kom till. Är beställningen ett anbud blir säljarens rena accept det som binder parterna, enligt 1 § avtalslagen. Har kunden i stället beställt mot en offert som redan var bindande fanns avtalet på plats när beställningen kom in, och bekräftelsen dokumenterar snarare än sluter det. Gemensamt för båda fallen: avviker bekräftelsen från beställningen, i pris, antal eller datum, är den en oren accept enligt 6 § och räknas som ett nytt anbud som motparten behöver godta. Det är därför avvikelser aldrig bör passera tyst — den som skickar en bekräftelse med ett annat datum än det beställda har inte bekräftat något, utan öppnat en ny förhandling.

Tidpunkten avgör hur mycket bekräftelsen är värd. Skickas den som ett automatiskt kvitto i samma sekund som ordern landar blir leveransdatumet en gissning, och gissningen är det kunden sedan planerar efter. Bekräftelsen bör gå ut först när priset är satt mot rätt prislista och saldot är kontrollerat mot vad som faktiskt är [tillgängligt att lova](/ordlista/atp), inklusive redan reserverade kvantiteter och inneliggande inköp.

Innehållsmässigt är det tre saker som brukar orsaka tvister i efterhand, och de bör därför alltid stå med: leveransvillkoret som avgör var risken går över, betalningsvillkoret, och kundens egen referens eller inköpsordernummer. Utan referensen får kunden svårt att matcha bekräftelsen mot sin beställning, och senare fakturan mot båda.

När något ändras efter bekräftelsen, ett framflyttat datum eller en restnoterad rad, är rätt hantering en ny bekräftelse snarare än ett mejl vid sidan om. Då finns hela överenskommelsen på ett ställe, och det är den versionen som gäller när leveransen sedan stäms av mot [följesedeln](/ordlista/foljesedel) och fakturan.

I Fluit genereras orderbekräftelsen från kundordern med aktuellt saldo och prislista, och skickas till kunden direkt. Ändras ordern efteråt kan en ny bekräftelse skickas med ändringen markerad. Se [Orderhantering](/funktioner/orderhantering) för hela orderflödet.

### Vanliga frågor

**Vad är skillnaden mellan orderbekräftelse och inköpsorderbekräftelse?**

En orderbekräftelse går från säljaren till kunden som svar på en inkommen kundorder. En inköpsorderbekräftelse går åt andra hållet: där är det leverantören som bekräftar en inköpsorder ditt företag har lagt.

**Vad ska en orderbekräftelse innehålla?**

Orderns artiklar med antal och priser, överenskommen leveranstid och leveransvillkor, samt betalningsvillkor och referenser.

**Är en orderbekräftelse juridiskt bindande?**

Det beror på var i flödet avtalet uppstod. Är beställningen ett anbud blir en ren accept från säljaren det som binder parterna, enligt 1 § avtalslagen. Har kunden i stället beställt mot en bindande offert fanns avtalet redan när beställningen kom in, och bekräftelsen är då en avstämning snarare än rättshandlingen. Avviker bekräftelsen från beställningen räknas den som en oren accept enligt 6 §, alltså ett nytt anbud som motparten behöver godta.

**När ska orderbekräftelsen skickas?**

Efter att pris och lagersaldo kontrollerats, inte som ett automatiskt kvitto i samma sekund som ordern kommer in. Bekräftelsen är framför allt ett löfte om leveransdatum, och ett datum som sätts innan saldot är kontrollerat blir ofta fel.

---

## Orderrad

Källa: https://fluit.se/ordlista/orderrad
Kategori: Order
Uppdaterad: 2026-07-30

En orderrad är en enskild rad på en order som anger en artikel med antal, pris och eventuell rabatt. Raderna styr vad som ska plockas, levereras och faktureras. Kan ordern inte levereras komplett kan en rad splittras: det som finns blir en delleverans och resten ligger kvar som restorder.

**En orderrad är en enskild rad på en order som anger en artikel med tillhörande antal, pris och eventuell rabatt.** En order består av en eller flera sådana rader, och det är raderna som styr vad som ska plockas, levereras och faktureras.

På en rad hittar du normalt själva artikeln (referens till artikelnummer eller SKU), antal och enhet, priset per enhet och en eventuell radrabatt, samt leveranstid och radstatus.

När en order inte kan levereras komplett kan en rad splittras, så kallad radsplittring. Den del som går att skicka blir en delleverans, medan resten ligger kvar som restorder. På så sätt kan varje delleverans plockas och faktureras för sig, samtidigt som den ursprungliga raden behåller spårbarheten.

Raden är också den nivå som ett [orderhanteringssystem](/kunskap/order/vad-ar-ett-orderhanteringssystem) räknar på. Allokering, plockunderlag och fakturaunderlag utgår från raden, inte från ordern som helhet.

I Fluit hanteras orderrader med stöd för delleverans och restnotering, kopplat till artikeldata från [artikelhanteringen](/funktioner/artikelhantering). Se [Orderhantering](/funktioner/orderhantering).

### Vanliga frågor

**Vad är radsplittring?**

Att en orderrad delas när ordern inte kan levereras komplett. Den del som går att skicka blir en delleverans, medan resten ligger kvar som restorder. Varje delleverans kan då plockas och faktureras för sig utan att spårbarheten bryts.

**Vad står på en orderrad?**

Referens till artikelnummer eller SKU, antal och enhet, pris per enhet och eventuell radrabatt, samt leveranstid och radstatus.

---

## Packsedel

Källa: https://fluit.se/ordlista/packsedel
Kategori: Order
Uppdaterad: 2026-07-30

En packsedel talar om vad som ligger i ett enskilt kolli, till skillnad från följesedeln som beskriver hela leveransen. Skillnaden märks när en order går i flera lådor: med packsedel kan varje kolli tas emot för sig och en avvikelse pekas ut exakt, i stället för att hela leveransen underkänns.

**En packsedel talar om vad som ligger i ett enskilt kolli.** Den skiljer sig från följesedeln genom att den beskriver paketet, inte hela leveransen, och det är precis den skillnaden som gör den nödvändig när en order går i flera lådor.

Utan packsedel måste mottagaren öppna alla paket innan hen kan kvittera något, eftersom ingen vet vad som skulle ligga var. Med packsedel kan varje kolli tas emot för sig, och avvikelsen kan pekas ut exakt: kolli 2 av 4 saknar tre enheter, inte "leveransen stämde inte".

Det gör packsedeln viktig i två lägen framför allt. Vid tunga eller skrymmande leveranser som delas upp på flera pallar, och vid leverans till kunder som har egen godsmottagning med skanning, där kollinumret på packsedeln är det som kopplar det fysiska paketet till er order.

För export tillkommer ett tredje skäl: tullen vill ha innehållet specificerat per kolli, och en packlista som stämmer med fraktsedeln sparar tid i gränsen.

I Fluit byggs kollit under packningen, och packsedeln speglar det som faktiskt lagts i paketet. Se [följesedel vs packsedel](/kunskap/order/foljesedel-vs-packsedel) för skillnaden, och [Frakt och fraktberäkning](/funktioner/frakt-och-fraktberakning) för hur kollit blir en bokad transport.

### Vanliga frågor

**Vad är skillnaden mellan packsedel och följesedel?**

Packsedeln beskriver innehållet i ett enskilt kolli, följesedeln redovisar hela leveransen. Skillnaden märks när en order går i flera lådor: med packsedel kan varje kolli tas emot för sig och avvikelsen pekas ut exakt.

**När behövs packsedel?**

Vid tunga eller skrymmande leveranser som delas upp på flera pallar, och vid leverans till kunder med egen godsmottagning med skanning. Vid export tillkommer att tullen vill ha innehållet specificerat per kolli.

---

## PIM

Källa: https://fluit.se/ordlista/pim
Kategori: E-handel
Uppdaterad: 2026-08-18

PIM står för Product Information Management och betyder ett system som samlar produktinformation: beskrivningar, bilder, attribut, översättningar och kanalspecifika texter. Syftet är att samma produkt beskrivs likadant i webbutik, katalog och marknadsplats. Ett PIM hanterar hur produkten presenteras, inte saldo, inköpspris eller order, som hör hemma i affärssystemet.

**PIM står för Product Information Management: ett system som samlar produktinformation** som beskrivningar, bilder, attribut, översättningar och kanalspecifika texter.

Behovet uppstår ur ett konkret problem. Samma produkt ska beskrivas i webbutiken, i en tryckt katalog, i en produktfeed till Google och kanske hos en marknadsplats, på flera språk, med olika mycket text beroende på kanal. Utan ett gemensamt ställe hamnar beskrivningarna i kalkylblad, och efter ett år vet ingen vilken version som är den riktiga.

Gränsen mot affärssystemet går vid frågan datan svarar på. Ett PIM svarar på hur produkten presenteras. Artikelregistret svarar på vad vi har, vad den kostade, var den ligger och vem vi köper den av. Samma artikelnummer, två olika sorters uppgifter, och den enda hårda regeln är att artikelnumret bara får skapas på ett ställe. Går det att skapa artiklar i båda systemen får du förr eller senare två produkter som är samma produkt.

Ett separat PIM är rätt investering vid stora sortiment, många kanaler och många språk, framför allt när flera personer arbetar med texterna samtidigt. För ett bolag med några tusen artiklar och en eller två butiker blir det en systemgräns till att hålla vid liv, till liten nytta.

Fluit lägger presentationen på artikeln själv: attribut och attributgrupper, varianter i matris, bilder och dokument, varumärken, kategorier, och kanalspecifika beskrivningar och SEO-texter så att en artikel kan skrivas olika i en svensk B2C-butik och en norsk B2B-kanal. Se [Artikelhantering](/funktioner/artikelhantering) och [Innehåll och SEO i webbutiken](/funktioner/webshop-innehall).

### Vanliga frågor

**Behöver alla e-handlare ett separat PIM?**

Nej. Ett eget PIM lönar sig när sortimentet är stort, när samma produkt ska publiceras i många kanaler och språk, och när flera personer arbetar med produkttexter parallellt. Har du några tusen artiklar och en butik blir ett extra system oftast en gräns till att förvalta.

**Vad är skillnaden mellan PIM och DAM?**

Ett PIM håller produktinformationen, alltså texter, attribut och relationer. Ett DAM (Digital Asset Management) håller själva mediefilerna: bilder i flera format, video och dokument. De överlappar, och många PIM-system har enklare DAM-funktioner inbyggda.

**Var ska produktdatan bo om man inte har ett PIM?**

I artikelregistret, med kanalspecifika fält ovanpå. Poängen är att artikelnumret bara finns på ett ställe och att beskrivningen kan skilja sig mellan en svensk B2C-butik och en norsk B2B-kanal utan att artikeln dubbleras.

---

## Plocklista

Källa: https://fluit.se/ordlista/plocklista
Kategori: Lager
Uppdaterad: 2026-07-30

En plocklista talar om vilka artiklar som ska plockas, från vilken lagerplats och i vilken mängd för att uppfylla en eller flera order. Den innehåller normalt artikelnummer, antal, lagerplats, eventuella batch- eller serienummer, och en plockordning enligt optimerad rutt. Listan är bryggan mellan ordern och det fysiska arbetet i lagret.

**En plocklista är det dokument eller den digitala vy som talar om vilka artiklar som ska plockas, från vilken lagerplats och i vilken mängd för att uppfylla en eller flera order.**

Den är bryggan mellan ordern och det fysiska arbetet i lagret. Listan genereras utifrån orderraderna och brukar innehålla artikelnummer och benämning, antal som ska plockas, lagerplats (bin/location), eventuella batch- eller serienummer och en plockordning enligt optimerad rutt.

En plocklista kan gälla en enskild order eller samla flera order för batchplock. Digitala listor visas direkt i en mobil enhet och kvitteras med skanning, vilket är en stor skillnad mot de pappersbaserade listorna man jobbade med förr.

I Fluit skapas plocklistor automatiskt från [orderhanteringen](/funktioner/orderhantering) och presenteras i [WMS-appen](/funktioner/wms-app), där varje rad kvitteras vid plock.

### Vanliga frågor

**Vad ska stå på en plocklista?**

Artikelnummer och benämning, antal som ska plockas, lagerplats, eventuella batch- eller serienummer, samt en plockordning enligt optimerad rutt.

**Kan en plocklista omfatta flera order?**

Ja. En plocklista kan gälla en enskild order eller samla flera order för batchplock.

---

## Plockning

Källa: https://fluit.se/ordlista/plockning
Kategori: Lager
Uppdaterad: 2026-07-30

Plockning är arbetsmomentet där en lagermedarbetare hämtar varor från sina lagerplatser för att kunna leverera en eller flera order. Arbetet styrs av en plocklista och ofta av en plockrutt som kortar gångtiden. Vid orderplock tas en order i taget, vid batchplock flera samtidigt, och vid zonplock ansvarar varje plockare för sin zon.

**Plockning är arbetsmomentet där en lagermedarbetare hämtar varor från sina lagerplatser för att kunna leverera en eller flera order.** Det är ofta det mest tidskrävande i lagret, och därmed också där det finns mest att vinna på att effektivisera.

Arbetet styrs vanligtvis av en plocklista som anger vilka artiklar som ska hämtas, i vilken mängd och från vilken plats. För att kapa onödig gångtid läggs ofta en plockrutt som tar medarbetaren genom lagret i logisk ordning.

Hur själva plocket organiseras varierar. Vid orderplock tar man en order i taget. Vid batchplock plockas flera order samtidigt i samma runda. Och vid zonplock ansvarar varje plockare för sin egen zon.

Genom att skanna streckkoder under plocket bekräftas att rätt artikel och antal hämtas, vilket håller nere felplocken. I Fluit sker plockningen mobilt via [WMS-appen](/funktioner/wms-app), där plockaren kvitterar varje rad med skanning och saldot uppdateras direkt.

### Vanliga frågor

**Vad är skillnaden mellan orderplock, batchplock och zonplock?**

Vid orderplock tar plockaren en order i taget. Vid batchplock plockas flera order samtidigt i samma runda. Vid zonplock ansvarar varje plockare för sin egen zon av lagret.

**Hur minskar man felplock?**

Genom att skanna streckkoder under plocket. Skanningen bekräftar att rätt artikel och antal hämtas, i stället för att plockaren kvitterar i efterhand.

---

## Prislista

Källa: https://fluit.se/ordlista/prislista
Kategori: Order
Uppdaterad: 2026-08-07

En prislista är en uppsättning priser för artiklar, angivna i en valuta och normalt med en giltighetstid, som kopplas till en kund eller kundgrupp. Den gör att olika kundkategorier kan ha olika priser utan att någon räknar om per order. Vid prisberäkning prövas kundspecifikt avtalat pris först, därefter volympris, sedan prislistans baspris och sist artikelns standardpris.

**En prislista håller priserna för en kundkategori.** Återförsäljare, slutkund och exportkund kan ha olika priser på samma artikel utan att någon räknar om per order, eftersom kunden är kopplad till sin lista.

Listan har en valuta och normalt en giltighetstid. Båda är viktigare än de verkar: utan valuta går priser inte att jämföra över gränser, och utan giltighetstid blir gamla listor kvar.

## Ordningen avgör

I B2B har samma artikel sällan ett pris. Den har ett listpris, ett återförsäljarpris, ett förhandlat pris för en enskild kund och ett annat pris över hundra enheter. Prisberäkningen prövar nivåerna uppifrån och ned, och den första som träffar vinner.

Utan definierad ordning kan en generell prislista slå ut ett förhandlat pris, och det upptäcks när kunden ringer.

## Rabatter ligger ovanpå

När priset valts kan rabattregler läggas på: procent, belopp per styck eller volymrabatt. Fällan är dubbelrabattering, alltså att lägga en generell volymrabatt ovanpå ett volympris som redan innehåller den. Det syns sällan på en enskild order och tydligt i årets marginal.

## Priset är inte slutet

Två saker räknas efter priset: [frakten](/kunskap/ekonomi/moms-pa-frakt), som kan vara fri över ett visst ordervärde, och skatterna. Momsen räknas på priset efter rabatt, medan en eventuell [punktskatt](/kunskap/ekonomi/punktskatt) står kvar oförändrad när priset sjunker.

Det sista är värt att komma ihåg vid kampanjer på punktskattepliktiga varor. Marginalen faller snabbare än rabatten antyder.

### Vanliga frågor

**Vad är skillnaden mellan prislista och rabatt?**

Prislistan sätter priset. Rabatten är ett avdrag som läggs ovanpå det pris som redan valts. Blandas de ihop är det lätt att rabattera ett pris som redan innehåller volymrabatten, och då ges den två gånger.

**Varför ska en prislista ha giltighetstid?**

För att listor utan slutdatum blir kvar. Efter ett par år finns flera överlappande listor och ingen vet vilken som gäller, vilket i praktiken betyder att den lägsta gäller.

**Kan en kund ha flera prislistor?**

Ja, i praktiken en huvudprislista kompletterad med kundspecifika priser och rabattregler. Det är därför prioriteringsordningen behöver vara definierad, annars går det inte att förutse vilket pris kunden får.

---

## Produktfeed

Källa: https://fluit.se/ordlista/produktfeed
Kategori: E-handel
Uppdaterad: 2026-08-18

En produktfeed är en maskinläsbar fil med butikens sortiment, som Google Shopping, Meta och prisjämförelsetjänster läser in för att kunna visa produkter med bild, pris och lagerstatus. Filen uppdateras löpande från butikens katalog. Produkter avvisas när obligatoriska fält som bild, GTIN eller varumärke saknas, ofta utan att orsaken är uppenbar.

**En produktfeed är en maskinläsbar fil med butikens sortiment**, som Google Shopping, Meta och prisjämförelsetjänster läser in för att visa produkter med bild, pris och lagerstatus.

Feeden är inte en marknadsföringstext utan en datamängd, och det är därför den ofta är den ärligaste mätaren på hur välskött produktdatan egentligen är. Allt som saknas i katalogen saknas i feeden, och där märks det direkt: produkten kommer inte med. En katalog som ser komplett ut i butiken kan tappa en tredjedel av sortimentet i inläsningen för att streckkoden ligger i ett fritextfält eller för att varumärket bara står i beskrivningen.

De fält som fäller flest produkter är i tur och ordning bild, GTIN, varumärke, beskrivning och pris. Ordningen är värd att komma ihåg, för avslagen kommer sällan med en begriplig förklaring. Bilden måste vara publikt åtkomlig, GTIN krävs för allt som bär tillverkarens streckkod, och beskrivningen får inte vara tom. Lagerstatus sätts däremot maskinellt och är sällan problemet.

Det andra som är värt ett beslut är hur mycket som ska ligga i feeden. Adressen är öppen, vilket innebär att hela sortimentet med priser är läsbart för den som känner till den. För de flesta väger trafiken tyngre, men beslutet ska fattas medvetet.

Fluit publicerar feeden direkt på butikens egen domän, en för Google Shopping och en för Meta. Den är avstängd som standard och slås på per kanal, och den kräver att kanalen visar priser utan inloggning. Se [Innehåll och SEO i webbutiken](/funktioner/webshop-innehall) och [Artikelhantering](/funktioner/artikelhantering).

### Vanliga frågor

**Varför avvisas mina produkter i Google Shopping?**

De vanligaste orsakerna är att produktbild saknas, att GTIN eller EAN inte är ifyllt på en produkt som har tillverkarens streckkod, att varumärke saknas, att beskrivningen är tom eller att priset är noll. Google anger sällan orsaken tydligt, så gå igenom fälten i den ordningen.

**Behöver egentillverkade produkter GTIN?**

Nej. Produkter du tillverkar själv och som saknar tillverkarstreckkod behöver ingen GTIN, men då måste varumärke och artikelnummer finnas i stället. Fyll aldrig i en påhittad EAN-kod, det gör mer skada än en tom ruta.

**Bör man publicera hela sortimentet i feeden?**

Väg nyttan mot att feeden är öppen. Adressen exponerar hela sortimentet med priser för vem som helst som känner till den, inklusive konkurrenter. Feeden kräver dessutom att butiken visar priser utan inloggning, så en B2B-kanal med dolda priser kan inte publicera dem.

---

## Prognos

Källa: https://fluit.se/ordlista/prognos
Kategori: Produktion
Uppdaterad: 2026-08-07

En efterfrågeprognos är en uppskattning av hur mycket som kommer att efterfrågas under en framtida period, normalt räknad per artikel, lager och vecka utifrån historisk försäljning. Prognosen används för att planera inköp och tillverkning innan order finns. Allteftersom verkliga order kommer in konsumeras prognosen, så att samma behov inte planeras två gånger.

**En prognos är en kvalificerad gissning om framtida efterfrågan.** Den behövs så snart ledtiden mot kund är kortare än ledtiden för att skaffa fram varan, alltså i praktiken nästan alltid.

Utan prognos måste allt tillverkas eller köpas mot order, och då blir leveranstiden summan av alla ledtider i kedjan. Med prognos flyttas beslutet framåt i tiden, mot priset att beslutet fattas på osäkrare underlag.

## Konsumtion är nyckelmekanismen

Det som ofta saknas i enkla upplägg är avräkningen. Prognosen säger att 200 enheter kommer att efterfrågas i vecka 34. När en order på 80 kommer in ska prognosen för den veckan minska till 120, annars planeras 280 in.

Det är samma logik som gör att en prognos aldrig ska adderas till orderstocken rakt av. Den ska ersättas av den i takt med att verkligheten materialiseras.

## Horisonten sätts av ledtiden

Prognosen behöver sträcka sig minst så långt fram som den längsta ledtiden i kedjan. Har komponenten tolv veckors leveranstid är en prognos på åtta veckor värdelös när beslutet ska fattas.

Längre horisont än nödvändigt ger däremot sällan bättre beslut. Osäkerheten växer snabbare än nyttan.

## Alla prognoser är fel

Frågan är inte om prognosen slår fel utan hur och åt vilket håll. Ett systematiskt fel, där prognosen konsekvent ligger för högt eller för lågt, är ett metodproblem som går att rätta. Slumpmässig spridning kring rätt nivå är däremot inget fel, det är variation, och det är precis vad [säkerhetslagret](/kunskap/inkop/bestallningspunkt-och-sakerhetslager) finns till för.

Skillnaden är värd att hålla isär. Bufferten löser variation men botar aldrig en skev prognos.

## Aggregering hjälper

En prognos på hela artikelgruppen är alltid träffsäkrare än summan av prognoserna per artikel, eftersom avvikelserna tar ut varandra. Samma sak gäller tid: en månadsprognos slår bättre än fyra veckoprognoser.

Det är därför planering ofta sker på en grövre nivå än den nivå där ordern läggs.

### Vanliga frågor

**Vad menas med att en prognos konsumeras?**

Att inkommande verkliga order räknas av mot prognosen för samma period. Utan avräkning skulle behovet dubbelräknas, eftersom prognosen redan planerat in den efterfrågan som ordern nu bekräftar.

**Hur långt fram ska man prognostisera?**

Minst så långt som den längsta ledtiden i kedjan, annars finns inget beslutsunderlag när ordern behöver läggas. Längre horisont än så ger sällan bättre beslut, bara mer arbete.

**Varför blir prognosen alltid fel?**

För att den beskriver framtiden. Frågan är inte om den är fel utan hur mycket, och åt vilket håll. Ett systematiskt fel åt ett håll är ett metodproblem som går att rätta, medan slumpmässig spridning är det som säkerhetslagret finns till för.

---

## Punchout

Källa: https://fluit.se/ordlista/punchout
Kategori: Inköp
Uppdaterad: 2026-09-27

Punchout är en teknik där köparen öppnar leverantörens webbutik direkt från sitt eget inköpssystem, handlar med sina avtalade priser och skickar tillbaka varukorgen till inköpssystemet i stället för att gå till kassan. Där attesteras den, och först därefter skickas inköpsordern till leverantören. OCI och cXML är de vanligaste standarderna.

**Punchout är en teknik där köparen öppnar leverantörens webbutik direkt från sitt eget inköpssystem**, handlar där och skickar tillbaka varukorgen till inköpssystemet i stället för att gå till kassan.

Poängen är att båda parter behåller det de är bra på. Köparens attest, budget och avtal ligger kvar i inköpssystemet, och leverantörens priser, lagersaldon och produktval hämtas direkt från butiken i stället för från en katalogfil som hunnit bli inaktuell.

Det som skiljer punchout från vanlig e-handel är att varukorgen inte är en order. Den blir en rekvisition hos köparen, och ordern kommer som ett eget meddelande först när den attesterats. De två vanligaste standarderna är OCI från SAP och cXML från Ariba. Hela flödet, skillnaden mot EDI och de vanligaste fallgroparna finns i [kunskapsartikeln om punchout](/kunskap/inkop/punchout-oci-cxml).

### Vanliga frågor

**Vad betyder OCI och cXML?**

OCI, Open Catalog Interface, är SAP:s standard och skickar varukorgen som formulärfält. cXML, commerce XML, togs fram av Ariba och är XML-meddelanden som kan täcka hela kedjan från varukorg till order och faktura.

**Vem har nytta av punchout?**

Köpare med ett inköpssystem och attestflöde, som köper återkommande från samma leverantör. Leverantören slipper skicka katalogfiler och kan visa aktuella priser och lagersaldon direkt.

---

## Punktskatt

Källa: https://fluit.se/ordlista/punktskatt
Kategori: Ekonomi
Uppdaterad: 2026-10-06

Punktskatt är en skatt som tas ut på utvalda varor utöver momsen, och som oftast räknas på mängd i stället för pris, till exempel per kilo, liter eller styck. Vilka varor som omfattas bestäms av lag och pekas ofta ut med varukod. Skattskyldig är den som tillverkar, för in eller tar emot varorna yrkesmässigt.

**Punktskatt är skatten på en utvald vara, lagd ovanpå momsen.** Lagstiftaren pekar ut varorna (drivmedel, alkohol, tobak, el och en del elektronik hör dit) och sätter oftast ett belopp per kilo, liter eller styck. Därför följer skatten inte priset: en vara som säljs med rabatt bär samma punktskatt som till fullpris.

## Ett räknat exempel

Exemplet är hittepå och bygger på kemikalieskatten, som räknas per kilo nettovikt. Beloppen gäller 2026: 180,71 kronor per kilo för övrig elektronik och 12,42 kronor per kilo för vitvaror, med ett tak på 552,27 kronor per vara.

| Steg | Router, 0,8 kg | Tvättmaskin, 70 kg |
| --- | --: | --: |
| Pris exkl. moms | 600,00 | 6 000,00 |
| Punktskatt före tak | 0,8 × 180,71 = 144,57 | 70 × 12,42 = 869,40 |
| Punktskatt efter tak | 144,57 | 552,27 |
| Underlag för moms | 744,57 | 6 552,27 |
| Moms 25 % | 186,14 | 1 638,07 |
| Att betala | 930,71 | 8 190,34 |

Läs raderna uppifrån: momsen räknas på priset plus punktskatten, inte på priset ensamt. På tvättmaskinen kapar taket skatten från 869,40 till 552,27 kronor. Skatteverket anger sats, tak och att vikten räknas utan emballage på sin sida om [kemikalieskatt](https://www.skatteverket.se/foretag/skatterochavdrag/punktskatter/kemikalieskatt/skattesatserochexempelpahurskattenberaknas.4.5c1163881590be297b517599.html), och att punktskatter ingår i momsens beskattningsunderlag i sin vägledning om [beskattningsunderlag](https://www.skatteverket.se/download/18.18e1b10334ebe8bc8000114052/1708608337805/kap12.pdf).

## Det som gör den besvärlig

Tre saker brukar gå fel när skatten räknas för hand:

- Satsen byter år, och en order som läggs i januari får fel belopp om den gamla satsen ligger kvar.
- Taket glöms bort, så tunga varor får för hög skatt.
- Varan har bytt kategori, för att varukoden på artikeln är fel eller saknas. Det är [HS-koden](/ordlista/hs-kod) som avgör om en vara är skattepliktig och vilken sats den får.

## Så gör du i Fluit

Funktionen är opt-in: **Punktskatt** måste vara påslagen för bolaget. Scheman, kategorier, satser och HS-kodmappningar läggs in under **Inställningar → Ekonomi → Punktskatter**. På artikelkortet sätter du HS-koden under fliken **Tullinformation** och avdragsnivå eller kategori-override under fliken **Skatter**.

Därefter räknar systemet skatten på ordern och visar den som en egen rad på fakturan. Satserna har giltighetsperioder, så nästa års sats kan läggas in i förväg och rätt sats väljs efter orderdatum. Mer om upplägget finns i artikeln om [punktskatt](/kunskap/ekonomi/punktskatt) och på sidan [Punktskatt i Fluit](/funktioner/punktskatt).

## Vad som inte ingår

Fluit räknar fram skatten och lägger den på ordern och fakturan. Registreringen hos Skatteverket, rollen som godkänd lagerhållare eller registrerad mottagare och själva deklarationen sköter du fortfarande utanför systemet. Satserna fyller du i själv och ansvarar för att de stämmer med årets belopp.

### Vanliga frågor

**Är punktskatt samma sak som moms?**

Nej. Moms tas ut på nästan all försäljning och räknas i procent av priset. Punktskatt träffar bara utvalda varor och räknas oftast på mängd. De ligger dessutom i lager: momsen räknas på varupriset plus punktskatten.

**Vad styr hur mycket punktskatt en vara får?**

Varans kategori, dess mängd (vikt, volym eller antal) eller värde, beroende på skattens beräkningsbas, och den sats som gäller vid tillfället. För en mängdbaserad punktskatt påverkar en rabatt momsen men inte punktskatten.

**Måste jag lägga punktskatten på fakturan som en egen rad?**

Det är vanligt och ger kunden ett underlag som går att följa, men kraven varierar mellan skatterna. I Fluit läggs skatten som en egen rad på fakturan, en per skatteschema.

---

## RBAC (rollbaserad behörighet)

Källa: https://fluit.se/ordlista/rbac
Kategori: Arkitektur
Uppdaterad: 2026-09-17

RBAC, rollbaserad behörighet, är en åtkomstmodell där en användares rättigheter styrs av rollen hen tilldelats, inte av vem hen är. En roll samlar behörigheter per område och resurs, till exempel läsa, ändra eller ta bort, och kan ges till flera användare. Ändras rollen slår det igenom direkt för alla som har den, utan att varje konto justeras för sig.

**RBAC, rollbaserad behörighet, är en åtkomstmodell där en användares rättigheter styrs av vilken roll hen tilldelats, inte av vem hen är.** En roll samlar behörigheter per område och resurs, till exempel läsa, ändra eller ta bort, och går att ge till flera användare samtidigt.

Skillnaden mot att sätta rättigheter person för person märks först när organisationen växer. Med ett fåtal anställda räcker det ofta att någon kommer ihåg vem som får göra vad. Blir ni fler, eller byts personal ut oftare, blir den modellen svår att hålla korrekt: någon slutar men behåller åtkomsten, någon byter avdelning men rättigheterna följer inte med, och ingen minns längre varför en viss person kunde radera fakturor. RBAC löser det genom att flytta frågan från personen till rollen. Byts en person ut, tilldelas den nya personen samma roll. Ändras vad rollen ska få göra, justeras den på ett ställe och slår igenom för alla som har den.

En roll i den här modellen kan bara smalna av behörigheten inom den grundroll en användare redan har, aldrig utöka den. En egen roll gör alltså inte en vanlig användare till administratör, bara mer eller mindre begränsad inom det egna utrymmet. Menyer i systemet styr fortfarande bara vad som **visas** för användaren, inte vad som är **tillåtet**: att dölja en funktion i en meny är inget substitut för att faktiskt begränsa åtkomsten till den.

Ett system som säljer in AI-assistenter, integrationer eller ett öppet API bör pröva samma roll oavsett väg in. En behörighet som bara gäller i webbgränssnittet men inte i API:et, eller som en AI-assistent kringgår för att den kör med en bredare systembehörighet, är i praktiken ingen behörighetsmodell. Poängen med RBAC försvinner om den bara gäller en av flera vägar in i samma data.

I Fluit skapas roller under **Inställningar → Roller** och tilldelas användare under **Inställningar → Användare**. Samma roll prövas när [AI-assistenten](/funktioner/ai-assistans) utför något åt en användare, när en AI-klient är ansluten via MCP, och vid varje anrop mot API:et: ett verktyg utanför användarens behörighet syns inte ens i listan för en ansluten assistent. Mer om hur åtkomst och behörighet hänger ihop i praktiken finns under [drift och säkerhet](/driftmiljo-och-sakerhet).

### Vanliga frågor

**Vad är skillnaden mellan RBAC och att bara ge varje användare admin- eller läsrättigheter?**

Utan RBAC sätts rättigheter ofta person för person, eller så finns bara ett fåtal grova nivåer som ger mer eller mindre åtkomst än vad rollen egentligen kräver. RBAC samlar rättigheterna i en namngiven roll som beskriver ett arbetsmoment eller en funktion, till exempel lagerpersonal eller ekonomiassistent, och tilldelar den till alla som har den funktionen. Ändras kraven justeras rollen en gång, inte varje enskilt konto.

**Kan en egen roll ge en användare mer behörighet än hen redan har?**

Nej. En roll smalnar av vad en användare kommer åt inom den behörighet hen redan har genom sin grundroll. En vanlig användare blir alltså inte administratör genom att tilldelas en roll, bara mer eller mindre begränsad inom det egna utrymmet.

**Gäller rollbaserad behörighet även när en AI-assistent agerar åt en användare?**

Ja, om modellen är konsekvent genomförd. Samma behörighet ska prövas vid varje anrop, oavsett om det kommer från webbgränssnittet, en AI-assistent, en ansluten MCP-klient eller ett API. Ett verktyg eller en åtgärd utanför användarens behörighet ska då inte vara synlig eller möjlig att utföra via någon av vägarna.

---

## Rullande inventering (cykelräkning)

Källa: https://fluit.se/ordlista/cykelrakning
Kategori: Lager
Uppdaterad: 2026-07-30

Rullande inventering, även kallad cykelräkning, är att räkna en liten del av lagret i taget, löpande under året, i stället för att stänga verksamheten och räkna allt på en gång. Varje artikel får en frekvens, ofta satt efter ABC-klass. Fördelen är att felen hittas nära i tiden, när det fortfarande går att spåra vad som hände.

**Rullande inventering är att räkna en liten del av lagret i taget, löpande under året, i stället för att stänga verksamheten och räkna allt på en gång.** Metoden kallas också cykelräkning, efter engelskans *cycle counting*, och orden används om vartannat. Varje artikel får en frekvens, och över ett år har hela sortimentet gåtts igenom, de viktigaste flera gånger.

Frekvensen sätts oftast efter [ABC-klass](/kunskap/lager/abc-analys-lager). A-artiklar räknas kanske varje kvartal, B-artiklar halvårsvis och C-artiklar en gång om året. Det ger fler räknetillfällen där kapitalet och risken finns, och färre där de inte gör det.

Fördelen framför den stora årliga inventeringen är att felen hittas nära i tiden. Upptäcks en differens i mars går det ofta att spåra vad som hände, medan en differens som upptäcks i december lika gärna kan ha uppstått i februari. Dessutom slipper lagret stå still en hel dag, och räkningen kan läggas i luckor när det ändå är lugnt.

Det finns ett förbehåll: cykelräkning ersätter inte revisionens krav på ett verifierat lagervärde vid bokslut i alla lägen. Men med dokumenterad täckning och godkända justeringar räcker den ofta som underlag, och den ger dessutom ett mer tillförlitligt saldo hela året.

I Fluit finns cykelräkning som egen inventeringstyp, med urval på ABC-klass, plats eller kategori, och räkningen görs med skanner i appen. Se [Inventering](/funktioner/inventering) och guiden [ABC-analys av lagret](/kunskap/lager/abc-analys-lager).

### Vanliga frågor

**Är rullande inventering och cykelräkning samma sak?**

Ja. Rullande inventering är det vanligare svenska ordet, cykelräkning en översättning av engelskans cycle counting. Båda betyder att lagret räknas i delar löpande under året i stället för allt på en gång, och de används om vartannat i systemdokumentation och redovisningssammanhang.

**Hur ofta ska man cykelräkna?**

Frekvensen sätts oftast efter ABC-klass. A-artiklar räknas kanske varje kvartal, B-artiklar halvårsvis och C-artiklar en gång om året. Det ger fler räknetillfällen där kapitalet och risken finns.

**Vad är fördelen med cykelräkning jämfört med årsinventering?**

Felen hittas nära i tiden. Upptäcks en differens i mars går det ofta att spåra vad som hände, medan en differens som upptäcks i december lika gärna kan ha uppstått i februari. Dessutom slipper lagret stå still en hel dag.

---

## Serienummer

Källa: https://fluit.se/ordlista/serienummer
Kategori: Lager
Uppdaterad: 2026-08-07

Ett serienummer identifierar ett enskilt exemplar av en artikel, till skillnad från ett batchnummer som identifierar ett helt parti. Det används när varje individ behöver följas för sig, typiskt vid garanti, servicehistorik, högt värde eller regulatoriska krav. Numret registreras vid inleverans, vid utleverans eller båda, beroende på hur långt spårningsbehovet sträcker sig.

**Ett serienummer pekar ut ett enskilt exemplar.** Där ett [batchnummer](/ordlista/batch) säger vilket parti något kom ur säger serienumret exakt vilken individ det handlar om.

Skillnaden märks först när något går fel. Med batch dras hela partiet in. Med serienummer går det att kontakta precis de kunder som har de berörda exemplaren.

## Vad det kostar

Precisionen är inte gratis. Varje individ måste registreras vid varje överlämning, och det är arbete som utförs av människor under tidspress. Full serienummerspårning på en artikel som säljs i tusental per dag är sällan rimlig.

Därför är valet en avvägning: spåra på individnivå det som har garanti, service eller regelkrav, och nöj dig med batch för resten.

## Tre ambitionsnivåer

- **Ingen spårning.** Vanligt saldo. Räcker för det mesta.
- **Bara vid utleverans.** Numret registreras när varan lämnar lagret. Ger svar på vilken kund som fått vilken individ, utan arbetet vid inleverans.
- **Full spårning.** Numret registreras både in och ut. Ger dessutom svar på vilken leverans individen kom med.

Mellannivån är underskattad. Den löser garantifrågan, som är det vanligaste skälet till att man vill ha serienummer, till halva arbetsinsatsen.

## Kombinationen med batch

Många produkter behöver båda: ett serienummer på den färdiga maskinen och batchnummer på de komponenter som byggts in. Då kan en komponentavvikelse översättas till en lista över exakt vilka maskiner som berörs, vilket är skillnaden mellan ett riktat utbyte och en generell återkallelse.

I Fluit sätts spårningstypen per artikel, och kan även sättas per artikel och lager när kraven skiljer sig mellan enheterna.

### Vanliga frågor

**När behövs serienummer i stället för batch?**

När den enskilda individen behöver följas: garantiärenden, servicehistorik, produkter med högt värde eller regulatoriska krav. Räcker det att veta vilket parti något kom ur är batch både billigare och tillräckligt.

**Måste serienummer registreras både in och ut?**

Inte alltid. Full spårning registrerar numret både vid inleverans och utleverans. Ett vanligt mellanläge är att bara registrera vid utleverans, vilket räcker för att veta vilken kund som fått vilken individ.

**Vad händer när en serienummermärkt vara returneras?**

Den ska registreras tillbaka mot sitt nummer, så att historiken följer individen. Utan det tappas kopplingen mellan exemplaret och dess servicehistorik, vilket är hela poängen med numret.

---

## Servicegrad

Källa: https://fluit.se/ordlista/servicegrad
Kategori: Lager
Uppdaterad: 2026-08-07

Servicegrad mäter hur stor andel av efterfrågan som kunde levereras från lager. Det vanligaste måttet räknar andelen orderrader som kunde levereras komplett direkt, medan andra varianter räknar andelen kvantitet eller andelen perioder utan brist. Måttet är den nivå säkerhetslagret dimensioneras efter, och de sista procenten kostar oproportionerligt mycket.

**Servicegrad mäter hur stor del av efterfrågan som gick att leverera.** Det är måttet som avgör hur stort [säkerhetslagret](/kunskap/inkop/bestallningspunkt-och-sakerhetslager) ska vara, och därmed hur mycket kapital som binds i buffert.

## Varianterna mäter olika saker

- **Orderradsservice**: andel orderrader som kunde levereras komplett direkt. Det vanligaste och oftast mest relevanta måttet, eftersom kunden upplever bristen per rad.
- **Kvantitetsservice**: andel av efterfrågad kvantitet som levererades. Mildare, eftersom en rad där 90 av 100 levererades räknas som 90 procent i stället för som ett misslyckande.
- **Cykelservice**: andel perioder utan någon brist alls. Strängast, och det mått som klassiska formler för säkerhetslager bygger på.

Att blanda ihop dem gör jämförelser meningslösa. Samma lager kan visa 93, 98 och 85 procent beroende på vilket mått som används.

## De sista procenten är dyrast

Sambandet mellan servicegrad och buffert är inte linjärt. Steget från 90 till 95 procent kostar en viss mängd lager. Steget från 95 till 99 kostar ungefär lika mycket till, eftersom bufferten nu ska täcka allt mer osannolika utfall.

Det är därför ett generellt mål på 99 procent för hela sortimentet nästan alltid är fel beslut. Kostnaden hamnar på de artiklar där bristen betyder minst.

## Differentiera efter värde

En rimlig ansats är att koppla målet till [ABC-klassen](/kunskap/lager/abc-analys-lager): hög servicegrad på de artiklar som står för omsättningen och för kundernas upplevelse, lägre på det som sällan efterfrågas.

Vill du räkna på vad ett visst mål innebär i buffert finns [kalkylatorn för beställningspunkt och säkerhetslager](/verktyg/bestallningspunkt).

## Skilj på servicegrad och leveransprecision

Servicegrad handlar om att kunna leverera. [Leveransprecision](/ordlista/leveransprecision) handlar om att leverera när man lovat. Ett lager kan ha hög servicegrad och usel precision, om lovade datum sätts på önsketänkande.

### Vanliga frågor

**Hur räknas servicegrad?**

Vanligast är antalet orderrader som kunde levereras komplett direkt, delat med totalt antal orderrader. Andra varianter räknar levererad kvantitet delat med efterfrågad kvantitet, eller andelen perioder helt utan brist.

**Vad är en rimlig servicegrad?**

Det beror på vad bristen kostar. För A-artiklar med hög omsättning är 97 till 99 procent vanligt, för C-artiklar räcker ofta betydligt lägre. Att sätta samma mål för hela sortimentet är nästan alltid för dyrt.

**Varför kostar de sista procenten så mycket?**

För att säkerhetslagret växer snabbare än servicegraden. Steget från 95 till 99 procent kräver ungefär dubbelt så stor buffert som steget dit, eftersom det ska täcka allt mer osannolika utfall.

---

## SKU

Källa: https://fluit.se/ordlista/sku
Kategori: Identifiering
Uppdaterad: 2026-07-30

SKU, Stock Keeping Unit, är ett unikt internt artikelnummer som identifierar en specifik lagerförd variant av en produkt. Varje kombination av modell, storlek och färg får sitt eget SKU, så att saldo och försäljning går att följa på variantnivå. Till skillnad från GTIN sätts ett SKU av företaget självt.

**SKU (Stock Keeping Unit) är ett unikt internt artikelnummer som identifierar en specifik lagerförd variant av en produkt.** Varje kombination av exempelvis modell, storlek och färg får sitt eget SKU, så att du kan följa lagersaldo och försäljning ända ner på variantnivå.

Tre saker är värda att hålla isär. Ett SKU är internt och bestäms av företaget självt. Det är unikt per variant, inte per produktfamilj. Och det följer med genomgående i order, plockning, inköp och rapportering.

Blanda inte ihop SKU med GTIN/EAN. SKU är ditt eget interna nummer som du själv råder över, medan GTIN/EAN är en global, standardiserad identifierare som ofta sitter i streckkoden. En och samma artikel kan mycket väl ha både ett SKU och ett GTIN kopplat till sig.

I Fluit motsvarar SKU artikelns identitet i [artikelhanteringen](/funktioner/artikelhantering) och används för saldon, order och analyser som [ABC-analys](/kunskap/lager/abc-analys-lager).

### Vanliga frågor

**Vad är skillnaden mellan SKU och GTIN/EAN?**

SKU är ditt eget interna artikelnummer som du själv råder över. GTIN/EAN är en global, standardiserad identifierare som ofta sitter i streckkoden. En och samma artikel kan ha både ett SKU och ett GTIN kopplat till sig.

**Ska varje variant ha ett eget SKU?**

Ja. Varje kombination av exempelvis modell, storlek och färg får sitt eget SKU, så att lagersaldo och försäljning går att följa ända ner på variantnivå.

---

## SLA

Källa: https://fluit.se/ordlista/sla
Kategori: Service
Uppdaterad: 2026-08-07

SLA, Service Level Agreement eller servicenivåavtal, anger vilken servicenivå en kund har rätt att förvänta sig. I ärendehantering uttrycks det normalt som två tider per prioritet: första svarstid och åtgärdstid. Tiden mäts under den period ni är nästa part att agera, och pausas när ärendet väntar på kunden.

**Ett SLA är ett löfte om tider.** Hur snabbt kunden får svar, och hur snabbt problemet är löst. Löftet är enkelt att formulera och svårare att mäta rättvist.

## De två tiderna

**Första svarstid** mäter hur länge kunden väntar på ett bemannat svar. Ett automatiskt kvittensmejl räknas inte, eftersom det inte innehåller någon information om ärendet.

**Åtgärdstid** mäter hur länge det tar tills problemet är löst. Den är svårare att lova, eftersom lösningen ibland kräver en reservdel eller en tredje part.

## Prioriteten ska sättas av två saker

Utlovade tider varierar med prioritet, och prioriteten bör sättas av påverkan i kombination med omfattning. Ett stopp hos en kund är inte samma sak som en fråga om en inställning, även om båda kom in samtidigt och den senare ställdes av någon mer otålig.

Sätts prioriteten i stället av vem som ringer flest gånger blir SLA en mätning av tålamod.

## Vilken tid som räknas

Den vanligaste orättvisan i SLA-uppföljning är att klockan tickar även när ärendet väntar på kunden. Då straffas den som ställer följdfrågor, och belönas den som gissar.

Därför behöver statusarna skilja på att vänta på kunden och att vänta internt. Den första ska pausa klockan, den andra inte, eftersom internt väntande fortfarande är ert ansvar.

## Kopplingen till avtalet

En SLA-nivå som inte är kopplad till kundens avtal är en ambition. Ligger den i systemet, knuten till kunden, får ärendet rätt tider automatiskt och ingen behöver minnas vilka kunder som har premiumavtal.

I Fluit sätts SLA-policyer som styr tiderna, och [ärendena](/ordlista/arendeko) fördelas till köer där de följs upp mot dem.

### Vanliga frågor

**Vad står SLA för?**

Service Level Agreement, på svenska servicenivåavtal. Det är den del av ett avtal som anger vilken servicenivå kunden har rätt att förvänta sig, oftast uttryckt som svarstider, åtgärdstider och ibland tillgänglighet.

**Räknas ett automatsvar som första svar?**

Nej. Ett automatiskt kvittensmejl bekräftar bara att ärendet kommit fram. Första svarstid avser ett bemannat svar från någon som tagit sig an ärendet.

**Ska SLA-klockan ticka när vi väntar på kunden?**

Nej. Tiden ska mätas när ni är nästa part att agera. Räknas väntan på kunden in blir uppföljningen orättvis, och den som ställer många följdfrågor ser sämst ut i statistiken.

---

## Snittordervärde

Källa: https://fluit.se/ordlista/snittordervarde
Kategori: E-handel
Uppdaterad: 2026-08-18

Snittordervärde, ofta förkortat AOV efter engelskans average order value, är det genomsnittliga beloppet per lagd order: omsättningen delat med antalet ordrar. Talet används för att bedöma om fraktgränser, merförsäljning och kampanjer flyttar köpen uppåt. Det säger ingenting om marginalen, eftersom en höjning som bygger på rabatterade tillbehör kan sänka vinsten.

**Snittordervärde är det genomsnittliga beloppet per lagd order**, omsättningen delat med antalet ordrar. Förkortningen AOV kommer av engelskans average order value och används lika ofta på svenska.

Talet är populärt för att det är enkelt att påverka. Höjer du fraktgränsen, lägger till tillbehör i korgen eller paketerar två varor tillsammans rör sig siffran nästan omedelbart. Just därför är det också lätt att lura sig själv med. Ett snittordervärde som stiger tio procent på grund av rabatterade tillbehör kan innebära att täckningsbidraget per order gått ned. Måttet mäter kronor, inte vad som blir kvar av dem.

Medelvärdet i sig döljer dessutom formen på försäljningen. Har du en handfull stora företagsordrar bland tusentals konsumentköp ligger snittet någonstans där nästan ingen order faktiskt hamnar. Medianen berättar mer om den typiska ordern, och en uppdelning per kanal berättar mest av allt: B2B och B2C ska aldrig räknas ihop.

Den mest användbara varianten är snittordervärde per trafikkälla och per kundgrupp. Det är där besluten finns. Om nyhetsbrevets ordrar är dubbelt så stora som annonstrafikens vet du var nästa krona ska läggas, vilket totalsiffran aldrig hade avslöjat.

I Fluit sätts fri frakt-gränsen per kanal, och rabattreglerna klarar mängdrabatt och kampanjer med villkor på belopp och antal. Marginalen per order finns i samma system, så en höjning går att stämma av mot vad den kostade. Se [Prishantering](/funktioner/prishantering) och [E-handel](/funktioner/ehandel).

### Vanliga frågor

**Vad är skillnaden mellan snittordervärde och kundvärde?**

Snittordervärdet gäller en enskild order. Kundvärdet gäller allt en kund handlar över tid. En kund som lägger små ordrar varje vecka kan vara mer värd än en som lägger en stor order per år, trots att den första drar ned snittordervärdet.

**Hur höjer man snittordervärdet?**

De tre vanligaste greppen är fri frakt över ett belopp strax över dagens snitt, korsförsäljning av tillbehör i korgen, och mängdrabatt som gör det lönsamt att ta fler. Det första fungerar oftast bäst, men kostar dig frakten på ordrar som ändå hade lagts.

**Varför är medelvärdet missvisande?**

För att några få stora ordrar drar upp det. En B2B-order på 200 000 kr bland tusen konsumentordrar flyttar snittet utan att något har ändrats i hur folk handlar. Titta på medianen bredvid medelvärdet, och dela upp per kanal.

---

## Streckkod

Källa: https://fluit.se/ordlista/streckkod
Kategori: Identifiering
Uppdaterad: 2026-07-30

En streckkod är en maskinläsbar kod som trycks på en artikel, etikett eller lagerplats och läses av med skanner eller mobilkamera. Den knyter ihop det fysiska objektet med rätt post i systemet. Endimensionella koder som EAN-13 kodar siffror i streck, medan tvådimensionella som QR och DataMatrix rymmer mer information.

**En streckkod är en maskinläsbar kod som trycks på en artikel, etikett eller lagerplats och läses av med en skanner eller mobilkamera.** Den knyter ihop det fysiska objektet med rätt post i affärssystemet, vilket gör hanteringen både snabbare och säkrare.

I lagret används streckkoder bland annat för att identifiera artiklar vid plockning och packning, bekräfta rätt lagerplats vid inlagring och inventering, och spåra batch och serienummer.

Koderna finns i två varianter. De endimensionella, som EAN-13, kodar siffror i streck. De tvådimensionella, som QR- och DataMatrix-koder, rymmer betydligt mer information. Gemensamt för båda är att en skanning går snabbare och blir säkrare än att skriva av ett nummer för hand.

I Fluit används streckkoder genom hela lagerarbetet. Plockaren skannar både artikel och lagerplats i [WMS-appen](/funktioner/wms-app) för att bekräfta rätt vara, plats och antal. Se även [Lager och logistik](/funktioner/lager-och-logistik).

### Vanliga frågor

**Vad är skillnaden mellan 1D- och 2D-streckkoder?**

Endimensionella koder som EAN-13 kodar siffror i streck. Tvådimensionella koder som QR och DataMatrix rymmer betydligt mer information. Gemensamt är att en skanning går snabbare och blir säkrare än att skriva av ett nummer för hand.

**Vad används streckkoder till i lagret?**

Att identifiera artiklar vid plockning och packning, bekräfta rätt lagerplats vid inlagring och inventering, och spåra batch och serienummer.

---

## Stycklista (BOM)

Källa: https://fluit.se/ordlista/stycklista
Kategori: Produktion
Uppdaterad: 2026-08-07

En stycklista, på engelska Bill of Materials eller BOM, är förteckningen över vilka komponenter som ingår i en produkt och i vilken mängd. Den är underlaget för materialplanering, kalkyl och materialuttag vid tillverkning. Är produkten uppbyggd i flera nivåer har varje halvfabrikat en egen stycklista, vilket gör att behovet kan brytas ned nivå för nivå.

**Stycklistan är receptet på produkten.** Den säger vilka komponenter som ingår och i vilken mängd, och används för tre helt olika ändamål: att planera material, att räkna fram en kalkyl och att ta ut rätt saker ur lagret när tillverkningen startar.

Att samma lista bär alla tre är styrkan och risken. En komponent som saknas i listan planeras aldrig in, kostar ingenting i kalkylen och tas aldrig ut ur lagret, men förbrukas ändå. Resultatet blir ett lagersaldo som långsamt driver isär från verkligheten.

## Nivåer

Är produkten uppbyggd i steg har varje halvfabrikat en egen stycklista. Det gör att [MRP](/ordlista/mrp) kan räkna nivå för nivå och landa i olika startdatum för olika delar av kedjan.

En **fantomartikel** är en nivå som finns för strukturens skull men aldrig lagerhålls. Vid planeringen ser systemet igenom den och planerar komponenterna direkt.

## Spill hör hemma i listan

Om det systematiskt går åt mer material än vad som blir kvar i produkten ska överskottet stå i listan. Ett kapspill på fem procent som inte finns med betyder att varje arbetsorder planeras med för lite material, vilket i praktiken flyttar problemet till verkstaden.

Det är också en kalkylfråga. En produkt vars stycklista inte innehåller spillet ser billigare ut än den är.

## Versioner

Stycklistor ändras. En konstruktionsändring ska inte tyst påverka gamla order, och det ska gå att se vilken sammansättning som gällde för det som redan tillverkats. Vid [spårbarhetskrav](/kunskap/produktion/sparbarhet) är det inte en bekvämlighet utan ett krav.

I Fluit ligger komponenterna på artikeln, och materialbehovet på en [arbetsorder](/kunskap/produktion/arbetsorder) hämtas därifrån. Varje komponent kan dessutom flaggas för [backflush](/ordlista/backflush), så att billiga delar utan spårningskrav dras av automatiskt vid färdigrapportering i stället för att kvitteras för hand.

### Vanliga frågor

**Vad är skillnaden mellan enkelnivå och flernivå stycklista?**

En enkelnivålista visar bara de komponenter som går direkt in i produkten. En flernivålista visar hela trädet ned till inköpta artiklar, inklusive halvfabrikat som har egna stycklistor.

**Ska spill räknas in i stycklistan?**

Ja, om spillet är systematiskt. Går det åt 1,05 meter material för att få ut en meter färdig detalj ska listan säga 1,05, annars planeras det för lite material i varje order och bristen upptäcks i verkstaden.

**Vad är en fantomartikel?**

En nivå i stycklistan som finns för strukturens skull men aldrig lagerhålls som egen artikel. Vid planeringen ser systemet igenom nivån och planerar komponenterna direkt, vilket ger struktur utan att skapa onödiga lagerposter.

---

## Ställtid

Källa: https://fluit.se/ordlista/stalltid
Kategori: Produktion
Uppdaterad: 2026-08-07

Ställtid är den tid det tar att förbereda en resurs för ett jobb: byta verktyg, ställa in maskinen, hämta material och köra fram till godkänd första detalj. Den är oberoende av seriestorleken, vilket gör att den slår hårt på styckkostnaden i små serier och nästan inte alls i stora. Därför är ställtiden det som i praktiken styr hur stora serier som körs.

**Ställtiden är den tid som går åt innan något produceras.** Verktyg ska bytas, maskinen ställas in, material hämtas och den första detaljen köras fram och godkännas. Först därefter går produktionen med full takt.

Det som gör ställtiden intressant är att den är oberoende av antalet. Samma fyrtiofem minuter går åt oavsett om serien är tjugo eller tvåtusen.

## Konsekvensen för seriestorleken

| Serie | Ställ | Körning | Per enhet |
| --- | --- | --- | --- |
| 20 st | 45 min | 30 min | 3,75 min |
| 200 st | 45 min | 300 min | 1,73 min |
| 2 000 st | 45 min | 3 000 min | 1,52 min |

Kurvan faller brant i början och planar sedan ut. Det är därför långa serier känns billiga, och det är också fällan: den tid som sparas i ställ betalas med kapitalbindning i färdigvarulager.

Avvägningen mellan de två är precis vad [ekonomisk seriestorlek](/verktyg/epq) räknar fram.

## Korta ställ ändrar spelplanen

Argumentet för stora serier försvagas när ställtiden sjunker. En verkstad som kortar ställen från fyrtiofem till tio minuter kan köra mindre serier till samma styckkostnad, och därmed hålla mindre lager och svara snabbare på kundernas verkliga behov.

Den klassiska metoden bygger på att skilja på **inre ställ**, det som kräver att maskinen står still, och **yttre ställ**, det som går att förbereda medan den fortfarande går. Ju mer som flyttas till det yttre, desto kortare blir stoppet.

## Sekvensen påverkar summan

Fem jobb som delar verktygsuppsättning kräver ett ställ om de körs efter varandra och fem om de sprids ut. Det betyder att en plan kan bli genomförbar bara genom att ordnas om, utan att något tas bort.

I Fluit har varje [operation](/ordlista/operation) ställtid och stycktid per enhet, vilket gör att kapacitetsbehovet räknas ut ur serien i stället för att uppskattas.

### Vanliga frågor

**Vad ingår i ställtid?**

Verktygsbyte, inställning av maskinen, hämtning av material och ritningar, provkörning och kontroll av första detaljen. Allt som måste göras innan produktionen kan gå med full takt.

**Varför är ställtid viktig?**

För att den är en fast kostnad per körning. Ju mindre serie, desto större andel av tiden går till förberedelse i stället för produktion. Det är därför korta ställtider gör små serier möjliga.

**Hur kortas ställtiden?**

Genom att flytta så mycket som möjligt av förberedelsen till tiden innan maskinen stannar: förbereda verktyg, material och program medan föregående jobb fortfarande går. Metoden brukar kallas SMED och bygger just på att skilja inre ställ från yttre.

---

## Tullvärde

Källa: https://fluit.se/ordlista/tullvarde
Kategori: Ekonomi
Uppdaterad: 2026-08-07

Tullvärdet är det belopp som tull och importmoms beräknas på vid import till EU. Huvudregeln är transaktionsvärdet, alltså det pris som faktiskt betalats för varan, med tillägg för frakt och försäkring fram till EU:s gräns samt vissa andra kostnader. Transportkostnader inom EU räknas inte in och ska dras bort om de ingår i priset.

**Tullvärdet är beloppet som tull och importmoms räknas på.** Det är sällan detsamma som fakturabeloppet, och skillnaden går åt båda hållen: vissa kostnader ska läggas till, andra dras ifrån.

## Huvudregeln

Utgångspunkten är **transaktionsvärdet**, alltså det pris som faktiskt betalats eller ska betalas för varan vid försäljning för export till EU. Till det läggs kostnader fram till införselplatsen:

- frakt och hanteringskostnader fram till EU:s gräns,
- försäkring under samma sträcka,
- provisioner (dock inte inköpsprovision),
- royalties och licensavgifter som köparen måste betala som villkor för köpet,
- värdet av material eller verktyg som köparen ställt till tillverkarens förfogande.

Från beloppet dras kostnader som avser tiden efter införseln: transport inom EU, montering och installation, samt själva tullen och importmomsen. Avdraget förutsätter att posterna kan särskiljas i underlaget, vilket i praktiken betyder att de ska stå specificerade på fakturan.

## Var gränsen går

Att gränsen dras vid införselplatsen är hela poängen med begreppet. Sjöfrakten från Shanghai till Göteborg räknas in. Lastbilen från Göteborg till ditt lager gör det inte.

Det är också där skillnaden mot [hemtagningskostnad](/ordlista/hemtagningskostnad) sitter. Tullvärdet är ett myndighetsbegrepp med en tydlig slutpunkt, medan hemtagningskostnaden är ett internt kalkylbegrepp som fortsätter hela vägen till hyllan och därför även innehåller tullen, inrikes transport och hanteringsavgifter.

## Leveransvillkoret styr underlaget

Vilka kostnader som redan ligger i priset avgörs av [Incoterms](/kunskap/inkop/incoterms-forklarade). Ett pris enligt EXW innehåller varken frakt eller försäkring, och båda ska då läggas till. Ett pris enligt DDP innehåller allt fram till din dörr, och då ska posterna efter EU:s gräns i stället räknas bort.

Därför är leveransvillkoret inte bara en fråga om vem som bokar transporten. Det avgör hur tullvärdet ska räknas fram.

## Andra metoder

Går transaktionsvärdet inte att använda, till exempel vid gåvor, provsändningar eller när köpare och säljare är närstående på ett sätt som påverkat priset, finns sekundära metoder i tullagstiftningen. De bygger på värdet av identiska eller liknande varor, på återförsäljningspriset eller på en beräknad kostnad, och tillämpas i en bestämd ordning.

### Vanliga frågor

**Vad ingår i tullvärdet?**

Priset som betalats för varan plus frakt och försäkring fram till införselplatsen i EU. Dessutom vissa tillägg som provisioner, royalties, licensavgifter och värdet av material som köparen ställt till tillverkarens förfogande.

**Vad ska inte ingå?**

Transport och försäkring inom EU efter införselplatsen, installations- och monteringskostnader efter import, importtullar och importmoms, samt inköpsprovision. Dessa ska dras av om de ingår i det fakturerade beloppet och kan särskiljas.

**Vad är skillnaden mot hemtagningskostnad?**

Tullvärdet är ett myndighetsbegrepp och stannar vid EU:s gräns. Hemtagningskostnaden är ett internt kalkylbegrepp som fortsätter hela vägen till din hylla och därför inkluderar inrikes frakt, tull och hanteringsavgifter.

---

## Utleverans

Källa: https://fluit.se/ordlista/utleverans
Kategori: Lager
Uppdaterad: 2026-08-07

Utleverans är att skicka ut gods ur lagret mot en kundorder. Artiklarna plockas från sina lagerplatser, packas, dras av från lagersaldot och lämnar lagret tillsammans med en följesedel. Det är utleveransen som avgör vad kunden faktiskt fick, och därmed vad som ska faktureras.

**Utleverans är att skicka ut gods ur lagret mot en kundorder.** Artiklarna plockas, packas, dras av från saldot och lämnar lagret med en följesedel.

Ordningen spelar roll. När ordern frisläpps finns bara en reservation: antalet är lovat till kunden men ingen har rört varan. Vid [plockningen](/ordlista/plockning) binds antalet till en bestämd [lagerplats](/ordlista/lagerplats), och det är då lagersaldot ska minska. Görs avdraget först när transporten hämtar visar systemet ett saldo som inte finns under hela plockdagen, och nästa order säljs mot varor som redan står packade.

Räcker inte saldot till hela ordern blir det ett vägval: skicka det som finns och låt resten bli [restorder](/kunskap/order/restorderhantering), eller avbryt resterande rader. Båda är rimliga, men de ger olika svar på vad kunden ska faktureras för, vilket är skälet att beslutet fattas i orderrutinen och inte av den som står vid plockvagnen.

Utleveransen är också den händelse som gör faktureringen möjlig. Fakturan ska spegla det som faktiskt skickades, inte det som beställdes, och de två sakerna är olika så fort en leverans delas upp.

I Fluit går ordern genom stegen frisläppt, plockning, packad och skickad, och lagersaldot minskar när raden plockats. Se [Lager och logistik](/funktioner/lager-och-logistik).

### Vanliga frågor

**Vad är skillnaden mellan utleverans och inleverans?**

De är varandras motsatser. Inleverans är inkommande gods som tas emot mot en inköpsorder och ökar lagersaldot. Utleverans är utgående gods som plockas mot en kundorder och minskar det. Samma kontroller behövs åt båda hållen: rätt artikel, rätt antal, rätt plats.

**När dras varan av från lagersaldot?**

Vid plockningen, inte när transporten hämtar. Så fort en artikel plockats till en order är den inte längre tillgänglig för någon annan, och saldot ska visa det. Väntar systemet till avgång hinner samma vara säljas två gånger.

**Vad händer om hela ordern inte kan levereras?**

Då blir det antingen en delleverans, där det som finns skickas och resten ligger kvar som restorder, eller så avbryts resten. Vilket som passar beror på kunden och varan, och beslutet hör hemma i orderrutinen snarare än i lagret.

**Vilket dokument följer med godset?**

En följesedel, som listar vad som faktiskt skickas i sändningen. Den skiljer sig från fakturan, som är betalningsunderlaget, och kan omfatta färre rader än ordern om leveransen är en delleverans.

---

## Ärendekö

Källa: https://fluit.se/ordlista/arendeko
Kategori: Service
Uppdaterad: 2026-08-07

En ärendekö är en grupp som gemensamt äger en uppsättning ärenden, till exempel support, teknik eller order. Inkommande ärenden fördelas till rätt kö genom triage, och plockas därifrån av någon i gruppen som blir ägare. Poängen är att ansvar som ligger på alla inte ligger på någon, och en kö gör ansvaret adresserbart.

**En ärendekö ger ansvaret en adress.** Utan kö ligger inkommande frågor i ett gemensamt hav där alla ser dem och ingen äger dem. Med kö finns en definierad grupp som förväntas plocka just de ärendena.

Det låter som en organisatorisk formalitet och är i praktiken skillnaden mellan ärenden som plockas upp och ärenden som ligger.

## Triagen är det tidskritiska momentet

Innan ärendet når en kö måste någon avgöra vad det är, hur brådskande det är och vem som ska ha det. Det beslutet är billigt att göra rätt och dyrt att göra fel: hamnar ärendet i fel kö går första svarstiden åt till att skicka det vidare, och kunden märker bara fördröjningen.

## Kö och ägare är två saker

Kön äger ärendet tills någon tar det. Då blir den personen ägare och ansvarig för att det går framåt. Skillnaden märks vid frånvaro: en ägare som är sjuk gör att ärendet ska tillbaka till kön, inte ligga kvar och vänta på att någon kommer tillbaka.

Bevakare är ett tredje begrepp som är värt att skilja ut. En bevakare följer ärendet utan att äga det, till exempel säljaren som vill veta hur det går för sin kund.

## Färre köer är oftast bättre

Varje kö kräver bemanning och bevakning. En kö som ingen känner ansvar för är sämre än ingen kö alls, eftersom ärenden nu ligger osynliga i stället för synligt obesvarade.

En rimlig utgångspunkt är en kö per verklig kompetensgräns, inte per ruta i organisationsschemat.

## I ett system

I Fluit har ärenden kö, ägare, bevakare, taggar och kommentarer, med triage som fördelar inkommande ärenden. [SLA-policyer](/ordlista/sla) sätter tiderna, och ärenden kan skapas ur inkorgen från inkommande meddelanden eller som service- och [returärenden](/kunskap/order/rma-och-returhantering) kopplade till order och artiklar.

### Vanliga frågor

**Varför räcker inte en delad inkorg?**

För att den saknar ägarskap, status och historik per ärende. Två personer kan svara samma kund olika, och den som varit sjuk i en vecka har olästa ärenden som ingen tagit över.

**Hur många köer bör man ha?**

Så få som möjligt. Varje kö kräver bemanning och bevakning, och en kö som ingen känner ansvar för är sämre än ingen kö alls. Börja med en per verklig kompetensgräns, inte per organisationsruta.

**Vad är triage?**

Det första beslutet om vad ärendet är, hur brådskande det är och vilken kö det hör till. Görs det fel förbrukas den utlovade svarstiden på att skicka ärendet rätt, vilket gör triagen till det mest tidskritiska momentet.

---

## Överföringsorder

Källa: https://fluit.se/ordlista/overforingsorder
Kategori: Lager
Uppdaterad: 2026-07-30

En överföringsorder flyttar lagersaldo från ett lager till ett annat med samma spårbarhet som en vanlig order. Flytten sker i två steg som kan ligga dagar isär: utleverans från avsändaren och inleverans hos mottagaren. Däremellan ligger antalet i transit, vilket hindrar både dubbelräkning och att varorna försvinner ur saldot.

**En överföringsorder flyttar lagersaldo från ett lager till ett annat, med samma spårbarhet som en vanlig order.** Den skiljer sig från en manuell justering genom att flytten har en avsändare, en mottagare och ett mellanläge. Det mellanläget är det som gör den nödvändig.

Godset är sällan framme samma sekund som det lämnar avsändaren. Under transporten ska antalet varken räknas som tillgängligt i avsändande lager eller finnas i mottagande, och det är just det ett transitsaldo löser. Utan det uppstår antingen dubbelräkning eller ett svart hål där varorna inte finns någonstans.

Flytten sker därför i två steg som kan ligga dagar isär: utleverans från avsändaren, inleverans hos mottagaren. Skillnaden mellan de två är transiten, och en växande transitpost är en tydlig signal om att något inte kvitteras.

Överföringar används också inom ett och samma lager, för att flytta mellan zoner, från bulkplats till plockplats när plockfacket börjar ta slut. Principen är densamma, men transiten blir kortvarig.

I Fluit har överföringsordern ett eget statusflöde från utkast till mottagen, med delvis mottagna kvantiteter och batch- eller serienummer intakta genom hela flytten. Se [Lager och logistik](/funktioner/lager-och-logistik) och [lagersaldo](/ordlista/lagersaldo) för hur transitsaldot räknas.

### Vanliga frågor

**Vad är transitsaldo?**

Det saldo som varorna ligger i under transporten mellan två lager. Under tiden ska antalet varken räknas som tillgängligt hos avsändaren eller finnas hos mottagaren. Utan transit uppstår antingen dubbelräkning eller ett svart hål där varorna inte finns någonstans.

**Varför inte bara justera saldot manuellt i båda lagren?**

För att en manuell justering saknar avsändare, mottagare och mellanläge. Överföringsordern ger flytten samma spårbarhet som en vanlig order, och en växande transitpost blir en tydlig signal om att något inte kvitteras.

---

## Övergiven varukorg

Källa: https://fluit.se/ordlista/overgiven-varukorg
Kategori: E-handel
Uppdaterad: 2026-08-18

En övergiven varukorg är en varukorg i en webbutik som fyllts med varor men aldrig blivit en order. Den räknas som övergiven när sessionen tagit slut eller korgen löpt ut utan att kunden gått igenom kassan. Andelen ligger normalt högt, och orsakerna sitter oftast i kassan: fraktkostnaden, betalsätten eller kravet på att skapa konto.

**En övergiven varukorg är en varukorg som fyllts med varor men aldrig blivit en order.** Den räknas som övergiven när sessionen tagit slut eller korgen löpt ut utan att kunden gått igenom kassan.

Andelen är hög överallt, ofta två tredjedelar eller mer, och en del av den är inte ett problem att lösa. Varukorgen används som anteckningsblock: kunden lägger i tre varianter för att jämföra, eller lägger i en vara enbart för att se vad frakten landar på. Den sortens korgar var aldrig på väg att bli ordrar.

Resten är däremot förlorad försäljning med spårbara orsaker, och de flesta av dem ligger i kassan. Fraktkostnaden som dyker upp först i sista steget är den vanligaste. Sedan kommer betalsätt som saknas, ett krav på att registrera konto innan köp, och en leveranstid som visar sig vara två veckor. Gemensamt för dem är att informationen kom för sent. En butik som visar frakt och leveranstid redan på produktsidan tappar färre kunder, även när siffrorna är exakt desamma.

För en B2B-butik är mönstret ett annat. Där betyder en liggande korg ofta att inköparen väntar på ett godkännande internt, eller att hen bygger en beställning över flera dagar. Att behandla den som ett avhopp och skicka påminnelser är att missförstå vad som pågår.

I Fluit listas kanalens korgar med status övergiven, konverterad eller utgången, tillsammans med värdet och vilka artiklar som ligger i dem. Korgar från inloggade kunder visas med kundnamn, gästernas som gäst, och innehållet i dem visar vad besökarna faktiskt var nära att köpa. Se [E-handel](/funktioner/ehandel).

### Vanliga frågor

**Hur hög andel övergivna varukorgar är normalt?**

Två tredjedelar till tre fjärdedelar av alla korgar i konsumenthandel blir aldrig en order. Talet låter alarmerande men är delvis normalt beteende: en varukorg används också som önskelista och som ett sätt att se vad frakten kostar. Följ förändringen över tid hellre än nivån.

**Vad är vanligaste orsaken till att kunder överger korgen?**

Oväntade kostnader i kassan, framför allt frakten. Därefter kommer avsaknad av det betalsätt kunden ville använda, och krav på att skapa ett konto innan köp. De tre går att åtgärda utan att röra sortimentet.

**Vad händer med lagersaldot när en korg överges?**

Det beror på om butiken reserverar saldo redan i korgen. Gör den det måste reservationen ha en tidsgräns, annars låser övergivna korgar varor som ingen ska köpa. I Fluit släpps reservationen automatiskt när korgen löper ut.

---

# Nyheter

Produktnytt, sammanfattat per månad. Till skillnad från artiklarna ovan är
det här daterade poster som inte uppdateras i efterhand: de beskriver vad
som tillkom en viss månad, inte vad produkten kan idag. Citera dem med
datum, och läs den nyaste först.

---

## Nytt i Fluit: september 2026

Källa: https://fluit.se/nyheter/nytt-i-fluit-september-2026
Publicerad: 2026-10-05
Områden: Inköp, E-handel, Försäljning, Lager, Frakt, Portaler

I september 2026 fick Fluit offertförfrågan till flera leverantörer med jämförelse och radvis tilldelning, en variantväljare med färgprov och bilder per variant i webbutiken, Swish för handpenning i butiken, Shopify som säljkanal och en Ongoing WMS-koppling som synkar av sig själv. Kunder och agenter kan lägga order i portalen, leverantörer kan skriva meddelanden, och inloggning med kod via e-post finns som alternativ till lösenord.

September handlade om att fråga flera leverantörer om pris, om en webbutik som hanterar varianter
på riktigt, och om kopplingar mot Shopify och Ongoing som numera sköter sig själva.

## Offertförfrågan till flera leverantörer

En **offertförfrågan** samlar raderna på ett ställe och går ut till de leverantörer du väljer,
med en PDF och en egen svarslänk. Leverantören svarar i ett formulär utan inloggning: pris och
ledtid per rad, i egen valuta, med möjlighet att bifoga sin egen offert. Kommer svaret per telefon
eller e-post registrerar du det själv.

**Jämför svar** ställer svaren sida vid sida, med billigaste pris per rad förvalt. Olika valutor
räknas om till baskvalutan med kursen som gällde när svaret kom, och den kursen ligger fast.
Tilldelningen sker rad för rad och skapar riktiga inköpsordrar: vinner två leverantörer varsin
rad blir det två ordrar, var och en med sitt pris, sin valuta och sin kvantitet. En rad utan
artikel kan offereras i fritext, men artikeln måste finnas innan raden blir en orderrad.

Leverantörsportalen fick samtidigt **meddelanden**: trådar på inköpsordern, så att frågan om en
leverans hamnar där den hör hemma, och en allmän tråd på leverantören.

## Webbutiken hanterar varianter på riktigt

**Variantväljaren** förväljer den första variant som går att köpa och leder aldrig till en
kombination som inte finns. Under **Inställningar → Variantattribut** väljer du om en axel visas
som knappar, färgprov eller rullgardin. Ett värde som inte finns tillsammans med det valda är
överstruket, och ett slutsålt värde går att välja för leveransbesked och restorder. I
produktlistan visar kortet den billigaste variantens pris, med **från** när varianterna kostar
olika, och upp till fem färgprover.

**Bilder per variant**: bilderna på en huvudartikel kan taggas med variantvärden. Väljer kunden
svart visar galleriet de svarta bilderna, följda av de som gäller alla varianter.

Blocket **Vanliga frågor** i sidbyggaren kan dessutom hämta sina frågor ur kunskapsartiklarna.

## Swish på plats i butiken

Handpenningen i butiken kan betalas med Swish. Plattan visar en QR-kod med butikens
Swish-nummer och beloppet ifyllda, och säljaren bekräftar när pengarna syns i butikens egen
Swish-app. Först då släpps ordern. Valet syns bara i butiker som lagt in ett Swish-nummer och bara på order i svenska kronor,
eftersom Swish inte går i annan valuta. Fluit ser inte själva betalningen, så säljaren intygar
att den kommit in: kontrollera i butikens Swish-app innan du kvitterar.

## Shopify och Ongoing WMS

En försäljningskanal kan **kopplas till en Shopify-butik**. Artiklar och priser pushas dit,
lagersaldon hålls i takt med Fluit, ordrar kommer in som vanliga kundordrar och spårningsnummer
rapporteras tillbaka när försändelsen skickas. Du väljer vilken sida som äger produkttexter och
SEO-fält.

**Kopplingen mot Ongoing WMS** sköter sig nu själv: artiklar, försändelser och inköpsordrar går
över när de ändras eller släpps, statusar hämtas hem var femte minut och ett svep fångar upp det
som ändå inte kom fram.

Fraktsätt kan kopplas till Ongoings leveranssätt och transportörer per lager, så att lagret bokar
rätt frakt. Ett fraktsätt utan koppling stoppar sändningen på lager som börjat koppla.

**Begränsningar**: returer till och från Ongoing stöds ännu inte, och en försändelse som avbryts
i Fluit måste också avbrytas i Ongoing.

## Frakt och leveransavisering

Kunden kan få ett mejl med **spårningsnummer och spårningslänk** när försändelsen är på väg,
med varje kolli för sig. Aviseringen är avstängd från början och slås på under **Inställningar →
Sälj**, och varje kund kan ha ett eget val på kundkortet. **LogTrade** går att använda som
fraktleverantör vid sidan av nShift och Zhipster, och bokningar direkt mot **DHL Freight**
fungerar hela vägen, med etikett och skälet i klartext när DHL avvisar en bokning.

LogTrade sätts upp tillsammans med supporten. Fraktpris och spårningsuppdateringar hämtas ännu
inte därifrån, och försändelser med tulldata eller farligt gods (ADR) går inte att boka via
LogTrade. Etiketter kommer som PDF och avbokning görs hos LogTrade.

## Portaler och inloggning

Kunder och agenter kan **lägga order direkt i portalen** om kontaktpersonen har behörigheten
Skapa order. En handelsagent följer sin egen försäljning under **Min försäljning**, med
fakturerat belopp per månad, provisionsunderlag och uppdelning per slutkund.

Som alternativ till lösenord går det att **logga in med en sexsiffrig kod via e-post**, i både
Fluit och kundportalen. Koden gäller i 15 minuter och kan bara användas en gång, och har du
tvåfaktor påslagen frågar Fluit efter den koden också. Konton som loggar in via Microsoft får
ingen kod, där gäller organisationens egen inloggning.

## Fältstyrning

Under **Inställningar → Fältstyrning** väljer ni vilka fält på försäljningsordern som ska visas,
vilka som är obligatoriska och vad de heter, per roll eller arbetsområde. Kund, valuta, lager och
orderdatum går inte att dölja, men går att byta namn på. Kravet gäller när någon sparar i Fluit,
inte ordrar som kommer in via e-handel, integrationer, publikt API eller Excel-import.

---

## Nytt i Fluit: augusti 2026

Källa: https://fluit.se/nyheter/nytt-i-fluit-augusti-2026
Publicerad: 2026-09-01
Områden: Order, Lager, Farligt gods, Ärenden, Publikt API, AI, Dashboard

I augusti 2026 fick Fluit farligt gods (ADR) som ny modul, batch- och serienummerspårning med FEFO och partiåterkallelse, och en ärendehantering omgjord till en arbetsyta med eskalering och ett publikt API för hela ärendeflödet. Orderns status delades från leveransstatusen, vilket flyttar kreditexponeringen till fakturering. Publika API:t fick utgående webhooks, och AI-rutiner kan nu köras på schema.

Augusti blev månaden för farligt gods, spårbarhet i lagret och en ärendehantering som fick en
egen arbetsyta, plus en ändring i orderns status som flyttar när en order räknas som
kreditrisk.

## Orderns status skiljs från leveransstatusen

Ordern har fått en egen status för affären, **Utkast → Registrerad → Frisläppt till lager →
Avslutad**, skild från **leveransstatusen**: Ej levererad, Dellevererad eller Fullt levererad.
Tidigare låg plockning, packning och leverans som statusar på ordern samtidigt som
försändelsen hade sina egna, vilket inte gick ihop när en order skickas i flera omgångar. En
order med tre rader, där en skickas idag och två nästa vecka, kan nu visa sanningen: fortfarande
frisläppt till lager, och dellevererad.

Ändringen flyttar samtidigt gränsen för **kreditexponering** från leverans till fakturering. En
order som lämnat lagret men inte fakturerats försvann tidigare ur exponeringen, trots att den var
obetald. Ett exempel med en kreditgräns på 100 000 kr:

| | Tidigare | Nu |
| --- | --- | --- |
| Order A, öppen, inte levererad | 60 000 kr | 60 000 kr |
| Order B, levererad, inte fakturerad | 0 kr, räknades inte | 50 000 kr |
| Total exponering | 60 000 kr | 110 000 kr |
| Ny order på 35 000 kr | Går igenom (95 000 kr) | Stoppas (145 000 kr) |

**Kunder nära sin kreditgräns kan därför få fler ordrar stoppade än förut**, vilket är avsikten:
en levererad men ofakturerad order är fortfarande en fordran som väntar.

Order som aldrig ska faktureras, som ersättningsenheter och demomaterial, gick tidigare inte
att stänga. Åtgärden **Avsluta utan fakturering** finns nu på en fullt levererad order och kräver
en motivering som sparas på ordern.

## Farligt gods: ett helt ADR-flöde

Fluit hanterar nu farligt gods. Regelverkets ämnesposter (UN-nummer, transportbenämning, klass,
förpackningsgrupp, tunnelrestriktion, gränser för begränsad och reducerad mängd) läggs upp
centralt och delas mellan alla bolag, och artiklar kopplas till dem med hur mycket farligt ämne
varje enhet innehåller.

Vid fraktbokning bedöms försändelsen automatiskt: systemet räknar värdeberäknad mängd enligt
ADR 1.1.3.6, avgör om lasten är undantagen eller kräver full deklaration, och fyller i
transportörens tilläggstjänst för farligt gods. Saknar leveranssättet ett sådant tillägg stoppas
bokningen i stället för att gå ut utan deklaration. Ett tjugotal vanliga poster i nordisk handel
(färg, lim, etanol, gasol, litiumbatterier med mera) finns förinlagda, och du kan inte markera en
artikel som begränsad eller reducerad mängd när regelverksposten säger att undantaget inte är
tillåtet, som för litiumbatterier.

**Begränsningarna**: Klass 1 (explosivt) och klass 7 (radioaktivt) stöds inte, de har egna
regelverk. De förinlagda posterna täcker inte hela ADR Tabell A (cirka 3 500 rader), och
uppgifterna är avstämda mot publika regelverksuppslag, inte mot MSB:s ADR-S i original.
Bedömningen är ett underlag, inte ett besked om att en transport är laglig. Kontrollera mot
ADR-S innan ni lutar er mot en post för en faktisk transport.

## Spårbarhet i lagret: batch, utgångsdatum och återkallelse

Batch- och serienummer registreras nu på riktigt vid inleverans, med utgångsdatum, i stället för
att bara följa med som text på transaktionen. Allokeringen väljer automatiskt den batch som går
ut först (FEFO) före den som kom in först, och en batch i karantän, spärrad eller utgången
räknas inte längre som tillgängligt och kan inte plockas.

Partier har fått en egen vy under **Lager → Partier**, med saldo, utgångsdatum och status, sorterat
med det som går ut först överst. Spårningsfliken svarar på tre frågor: varifrån partiet kom
(leverantör, inköpsorder eller arbetsorder), var det finns nu, och vart det tagit vägen (vilka
kundordrar och kunder som fått det). **Återkallelse** spärrar partiet, släpper öppna
reservationer och visar direkt vilka kunder som redan fått det. Ett återkallat parti går inte att
frigöra utan att återkallelsen uttryckligen hävs. Sent i månaden kom genealogin: ett parti som
förbrukats i tillverkning visar nu vilken arbetsorder det gick in i, över flera tillverkningsled.

**Begränsningen**: en artikel måste stå på nollsaldo i lagret för att slå på full spårning där,
eftersom befintligt saldo saknar batch och utgångsdatum att sortera FEFO på.

Samtidigt fick lagret **gångordning**: plocklistan sorteras nu i den ordning plockaren faktiskt
går genom lagret i stället för bokstavsordning på platskoden, beräknat under
**Inställningar → Lager → Platser**. Artiklar kan också få en egen **plockplats** skild från
lagringsplatsen, som fylls på automatiskt från bufferten när den går under sin miniminivå.

## Ärendehantering blir en arbetsyta

Ärendets detaljsida är byggd om. Status, SLA-klocka, handläggare och kö ligger i en rad överst,
innehållet är samlat under flikar, och kommentarer, statusbyten och eskaleringar visas i en
gemensam tidslinje i stället för tre separata listor. Fälten sparas direkt när du lämnar dem.

Till arbetsytan kom flera nya verktyg. Ett ärende kan nu **byta kategori** utan att förlora
kommentarer eller historik, med två nya kategorier: Firmware och Önskemål. Kategorin **RMA**
heter numera **Returärende** i listor och filter, RMA-numret på själva returauktorisationen är
oförändrat. **Eskalera** i ärendets meny skickar en fråga vidare till en person eller ett team
utan att lämna ifrån sig ärendet, mottagaren svarar i tråden och kunden ser det aldrig. Kunden kan
i sin tur bifoga filer direkt på ärendet i kundportalen.

Ärendelistan har fått **Exportera** och **Importera** i åtgärdsmenyn, användbart för att flytta in
ärenden från ett annat system eller lägga upp många på en gång. Exporten följer listans filter,
och importen valideras mot en mall innan något skapas.

Det publika API:t hanterar nu ärenden hela vägen under `/preview/tickets`: lista, uppdatera,
läsa och svara i meddelandetråden, och driva flödet med triage, kö, lösning och stängning. En
kundportal eller ett externt helpdesksystem kan därmed sköta hela handläggningen, inte bara
inlämning och statusuppslag.

## Publikt API: webhooks och fler resurser

Under **Inställningar → Webhooks** kan Fluit nu knacka på hos ett annat system så fort något
händer i stället för att integrationer ska fråga om och om igen. Varje anrop är signerat, och
misslyckade leveranser skickas om automatiskt i drygt sju timmar innan Fluit ger upp.

API:t har samtidigt vuxit med ett fyrtiotal endpoints: leveranser som egen resurs
(`/preview/shipments`) med hela kedjan från plock till leverans, lagerreskontra och
lagerjusteringar, överföringar mellan lager, offerter som går att skicka och konvertera till
order, och returer. **API-nycklarnas behörigheter börjar samtidigt gälla på riktigt**: fältet har
funnits sedan starten men lästes aldrig, så varje nyckel kom åt hela API:et. Nycklar som redan är
utfärdade och saknar angivna behörigheter fortsätter fungera obegränsat, precis som idag, men en ny
nyckel går nu att avgränsa till exakt de resurser den behöver.

Delta-synken går dessutom att lita på: en ändring i en nästlad post, som en radnotering, flyttar
nu postens `modifiedDate` som den ska, och `GET /preview/deletions` rapporterar raderade poster
som annars inte syns i någon lista.

## AI: schemalagda rutiner och ledningsrummets rådgivare

En AI-skill går nu att lägga på schema under **Inställningar → Rutiner**, i stället för att någon
behöver fråga den. Rutinen kör en skill ni redan har, i ett av tre lägen: *Rapportera* som bara
läser, *Föreslå* som lägger förslag i en godkännandekö, och *Utför* som ändrar direkt inom era
agentregler. Hittar rutinen inget att säga skickas inget mail, vilket är avsiktligt: ett dagligt
mail som säger att allt är bra filtreras bort inom en vecka.

**Ledningsrum** i menyn samlar rådgivarroller som läser er faktiska data och skriver sina
slutsatser till en gemensam yta, där ni beslutar om varje råd. Ett avvisat råd föreslås
automatiskt till nuläget, så besluten bygger den kontext rollerna läser nästa gång i stället för
att samma råd ges om och om igen. Sju roller finns från start (Säljchef, Inköpschef,
Lagerchef med flera) och kan döpas om eller stängas av. Fluit kan nu också starta rådgivarnas
körningar själv enligt schemat i deras uppdrag, i stället för att schemat legat dubbelt hos både
Fluit och AI-tjänsten.

## Kortare noterat

- **Dashboarden täcker hela verksamheten.** 41 nya widgets för ekonomi, ärenden, produktion,
  kvalitet och projekt, plus tre nya standardvyer (Ekonomi, Produktion, Service) för nya företag.
- **Idélåda med röstning** under Support → Idéer. Ni röstar på förslag, ser hur många bolag som
  ligger bakom och hur ont det gör, i stället för att en idé bara ligger som ett ensamt
  supportärende.
- **Serviceorder har fått en egen vy** under Produktion, med planeringstavla, avtalsstyrt
  underhåll och servicebilar som eget lager.
- **Webbutiken blev snabbare och mer sökbar.** Sidorna hämtar ungefär hälften så mycket
  JavaScript som tidigare, och en SEO-granskning listar sidor med problem, sorterade efter hur
  mycket trafik de ger tillbaka.
- **Menyn är en tredjedel kortare** och visar bara de moduler ni faktiskt har i er licens.
- **Egna roller och behörigheter** går nu att bygga från grunden, inte bara välja mellan de
  färdiga rollerna.

## Rättat

Fraktpåslaget på ett leveranssätt som hämtar pris från fraktbolaget lades tidigare på två gånger,
så kunden debiterades för mycket och marginalen på frakten såg ut att vara noll. Det är rättat för
nya bokningar, men **redan bokade försändelser räknas inte om automatiskt**. Har ni ett
leveranssätt med Påslag % eller Påslag belopp ifyllt är det värt att kontrollera fraktpriset på
försändelser som bokats i augusti.

Övrigt som rättats:

- Täckningsbidraget kunde visas som ett stort negativt tal på ordrar i utländsk valuta.
- En tvåfaktorskod kunde kringgås under det halvfärdiga inloggningssteget, i upp till fem minuter
  efter att lösenordet stämt.
- Adresskontrollen mot interna nät saknades på AI-assistentens webbhämtning och hämtningen av
  leverantörernas priskataloger, så en omdirigerad adress kunde nå tjänster som inte ska vara
  åtkomliga utifrån.
- Två personer som sparade samma kund, order eller artikel strax efter varandra kunde skriva
  över varandras ändringar utan att någon fick veta det.
- Global sökning (Ctrl+K) rankade inte exakta träffar högst, så en sökning på ett ordernummer
  kunde missa just den ordern till förmån för nyare träffar.
- Ärendedetaljer kunde fastna i en oändlig laddning hos företag som ännu inte lagt upp några
  ärendeköer.
- Zhipster-bokningar av lagrade sändningar nådde aldrig fram till transportören och fick varken
  kollinummer eller etiketter.
- En rabattregel med kupong kunde ge rabatten till alla kunder utan att någon angav koden.
- En systemuppdatering kunde avbrytas i förtid på företag med mycket data och lämna dem stående
  på en äldre version.

---

## Nytt i Fluit: juli 2026

Källa: https://fluit.se/nyheter/nytt-i-fluit-juli-2026
Publicerad: 2026-08-01
Rättad: 2026-08-09
Områden: Ärenden, CRM, Lager, Order, Webshop, Publikt API, AI

I juli 2026 fick Fluit ett ärendesystem med köer och SLA, en ny CRM-översikt och plockrundor för samplockning av flera försändelser. Ordersumman räknar nu in frakt och avgifter, vilket påverkar kreditkontrollen. Webshoppen fick produktsök, recensioner och feeds till Google Shopping, och det publika API:t täcker nu inköp och måttanpassade produkter.

Juli gick åt till ärenden, CRM, lagret och webshoppen, plus en rättning i ordersumman som är värd
att läsa även för den som hoppar över resten.

## Ärenden fick köer, SLA och en väg in utifrån

Ett ärende kan nu adresseras till en **kö** i stället för till en namngiven person. Lägg det i
serviceteamets kö, så ligger det kvar där tills någon plockar det. Ett ärende står inte stilla för
att en handläggare är sjuk. I kövyn ser du varje kö med antal öppna och obemannade ärenden.

Kön säger vem som förväntas ta ärendet, inte vem som får. Bemanningen är informativ i det här
steget: alla som arbetar med ärenden kan plocka ur vilken kö som helst.

**SLA räknas på riktigt.** Du sätter upp policyer med svars- och lösningstider per prioritet, och
tiderna räknas i kontorstid enligt en affärskalender. Ett ärende som kommer in fredag 16:55 med
fyra timmars svarstid förfaller måndag 11:55 i stället för mitt i helgen. Klockan pausar medan ni
väntar på kundsvar, och ett jobb går igenom öppna ärenden var femte minut och flaggar dem som
passerat sin tid.

Ärenden kan också komma in utifrån i stället för att någon på kontoret knappar in det kunden
mailade. Koppla en brevlåda till ärendeflödet, så blir varje mail ett ärende. Utgående mail har en
svarsadress per ärende, så kundens svar hamnar som kommentar på rätt ärende även när ämnesraden
ändrats eller mailet vidarebefordrats. Kunder kan dessutom anmäla och följa ärenden i kundportalen,
och ett publikt API tar emot ärenden från ett kontaktformulär på er egen webbplats.

Fördelningen mellan köer är manuell i det här steget. Det finns ingen automatisk routing och ingen
eskalering mellan köer.

## CRM har fått en egen översikt

[CRM](/funktioner/crm) har fått en startsida som samlar pipeline, förfallna uppföljningar och
nyckeltalen för vunnet och vinstgrad. Du växlar mellan dina egna affärer och hela företagets, och
uppföljningar kan bockas av direkt i listan.

Till det kom förlustorsaker och konkurrenter på förlorade affärer, prospekt som en egen livscykel
före kund, och CRM-data i egna rapporter och i Power BI-flödet. Global sökning med Ctrl+K hittar nu
även affärer, offerter, kontaktpersoner och aktiviteter.

## Ordersumman räknar med avgifterna

Orderns totalbelopp summerade tidigare bara orderraderna. Frakt, expeditionsavgift och andra
avgifter låg utanför. Det fick tre följder som alla ser ut som olika problem men är samma fel:
kreditkontrollen släppte igenom ordrar som låg över gränsen, kundexponeringen visades för lågt, och
kunden såg ett belopp i portalen och ett annat på fakturan.

Nu ingår avgifterna, och deras moms, i ordersumman. Avbrutna orderrader räknas inte längre in i
ordervärdet.

Ett exempel på en order med frakt och expeditionsavgift, räknat med 25 procent moms:

| | Tidigare | Nu |
| --- | --- | --- |
| Orderrader | 40 000 kr | 40 000 kr |
| Frakt | 1 000 kr, utanför summan | 1 000 kr, i summan |
| Expeditionsavgift | 200 kr, utanför summan | 200 kr, i summan |
| Ordersumma exklusive moms | 40 000 kr | 41 200 kr |
| Mot kreditgränsen, inklusive moms | 50 000 kr | 51 500 kr |

Kreditgränsen mäts på beloppet inklusive moms, så det är den nedersta raden som avgör om ordern
går igenom.

**Räknar ni kreditgränser på ordervärdet kan ordrar som tidigare gick igenom nu stoppas**, vilket
är avsikten. Åsidosätter någon en kreditgräns krävs numera en motivering, och det loggas vem som
godkände och när.

Två spärrar tillkom i samma veva. En orderrad som redan levererats eller fakturerats går inte att
ta bort, och priset på en fakturerad rad går inte att ändra: sådana ändringar gjorde order och
faktura oförenliga, och rättelsen är en kreditnota. Verifikat till ekonomisystemet kontrolleras nu
också så att debet och kredit går jämnt ut innan de skickas, och ett bokfört verifikat går inte
längre att ändra i efterhand.

**Avbryt återstående** är den nya åtgärden för när kunden inte vill ha resten av en delvis levererad
order. Rader som inte levererats alls avbryts, och delvis levererade rader krymps till det som
faktiskt skickats, så att ordern kan faktureras och stängas. Redan levererat antal rörs aldrig.

## Plockrundor i lagret

Flera frisläppta försändelser kan nu plockas i en gemensam runda. Raderna sorteras på lagerplats så
att varje plats besöks en gång, och varje försändelse får ett vagnfack som talar om var artiklarna
ska läggas. Du behöver aldrig hålla reda på leveransnummer under plocket: ange antal, så fördelar
systemet plocket på rätt försändelser i fackordning, med samma saldo- och spårningskontroller som
vanligt plock.

En runda omfattar ett lager och som mest tolv försändelser, och en försändelse kan bara ingå i en
aktiv runda i taget. Rundorna går att köra i [WMS-appen](/funktioner/wms-app), och plocklistan
finns som PDF.

![Plocklista som PDF med lagerplats, artikelnummer, beskrivning, vikt och antal att plocka per rad](../../assets/screenshots/produkt/plocklista.png)

Plocklistan för en enskild försändelse ser ut så här, med raderna sorterade på lagerplats. I en
plockrunda tillkommer en kolumn: vilket vagnfack artikeln ska läggas i.

### Att leverera, och en hylla för det som är öronmärkt

Orderlobbyn har fått snabbfiltret **Att leverera**, som samlar alla orderrader vars hela
återstående antal kan skickas nu och som inte redan ligger på en aktiv försändelse. Markera rader
och välj **Släpp för leverans**, så grupperas de per order och en följesedel skapas per order.
Rader som inte kan släppas hoppas över och rapporteras med orsak. Samma urval kan exporteras till
Excel som restorder- eller orderstocksrapport.

Vid inleverans kan ett lagerställe peka ut en **direktleveransplats**. När inkommande gods är
reserverat för väntande kundorder markerar inleveransappen raden med hur många som är öronmärkta,
och mottagningsdialogen föreslår en delad placering: det öronmärkta antalet till direkthyllan och
resten till ordinarie plats. Förslaget går alltid att ändra eller stänga av. Gods som läggs på
direkthyllan reserveras hårt för kundordern direkt, så att plocket hämtar där godset redan står.

### Karantänplatser räknas inte längre som tillgängligt

Saldo som står på en karantänplats eller en avaktiverad lagerplats räknas inte längre som
tillgängligt. Tidigare kunde en order lovas varor som sedan visade sig omöjliga att plocka:
reservationen gick igenom, leveransdatumet sattes, och sedan fastnade ordern.

Det här är den ändring i juli som syns mest i era egna siffror. **Tillgängligt** kan sjunka direkt
för artiklar med saldo på spärrade platser, i lagerrapporten, artikelöversikten, leveranslöftet
(ATP), orderlobbyn och webshoppens lagersaldo. Det fysiska lagersaldot är oförändrat.

## Webshoppen kan annonseras och sökas i

[Butiken](/funktioner/ehandel) kan nu publicera sin katalog som produktfeed till Google Shopping
och Metas katalog. Feeden innehåller pris, kampanjpris med giltighetstid, lagerstatus, varumärke,
streckkod, fraktpris och mått, och varianter grupperas ihop så att kunden ser dem som en produkt.
Den är avstängd som standard, och en kanal som kräver inloggning för att visa priser kan inte
publicera någon feed alls: priserna skulle då bli öppna för vem som helst.

Butiken fick också produktsök, produktrecensioner med godkännande före publicering och egna
typsnitt.

Rabattkoderna i kassan går nu genom samma rabattmotor som resten av Fluit. Kuponger som skapats
under Rabatter fungerar därmed i butiken, och regelns villkor, giltighetsdatum, maxrabatt och antal
användningar respekteras. Automatiska orderrabatter, som tio procent över 5 000 kronor, slår igenom
i butiken när villkoren är uppfyllda. Kassan gör dessutom en sista lagerkontroll när ordern läggs,
så att en vara som tagit slut sedan den lades i korgen ger ett tydligt fel i stället för att tyst
bli en restorder.

## Publikt API: inköp och måttanpassade produkter

[Det publika API:t](/api-docs/rest) täcker nu leverantörer och inköp, och har fått stöd för
produktkonfiguratorn. Bygger du en egen konfigurator för något som tillverkas efter kundens mått
och val, kan appen hämta artikelns konfigurationsschema, räkna fram pris och validering live medan
kunden väljer, spara konfigurationen och göra kundorder av den.

En detalj värd att nämna för den som redan integrerat: konfigurerade rader följer nu prislistorna.
Grundpriset hämtades tidigare direkt från artikelns försäljningspris och gick förbi prismotorn, så
kundprislistor, ramavtal, kampanjer och volympriser fick inget genomslag. Nu används samma
prishierarki som för vanliga orderrader.

## Spårning av AI-agenter

Aktivitetsloggen visar nu om en ändring gjordes av en människa eller av en AI-agent, och på vems
mandat agenten agerade. Varje verktygsanrop en agent gör sparas i en agentliggare, även rena
läsningar: annars kan en integration med enbart läsrättighet gå igenom hela kundregistret utan att
lämna spår. Du kan också kräva att en människa godkänner utvalda åtgärder innan de utförs, med
regler per kategori, per åtgärd eller per namngiven agent. Mer om hur vi tänker kring det finns på
sidan om [agentic ERP](/agentic-erp).

## Kortare noterat

- **Mobilvy för säljare och chefer.** En egen vy för den som jobbar utanför skrivbordet, med
  kundkort, orderstatus, uppgifter, besökslogg och arbetsorder för fälttekniker. Den är en
  förhandsvisning och görs för att läsa och följa upp i farten. Ändringar, prissättning och
  inställningar görs som tidigare på datorn.
- **Postnummerregister.** Skriver du ett postnummer i ett adressfält fylls orten i av sig själv, på
  kundkortet, i order- och inköpsadresser, på leverantörer, lagerställen och försändelser. Registret
  täcker Sverige, Norge, Danmark och Finland. Kontrollen är en hjälp och aldrig ett hinder: du kan
  alltid spara ändå.
- **Menyer per roll.** Menyn går att sätta upp per roll, så att lagerpersonalen inte behöver bläddra
  förbi ekonomimodulerna.
- **Portalåtkomst från kundkortet.** Du ger en kontaktperson inloggning till
  [kundportalen](/funktioner/kundportal) direkt på kundens kontaktflik, väljer roll, och skickar
  antingen en inbjudan där kontakten sätter sitt eget lösenord eller sätter ett lösenord direkt. En
  kolumn visar vilka kontakter som har åtkomst, vilken roll de har och när de senast loggade in.
- **Lagerrapport per datum.** Välj ett datum för att se saldot som det såg ut vid ett månads- eller
  årsskifte. Antal, snittpris och lagervärde räknas fram ur lagerhändelserna fram till den dagen,
  och kan exporteras till Excel och PDF. Reservationer och inkommande inköp visas inte historiskt,
  eftersom de beskriver nuläget.
- **Automatisk fakturering per ordertyp.** Varje ordertyp kan följa företagsinställningen, alltid
  fakturera vid leverans, eller aldrig. Webbordrar kan därmed faktureras automatiskt medan interna
  ordrar inte gör det. Ordertyper som inte faktureras alls, som varuprov och reklamationer, undantas
  numera helt.

## Rättat

- Pipeline-nyckeltalen summerade belopp i olika valutor rakt av.
- En affär som stängdes som vunnen eller förlorad låg kvar i det steg den råkade befinna sig i.
- Priset som skickades till sökmotorerna var exklusive moms, även i butiker som visar priser med.
- Produktsidan angav mått i millimeter fastän de registreras i centimeter, så en 25 cm bred lampa
  visades som 25 mm.
- Ändrat pris eller ändrad leveranstid på ett leveranssätt slog inte igenom i butiken.
- Momsen räknades inte om när en rabattkod användes i kassan.
- Ordrar från Klarna Checkout skapades helt utan moms på raderna.
- Ett artikelnamn med teknisk kod i sig kunde påverka sidans osynliga sökmotordata.
- Ärendelistan sorterade väntestatus fel.

---

## Nytt i Fluit: juni 2026

Källa: https://fluit.se/nyheter/nytt-i-fluit-juni-2026
Publicerad: 2026-07-01
Rättad: 2026-08-09
Områden: Lager, Produktion och kvalitet, Order, Inköp, AI, Publikt API, Ekonomi

I juni 2026 fick Fluit leveranslöfte (ATP), kvalitetskontroll på arbetsorder med kontrollplaner och avvikelser, samt förebyggande underhåll. Orderstocken fick en egen lobby, AI-kopplingen via MCP gick från API-nyckel till vanlig inloggning, och det publika API:t fick idempotensskydd och betydligt fler endpoints.

I juni växte tillverkningsdelen ifrån att bara vara arbetsordrar, och frågan om när något kan
lovas fick ett eget svar i systemet.

## Leveranslöfte

Under **Lager & logistik → Leveranslöfte** finns nu en planeringsvy per artikel och lager. Sex
nyckeltal överst, en graf över projicerat saldo, och en tabell med samtliga inflöden och behov:

| Nyckeltal | Svarar på |
| --- | --- |
| Saldo | Vad som fysiskt står på lagret. |
| Allokerat | Hur mycket av det som redan är lovat till andra ordrar. |
| Tillgängligt | Vad som är kvar att lova. |
| Öppet inköp | Vad som är beställt men inte inlevererat. |
| Planerad tillverkning | Vad som är inplanerat i produktionen. |
| Otäckt behov | Vad som saknas, alltså det som kräver en åtgärd. |

Beräkningen utgår från fritt lagersaldo, inkommande inköp och pågående tillverkning, netto mot det
som redan är reserverat för andra ordrar. Anger du antal och önskat datum får du direkt besked om
hela kvantiteten kan lovas i tid, och annars vilket datum som är tidigast möjligt. Begreppet
förklaras i ordlistan under [ATP](/ordlista/atp).

## Kvalitet på arbetsordern

[Kvalitetskontroll](/funktioner/kvalitetskontroll) kom som tre nya vyer under Produktion:
kontrollplaner, inspektioner och avvikelser.

En **kontrollplan** beskriver vad som ska kontrolleras, med mått mot tolerans, godkänt eller
underkänt, och kvittenser. Planen kopplas till artiklar, artikelkategorier, produktionsgrupper
eller ordertyper. När en arbetsorder planeras skapas inspektionerna automatiskt utifrån de planer
som matchar. Flera planer staplas, och en kundskärpt kontroll vinner över baskontrollen när de
krockar.

På inspektionen registrerar du resultat per kontrollpunkt och fattar ett accept- eller
avslagsbeslut, där en kritisk avvikelse blockerar godkännande. **Avvikelser** kan registreras
separat, och beslutas en avvikelse som kassation skrivs kassationen automatiskt på arbetsorderns
utfall.

## Förebyggande underhåll

Underhållsplaner planerar återkommande underhåll på tillgångar. En plan utlöses på kalenderintervall
(var tredje månad), på mätarintervall (var femhundrade drifttimme) eller på båda. Planen håller reda
på nästa förfallodatum, och med **Generera nu** skapar du underhållsarbetsordern direkt. Planer kan
kopplas till en tillgång, få förvald prioritet och uppskattad tid, och pausas eller arkiveras. Mer
på sidan om [underhåll](/funktioner/underhall).

## Produktkonfiguratorn nådde estimaten

Konfigurerbara artiklar kan nu prissättas via arbetsorderestimat: fyll i mått och val, se
förhandsvisningen av material och operationer, och skapa offert eller försäljningsorder direkt.
Stycklistan kan ha kvantitetsformler och villkor, så att beslag bara följer med när montering är
valt, och produktionsstegen kan ha tidsformler och villkor på samma sätt. Den sparade
konfigurationen visas på arbetsordern och går att skriva ut till produktionen.

## Orderlobbyn

Orderstocken fick samma behandling som inköpen fick i maj. Klickbara nyckeltal filtrerar på de
lägen som kräver en åtgärd: ej lagda, spärrade, försenade, sen men finns i lager, sen och väntar på
försörjning, klar att leverera, ej eller delvis allokerade, och sen mot kundens önskade datum.

Varje rad visar allokeringsstatus, leveransstatus och varifrån godset försörjs, alltså lager, inköp,
tillverkning eller överföring. Saknas en koppling står det "Ingen anskaffning" i stället för ett
missvisande "I lager" när saldot egentligen är reserverat för någon annan.
[Inköpslobbyn](/funktioner/inkop) fick i sin tur planeringslista per rad, filter på lagerställe,
leverantör och artikelgrupp, en växel mellan alla och egna rader, och export till Excel.

## AI-kopplingen bytte till inloggning

MCP-kopplingen kom först i månaden som förhandsversion, autentiserad med API-nyckel. Två dagar
senare byttes den mot vanlig inloggning:

| | Förhandsversionen | Nu |
| --- | --- | --- |
| Autentisering | API-nyckel | Vanlig Fluit-inloggning med OAuth, inklusive MFA |
| Behörighet | Nyckelns, satt av en administratör | Din egen, och du godkänner läsa och utföra var för sig |
| Vem assistenten är | Nyckeln, inte en person | Du |
| Byte av företag | Bundet till nyckeln | Väljs vid inloggning |

Att kopplingen är personlig är hela poängen. Assistenten ser aldrig mer än du själv gör, och
aktivitetsloggen kan peka ut vem den agerade för. Befintliga kopplingar med API-nyckel behövde
kopplas om, och nycklar fungerar fortfarande för det publika API:t.

Detaljerna finns på sidan om [MCP-kopplingen](/ai/mcp).

## Publikt API: idempotens och fler endpoints

Alla POST-anrop kräver nu en `Idempotency-Key`. Går ett anrop igenom men svaret försvinner på vägen
kan klienten skicka om det med samma nyckel och få originalsvaret i repris, i stället för att samma
order skapas två gånger. Samma nyckel med annat innehåll avvisas, och svar sparas i ett dygn.

Ytan växte också: lagersaldo per lager, prisberäkning inklusive kundspecifika priser och
mängdrabatter, kundens kontaktpersoner och leveransadresser, orderns leveranser med spårningsnummer,
samt ändring och borttagning av orderrader. Artiklar fick publika bilder och dokument, och
artikeldetaljen returnerar nu allt som behövs för att rendera en produktsida i ett enda anrop.
Referensen på [/api-docs/rest](/api-docs/rest) fick samtidigt en fullständig kom igång-guide.

Ett par fältnamn ändrades i samma veva. `/preview` är fortfarande en förhandsversion, och
namnbyten där sker utan bakåtkompatibilitet.

## Kortare noterat

- **Kommentarer och aktivitet.** En flik på försäljningsorder, kund, affär och offert där interna
  anteckningar och kundsynliga meddelanden ligger i samma tråd. Synligheten väljs i skrivfältet och
  är intern som standard. Fliken väver dessutom ihop ändringslogg, mejl och CRM-aktiviteter till en
  tidslinje. Kunden ser sin del i [portalen](/funktioner/kundportal), där interna anteckningar
  aldrig når fram.
- **Lagerförflyttningar går att ta emot.** Mottagningen bokför in godset på mållagrets plats och
  för förflyttningen mot Mottagen, med delmottagning. Tidigare gick en förflyttning inte att
  avsluta alls.
- **Produktbokföringsgrupper.** Försäljningskontot styrs nu av både kundens bokföringsgrupp och vad
  som säljs, via en matris. Frakt inrikes kan hamna på ett konto och frakt export på ett annat.
  Saknas en matrisrad används kundgruppens generella konto som förut.
- **Förskott på säljorder.** Ett eller flera förskottskrav per order med belopp och förfallodag.
  Förskottsfakturan skapas i Fortnox, betalstatus synkas löpande, och ordern blockeras eller
  frisläpps utifrån den. Betalda förskott avräknas sedan mot orderns fakturor.
- **SIE-export av bokförda fakturor.** Välj datumintervall och om verifikaten ska vara detaljerade
  eller grupperade.
- **Omvärderingsjournal.** Justera anskaffningsvärde, och antal, för många artiklar samtidigt, med
  Excel-import och export och full historik.
- **Integration Center.** En vy under Inställningar för att skapa och följa dataintegrationer, med
  körhistorik som visar resultat och felmeddelanden per post.

## Rättat

- Lagerförflyttningar skapade inga lagertransaktioner alls, så saldot på käll- och mållager stämde
  inte efter en förflyttning.
- Fakturor i utländsk valuta använde alltid kurs 1,0, vilket gav fel belopp i basvaluta.
- Radrabatter skickades till Fortnox utan enhet, så 15 % kunde tolkas som 15 kr.
- En order stängdes inte när sista raden minskades till redan levererat antal eller avbröts, utan
  låg kvar som öppen fast allt var skickat.
- Avgiftsartiklar gick att lägga till som vanliga orderrader.
- Beräknat leveransdatum visades även för inköpsordrar leverantören inte hade bekräftat.
- En EU-kund med giltigt VAT-nummer kunde få svensk moms i stället för omvänd skattskyldighet när
  orderraden fick nytt pris.
- Leveranssättet "Hämtas av kund" krävde en leveransadress.
- Kolumnerna i orderradstabellerna kunde hamna utanför tabellens ram i stället för att gå att rulla
  i sidled.

---

## Nytt i Fluit: maj 2026

Källa: https://fluit.se/nyheter/nytt-i-fluit-maj-2026
Publicerad: 2026-06-01
Rättad: 2026-08-09
Områden: Inköp, Priser och rabatter, Fortnox, Integrationer, CRM, Lager

I maj 2026 fick inköpen en egen arbetsyta i inköpslobbyn, och rabatterna blev provbara innan de släpps: staplingsregler, tak per rad och kupongkoder. Fortnox-integrationen började synka artiklar åt andra hållet och ordrar var tionde minut. Leverantörer och inköpsordrar går nu att importera från Excel.

Maj gav två nya arbetsytor, inköpslobbyn och rabattprovaren. Båda finns för att man ska hinna se
vad som händer innan det blir ett problem.

## Inköpslobbyn

En ny arbetsvy under Inköp som samlar alla öppna inköpsrader på ett ställe, med klickbara nyckeltal
för de fyra frågor en inköpare faktiskt ställer på morgonen: vad är inte orderkänt, vad är inte
skickat, vad är sent, och vad behöver planeras om. Tabellen visar leverantör, artikel, öppet antal,
efterfrågat datum och saldo, så att prioriteringen går att göra i listan i stället för i huvudet.

Det är samma grepp som senare kom till orderstocken. Mer om hur inköpsflödet hänger ihop finns på
sidan om [inköp](/funktioner/inkop).

## Rabatterna går att prova

Under Priser finns nu en **rabattprovare**. Välj artikel, ange mängd och eventuellt enhetspris,
kund, kundgrupp, valuta och datum, så visar verktyget exakt vilka rabatter som aktiveras, varför
vissa uteslöts, och vad slutpriset blir. Frågan "varför fick den här kunden det här priset" har
därmed ett svar som inte kräver att någon läser reglerna baklänges.

Samtidigt fick [rabattreglerna](/funktioner/prishantering) styrning över hur de samverkar. Varje
regel får ett staplingsläge:

| Läge | Vad som händer när flera regler träffar |
| --- | --- |
| Additiv | Alla aktiva rabatter summeras. |
| Bäst i grupp | Bara den förmånligaste regeln inom kombineringsgruppen aktiveras. |
| Exklusiv | Antingen slår regeln ensam, eller så kombineras de övriga. Det som ger störst rabatt vinner. |

Till det kommer två spärrar som gäller oavsett läge. **Stoppa vidare rabatter** hindrar lägre
prioriterade regler från att lägga sig ovanpå, och **Max rabatt %** sätter ett tak för hur stor den
totala rabatten på en rad får bli.

Ett exempel gör skillnaden konkret. Säg att en rad på 10 000 kr träffas av både ett kundavtal på
10 procent och en kampanj på 5 procent:

| Inställning | Rabatt | Radens pris |
| --- | --- | --- |
| Additiv | 15 % | 8 500 kr |
| Bäst i grupp | 10 % | 9 000 kr |
| Exklusiv, kundavtalet ensamt mot kampanjen | 10 % | 9 000 kr |
| Additiv med Max rabatt 12 % | 12 % | 8 800 kr |

Taket på sista raden är det som räddar dig när en kampanj och ett kundavtal råkar träffa samma rad
utan att någon tänkt igenom kombinationen.

Rabattregler kan också kopplas till **kupongkoder**, med tak för antal användningar totalt, antal
per kund och giltighetstid.

## Fortnox: synken går åt båda hållen

Artiklar kan nu synkas från Fluit till Fortnox. Slå på riktningen **Fluit → Fortnox** under
**Inställningar → Fortnox → Artiklar**, så synkas artikeln när den sparas, och du kan starta en
manuell synk från artikelkortet.

Vilka artiklar som faktiskt går över avgörs av statusen:

| Artikelstatus | Synkas till Fortnox |
| --- | --- |
| Aktiv | ja |
| Fasas ut | ja |
| Utkast | nej |
| Väntar på godkännande | nej |
| Avslutad eller arkiverad | nej |

Uppdelningen är avsiktlig: ett utkast är inte ett beslut, och att låta det skapa en artikel i
bokföringssystemet vore svårt att backa.

Ordrar hämtas nu automatiskt var tionde minut, och annullerade och levererade ordrar uppdaterar
statusen i Fluit. En **Synka nu**-knapp startar en fullständig ordersynk direkt. Kundsynken blev
dessutom tåligare vid hög belastning: anropen begränsas per anslutning och massynken körs i
kontrollerad sekvens, vilket minskar risken för avbrott när Fortnox svarar med rate limiting.

Orderrader som importeras kopplas nu till rätt lagerplats per artikel i stället för att alltid
hamna på standardlagret.

## Import från Excel

Leverantörer och inköpsordrar går nu att importera från Excel. Båda importerna kan köras i
valideringsläge först, utan att spara, och mallen laddas ned direkt ur dialogen. Vid import av
inköpsordrar blir varje rad en orderrad, och rader med samma ordernummer och leverantör grupperas
automatiskt till en order. Befintliga utkastordrar kan uppdateras i samma körning.

## Kortare noterat

- **CRM fick en kontaktlista.** Alla kontaktpersoner i systemet på en sida, med sök, filter på
  portalåtkomst och länk till kundkortet. Kunden fick i sin tur en CRM-flik med prospektstatus,
  bransch, storlek och leadkälla, plus kundens affärer, offerter, aktiviteter och uppgifter.
- **Integrationscentret blev användbart.** Scriban-mallar i transformationssteget, en sink som
  anropar en Fluit-endpoint direkt, en godkänd rapport som datakälla, och läsning och skrivning av
  filer via lokalt filsystem eller SMB-utdelning.
- **Ongoing WMS: fyra synkflöden går att stänga av var för sig.** Artiklar, utgående, ingående och
  lagersaldo. Inaktiverade flöden hoppas över i bakgrundsjobben, medan manuella åtgärder påverkas
  inte.
- **GR/IR-konto i lagerbokföringen.** Ett valfritt konto för mottaget men ej fakturerat gods, som
  används som motkonto vid inleverans i stället för kontot för sålda varors kostnad. Det är
  förutsättningen för att kunna matcha mot leverantörsfakturan senare.
- **Orderraden kan splittas efter allokering.** Varje allokeringsgrupp får en egen rad, vilket gör
  delleveranser lättare att följa. Raden kan också reduceras till den faktiskt allokerade mängden.
- **Rapportera saknat i WMS-appen.** Plockaren anger antal och orsak, saldot justeras ned, och
  kundens restorderinställning avgör vad som händer med ordern: ny restorderrad, minskad kvantitet,
  eller ett stopp när ordern måste hållas samlad.
- **Bilagor på ärenden.** Ladda upp, ladda ned och ta bort filer direkt på ärendet.

## Rättat

- En avbruten eller borttagen inköpsorderrad frigjorde inte de säljorderallokeringar som väntade på
  just den leveransen.
- Sändningslistan visade 0 kollin i både PDF och Excel.
- Ordrar som importerats från Fortnox uppdaterades inte vid efterföljande synkar, så ändrade
  leveransdatum och referenser blev kvar på det gamla.
- En PDF som laddades ner utan valt språk föll tillbaka på svenska i stället för på kundens språk.
- Fluit kunde skicka kunder, artiklar, fakturor och verifikat till Fortnox även när synkriktningen
  inte var satt åt det hållet.
- Hämtning av lagersaldon i Fortnox-migreringen svarade med fel och visade en trasig antalskolumn.
- Flera transportörsfel vid nShift-bokning slogs ihop till ett meddelande, så det gick inte att se
  om det var totalvikten eller kollivikten som var fel.

---

## Nytt i Fluit: april 2026

Källa: https://fluit.se/nyheter/nytt-i-fluit-april-2026
Publicerad: 2026-05-01
Rättad: 2026-08-09
Områden: E-handel, CRM, Order, Leverans, Utskrift, Inköp

I april 2026 började webshoppens ordrar bli riktiga försäljningsordrar i Fluit. CRM fick webbformulär som fångar affärer, filter i affärslistan och massuppdatering. Lagret fick samleverans och kontrollerat släpp av orderrader, och säljordern visar nu täckningsbidrag och täckningsgrad per rad. Skrivarprofiler kom samtidigt.

April handlade om kopplingar. Webshopen började skapa riktiga ordrar, CRM fick webbformulär som
fångar affärer, och lagret kan slå ihop leveranser som ska till samma adress.

## Webshopen skapar riktiga ordrar

En order som läggs i [butiken](/funktioner/ehandel) blir nu en försäljningsorder i Fluit, med
artikelrader, leveranssätt, valuta och kunduppgifter kopplade rätt. Butiksfronten startar också en
riktig butikssession vid första besöket, så kanalinställningar, varukorg och inloggat läge följer
med mellan sidvisningar, och den använder kanalens eget namn, navigation och tema direkt i
layouten. Både förhandsvisning och kunddomän känns som respektive butik redan från första sidan.

## CRM: fånga affären där den uppstår

Nyheten som ändrar mest i vardagen är **webbformulär**. Du bygger ett formulär, väljer fält,
pipeline, steg och tilldelning, och bäddar in det på er egen hemsida eller delar det som länk.
Inkommande svar hamnar i en lista och konverteras till affärer med ett klick.

Resten av månaden gick åt till att göra [CRM](/funktioner/crm) användbart när listorna växer:

- Affärslistan fick filter för pipeline, steg, kund och ansvarig, och massuppdatering som markerar
  flera affärer som vunna eller förlorade, eller tilldelar en säljare, i ett steg.
- Affärskortet har fått en tvåkolumnslayout med kontaktuppgifter i sidopanelen, uppgifter inline i
  huvudkolumnen och en egen flik för offerter.
- Uppgifter visar nu alla sina kopplingar: kund, affär, projekt, offert och kontakt, med
  direktlänkar till respektive post.
- I kalenderns vecko- och månadsvy skapar du en aktivitet genom att klicka i dagrutan.
- Pipelines ligger numera under Inställningar, där resten av konfigurationen bor.

Kundkortet fick samtidigt en projektflik och direktknappar för ny offert och ny affär.

## Samleverans och kontrollerat släpp

Två nya sätt att styra vad som går ut ur lagret.

**Samleverans** grupperar leveranser med samma leveransadress och slår ihop dem till en. Rader och
orderreferenser flyttas automatiskt, och skiljer sig fraktmetoderna åt får du en varning och väljer
vilken som ska gälla. När du skapar en leverans från en order föreslås dessutom andra frisläppta
ordrar till samma kund och adress som kan följa med.

**Kontrollerat släpp till laget** går åt andra hållet: du väljer vilka orderrader och vilket antal
som ska släppas, och får en leverans med just de raderna.

Två saker att känna till innan du letar efter knappen. Den ligger i mer-menyn på ordern, inte bland
sidans huvudåtgärder, och den visas bara när ordern är registrerad eller frisläppt **och** har
allokerade rader. En order utan allokering har inget att släppa, och då är knappen borta.

## Täckningsbidrag på orderraden

Självkostnaden fryses nu när orderraden skapas, och varje rad visar täckningsbidrag och
täckningsgrad. Ordersammanställningen visar totalen. Det betyder att marginalen syns när ordern
läggs, inte först i efterkalkylen.

Räknat på en rad med tio artiklar:

| | Belopp |
| --- | --- |
| Pris per styck | 450 kr |
| Självkostnad per styck, fryst vid orderraden | 320 kr |
| Radens värde, 10 st | 4 500 kr |
| Täckningsbidrag | 1 300 kr |
| Täckningsgrad | 28,9 % |

Att självkostnaden fryses är det som gör siffran stabil. Ändras artikelns kostpris i efterhand
räknas inte gamla ordrar om, så marginalen på ordern är den som gällde när den lades.

## Skrivarprofiler

Under Utskrift skapar du namngivna skrivarprofiler, till exempel "Lager 1", med regler för vilka
dokument, etiketter och kvitton som går vart. Profiler kan tilldelas per enhet, per lager, per
användare eller för hela företaget. Mer om hur utskrifterna hänger ihop finns på sidan om
[utskriftsagenten](/funktioner/utskriftsagent).

## Kortare noterat

- **Egna nummerserier.** Du kan skapa och ta bort egna serier, och koppla en serie till en
  kundgrupp så att nya kunder i gruppen får sitt nummer därifrån. Systemets inbyggda serier är
  skyddade.
- **Legacy-nummer på kund och leverantör.** Ett fält för den gamla systemreferensen, sökbart i
  väljare och importerbart via Excel. Det gör en migrering betydligt lättare att stämma av.
- **Prisstafflor på leverantörspriser.** Varje [inköpspris](/funktioner/inkop) kan ha flera
  kvantitetssteg med olika enhetspris, och prisupplösningen tar hänsyn till både stafflor och
  giltighetsdatum.
- **Fortnox-synken går var tionde minut.** Kunder, leverantörer, artiklar och kontoplan hämtas nu
  löpande i stället för en gång per natt, och du ser när synken senast kördes.
- **Artikelspecifika decimaler.** En artikel kan ha ett eget antal decimaler för kvantitet. Utan
  eget värde används enhetens standard.

## Rättat

- En order gick att avbryta även när plockningen på kopplad leverans redan hade börjat.
- Antalet på en orderrad gick att ändra efter att plockningen startat.
- Minskat antal på en orderrad slog inte igenom på en opickad leveransrad, så order, allokering och
  leverans kunde visa olika siffror.
- Ångra plockning kunde nollställa hela raden i stället för att backa det antal du valde, och gick
  inte att rikta mot ett enskilt serienummer.
- `0001-01-01` visades som önskat leveransdatum när ordern saknade datum, både i appen och på
  leveransdetaljen.
- Fortnox-synken avvisades med "ogiltig tidsstämpel" när den hämtade ändringar.
- Kundimport från Fortnox sparade landet som "Sverige" i stället för landkoden `SE`.
- Manuell kundsynk från kundkortet körde åt fel håll och försökte uppdatera Fortnox även när
  riktningen var satt till Fortnox till Fluit.
- Ett nytt projekt öppnades inte efter att det skapats, så du fick leta upp det i listan.

---