A buyer orders 500 units of a technical component because the shop says "in stock". Two hours later the cancellation arrives by email: the warehouse had been empty for a while, the display was simply out of date. The buyer places the order with a competitor. Customer service spends the rest of the day apologising.
This scenario is not an isolated case. A recent 2026 analysis shows that seven out of ten online shops examined do not run automated ERP synchronisation. The consequences: high cancellation rates, an overloaded customer service team and a creeping loss of trust among existing customers. At the same time, B2B buyers today expect binding availability and price information in real time, not on the next working day.
ERP integration in the B2B shop is therefore no longer a purely technical task. It is a strategic prerequisite for a future-proof B2B platform. The following five steps show how manufacturers and wholesalers can implement this integration cleanly.
Step 1: Clarify data ownership – which system leads which data?
Before a single interface is configured, one question needs an answer: which system is the leading system for which data object?
That sounds obvious, but in practice it rarely is. In many companies, sales, purchasing and marketing maintain product data in parallel systems. The ERP knows the stock levels, the PIM system (Product Information Management, the central database for product content) holds the texts and images, and over the years the shop has built up its own fields that exist nowhere else.
The result: during the first data sync the ERP accidentally overwrites descriptions, or the shop reports stock levels the ERP corrected long ago.
A recommended ground rule for data ownership:
Stock levels and prices: the ERP leads, always.
Product texts, images, technical attributes: the PIM leads.
Customer-specific terms and discount tiers: ERP or CRM, depending on the existing system landscape.
Order status and delivery notes: ERP, without exception.
This allocation must be documented in writing and accepted by everyone involved before technical implementation begins.
Step 2: Clean up master data and product structure
An interface transfers data. It does not improve it. Anyone who feeds poor data into the ERP will get poor data in the shop. This simple truth is regularly underestimated before projects start.
Typical problems in grown ERP systems:
Products without a unique identifier, for example duplicate item numbers after system migrations
Missing or contradictory units (piece, pack, pallet)
Inactive products that still appear in the data export
Missing classifications that are needed for shop categories
Before the interface between ERP and online shop goes live, a structured data cleansing phase is worthwhile. That means: checking product master data, removing duplicates, standardising unit logic. This step is unspectacular, but it saves considerable effort during later troubleshooting.
A practical approach: first clean up a single product category completely and run it through the interface as a pilot group. Only once this category synchronises without errors should the rollout be extended to the full catalogue.
Step 3: Define the interface and the synchronisation rhythm
Not every data object needs real-time synchronisation. This distinction matters because it directly affects system load and infrastructure costs.
Real-time stock data is essential for B2B shops with frequent orders and limited warehouse capacity. Here a delay of 30 minutes can already lead to overselling. Modern middleware solutions (software that acts as an intermediary between ERP and shop) now allow push notifications directly from the ERP as soon as a stock level changes.
Price data can in most cases be synchronised in batches, meaning at fixed intervals such as hourly or overnight. The exception: if customer-specific prices are calculated directly during the ordering process, a real-time query via an API (programming interface) makes sense. Why this is no minor matter in B2B is covered in the article on real-time prices in the B2B shop.
Product master data such as texts, images and technical attributes rarely changes and is well suited to daily batch synchronisation.
For the technical implementation of an ERP-Shopware integration or comparable shop systems, middleware that centrally manages transformation rules – the translation of data formats between systems – is recommended. This avoids direct point-to-point connections, which regularly break during system updates. Which criteria decide the success of a platform choice is described in the article on choosing a B2B shop system.
Step 4: Map customer-specific prices and stock correctly
In B2B, the list price is rarely the actual price. Discount tiers, framework agreements, customer-specific terms and volume-based pricing are the norm. This point is one of the most common stumbling blocks in B2B e-commerce automation.
Technically there are two fundamental approaches:
Price calculation in the ERP: the shop sends a request with customer number, item number and quantity to the ERP. The ERP calculates the price and returns it. Advantage: the pricing logic stays exclusively in the ERP, inconsistencies are ruled out. Disadvantage: every price display in the shop generates an ERP request, which increases system load.
Price transfer into the shop: the ERP transfers price tables for each customer into the shop. Advantage: faster display, less ERP load. Disadvantage: price changes must be synchronised promptly, otherwise discrepancies appear.
Which approach fits better depends on the complexity of the pricing structure and the technical capacity of both systems. With more than 500 active customers on individual terms, calculation on the ERP side is usually the better choice. For designing volume-based terms, the article on tiered pricing in the B2B shop provides concrete rules.
The same principle applies to stock data across multiple warehouses: if a company operates five locations, the shop must correctly show either the total stock or the location-specific stock. Clear rules need to be defined in advance.
Step 5: Establish error handling and monitoring
Interfaces do not always work. ERP updates, network interruptions, faulty records: the question is not whether a synchronisation will fail, but when. Anyone unprepared for this notices the error only when customers complain.
A solid monitoring concept includes:
Automatic error alerts: the system reports synchronisation errors immediately by email or in an internal ticketing system.
Error logs with context: not just "an error occurred", but which record, which system, which timestamp.
Fallback behaviour: what does the shop display when the ERP is unreachable? "Availability on request" is better than a wrong number.
Regular consistency checks: a weekly automated comparison between ERP stock and shop stock uncovers creeping discrepancies before they become a problem.
Beyond that, a responsible person in the company should be named who decides in case of escalation. Technical monitoring alone is not enough if nobody reads the alerts. How recurring processes can be automated on a rule basis is described in the article on the Rule Builder in Shopware.
Common mistakes that delay projects
Three patterns appear particularly often in ERP-shop projects:
Too much at once: trying to connect all products, all customers and all processes simultaneously leads to projects that run for months without a go-live. Better: start with a pilot area, gather experience, then expand.
An interface without data maintenance: building a technically clean interface on top of poor data simply scales the problem. Master data first.
No ownership for the interface: if it is unclear after go-live who is responsible when problems arise – IT, sales or the service provider – response times emerge that customers will not tolerate.
Which processes are the first to automate after a clean integration is shown in the article on manual order entry in B2B.
Conclusion: the technical foundation for a future-proof B2B platform
A functioning ERP integration is not optional, it is the foundation. Anyone who wants to show B2B buyers binding stock levels and correct prices in real time cannot avoid a clean data strategy. The five steps described follow a proven sequence: first clarity about data ownership, then master data, then technology, then pricing logic, then operations.
Companies that take this path in a structured way report significantly reduced cancellation rates and a noticeably relieved customer service team. Not because technology works miracles, but because data finally arrives where it is needed: in the right format, at the right time, in the right system.
