How to sync ERP and stock data in B2B e-commerce

Syncing ERP and stock data in B2B e-commerce means the webshop shows available stock, meaning physical stock minus open allocations, taken from the business system. Synchronisation is event-driven for list views and real time on the product page, with a final check in the checkout. The business system remains the source of truth for stock, and the webshop shows an interpretation of it per warehouse location, customer and market.

A contract customer logs in at 08:15 and sees the item is in stock. At 08:20 they place an order for 400 units. At 11:00 your sales support calls to explain that the stock actually ran out yesterday afternoon, that the delivery will be split, and that the backorder lands in three weeks. That call costs more than a lost order. It costs the trust in the entire digital channel.

According to Litium's report Nordic Digital Commerce in B2B 2026, 91 per cent of Nordic wholesalers now have digital sales channels. But stock data is the figure most often shown incorrectly, and it is also the one buyers check first. A price can be discussed afterwards. A stock balance that is wrong is caught by the customer immediately, every time.

This guide walks through how stock data is actually synchronised between the business system and the webshop: what a stock balance consists of, which synchronisation methods exist, how multiple warehouses and 3PL are handled, and what you need to demand when evaluating a platform and an integration.

1. A stock balance is four numbers, not one

The first mistake in many integration projects is treating stock as a single figure. The business system holds several different balances for the same item, and deciding which of them to show in the webshop is a business decision, not a technical detail.

Physical stock is what sits on the shelf right now. It is the figure most people mean when they say stock balance, but it is rarely the one that should be shown to the customer.

Allocated stock is units already committed to orders that have not yet been picked or invoiced. If allocations are not deducted, the webshop will sell the same units twice.

Available stock is physical minus allocated, meaning what can actually be promised. This is normally the figure the webshop should work from.

Incoming stock is on order from the supplier with an expected arrival date. For many wholesalers and manufacturers this is the difference between a lost order and an accepted lead time, because a B2B buyer will often rather wait two weeks for a known date than buy somewhere else.

Beyond that you need to decide whether safety stock should be held back from the web channel, for example so that priority contract customers or the service organisation always have cover. The decision is easy to make, but it has to be explicit in the integration, otherwise it becomes an unwritten rule in somebody's head.

2. Real time, event-driven or batch

The next question is how often the stock balance is updated. There are three common methods and they can be combined.

Nightly or hourly batch export means the business system sends a file or an API call containing the full stock list on a schedule. It is simple to build and loads the business system at a predictable time. The drawback is that the balance in the webshop is exactly as old as the time since the last run, which for fast-moving items means it is wrong for most of the day.

Event-driven synchronisation means the business system or the integration platform sends an update whenever something actually changes: a pick, a goods receipt, a cancelled order. Traffic stays low because only changes are sent, and the balance in the webshop normally trails reality by seconds. It assumes the business system can trigger events, or that an integration platform polls frequently enough to simulate it.

Real-time calls mean the webshop asks the business system for the balance at the moment the customer looks at the product. It always gives the correct figure, but it puts load on the business system at every page view and makes the webshop dependent on the business system responding quickly.

In practice a combination works best: event-driven synchronisation as the basis for list views and search, complemented by a real-time call on the product page and a final check in the checkout before the order is confirmed. Ask the supplier directly: which method is used per view, and what is the actual lag measured in seconds?

Apex Stainless Fasteners has 63 per cent of its B2B customers logging in daily to check prices and stock status on their own. That habit rests on the figures being correct. The moment they are not, the customer calls the sales rep instead, and the whole point of self-service is gone.

3. Multiple warehouses, 3PL and stock per customer

Few B2B companies keep everything in one place. There is a central warehouse, one or more regional warehouses, perhaps a 3PL warehouse for certain markets, and a number of items shipped directly from the supplier. The customer should not have to understand that structure, but it has to exist in the data.

What the platform and the integration need to handle:

• Stock per warehouse location, not just an aggregated total for the whole operation
• Rules for which warehouse serves which customer, based on delivery address, market or contract
• Split deliveries when an order has to be picked from several warehouses, and a decision on whether the customer can choose
• Direct delivery from the supplier with a separate lead time and a separate stock source
• Lead time calculated per warehouse and customer, so the customer sees a delivery date and not just a quantity

An aggregated balance showing 500 units where 480 sit in a warehouse that does not deliver to the customer's market is in practice an incorrect balance, even though the sum is right. It is one of the most common reasons orders have to be handled manually after they come in.

BE Group runs several markets in parallel with contract customers on their own terms, and TMHI chose Litium specifically for its globalisation. In both cases internationalisation and stock logic are the same question: which warehouse applies to which customer, in which sales company, with which lead time.

4. Allocations, overselling and backorders

Even with perfectly synchronised data a gap appears. Two customers can look at the same last pallet at the same time, and both see that it exists. The question is what happens when both put it in their cart.

There are three common models. Allocating stock as soon as the item goes into the cart gives the customer the most certainty but locks up stock that may never become an order, and requires a clear expiry time. Allocating at checkout is the most common compromise: stock is checked and allocated the moment the customer confirms. Checking only when the order lands in the business system is the simplest to build, but moves the problem to the sales support team who have to call the customer.

Whichever model you choose, you need answers to:

• How long does an allocation hold before it is released?
• What happens if the balance changes between cart and checkout, should the order be stopped or split?
• Are backorders allowed, and if so on which items and for which customers?
• Is an expected arrival date shown for backordered items, and is it updated when the supplier moves the delivery?
• Can the customer choose between a partial delivery now and a consolidated delivery later?

For a B2B buyer planning production, the answer to that last question is often more important than the stock figure itself. An honest delivery date beats an optimistic balance every time.

5. Performance when stock is shown in list views

Stock data has the same performance problem as customer-specific prices, but with an extra dimension: the balance changes continuously, even when nobody is looking.

A category page with a hundred items can in the worst case trigger a hundred separate calls to the business system, and a customer browsing quickly through the range can generate thousands of calls in a few minutes. If the business system is also being used for production planning and invoicing at the same time, the webshop becomes a load the IT department notices.

Patterns that work:

• Bulk calls that fetch stock for every item in the view in a single call instead of one per item
• Short-lived cache in list views, combined with a fresh call on the product page
• Event-driven invalidation, so the cache is cleared when a balance actually changes and not only on a timer
• Status ranges instead of exact figures in list views, for example more than 100 in stock, which both reduces the need for precision and protects your purchasing data
• A final check in the checkout, which is the only place the figure has to be exact

Litium's B2B e-commerce platform is built to handle stock data per warehouse location with API-based updates. Exactly how caching, bulk calls and ranges are set up in your case is decided together with the implementation partner, based on your range, your traffic volume and how much load the business system can take.

6. Who owns the stock data

Stock data often travels through more systems than you would think. The business system holds the recorded balance, a WMS holds the physical one, a 3PL system holds what sits with a third party, and the webshop displays an interpretation of all of them. If nobody owns the whole, the figures will drift apart.

Decide and document:

• Which system is master for physical stock, and which is master for available stock?
• Where are allocations calculated, in the business system or in the webshop?
• Who sets the rules for safety stock, and where are they stored?
• How often are balances reconciled between the systems, and what happens when they differ?
• Who gets alerted when the synchronisation stops delivering updates?

That last point is the one most often missed. An integration that fails loudly is an operational problem fixed the same day. An integration that fails quietly keeps showing yesterday's stock for a week before anyone notices, and by then you have already confirmed orders you cannot deliver.

Varsego reduced its manual work by 80 per cent by connecting the webshop directly to the business system's data without an intermediate layer. Fewer steps between source and customer means fewer places where data can drift apart, and fewer systems somebody has to remember to reconcile.

One way to avoid the ownership discussion altogether is to not create more sources of truth than you already have. Litium Core is built on that principle for manufacturing companies running Monitor. Monitor remains the source of truth for products, prices, stock, customers and orders, while the portal reads from it and writes orders back into the normal flow of picking, shipping and invoicing. There is no intermediate layer that can drift, because only one system owns the balance.

7. What happens when the integration does not respond

Business systems get upgraded, networks go down and APIs respond slowly. The question is not whether it happens but what the webshop does when it does.

A well-designed integration has a defined behaviour for every outage. Should the webshop show the last known balance, show a general availability status without a figure, or block purchases entirely? Should orders be queued and sent when the business system is back, or should the checkout close? Most B2B companies choose to keep taking orders and queue them, because a closed checkout costs business for certain while a queued order can usually still be delivered.

Ask the supplier three things before you sign. Who owns the integration and tests it when either system is upgraded? What is the defined behaviour during an outage, and can it be configured per product group? How are you alerted when the synchronisation stops?

Litium's ERP integrations with Monitor, Jeeves, Business Central and SAP are built and maintained by Litium or certified partners. The difference from an integration that is merely possible to build is that somebody other than you is responsible for keeping it working after the next upgrade.

For Monitor users it goes one step further. In Litium Core the portal and the Monitor connection are preconfigured and have been run against Monitor before, which means stock synchronisation is not something you specify and build but something you configure. What takes time becomes your product catalogue rather than the integration code. If you run a different business system, or need your own frontend, the full platform with an implementation partner is the route instead.

Summary: seven questions to work through before an integration project

Stock synchronisation looks like a technical detail on a requirements list and turns out in practice to be what decides whether contract customers use the digital channel or call the sales rep as before.

The seven points to work through:

• Which balance should the customer see: physical, available or a range, and how is safety stock handled?
• How is stock synchronised per view: batch, event-driven or real time, and what is the actual lag?
• Is stock handled per warehouse location, 3PL and direct delivery, with lead time per customer and market?
• When is stock allocated, how long does the allocation hold and are backorders allowed?
• Can the platform handle bulk calls and caching so that list views do not load the business system?
• Which system is master for which balance, and how are they reconciled?
• What happens during an outage, and who is alerted when synchronisation stops delivering?

Suppliers are happy to show a green stock figure in a demo environment. Ask instead to see how the system behaves when stock runs out mid-order, when a warehouse responds slowly and when the integration loses contact. That is where the difference between platforms sits.

If you run Monitor, those seven questions are already answered in Litium Core, where the Monitor connection is included rather than built per customer. If you run something else, the list above is the requirement specification to take into the procurement.