Hur du synkar ERP och lager inom B2B-e-handel

Att synka ERP och lager i B2B-e-handel innebär att webshopen visar disponibelt saldo, alltså fysiskt saldo minus öppna reservationer, hämtat från affärssystemet. Synken sker händelsestyrt för listvyer och i realtid på produktsidan, med en sista kontroll i checkout. Affärssystemet förblir sanningskälla för saldot, och e-handeln visar en tolkning av det per lagerplats, kund och marknad.

En avtalskund loggar in klockan 08:15 och ser att artikeln finns i lager. Klockan 08:20 lägger de en order på 400 enheter. Klockan 11:00 ringer er innesäljare och berättar att saldot egentligen tog slut i går eftermiddag, att leveransen är delad och att restnoteringen landar om tre veckor. Det samtalet kostar mer än en förlorad order. Det kostar förtroendet för hela den digitala kanalen.

Enligt Litiums rapport Nordic Digital Commerce in B2B 2026 har 91 procent av grossisterna i Norden i dag digitala säljkanaler. Men lagersaldo är den datapunkt som oftast visas fel, och det är också den som köparen kontrollerar först. Priset kan diskuteras i efterhand. Ett saldo som inte stämmer upptäcks direkt av kunden, varje gång.

Den här guiden går igenom hur lagerdata faktiskt synkas mellan affärssystemet och e-handeln: vad ett saldo består av, vilka synkmetoder som finns, hur flera lager och 3PL hanteras, och vad du behöver ställa krav på när ni utvärderar plattform och integration.

1. Ett lagersaldo är fyra siffror, inte en

Det första felet i många integrationsprojekt är att behandla lagersaldo som ett enda tal. I affärssystemet finns flera olika saldon för samma artikel, och frågan om vilket av dem som ska visas i webshopen är ett affärsbeslut, inte en teknisk detalj.

Fysiskt saldo är vad som står på hyllan just nu. Det är siffran de flesta menar när de säger lagersaldo, men det är sällan den som ska visas för kunden.

Reserverat saldo är enheter som redan är knutna till order som ännu inte plockats eller fakturerats. Om reservationerna inte dras av kommer webshopen att sälja samma enheter två gånger.

Disponibelt saldo är fysiskt minus reserverat, alltså det som faktiskt går att lova bort. Det här är i normalfallet den siffra e-handeln ska räkna på.

Inkommande saldo är beställt från leverantör med ett förväntat ankomstdatum. För många grossister och tillverkare är det här skillnaden mellan en förlorad order och en accepterad leveranstid, eftersom en B2B-köpare ofta hellre väntar två veckor på ett känt datum än handlar hos någon annan.

Utöver det behöver ni bestämma om ett säkerhetslager ska hållas undan från webbkanalen, exempelvis för att prioriterade avtalskunder eller serviceorganisationen alltid ska ha täckning. Beslutet är enkelt att fatta, men det måste vara explicit i integrationen, annars uppstår det som en oskriven regel i någons huvud.

2. Realtid, händelsestyrt eller batch

Nästa fråga är hur ofta saldot uppdateras. Det finns tre vanliga metoder och de går att kombinera.

Nattlig eller timvis batchexport innebär att affärssystemet skickar en fil eller ett API-anrop med hela saldolistan enligt schema. Det är enkelt att bygga och belastar affärssystemet vid en förutsägbar tidpunkt. Nackdelen är att saldot i webshopen är exakt så gammalt som tiden sedan senaste körning, vilket på artiklar med hög omsättning betyder att det är fel större delen av dygnet.

Händelsestyrd synkronisering innebär att affärssystemet eller integrationsplattformen skickar en uppdatering när något faktiskt förändras: en plockning, en inleverans, en makulerad order. Trafiken blir liten eftersom bara förändringar skickas, och saldot i e-handeln ligger normalt sekunder efter verkligheten. Det förutsätter att affärssystemet kan trigga händelser, eller att en integrationsplattform pollar tillräckligt tätt för att simulera det.

Realtidsanrop innebär att e-handeln frågar affärssystemet om saldot i samma ögonblick som kunden tittar på produkten. Det ger alltid rätt siffra, men lägger last på affärssystemet vid varje sidvisning och gör webshopen beroende av att affärssystemet svarar snabbt.

I praktiken fungerar en kombination bäst: händelsestyrd synkronisering som bas för listvyer och sök, kompletterad med ett realtidsanrop på produktsidan och en sista kontroll i checkout innan ordern bekräftas. Ställ frågan rakt till leverantören: vilken metod används per vy, och vad är den faktiska eftersläpningen mätt i sekunder?

Apex Stainless Fasteners har 63 procent av sina B2B-kunder inloggade dagligen för att kontrollera priser och lagerstatus på egen hand. Den vanan bygger på att siffrorna stämmer. Så fort de inte gör det ringer kunden säljaren i stället, och då är hela poängen med självbetjäning borta.

3. Flera lager, 3PL och saldo per kund

Få B2B-företag har allt på ett ställe. Det finns ett centrallager, ett eller flera regionallager, kanske ett 3PL-lager för vissa marknader och ett antal artiklar som levereras direkt från leverantör. Kunden ska inte behöva förstå den strukturen, men den måste finnas i datan.

Det plattformen och integrationen behöver hantera:

• Saldo per lagerplats, inte bara ett aggregerat totalsaldo för hela verksamheten
• Regler för vilket lager som ska betjäna vilken kund, baserat på leveransadress, marknad eller avtal
• Delade leveranser när en order behöver plockas från flera lager, och beslut om kunden ska kunna välja
• Direktleverans från leverantör med separat ledtid och separat saldokälla
• Ledtid räknad per lager och kund, så att kunden ser ett leveransdatum och inte bara ett antal

Ett aggregerat saldo som visar 500 enheter men där 480 ligger i ett lager som inte levererar till kundens marknad är i praktiken ett felaktigt saldo, även om summan är korrekt. Det är en av de vanligaste orsakerna till att ordrar måste hanteras manuellt efter att de kommit in.

BE Group driver flera marknader parallellt med avtalskunder som har egna villkor, och TMHI valde Litium specifikt för sin globalisering. I båda fallen är internationaliseringen och lagerlogiken samma fråga: vilket lager gäller för vilken kund, i vilket säljbolag, med vilken ledtid.

4. Reservationer, översäljning och restnotering

Även med perfekt synkroniserad data uppstår ett glapp. Två kunder kan titta på samma sista pall samtidigt, och båda ser att den finns. Frågan är vad som händer när båda lägger den i sin kundvagn.

Det finns tre vanliga modeller. Reservation redan när varan läggs i kundvagnen ger kunden störst trygghet men låser saldo som kanske aldrig blir en order, och kräver en tydlig utgångstid. Reservation vid checkout är den vanligaste kompromissen: saldot kontrolleras och reserveras i det ögonblick kunden bekräftar. Kontroll först när ordern landar i affärssystemet är enklast att bygga, men flyttar problemet till innesäljaren som får ringa kunden.

Oavsett modell behöver ni ha svar på:

• Hur länge håller en reservation innan den släpps tillbaka?
• Vad händer om saldot ändras mellan kundvagn och checkout, ska ordern stoppas eller delas?
• Tillåts backorder, och i så fall på vilka artiklar och för vilka kunder?
• Visas ett förväntat ankomstdatum vid restnotering, och uppdateras det när leverantören flyttar leveransen?
• Kan kunden själv välja mellan delleverans nu och samlad leverans senare?

För en B2B-köpare som planerar en produktion är svaret på den sista frågan ofta viktigare än själva saldot. Ett ärligt leveransdatum slår ett optimistiskt saldo varje gång.

5. Prestanda när saldot ska visas i listvyer

Lagerdata har samma prestandaproblem som kundunika priser, men med en extra dimension: saldot förändras hela tiden, även när ingen tittar.

En kategorisida med hundra artiklar kan i värsta fall utlösa hundra separata anrop mot affärssystemet, och en kund som bläddrar snabbt genom sortimentet kan generera tusentals anrop på några minuter. Om affärssystemet dessutom används för produktionsplanering och fakturering samtidigt blir e-handeln en belastning som IT-avdelningen märker.

Mönster som fungerar:

• Bulkanrop som hämtar saldo för alla artiklar i vyn i ett enda anrop i stället för ett per artikel
• Cache med kort livslängd i listvyer, kombinerad med ett färskt anrop på produktsidan
• Händelsestyrd invalidering, så att cachen slås ut när ett saldo faktiskt ändras och inte enbart på en timer
• Statusintervall i stället för exakta tal i listvyer, exempelvis fler än 100 i lager, vilket både minskar behovet av precision och skyddar er inköpsdata
• En sista kontroll i checkout, som är det enda ställe där siffran måste vara exakt

Litiums B2B-e-handelsplattform är byggd för att hantera lagerdata per lagerplats med API-baserad uppdatering. Exakt hur cachning, bulkanrop och intervall sätts upp avgörs tillsammans med implementationspartnern utifrån ert sortiment, er trafikvolym och hur mycket last affärssystemet tål.

6. Vem äger lagerdatan

Lagerdata rör sig ofta genom fler system än man tror. Affärssystemet håller det bokförda saldot, ett WMS håller det fysiska, ett 3PL-system håller det som ligger hos tredje part och e-handeln visar en tolkning av allihop. Om ingen äger helheten kommer siffrorna att glida isär.

Bestäm och dokumentera:

• Vilket system är master för fysiskt saldo, och vilket är master för disponibelt?
• Var beräknas reservationer, i affärssystemet eller i e-handeln?
• Vem sätter reglerna för säkerhetslager, och var lagras de?
• Hur ofta stäms saldona av mellan systemen, och vad händer vid avvikelse?
• Vem larmas när synkroniseringen slutar leverera uppdateringar?

Den sista punkten missas oftast. En integration som går ner högljutt är ett driftproblem som åtgärdas samma dag. En integration som går ner tyst fortsätter visa gårdagens saldo i en vecka innan någon upptäcker det, och då har ni redan hunnit bekräfta order ni inte kan leverera.

Varsego minskade sitt manuella arbete med 80 procent genom att koppla e-handeln direkt mot affärssystemets data utan mellanlager. Färre led mellan källa och kund betyder färre ställen där data kan glida isär, och färre system som någon måste komma ihåg att stämma av.

Ett sätt att slippa hela ägarskapsdiskussionen är att inte skapa fler sanningskällor än ni redan har. Litium Core är byggt på den principen för tillverkande företag som kör Monitor. Monitor förblir sanningskällan för produkter, priser, lager, kunder och order, portalen läser därifrån och skriver tillbaka order som går in i det vanliga flödet med plock, frakt och fakturering. Det finns inget mellanlager som kan glida isär, eftersom det bara finns ett system som äger saldot.

7. Vad som händer när integrationen inte svarar

Affärssystem uppgraderas, nätverk går ner och API:er svarar långsamt. Frågan är inte om det händer utan vad webshopen gör när det gör det.

En genomtänkt integration har ett definierat beteende för varje avbrott. Ska webshopen visa senast kända saldo, visa en generell tillgänglighetsstatus utan siffra, eller blockera köp helt? Ska ordrar köas och skickas när affärssystemet är tillbaka, eller ska checkout stängas? De flesta B2B-företag väljer att fortsätta ta emot order och köa dem, eftersom en stängd checkout garanterat kostar affärer medan en köad order oftast går att leverera.

Fråga leverantören tre saker innan ni skriver på. Vem äger integrationen och testar den vid versionsuppdateringar i båda systemen? Vad är det definierade beteendet vid avbrott, och går det att konfigurera per artikelgrupp? Hur larmas ni när synkroniseringen stannar?

Litiums ERP-integrationer mot Monitor, Jeeves, Business Central och SAP är byggda och underhållna av Litium eller certifierade partners. Skillnaden mot en integration som är möjlig att bygga är att någon annan än ni ansvarar för att den fortsätter fungera efter nästa uppgradering.

För Monitor-användare går det ett steg längre. I Litium Core är portalen och Monitor-kopplingen förkonfigurerade och har körts mot Monitor tidigare, vilket gör att lagersynken inte är något ni kravställer och bygger utan något ni konfigurerar. Det som tar tid blir er produktkatalog i stället för integrationskoden. Kör ni ett annat affärssystem, eller behöver en egen frontend, är det i stället den fulla plattformen med en implementationspartner som gäller.

Sammanfattning: sju frågor att gå igenom före ett integrationsprojekt

Lagersynkronisering ser ut som en teknisk detalj i en kravlista och visar sig i praktiken vara det som avgör om avtalskunderna använder den digitala kanalen eller ringer säljaren som förut.

De sju punkterna att gå igenom:

• Vilket saldo ska visas för kunden: fysiskt, disponibelt eller ett intervall, och hur hanteras säkerhetslager?
• Hur synkas saldot per vy: batch, händelsestyrt eller realtid, och vad är den faktiska eftersläpningen?
• Hanteras saldo per lagerplats, 3PL och direktleverans, med ledtid per kund och marknad?
• När reserveras saldo, hur länge håller reservationen och tillåts backorder?
• Klarar plattformen bulkanrop och cachning så att listvyer inte belastar affärssystemet?
• Vilket system är master för vilket saldo, och hur stäms de av?
• Vad händer vid avbrott, och vem larmas när synkroniseringen slutar leverera?

Leverantörer visar gärna ett grönt saldo i en demomiljö. Be i stället att få se hur systemet beter sig när saldot tar slut mitt i en order, när ett lager svarar långsamt och när integrationen tappar kontakten. Det är där skillnaden mellan plattformarna sitter.

Kör ni Monitor är de sju frågorna redan besvarade i Litium Core, där Monitor-kopplingen ingår i stället för att byggas per kund. Kör ni något annat är listan ovan den kravställning ni behöver ta med in i upphandlingen.