Case study · JTL-Wawi
Connecting Kaufland to JTL-Wawi
An additional sales channel without a second backend and without maintaining products twice: products, prices and stock flow automatically from the ERP system to Kaufland, and orders and returns come back into your usual order process.
- System
- JTL-Wawi
- Industry
- Food & delicatessen retail
The starting point
What wasn't working
An additional marketplace sounds like additional revenue. In practice, for most businesses it first means additional work: another backend where someone creates products, maintains prices and collects orders. After a few weeks nobody knows for sure which price applies where.
In my experience, four things make the difference between a sales channel and a construction site:
No double maintenance
If products have to be maintained separately for the marketplace, the range drifts apart within a few months. Descriptions, prices and images diverge, and nobody knows which version is right.
No overselling
As soon as stock is sold across several channels, the speed of the sync decides how often you sell something that's long gone. On marketplaces that doesn't just cost cancellations, it costs the performance metrics your visibility depends on.
Required fields the master data doesn't provide
Kaufland requires its own categories and attributes, plus legal information such as the GPSR obligations. For food, the EU food information regulation (LMIV in German) comes on top: ingredients list, allergens, nutritional values and origin, precise for each product, not approximate. In an ERP system that has grown over years, this information is rarely where the marketplace expects it.
Product codes in several formats
Kaufland only accepts 13-digit EANs in its feed. Products with a different format don't get listed, and what isn't listed doesn't receive price and stock updates either. In this product range, however, the codes came in very different states: 12-digit UPC codes from the US market, 8-digit EANs from small packages, case codes for whole outer cartons and products with no code at all. Each of these cases needs a different, standards-compliant treatment, and one of them can't be solved at a desk at all.
Orders and returns in the usual process
If marketplace orders land somewhere other than everything else, you end up with two processes in the warehouse, two routes for returns and two versions of the truth in accounting. That's exactly what a new channel shouldn't cause.
The solution
How it works
Kaufland isn't run as a separate system but managed as a sales channel inside JTL-Wawi. The ERP system remains the only place where data is maintained. Technically this runs through JTL-SCX, JTL's marketplace interface: JTL-Wawi always talks to SCX in the same way, and SCX translates that into whatever the marketplace needs.
That's the real reason the effort pays off: the process is identical for every channel except Amazon and eBay. What you build once for Kaufland works just the same for OTTO, Temu or Metro. The only differences are the registration with the marketplace and the mapping of the marketplace's own fields.
Two stumbling blocks that had nothing to do with the interface
The first was the food information. The data existed in the ERP system, meticulously maintained, which was the bigger part of the work and already done. Getting it completely into the right marketplace fields still couldn't be fully automated: part of it had to be mapped and reworked by hand until ingredients, allergens, nutritional values and origin appeared on the marketplace where they belong. If you sell food, plan for this effort from the start instead of discovering it shortly before going live.
The second was the EAN format, and it was a tricky one because it didn't have a single cause. The first step was therefore not correcting but sorting: exporting the product master data and classifying every code by its defect. Only then did it become clear that the one symptom, "doesn't get listed", hid several different problems.
Some of them could be solved cleanly at a desk. Under the GS1 standard, a 12-digit UPC code becomes an EAN-13 by adding a leading zero, and the check digit stays valid. 14-digit codes with a meaningless leading zero are shortened accordingly. Every correction was double-checked: correct check digit, no EAN assigned twice.
The uncomfortable part couldn't be calculated away. For products with no code at all you can't invent an EAN; Kaufland explicitly requires an officially assigned one, which has to be requested from the manufacturer or supplier. 8-digit EANs, as assigned to small packages, look solvable at first glance but weren't here: representing them as a 13-digit code with five leading zeros is GS1-compliant by the book, but Kaufland still rejected it as invalid in the feed. That puts these products in the group that needs a real EAN-13 from the supplier. And case codes for outer cartons don't work as a sales unit: if you want to sell a case, you need its own EAN and a second product in JTL, set up as a bill of materials with stock derivation, so the same stock isn't sold twice. These cases belong on the client's desk with a clear recommendation, not quietly skipped.
Throughout all of this, the constraint was that the warehouse also depends on these codes: labels, scanners, goods receipt. A change during live operation must not break anything there. Otherwise, issues like these only surface when the marketplace rejects the first products, and by then you're in the middle of the project.
The rest is craftsmanship
So the work isn't in creating the channel, which takes half an hour, but in the mappings behind it. Categories are linked once so new products are sorted into the right place automatically. Marketplace fields are filled dynamically from the product master data instead of being maintained by hand. Where data is missing or inconsistent, it's cleaned up in JTL-Wawi rather than patched on the marketplace. After that, the JTL-Worker takes over day-to-day operation: stock and prices go out automatically, orders come in as regular orders, and after shipping the tracking number goes back to the marketplace automatically.
Set up the channel
Seller account and API access with the marketplace, license in the JTL customer center, sales channel created in JTL-Wawi. Plus the basic settings nobody touches again later: returns warehouse, stock sync, price group.
one-time
Map categories and fields
Your JTL-Wawi categories are linked to the marketplace categories, and the marketplace's required fields are filled dynamically from the product master data. New products then land in the right place on their own.
the actual effort
Stock and prices automatically
The JTL-Worker transfers changes continuously. If the physical store sells the last item, stock drops on the marketplace too, without anyone having to think about it.
runs in the background
Orders and returns
Marketplace orders come into JTL-Wawi as regular orders and go through picking and shipping like all others. Tracking and shipping status go back automatically, returns go to the designated warehouse.
one process for all channels
The result
What it changes day to day
- One place to maintain data instead of two: products, prices and descriptions come exclusively from the ERP system
- Stock stays in sync automatically across all connected channels, without manual reconciliation
- New products land in the right marketplace category on their own through the category mapping
- Required fields are filled from the master data instead of being typed in for each channel
- The food information required under EU rules is complete on the marketplace, including allergens, nutritional values and origin
- Product codes are systematically classified: cases that could be fixed right away were brought to EAN-13 cleanly, the rest documented with a clear action and owner instead of piling up in the feed
- Marketplace orders go through the same warehouse and shipping process as every other order
- The setup carries forward: a second or third channel is then mostly configuration, not a new construction site
For your business
What you get
I can set this solution up in your business too: adapted to your processes and documented so your team can work with it right away.
Set up at a fixed price, quote after a free initial call. The scope depends on how many products should go on the channel and how complete your master data is.
- Upfront check: does your range fit the marketplace, which data is missing for the required fields, what needs cleaning up in JTL-Wawi first
- Product code check: where is there a 12-digit GTIN-12 instead of an EAN-13, and what does a change mean for labels and warehouse processes
- Setting up the sales channel including license, access and basic settings
- Category mapping and dynamic filling of the marketplace fields from your product master data
- A controlled first sync with a small part of the range before the whole range goes live
- Onboarding for your team: how new products get onto the channel and how to tell when something is stuck
- On request, connecting further channels on the same setup
FAQ
Quick answers
Does this only apply to Kaufland?
No. All sales channels except Amazon and eBay are connected the same way, for example OTTO Market, Temu, Metro, ManoMano or MediaMarktSaturn. What differs is the registration with the marketplace and each marketplace's own required fields. Amazon and eBay still run through their own connections in JTL-eazyAuction.
Can I connect Idealo the same way?
No, Idealo is a different case. Since direct checkout was discontinued on 31 December 2022, Idealo has been a pure price comparison site: purchases happen in your shop, not on the platform. Accordingly there's no SCX channel for it, but a data feed via an export format or Idealo's real-time API.
What changed with the takeover of the ninepoint interfaces?
JTL took over the SCX interfaces and the ninepoint team, announced in February 2026 and effective 1 April 2026. For you that mainly means no separate subscription with a third-party provider anymore, existing contracts were transferred, and operation and further development now sit with JTL. Nothing changes in the setup itself.
What additionally applies to food?
On top of the general required fields and the GPSR information comes the EU food information regulation (LMIV): ingredients list, allergens, nutritional values and origin, per product. If this data is maintained in the ERP system, the bigger part is done. The rest is mapping it cleanly to the marketplace fields, and in my experience some manual work remains. Plan for it rather than hope.
Kaufland requires EAN-13, but my products have 12-digit codes. Is that a problem?
It's solvable, but not something you do on the side. Under the GS1 standard, a 12-digit UPC code becomes an EAN-13 by adding a leading zero; the calculation is the easy part. What matters is what depends on these codes in the warehouse: labels, scanners, goods receipt. That needs to be clarified before the change, not after.
I have 8-digit EANs. Is it enough to pad them to 13 digits?
Under the GS1 standard, an EAN-8 can be represented as a 13-digit code with five leading zeros, which is formally correct. In practice, though, Kaufland rejected this padded form as invalid. So I wouldn't rely on it. If Kaufland rejects it, the way forward is the same as for missing codes: a real EAN-13 from the supplier.
What about products that have no EAN at all?
They can't be listed on Kaufland as long as there's no code, and you can't make up an EAN yourself. Kaufland requires a code officially assigned by GS1 or the manufacturer. The route then is a request to the manufacturer or supplier. The upfront check finds exactly these cases, so it's clear which part of the range can go online right away and where something still needs to be sourced.
My images don't show on the marketplace even though they're on the product. Why?
It doesn't have to be a transfer error. In one case the images were already in the Kaufland backend but weren't accepted as valid there, so the products still counted as having no images. It was solved directly on the Kaufland side: the affected images were edited and saved again in the Kaufland backend, after which the platform accepted and displayed them, without having to transfer them from the ERP system again. The order of diagnosis matters: if the images are demonstrably on the product, an unfinished processing step on the marketplace side is more likely than a transfer problem from JTL-Wawi.
How long does the setup take?
Creating the channel takes minutes. The time goes into the mappings and above all into data quality: the cleaner categories and attributes are maintained in your JTL-Wawi, the faster it goes. That's why I look at this beforehand and tell you what needs doing before anything goes live.
What are the ongoing costs?
You pay marketplace fees directly to the marketplace. On the JTL side you need an active JTL-eazyAuction license and an order package, since orders are billed per transaction. I'll work out what that adds up to in your case before you decide.
Do I need to clean up my product range first?
Usually partly, yes. Marketplaces are stricter than your own shop, especially with categories, attributes and the legal information under GPSR. That's not wasted effort: whatever you fix along the way helps you on every further channel and in your own shop as well.
Want this running in your business?
Describe your current process in two sentences. I'll get back to you with an honest assessment of what's possible.
Send a no-obligation request