For many online retailers, JTL-Wawi is the control center of the business: articles, prices, stock levels, customers and orders all live in one place. As soon as an online shop is added, a second data world appears -- and with it the question of how both systems work together cleanly. According to the vendor, more than 50,000 merchants rely on JTL-Wawi as the core of their e-commerce (JTL-Software GmbH). The market behind it is substantial: German e-commerce reached a goods turnover of 83.1 billion euros in 2025, up 3.2 percent on the previous year (bevh). Marketplaces now account for 56 percent of that (bevh) -- a clear sign that few retailers serve only a single channel. This is exactly where the trouble begins: coupling inventory system and shop without a plan produces duplicate articles, diverging stock and duplicates in variants and customer records. This article shows which data objects are synchronized in which direction, how to define the leading system, and how to resolve conflicts cleanly -- as the basis for an orderly connection of JTL-Wawi to the online shop.
Why the Shop Sync Fails with JTL-Wawi
Most problems when coupling JTL-Wawi and a shop arise not from missing technology but from missing planning. The JTL-Connector sets up the connection in a manageable time, yet the decisive questions -- which system leads, which field wins in a contradiction, how are articles and customers matched unambiguously -- are often only clarified once the first errors appear. By then, duplicate records already sit in both systems, and the effort to clean them up clearly exceeds that of a proper initial plan.
Four patterns recur again and again. First, duplicate article creation: a product exists in the shop under a different article number than in the Wawi, the sync does not recognize it as the same item and creates it a second time. Second, stock discrepancies, when shop and Wawi change the same stock level independently -- for example through an order in the shop and a simultaneous correction in the Wawi. Third, duplicates in variants, because color and size combinations are structured differently. And fourth, duplicate customer records, when a shop customer cannot be matched unambiguously to an existing Wawi customer.
Data quality is not optional -- it is a revenue factor
The effort is real: one in five consumers already plans a return from the outset (ECC Cologne). For a returns or status process to run smoothly, order, payment status and shipping status must show the same state in both systems. That only works if it is settled in advance which system leads which value -- and both do not believe at the same time that they are right.
Which Data Objects Flow in Which Direction
A viable connection begins with a simple inventory: which data objects exist, and in which direction should they flow? The JTL-Connector enables the bidirectional exchange of articles, categories and customer data between JTL-Wawi and a third-party shop (JTL-Software GmbH product documentation). But bidirectional does not mean that every field travels in both directions. Each object needs a clearly defined direction, otherwise the systems overwrite each other.
In practice, six core data flows can be distinguished. Master data such as articles, variants and prices are maintained in the Wawi and pushed to the shop. Stock levels also move from the Wawi into the shop so the availability display is correct. In the opposite direction run the orders: they originate in the shop and are imported into the Wawi, where they become sales orders. Customer data arrives with the order from the shop. Payment and shipping status, finally, move in both directions depending on the process -- payment is often captured in the shop, the shipping status arises in the Wawi and returns to the shop.
| Data object | Direction | Leading system |
|---|---|---|
| Articles and variants | Wawi to the shop | JTL-Wawi |
| Prices | Wawi to the shop | JTL-Wawi |
| Stock levels | Wawi to the shop | JTL-Wawi |
| Orders | Shop to the Wawi | Online shop |
| Customer data | Shop to the Wawi | Online shop (creation) |
| Payment and shipping status | bidirectional | per status field |
This split is not a law of nature but a design decision. It can be refined per field: a retailer may decide, for instance, that product descriptions and images are maintained editorially in the shop and not overwritten by the Wawi, while price and stock come strictly from the Wawi. What matters is that these rules are set deliberately once and documented -- ideally as part of a clean data mapping between ERP and shop that assigns each field a source and a direction.
Defining the Leading System
The most important decision of a JTL connection is defining the leading system, often called the master. It answers the question: when two systems know the same record and both could change it, whose version is binding? For the standard case, the vendor documentation gives a clear recommendation. From the initial data transfer onward, JTL-Wawi is the leading system; changes to the data should be made exclusively in the Wawi and no longer in the shop's admin area (JTL-Software GmbH product documentation).
From the initial data transfer onward, JTL-Wawi is the leading system. Changes to the data are to be made exclusively in the Wawi -- and no longer in the admin area of the online shop.
This rule sounds strict but is the actual prerequisite for conflict-free operation. If an article price is accidentally changed in the shop backend even though the Wawi leads, the next sync overwrites this change again with the Wawi value. To the shop team this looks like an error -- in fact the connection works correctly, the maintenance was simply done in the wrong place. That is why technical setup also comes with an organizational one: who maintains what, in which system?
Master does not mean everything comes from one system
Avoiding Duplicates and Stock Discrepancies
Duplicates mostly arise at one point: matching. So that an article or customer is not created a second time, the sync needs a unique, stable key. For articles this is usually the article number or SKU, which must be identical in both systems. For customers, the JTL-Connector works via the billing address: JTL-Wawi searches for the customer by the billing address and can only update customer data previously imported from the online shop (JTL-Software GmbH product documentation). If the address differs slightly, a new record arises instead of an update.
With stock, the pitfall lies in the initial sync. At the start, the connector transfers the stock levels stored in the shop and books them into the Wawi as actual stock (JTL-Software GmbH product documentation). If the shop stock levels are not maintained at that point, a wrong starting value moves into the Wawi -- and from then on the Wawi leads, but on a wrong basis. That is why it should be settled before the first productive sync which system supplies the correct starting stock.
Stable keys
Article number, SKU and customer key must be identical and immutable in both systems. Without a stable key, every sync potentially creates a new record.
Structure variants consistently
Parent-child articles and attribute sets must be modeled the same in both systems before coupling, so color and size combinations do not drift apart as separate products.
Set the starting stock once
Before the initial sync, clarify which system supplies the correct actual stock. A clean starting value prevents a discrepancy from burning into the Wawi from the start.
- Unify keys: align article numbers, SKUs and variant codes in both systems before coupling.
- Test run in a sandbox: run the initial sync in a test environment first and check the results against expectations.
- Fix the starting stock: determine the correct starting stock before the Wawi takes over as the leading system.
- Duplicate report: after the first productive sync, check article and customer lists for double entries and clean them up.
- Define the place of maintenance: anchor organizationally that master data is only maintained in the Wawi.
Resolving Conflicts Cleanly
Even with a clear master rule, there are moments when two systems change the same record in quick succession. For these cases a connection needs a defined conflict strategy. Three approaches have proven themselves and can be combined per data object. With the master-wins strategy, the leading system simply wins -- suitable for prices and stock, which come from the Wawi anyway. With timestamp-based resolution, the most recent change wins, sensible for status fields that can advance in both systems. And with field-level resolution, it is decided per field which source leads -- the most precise but also most involved variant.
| Conflict strategy | Principle | Fits |
|---|---|---|
| Master wins | The leading system overwrites | Prices, stock, master data |
| Timestamp (last write wins) | The most recent change wins | Payment and shipping status |
| Field-level rule | One defined source per field | Objects maintained on both sides |
What matters is that the strategy is not left to chance. A connection that resolves conflicts silently in the background, without anyone knowing the rule, produces exactly the hard-to-find discrepancies reported weeks later as a supposed software bug. It is more sensible to have conflicts logged and reviewed regularly. How such flows differ between point-to-point coupling and a central middleware is covered in the comparison of REST API and middleware.
Conflict rules belong in the concept, not in operations
Real Time or Batch: Planning the Sync Cadence
Besides direction and master, cadence is the third planning dimension. Not every object has to flow in real time. Stock benefits from the shortest possible latency, so the shop does not sell goods already gone through another channel -- especially in multichannel operation, where marketplaces account for 56 percent of e-commerce turnover (bevh). Article descriptions or categories, by contrast, can be transferred in a nightly batch without issue. A good connection separates these cadences: time-critical objects often, uncritical ones less so.
Short latency requires relief for the systems
The Path to a Planned Connection
A robust JTL-Wawi shop connection emerges in a traceable order. At the start comes not the technology but the inventory of data objects, their direction and their leading system. Only then follow the technical setup, the test run and finally monitored production operation. This approach pays off, because the market keeps growing: for 2026, the associations expect nominal growth of e-commerce goods turnover of 3.8 percent (bevh), and the sector scenario for online retail lies in a corridor of 2.7 to 5.7 percent (IFH Cologne). Anyone who sets up their connection cleanly can follow this growth without rising maintenance effort.
1. Capture data objects
Record all objects, their intended direction and their leading system. Key fields and variant structure are unified in the process.
2. Define rules and conflicts
Set master, conflict strategy and cadence per object and document them before the connector is configured.
3. Initial sync and test
Fix the starting stock, run the initial sync in a test environment and check for duplicates and discrepancies.
4. Monitor and operate
Watch sync runs, error rates and conflict logs continuously so discrepancies become visible early.
Anyone who keeps to this order turns a grown coupling into a planned integration. For adjacent topics, it is worth looking at stock synchronization across multiple warehouses, at securing the interface with OAuth 2.0 and at the coming data obligations around the digital product passport under the ESPR. If the standard connector is not enough -- for marketplaces, DATEV or individual field rules, say -- we connect the systems through a central middleware and matching API development. Connecting further channels is covered by our marketplace integration, the accounting side by DATEV integration, and the overall frame is formed by our systems integration. How an inventory system can generally be coupled to a shop is also shown on our page on inventory-to-shop integration.
Sources and studies