Importing products from supplier XML: the five pitfalls and how to avoid them.

Your supplier gives you a link to an XML file with 8,000 product codes: titles, prices, stock, photos. An eshop plugin loads them overnight, and in the morning you have a catalogue. By hand, the same work would take months.

Three months later, though, the same product shows up twice, a customer buys something the supplier ran out of on Tuesday, and half the eshop’s categories have names nobody understands. None of this is bad luck. They’re five pitfalls you can see from the start, if you know where to look.

Two suppliers bring in the same drill. One calls it “Cordless drill 12V”, the other “DRILL-DRIVER 12V LI-ION”. If the import matches products by title or by the supplier’s code, you’ll have two products on the eshop, with two prices and two stock levels.

Matching is done by the EAN, the product’s barcode. GS1, the organisation that issues barcodes, now calls it a GTIN, and every GTIN identifies one product uniquely, whoever sells it. Where the EAN is missing, you match by the manufacturer’s code (MPN) together with the manufacturer. Whatever matches neither way goes to a person to look at.

When the same product comes from two suppliers, the eshop keeps one product with two sources. Each supplier’s code is stored in its own field, so you know where you order from. The product’s code on the eshop is yours, and it doesn’t change.

Duplicates don’t only spoil the eshop. Skroutz, Greece’s largest price-comparison site and marketplace, for example, wants each product once in the XML, and a different EAN for each different product. Watch out for the opposite mistake too: suppliers who put the same EAN on every colour of a model. There the EAN isn’t enough to tell them apart, and you need the colour as well.

Many suppliers update their XML once a day, some every hour. If the eshop reads it less often than it changes, you’ll sell products that don’t exist. Ask the supplier how often they update the file, and read it at least that often.

Two rules help a lot:

• A safety margin on stock: if the supplier has one or two units left, the product shows as unavailable. By the time your order reaches them, they may have sold them to someone else.
• The right availability: what you hold in your own warehouse ships straight away, while what comes from the supplier takes days. On Skroutz, the first is «Άμεσα διαθέσιμο» (in stock) and the second, usually, «Διαθέσιμο από 1 έως 3 ημέρες» (available in 1 to 3 days). All the values are in the Skroutz feed 2026 guide.

The supplier’s price is your purchase price, not your selling price. The selling price comes from your own rules: margin, rounding, minimum price. Add a brake too: if a product’s price changes sharply from one day to the next, hold it for a check instead of sending it straight to the eshop. One misplaced decimal point in the supplier’s file is enough to sell something at a tenth of its price.

Every supplier has its own categories. If you load them as they are, the eshop will have three categories for the same products, named after three different warehouses.

The answer is a mapping table: each of the supplier’s categories maps to one of yours. You build it once, and then add to it only when the supplier adds something. A new supplier category doesn’t open on the eshop by itself; it goes on a list to be checked.

The same goes for attributes, which make the eshop’s filters work. One supplier writes “Black”, another «Μαύρο» (Greek for black) and a third “MATT BLACK”. If they don’t become one value, a customer who filters on “Black” doesn’t see half the products. The same with units: “1000W”, “1 kW” and “1000 Watt” are the same thing.

Across thousands of product codes, AI can suggest the first mapping, and a person checks whatever isn’t certain.

The fact that photos and descriptions are in the XML doesn’t mean you can use them everywhere. Ask the supplier, in writing, whether you can put them on your eshop and on the marketplaces.

Then there’s quality. Suppliers’ photos are often small, each on a different background, or carry the supplier’s logo. Skroutz doesn’t accept photos with a logo or watermark, and wants the product over 1,000 pixels on one side. Keep a copy of every photo on your own server: if the supplier changes its links, your eshop’s photos won’t disappear. AI can bring all the photos to the same size and the same background.

Suppliers’ descriptions are the same on dozens of eshops. Google, in its guidance on helpful content, asks whether a page that draws on other sources adds something of its own or simply copies them. You don’t need to rewrite 8,000 descriptions; start with your best-selling products. And clean out whatever doesn’t belong on your eshop: HTML, text in all capitals, the supplier’s name or instructions to its resellers.

One day the XML will arrive empty, half-finished, with a different structure, or not at all. The supplier’s server went down, someone renamed a field, the link changed. A simple import reads the empty file and sets the whole catalogue’s stock to zero. Or, worse, it reads nothing and leaves yesterday’s stock showing as available for weeks.

The import has to check every file before it goes in:

• Is it valid XML, with the fields we expect? If not, nothing goes in.
• Does it have roughly as many products as yesterday? If a large part is suddenly missing, the update stops and someone is alerted.
• When did a good file last arrive? If the supplier hasn’t updated for many hours, their products show a longer delivery time or become unavailable, until a good file comes in again.

That way, if the supplier’s XML goes down, nothing is lost: the eshop keeps the last good file, and you hear about it from an email, not from an angry customer.

Behind the five pitfalls lies one question: for each piece of data, who decides? The supplier knows what they have and at what price they sell it to you. Everything else is decided by your own catalogue.

The rule in the last row matters: if you correct a title or write your own description, the supplier’s next update mustn’t overwrite it. There’s more in the guide which system has the last word.

From this one catalogue, everything else is then updated: the eshop, your business software and the feeds for the marketplaces.

1. How often is the XML updated? Both price and stock, or only one of the two?
2. Do all products have an EAN and an MPN? If not, how many are missing?
3. Is the price with or without VAT? Is it your purchase price or the recommended retail price?
4. What does “available” mean? In their warehouse today, or to order from the manufacturer?
5. Can I use the photos and descriptions? On the marketplaces too?
6. Who tells us when the file changes? One renamed field is enough to stop the import.

We bring your suppliers’ XML files, Excel files and connections (APIs) together into one clean catalogue. Products are matched by EAN and MPN, and for each piece of data it’s written down which supplier we take it from when two disagree.

Whatever is missing, such as a description, a category or an attribute, is filled in by AI and checked by a person. What AI writes never overwrites the supplier’s data, so every change can be seen and undone. Every new import runs as a trial first, so you see what will change before it changes.

The catalogue updates Odoo or the software you use today, the eshop and the marketplaces. See our supplier XML feeds service, and how we set it up for wholesale & distribution.