En grossist kan ha samma artikel i sortimentet till tre hundra olika priser. En kund får sitt pris från ett avtal som förhandlades fram för fem år sedan. En annan får pris baserat på vilken volym de plockar varje månad. En tredje får en tidsbegränsad kampanj som ligger ovanpå allt annat. Allt det här ska visas korrekt, för rätt kund, vid varje sidvisning.
Enligt Litiums rapport Nordic Digital Commerce in B2B 2026 är just kundspecifik prissättning den enskilt största anledningen till att B2B-företag väljer bort plattformar byggda för B2C. Det är inte produktfunktionen som fattas. Det är pris- och avtalslogiken som inte håller.
Den här guiden går igenom hur kundspecifik prissättning faktiskt fungerar i en B2B-e-handel: vilka prismodeller som är vanliga, var priset räknas ut, vad realtid betyder i praktiken, och vad du behöver ställa krav på när ni utvärderar plattformar.
1. De fem prismodellerna i B2B-e-handel
En B2B-affär lutar sig sällan på en enda prismodell. De flesta grossister och tillverkare kör flera parallellt, och plattformen måste kunna räkna ut vilken som gäller för vilken kund vid varje given tidpunkt.
Listpris är utgångspunkten. Det publicerade priset på en produkt, ofta synligt för inloggade kunder utan eget avtal eller för nya kunder utan förhandlade villkor.
Kundgruppspris bygger på segmentering. Återförsäljare, distributörer, nyckelkunder och slutkunder kan ha varsin prisnivå som gäller hela sortimentet eller delar av det. Det är ett pragmatiskt sätt att hantera kunder som har liknande villkor utan att skriva individuella avtal.
Avtalspris är individuella priser som förhandlats fram med en specifik kund. De ligger nästan alltid i affärssystemet och hämtas in i e-handeln när priset ska visas. För många grossister är det här majoriteten av prissättningen i praktiken.
Volymrabatt och stegprissättning ger lägre styckpris ju fler enheter kunden lägger i kundvagnen. Det kan vara linjärt med en procentskala eller tröskelbaserat med konkreta steg.
Kampanjpris läggs ovanpå övriga prisregler under en begränsad tid. Här blir prioriteringen viktig. Ska kampanjen slå mot avtalspriset, eller bara mot listpriset? Det är en regel som måste vara explicit definierad i systemet, inte underförstådd.
Bevent Rasch dubblerade sin orderingång efter att de kopplat e-handeln direkt mot affärssystemets prislogik. Korrekt pris för rätt kund, från första sidvisningen, utan manuell hantering. Det är inte en separat tilläggsfunktion utan själva grunden för att en B2B-e-handel ska fungera.
2. Var räknas priset ut: tre arkitekturer
En central fråga är var priset egentligen beräknas. Det finns tre vanliga uppställningar och de har var sin avvägning.
I den första ligger all logik i affärssystemet, exempelvis Monitor, Jeeves, Business Central eller SAP. E-handeln gör ett API-anrop varje gång ett pris ska visas och får tillbaka en siffra. Det ger maximal kontroll och säkerställer att samma pris gäller i webshopen, säljarens orderlägg och kundens faktura. Det ställer å andra sidan höga krav på affärssystemets API-prestanda och på smarta cachningsstrategier i e-handeln.
I den andra hanteras priser i e-handelsplattformen, med regler och prislistor som synkas från affärssystemet. Snabbare svarstid för kunden, men förutsätter att prislogiken speglas korrekt i båda systemen och att synkroniseringen verkligen fångar varje förändring.
I den tredje används en separat prismotor som en del av en headless-arkitektur. Både affärssystem och e-handelsplattform frågar samma prismotor, vilket gör det enklare att skala in andra kanaler som säljapp, kundportal och partnerintegration utan att duplicera prislogiken. Den modellen blir vanligare när företag växer in i flera marknader och försäljningskanaler.
Det viktiga är att veta vilken modell ni har, vem som äger respektive lager och vad som händer när en regel ändras. Att inte ha det svaret är den vanligaste källan till priskonflikter mellan webb och faktura.
3. Realtid eller batch: skillnaden som syns i kundens köpupplevelse
Den enskilt största arkitekturfrågan i kundspecifik prissättning är om priserna hämtas i realtid eller via schemalagda exporter.
Batchsynkronisering, där priser exporteras från affärssystemet en gång per natt eller per timme, var en acceptabel lösning för tio år sedan. I dag skapar det konkreta affärsproblem för B2B:
- En kund förhandlar fram ett nytt pris med säljaren kl 09:30. Webshopen visar det gamla priset till nästa batch körs kl 03:00, även om kunden loggar in samma eftermiddag.
- En kampanj går ut kl 16:00. Webshopen ger fortfarande kampanjpriset till natten.
- En förändring av kreditlimit eller kundgrupp tar timmar att slå igenom, vilket gör att fel kunder ser fel prislista.
Realtidsintegration betyder att varje sidvisning för en inloggad kund hämtar aktuellt pris via API-anrop direkt mot affärssystemet eller prismotorn. Det är en högre teknisk ribba att lägga sig på, men det är också det som gör att avtalskunder vågar lita på siffrorna de ser.
Apex Stainless Fasteners har 63 procent av sina B2B-kunder inloggade dagligen för att kontrollera priser och lagerstatus på egen hand. Den siffran förutsätter att kunderna litar på datan. Litar de inte på att priset stämmer, loggar de inte in. De ringer säljaren i stället, och då försvinner hela skälet att ha en digital kanal.
Ställ frågan rakt till plattformsleverantören och affärssystemsleverantören: är det realtid via API-anrop, eller är det schemalagda exporter? Det avslöjar mer om systemets B2B-mognad än vad funktionslistor gör.
4. Prestanda och cachning av kundunika priser
Här ligger en fälla som sällan tas upp i utvärderingsfasen. Kundspecifika priser kan inte cachas på samma sätt som vanliga produktdata.
För en publik produktsida räcker det att räkna ut priset en gång och servera det till alla besökare. För en inloggad B2B-kund är priset en funktion av just den kundens avtal, kundgrupp, valuta och eventuella aktiva kampanjer. Varje sidladdning kräver i värsta fall ett externt prisanrop per produkt, och en kategorisida med hundra artiklar kan utlösa hundra separata anrop.
Det är en av de vanligaste anledningarna till att B2B-sajter blir märkbart långsammare efter inloggning. Lösningen ligger i en kombination av tekniker:
- Cache per kund och prisuppsättning med tydlig invalidering vid avtalsändring
- Bulkanrop som hämtar priser för flera produkter i ett enda API-anrop i stället för ett per produkt
- Asynkron uppdatering där priset visas direkt från cache och uppdateras i bakgrunden vid förändring
- Pre-warming av prislistor för kunder med högt återkommande trafikmönster
Plattformen behöver vara byggd för det här. Det går att lägga ovanpå i efterhand, men det blir dyrt och bräckligt. Litiums B2B-e-handelsplattform stödjer kundunik prissättning via prislistor kopplade till organisationer som en kärnfunktion. Hur cachning, bulkanrop och asynkron uppdatering implementeras i ert fall avgörs tillsammans med implementationspartnern utifrån era trafikmönster och anropsvolymer mot affärssystemet.
5. Flera marknader, valutor och momsregler
Så fort en B2B-affär expanderar utanför hemmamarknaden multipliceras komplexiteten i prissättningen. Samma kund kan ha olika priser beroende på vilket land leveransen går till, vilket säljbolag som fakturerar och vilken valuta avtalet skrevs i.
Plattformen behöver hantera:
- Separata prislistor per marknad och valuta utan att duplicera hela produktregistret
- Automatisk valutahantering med möjlighet att låsa avtalspriser i en specifik valuta oavsett växelkurs
- Momsregler per land, inklusive EU:s OSS-regler för gränsöverskridande B2B-handel
- Flera juridiska bolag i samma plattformsinstans, så att en koncern kan sälja från olika säljbolag utan separata systeminstallationer
- Kunder som handlar från flera marknader med olika prisstrukturer per marknad
TMHI valde Litium specifikt för sin globalisering. När en truckorder ska gå genom flera marknader, valutor och säljbolag måste prislogiken hänga ihop i alla led. Det är en typ av komplexitet som inte syns i en demomiljö men som bestämmer om en plattform håller i fem år.
För grossister som BE Group, där varje avtalskund har sina egna villkor och flera marknader körs parallellt, blir internationaliseringen en lika viktig del av prissättningen som själva prislogiken.
6. Prisuppdateringar och ägarskap
En prismodell är aldrig statisk. Avtal omförhandlas, kampanjer startar och slutar, råvarupriser ändrar inköpspriser som måste reflekteras i sälj. Det som avgör om systemet håller över tid är hur förändringar genomförs och vem som äger dem.
Frågorna ni behöver kunna svara på:
- Vem äger uppdateringen av ett avtalspris? Är det säljaren i affärssystemet, ekonomi via en separat import, eller någon i marknads- eller e-handelsteamet?
- Hur snabbt slår en förändring igenom i webshopen efter att den registrerats i affärssystemet?
- Hur hanteras massuppdateringar, exempelvis en årlig generell prisjustering som ska slå mot tusentals avtal samtidigt?
- Vilken regel gäller för aktiva kundvagnar och offerter när priset ändras innan ordern är slutförd?
Varsego minskade sitt manuella arbete med 80 procent efter att de kopplade e-handeln direkt mot affärssystemets prislogik utan mellanlager. Det innebär att en avtalsförändring som tidigare krävde manuell hantering i flera system nu sker på ett ställe och slår igenom överallt automatiskt. Det är skillnaden mellan en e-handelskanal som skalar med antalet kunder och en som behöver mer personal för varje ny kund.
7. ERP-integration som faktiskt håller
All kundspecifik prissättning som beskrivits ovan står och faller med kopplingen mellan e-handeln och affärssystemet. Det spelar ingen roll hur smart plattformen är om integrationen inte är på plats, eller om den måste byggas om vid varje versionsuppdatering.
Skillnaden mellan en möjlig integration och en färdig integration är stor. En möjlig integration innebär att affärssystemet har ett API och att det tekniskt går att bygga en koppling. Det kan ta många månader att färdigställa och måste sedan underhållas av någon i din organisation eller av en konsult. En färdig integration är dokumenterad, testad och underhållen av plattformsleverantören eller en certifierad partner, och fungerar från dag ett.
Litiums ERP-integrationer mot Monitor, Jeeves, Business Central och SAP är byggda och underhållna av Litium eller certifierade partners. Det innebär att prislogiken har en tydlig ägare och att versionsuppdateringar i båda systemen testas innan de slår mot er produktion.
Fråga alltid tre saker: vem äger integrationen, hur ofta testas den vid versionsuppdateringar, och vad händer om integrationen går ner mitt under arbetstid. Svaren avslöjar hur långt plattformen tänkt om B2B-driftsverkligheten.
Sammanfattning: sju saker att gå igenom innan ni väljer plattform
Kundspecifik prissättning är inte en funktion på en kravlista. Det är ett område som genomsyrar hela B2B-affären online och som avgör om plattformen håller på sikt eller blir en flaskhals.
De sju punkterna att gå igenom:
- Vilka prismodeller hanterar plattformen: listpris, kundgrupp, avtal, volymrabatt och kampanj?
- Var räknas priset ut, och vem äger logiken: affärssystemet, plattformen eller en separat prismotor?
- Är prishämtningen realtid via API, eller schemalagd batchexport?
- Hur hanteras prestanda och cachning av kundunika priser i listvyer?
- Hanterar plattformen flera marknader, valutor, momsregler och säljbolag i samma instans?
- Hur snabbt slår en prisförändring igenom efter att den registrerats i affärssystemet?
- Finns en färdig, dokumenterad och underhållen ERP-integration mot ert affärssystem?
Leverantörer säljer på funktionslistor. Ni ska köpa på arkitektur, prestanda och vem som äger underhållet över tid. Det är de tre faktorerna som avgör om kundspecifik prissättning fungerar i produktion eller bara i demomiljön.