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.
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.
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.
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:
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.
Ä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å:
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.
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:
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.
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:
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.
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.
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:
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.