If you run an online shop with SAP Business One in the back office, you know the friction: articles are maintained in the ERP and re-entered in the shop anyway, prices diverge, stock is only correct until the next goods receipt, and every online order is copied into the ERP by hand. A clean SAP Business One integration with Shopware removes this duplicate work by letting articles, prices, stock, orders and documents flow automatically between both systems. With more than 83,000 customers (SAP) and around 1.2 million users (SAP) in over 170 countries (SAP), SAP Business One is one of the most widely used midmarket ERPs in the world - and Shopware a common platform for making that ERP sell online. This practical guide shows which interfaces the integration runs on, which objects are synchronised in which direction and what matters in operation.
Why SAP Business One and Shopware belong together
SAP Business One targets small and mid-sized companies. Roughly 61% of installations are at firms with fewer than 100 employees (according to industry analyses), and around 3,000 new customers are added each year (SAP). These are exactly the companies increasingly running an online shop, facing the question of how the ERP as the leading system and the shop as a sales channel work together. The ERP holds the truth about articles, prices, customers and stock, as well as the commercial documents. The shop is where that becomes revenue. Without integration, staff maintain both sides separately, which costs time and creates discrepancies.
That the effort pays off is shown by market development. In B2B, the buying journey follows the rule of thirds: at any stage about one-third of customers prefer in-person contact, one-third remote communication and one-third digital self-service (McKinsey, B2B Pulse). Buyers now use an average of ten channels across a purchase decision (McKinsey), and 34% of total B2B revenue already comes from self-service e-commerce and remote interactions (McKinsey). Germany's B2B internet trade via shops and marketplaces most recently reached 509 billion euros with a 7% increase (IFH Cologne); through these channels, wholesalers and manufacturers realise 12.1% of their total revenue (IFH Cologne), and a further 6.3% increase is expected for the following year (IFH Cologne). Measured against Germany's total B2B online trade of roughly 1.67 trillion euros (Statista/IFH Cologne), there is still considerable headroom. At the same time, 73% of B2B buyers would be willing to spend more than 50,000 US dollars per order online (McKinsey). A shop cleanly connected to SAP Business One serves this digital third without excluding the other two - and without anyone re-keying orders.
39% of B2B buyers now spend more than 500,000 US dollars per order via self-service e-commerce or remote interaction, up from 28% two years earlier (McKinsey). And 60% of self-identified market leaders report double-digit revenue growth for 2025, compared with just 21% of laggards (McKinsey). The common denominator among the winners is end-to-end, cross-channel processes - and those start with clean master data from the ERP.
The most expensive part of a missing integration is rarely visible, because it is spread across everyday work: a price update in the ERP that reaches the shop late; a sold-out article that is still orderable online; an online order recorded manually as an ERP order two days later. Anyone who has understood the fundamentals of ERP integration between Shopware and SAP knows that the real work is not the data exchange itself, but the question of which system leads for which field. This matters even more in B2B e-commerce than in the consumer business, because customer-specific prices and terms are in play.
The two paths into SAP Business One: Service Layer and DI-API
SAP Business One offers two technical entry points through which an integration can read and write data. Both have their place, and in practice they are often combined. The choice determines not only the effort but also operation, scaling and the question of which operating system the integration component runs on.
Service Layer (REST/OData)
The modern, REST-based interface. It exposes SAP Business One business objects via the OData protocol (version 4) as HTTP endpoints, works statelessly with JSON and can run load-balanced. Usually the first choice for new integrations because it fits cleanly into a service-oriented architecture and needs no Windows components.
DI-API (COM)
The older, COM-based path. It runs only on Windows, is tightly coupled to the application logic and covers some special cases the Service Layer does not fully map depending on the version. Existing integrations often use it; for new projects it mostly matters only where a function is not reachable via the Service Layer.
For the DACH midmarket it is also relevant that SAP Business One exists in two database variants - the classic SQL variant and the variant on SAP HANA. The Service Layer is available in both but differs in detail at individual endpoints and in query syntax. A robust integration accounts for these differences from the start rather than retrofitting them later as a special case.
Which objects get synchronised
An SAP B1 integration with Shopware revolves around five core objects that map the flow of goods from ERP to shop and the documents from shop back to ERP. What matters is not only that an object is synchronised, but in which direction, which system leads and how current the data must be.
| Object | Direction | Leading system | Typical frequency |
|---|---|---|---|
| Articles / master data | SAP to Shop | SAP Business One | On change / hourly |
| Prices and price lists | SAP to Shop | SAP Business One | On change / daily |
| Stock | SAP to Shop | SAP Business One | Near real time |
| Customers and groups | Both directions | depends on field | On change |
| Orders | Shop to SAP | Shopware (origin) | On order |
| Invoices and documents | SAP to Shop | SAP Business One | After document creation |
Article synchronisation is the core. From the ERP come article number, name, tax rate, weight, units of measure and product groups; in the shop these become products with media, SEO text and category assignment. As soon as an article has variants - size, colour, pack size - the mapping decides whether the shop gets a clean variant product or a sprawl of individual items. How to solve this without duplicate content on product variants is a discipline of its own that belongs in the mapping concept early.
Stock is the field with the highest currency requirement. Inventory synchronised only once a day leads to oversells and cancellations. Stock is therefore ideally transferred event-driven, the moment a posting changes in the ERP. On this basis, the product page can also show a reliable delivery date as a conversion lever instead of just in stock or unavailable. Prices in B2B are rarely a single value: SAP Business One manages price lists, customer and quantity discounts and special prices that must apply in the shop depending on customer group or logged-in customer. The integration therefore transfers not the price but the pricing logic - including whether net or gross is used.
Direction and frequency: push, pull and events
Not every object needs the same currency, and not every transfer should run in both directions. Three patterns have proven effective: scheduled batch runs for bulk data such as the nightly catalogue sync, event-driven transfer for time-critical fields such as stock, and a direct pull for rarely used detail data loaded only on demand.
Shopware delivers events such as a new order via webhooks, which the middleware can react to without constantly polling the shop. How to cleanly build such an event-driven shop integration with webhooks determines load and reliability. The clear separation matters: a new order originates in the shop and is written to the ERP; prices and stock originate in the ERP and are written to the shop. If a field accidentally runs in both directions, the systems overwrite each other - one of the most common causes of seemingly inexplicable data discrepancies.
Not everything has to run in real time. An article text may update hourly, a stock level should update within seconds. The rule of thumb: the more directly a field triggers a purchase decision or a cancellation, the higher the required currency. Everything else belongs in scheduled runs that do not burden the ERP unnecessarily.
Middleware or direct integration?
Technically, Shopware can connect directly to the Service Layer. In simple scenarios with few objects and low frequency, that can be enough. But as soon as multiple objects, error handling, retries and logging come into play, a middleware effectively emerges - the only question is whether it is planned or a grown script.
| Aspect | Direct integration | Middleware |
|---|---|---|
| Getting started | Faster, fewer components | Higher initial effort |
| Error handling | Embedded in the shop plugin | Central with queue and retry |
| Multiple systems | Hard to extend | ERP, PIM, shipping attachable |
| Traceability | Distributed | Central log per transaction |
| Load spikes | Directly on the ERP | Decoupled via queue |
| Maintenance | Check on every update | Clearly separated responsibility |
Whether a dedicated integration layer makes sense depends on the number of objects, the frequency and the number of systems involved; we go deeper into the trade-off in the article on middleware in e-commerce integration. For a pure two-system link from SAP Business One to Shopware with no further channels, a lean direct connection can suffice. But anyone who wants to add marketplaces, shipping providers or a PIM usually runs more calmly with a middleware, because the integration logic then lives in one place instead of being duplicated in every endpoint.
Master data mapping and the leading-system principle
The heart of every integration is the mapping - the translation between the data world of SAP Business One and that of Shopware. The article key (ItemCode in the ERP, product number in the shop) must map unambiguously onto each other so an article is recognised over years. The same applies to tax classes, price lists, customer groups, payment terms and the number ranges of documents. Each of these fields needs a deliberate decision about which system leads it.
The most important rule of any integration: for each data field there is exactly one system that holds the truth. If a discount can be maintained both in the shop and in SAP Business One, discrepancies arise that in the worst case lead to a wrong price in the cart. Where responsibilities overlap, experience shows that exactly the errors emerge which are hardest to find in operation.
The same mapping discipline applies to every ERP. Anyone connecting Microsoft Dynamics 365 Business Central to Shopware in parallel faces the same questions with different terminology - and a company running several inventory systems should design the mapping so that the rules per source stay cleanly separated. A well-thought-out mapping is therefore less a technical than a commercial task: it reflects how the company actually forms prices, segments customers and manages documents.
Error handling, idempotency and monitoring
An integration is a production system with its own failure scenarios: the ERP is unreachable during a maintenance window, an order fails on write, a network error interrupts a batch. To keep this from becoming data loss, retries with increasing backoff, a queue for failed transactions (dead-letter) and idempotency are standard - the same message may arrive multiple times without creating a duplicate order.
Visibility matters just as much. Without a log per transaction, without metrics for throughput and error rate and without alerting on backlog, an integration remains a black box that no one recognises as the cause in time. A good integration shows at any moment which order was in which state when, and where a transaction is stuck.
A lost catalogue entry can be re-fetched on the next run - a lost order cannot. Order and document data therefore belong in a well-thought-out backup concept that also includes the integration layer. What to consider is covered in our article on backup and disaster recovery for online shops. A blanket promise of absolute failsafety would be dishonest; what is achievable is a high level of protection with defined recovery times.
Common pitfalls in SAP B1 integration
Many problems in an SAP B1 integration are recurring and can be avoided from the outset with a clean concept. These points come up especially often in practice:
- Net and gross confused: SAP Business One and the shop must use the same basis. A mix of a net price list and a gross display creates rounding errors that only surface at checkout.
- Number ranges not aligned: If order and document numbers collide or are assigned twice between shop and ERP, matching them later becomes tedious. Assignment must be clearly governed.
- Variants mapped poorly: A variant article in the ERP quickly becomes many individual products in the shop if the mapping does not know the structure - with consequences for navigation and SEO.
- Payment methods and terms not mapped: ERP payment terms and shop payment methods are two worlds. Without mapping, an online payment lands in the ERP without a matching document assignment.
- ERP burdened by too-frequent queries: A stock query every second for tens of thousands of articles puts the ERP under load. Events and caching relieve it far more than shorter intervals.
- No test system: Trying out mapping and error handling directly on the production system risks wrong stock and documents. A separate test company belongs in the project.
- Partial deliveries and document flow ignored: One order often becomes several deliveries and invoices in the ERP. The shop should reflect this document flow so the customer sees the real status in their account.
How we approach the integration
At the start there is no line of code but an inventory: which objects must flow, in which direction, at what frequency, and which system leads which field? From this map comes the mapping concept, then the choice between Service Layer and DI-API and the decision for or against a middleware. Only then follows the custom development, accompanied by a test system on which articles, prices, stock and a complete order and document run are checked before the first real product goes live.
Whether a lean direct connection or an extensible integration layer is the right choice depends on your system landscape - and on the channels you plan to add over time. If you want to explore how your shop can be connected to SAP Business One and which further integrations make sense alongside it, we are happy to discuss your project - from process discovery through mapping to stable operation. Contact us for a first assessment of your existing systems.
This article draws on data from: SAP (SAP Business One figures, as of end of 2025 - more than 83,000 customers, around 1.2 million users, over 170 countries, about 3,000 new customers per year), McKinsey (B2B Pulse Survey - rule of thirds, an average of ten channels, 34% of B2B revenue via self-service and remote, 39% versus 28% for orders over 500,000 US dollars, 60% of market leaders with double-digit growth versus 21% of laggards) IFH Cologne (B2B market monitor - 509 billion euros of B2B internet trade, plus 7%, 12.1% revenue share, forecast plus 6.3%) and Statista/IFH Cologne (roughly 1.67 trillion euros of B2B online trade in Germany). The figure of around 61% of installations at firms with fewer than 100 employees is based on install-base analyses (according to industry analyses). The figures cited refer to different survey periods and may vary by point in time and market segment.
For new integrations the Service Layer is usually the first choice because it is REST-based, stateless and can run without Windows components, fitting well into a service-oriented architecture. The DI-API remains useful when a specific function is not reachable via the Service Layer depending on the version, or when an existing integration already builds on it. In practice, the two paths are occasionally combined.
Stock and prices originate in the ERP and are written to the shop - SAP Business One is the leading system here. Orders, by contrast, originate in the shop and are transferred to the ERP. This separation matters: if a field accidentally runs in both directions, the systems overwrite each other, causing hard-to-find discrepancies.
Not necessarily. For a simple two-system link with few objects and low frequency, a lean direct connection can suffice. A middleware pays off as soon as multiple objects, robust error handling, retries, logging or further channels such as marketplaces, shipping or a PIM come into play. Then the integration logic lives in one place instead of being distributed across every endpoint.
SAP Business One manages price lists, customer and quantity discounts and special prices. The integration transfers not a single price but the pricing logic: price lists are mapped to customer groups and logged-in customers in the shop, with tiers and special prices assigned accordingly. It is important that net or gross handling matches in both systems so that no rounding differences arise at checkout.
That depends on the chosen pattern. With event-driven transfer reacting to a posting in the ERP, stock is typically current within seconds to a few minutes. With purely scheduled batch runs, currency equals the interval. Because stale stock leads to oversells and cancellations, this field warrants the highest sensible currency, while non-critical data belongs in less frequent runs.
Yes. The Service Layer is available in both database variants but differs in detail at individual endpoints and in query syntax. A robust integration accounts for these differences from the start. We clarify which variant you run at the start of the project so that the mapping and queries fit.