Supplier XML/CSV Feeds: Map Products and Variants Without Duplicate SKUs

A supplier XML or CSV feed is a source of product information, not a ready-made instruction to change every matching field in an ecommerce catalogue. A supplier code may differ from the store's SKU; several source rows may describe variations of one parent product; and an omitted quantity is not the same as an explicit zero. Reliable mapping begins with stable source identity, a verified link to an existing variant and a clear owner for each field that the feed is allowed to update.

This guide follows supplier records from their original structure through normalisation and into product, pricing and inventory data. It covers Shopify's separate product and location-level inventory CSV formats as well as the general identification principles relevant to PrestaShop. A fictional size-and-colour family illustrates how to prevent duplicate products and update the correct variant without confusing translations, photographs and stock records.

Keep supplier identity, store SKU, variant ID and GTIN separate

Treat the combination of supplier identity plus the supplier's permanent item code as a stable external key. A value such as 000847 on its own may also exist in a second wholesaler's catalogue. Prefixing or associating it with supplier North and saving the resulting relationship lets the same inbound item consistently find the same store variant. This is a record identity, not necessarily the code displayed to warehouse employees.

Your own SKU is an operational identifier within the store. The internal variant ID identifies the existing technical record in the platform. A GTIN, including an EAN when assigned, belongs to a global trade-item identification scheme. A supplier reference, store SKU, platform ID and assigned GTIN can all refer to the same sellable version while containing different values. Avoid replacing one with another merely because the data look alike.

Products and variants also have different roles. A parent product groups the model, descriptions and relevant shared attributes; each variant represents an actual combination such as M/Blue or L/Blue. A source record that describes a new colour label or product image is not evidence of a new sellable version. Compare the incoming options with the known parent and variant records before deciding whether to update one record or propose an additional version.

Keep item codes as text, including leading zeros. If spreadsheet software turns 000847 into 847, the stable supplier key has changed. The same risk applies to an internal SKU or valid GTIN represented as digits. Specify text handling during import and export, use consistent character encoding and preserve meaningful punctuation. Normalisation should remove agreed formatting noise, not erase the distinctions that make an identifier unique.

When an incoming record has no verified shop relationship, put it in a review set instead of matching on a similar title. Titles can change, contain translations or occur in multiple product families. The target variant ID and selected option values provide a stronger basis for validation. Once the association is established, later source updates can continue to use it without generating a duplicate parent or losing the shop's own SKU scheme.

Normalise XML and CSV values without changing catalogue identity

An XML feed may express parent products as nested elements with repeated variant children, while a CSV presents columns and rows. Check either source format against the store's actual native import fields and rules. First decide whether a record describes a parent, a variation, a stock observation or media. Then identify source fields and repeatable groups before selecting the corresponding destination. The presence of a column called sku does not establish which code system it contains.

Normalise values using deliberate, documented mappings. A supplier colour code BLU can become Blue in the storefront when the dictionary defines it unambiguously. A source size of large can map to L if that matches the catalogue's actual options. Retain the original value alongside the normalised version for future comparison. Do not infer two different physical colours are identical just because a translated word happens to look similar.

Preserve correct data types and units. Identifiers remain text, prices need a known currency and price definition, and inventory quantities need an explicit unit and status. An unqualified field named quantity may represent available, physically on hand or a different supplier-specific amount. Capture the stock location and observation timestamp with its time zone. Without those details a numeric value can be valid in its own system yet unsuitable for updating a shop's inventory.

Translations should target existing language fields on the correct parent or variant, not trigger product creation. The same applies to images. A new source photograph can update an image association for one colour while all other variants retain their identities. Compare the media's intended option values with the variant before linking it. An image URL, title translation and sellable variant are different entities even if the feed distributes them on separate rows.

Build an intermediate mapping record with supplier, supplier item code, parent reference, selected options, existing shop variant ID, store SKU, assigned GTIN, stock location, source type and timestamp. This intermediate view is a review layer rather than the CSV the platform will import. After validating the links and field ownership, translate only the approved values into the particular Shopify or PrestaShop input format actually supported by that destination.

Fictional Atlas variants: source, normalisation and destination

Consider a fictional supplier called North offering the Atlas shirt. Its feed contains 000847 for M/Blue, 000848 for L/Blue and 000849 for M/Sand. The store already has each of these versions under its own SKU and variant ID. L/Sand is not yet offered. All item codes shown here are illustrative internal references. Record a GTIN when the actual assigned identifier for that variant has been verified.

The four columns show how each inbound source field is interpreted before it is linked to the destination. The full external key combines supplier and code. Normalisation standardises the option names, but does not rewrite the code. The destination is an existing parent or variant record, with a rule identifying what may change. In particular, a variant from the same supplier with a different size is not simply an update to the nearest existing size.

One feed row can carry several types of data. The source may own a supplier product description while the merchant controls its selling price. Likewise, a stock figure may refer to a supplier warehouse that is not one of the shop's fulfilment locations. Use an explicit ownership policy for each column. The mapping rule is not only a translation between field names; it determines whether the new value should modify the store at all.

Shopify product CSV updates must preserve variant options

Shopify represents a parent product and its options separately from the sellable variants. In the GraphQL Admin API 2026-10, ProductVariant exposes fields such as sku, barcodes, selectedOptions and the associated inventoryItem. These connect product options, merchandising and inventory to one variant. The supplier's item code is a separate mapping key even when the shop chooses a similar SKU.

Product CSV files have an exact format, with columns that depend on one another. When updating variant-related values such as SKU or weight, Shopify requires the corresponding option fields. In particular, the product CSV documentation identifies Option1 name and Option1 value. Omitting the relevant options can lead to an unintended default variant being created and existing variants being deleted. The selected size and colour must therefore travel with the variant row.

Do not treat the GraphQL variant object and a Shopify product CSV as interchangeable structures. The API refers to selectedOptions and an internal variant ID; a native product CSV needs the current names of the appropriate option columns. Map the same existing variant carefully into either representation. An arbitrary supplier CSV column named variant will not satisfy the platform's required product import relationships on its own.

The official Shopify product CSV instructions explain required headers, dependencies and how blank or missing columns can affect an overwrite. Review those rules before preparing an update, especially if only one business field is intended to change. A minimal-looking CSV can have broader effects when its omitted columns are needed to identify the correct existing variants.

PrestaShop also distinguishes parent products from individual combinations, but uses its own native field names. The guide PrestaShop Combinations: SKU, EAN and Stock by Variant details the difference between product ID, combination ID, internal reference, supplier reference and assigned GTIN. Across both platforms, the supplier feed is the starting data source; a properly mapped platform-specific input is a separate deliverable.

Inventory CSV, location and current/new protection are separate

For stores with multiple inventory locations, Shopify uses an inventory CSV distinct from the product CSV. An inventory row identifies a variant in a particular location rather than changing its product title or selectable options. The All states export has separate location rows and distinguishes physical stock, committed units, available units and other inventory states. An incoming supplier quantity cannot be assigned safely until the location and the meaning of that quantity are understood.

The recommended All states CSV includes On hand (current) and On hand (new). Current records the quantity when the CSV was exported and provides the basis for safety validation. New is the quantity you intend to set; leaving it blank means you are not changing the quantity. Shopify compares the current real stock with the saved snapshot before applying the update. If newer stock movements have occurred, the relevant rows fail validation instead of silently overwriting those changes.

Keep this protection rather than clearing the current column merely to force an older update through. A sale, receipt or other movement since export changes the meaning of the new quantity. Reconcile the later events, refresh the baseline and decide what the correct current target should now be. Shopify's inventory CSV guidance explains the All states and Available formats and the safety check for the current/new columns.

Changing the identifying SKU cell within an inventory CSV does not rename the SKU of the product variant. The inventory CSV uses identification to find the item; product SKU changes belong in the relevant product or variant workflow. With multiple warehouses, the same variant can appear on several location rows. Know which fulfilment location each supplier figure represents. Do not add together unrelated supplier quantities or apply a stock figure to every location just because the variant code matches.

Save the observation timestamp with a time zone, the stock location and the quantity's semantics. On hand, available to sell and reserved are different states. An explicit zero may mean a genuine count of no units; a missing value says that the source did not provide a number. Price updates also require their own ownership and timing rules. Separating these decisions prevents an inventory feed from inadvertently acting as a master source for the shop's retail price.

Give missing, blank, zero and deleted records different rules

An omitted field means the source did not provide that attribute. An empty value is a present field with no content. An explicit numeric zero is a value, while a deleted record is a separate catalogue event. These states need different rules. For each destination field, determine whether an empty input should leave it unchanged, clear it when explicitly authorised or be held for validation. Do not let the default behaviour of an import tool silently decide.

A missing quantity cannot automatically be interpreted as stock zero. Likewise, an item that disappears from one incomplete supplier export has not necessarily been discontinued. A deletion or retirement requires a documented signal or explicit assortment decision. Process a true counted zero only when the source owns that stock figure and the location, timestamp and type of quantity are known. Unknown values should be recorded as unknown, not represented as quantities that were observed.

Assign an owner to every updated column. Suppliers may own manufacturer descriptions and technical attributes, while the retailer controls its customer-facing title, sale price and market-specific merchandising. A supplier can be authoritative for one warehouse's availability while another service supplies the shop's physical inventory balance. Keep pricing and stock ownership separate, including currencies, tax meaning, price type, location and inventory state. Apply each feed value only to the fields assigned to that source.

Translation rows and image references target content attached to an existing parent or variant. A second-language title and a new photo can both appear in additional rows without requiring a second product. Confirm the intended language and variant-image relationship before applying them. A new source option pair with no match should be reviewed as a possible new assortment version, rather than being merged into the closest colour or created automatically.

Validate saved records, repeatability and selective correction

Start with a small representative sample in an isolated test environment. Include an existing variant, a source code with leading zeros, an unknown option pair, a blank quantity and a warehouse row changed since export. Save the pre-update values. Apply only fields whose mapping and ownership have been approved, then read back the saved product, variant, options, price and location quantity. A successful file upload is not the same as confirmation that the correct record was modified.

Process the identical approved input a second time. Supplier North plus code 000847 must resolve to the same existing variant ID, rather than creating a second product or another size option. That property is often called idempotence. Compare the resulting relationships and values, not just the row count. A translated title or an additional image should remain attached to the existing product.

Prepare a targeted reversal of the fields actually changed. Keep a record of previous values and the reason for each update, but consider new sales, receipts, pricing decisions and corrections that occurred after the baseline was captured. Restoring an entire older product or stock snapshot can overwrite legitimate later events. Review the affected records and preserve newer business changes when correcting only the import's effects.

Kiljano's Supplier XML/CSV Feed Analysis examines one feed with up to 100 sample records and proposes a field mapping in CSV or spreadsheet form. CSV Data Cleanup — 100 Rows handles one UTF-8 CSV of up to 100 data rows in agreed columns, checking straightforward duplicates, missing values and formats and returning a cleaned CSV with a short change log. Both provide concrete, reviewable input for well-organised catalogue data.

Frequently asked questions about supplier feed mapping

Can I use the supplier item code as the store SKU?

It can differ from the store's own reference. Preserve supplier identity plus code as the source key and map it to the verified store SKU and variant ID.

How do I preserve codes beginning with zero?

Treat them as text throughout parsing, spreadsheet editing and export. The identifier 000847 is not interchangeable with the number 847.

Does a blank inventory field mean that stock is zero?

No. Missing, empty and explicit zero values mean different things. Stock updates also need the relevant location, quantity type and observation time.

Does a new translation or photograph create a product?

No. Attach translated fields and relevant images to the known parent or variant. Review a genuinely new option combination separately.

Can product CSV update stock at several Shopify locations?

Shopify uses a separate inventory CSV for multi-location inventory. The recommended All states format protects physical stock with current/new validation.

What if a stock level changes after the inventory export?

Shopify compares On hand (current) with the actual quantity and can reject the affected row. Review the later movements and recalculate the intended new value.

How can I tell whether mapping creates duplicates?

Read back the internal product and variant IDs, then process the same sample again. Unchanged external keys should continue to resolve to the same records.