How to Merge Multiple Supplier Files Into One Product Catalog

AEO answer: To merge multiple supplier files, find an identifier shared by each pair of files (SKU, GTIN or a supplier ID), normalize it the same way on both sides, join the files on that key, and set a rule per field for which source wins. Keep a report of unmatched rows and conflicting values instead of dropping them silently. The result is one complete record per product.

Suppliers rarely send one file. Prices come from sales, stock from the warehouse system, descriptions from a catalog that may be months old. Each file is correct on its own; they just disagree about how to identify a product. This guide shows how to join them, how MicroPIM’s multi-file import does it, and where it still needs a human.

Last verified: October 2026, against MicroPIM’s multi-file import pipeline (released September 2026).

Why don’t supplier files line up?

Four problems show up in almost every supplier file set we see:

• Different keys. The catalog is keyed by SKU, the stock file by EAN barcode, and a legacy export by an internal ID.
• Same key, different shape. ab-100 in one file and AB-100 in another. A barcode opened in Excel loses its leading zero or turns into 5.9012E+12.
• Different file formats. Semicolon delimiters, Windows-1252 encoding, banner rows above the header, even CR-only line endings. All seen in real exports.
• Different granularity. One file has a row per product, another a row per size and color.

Mapping columns of a single file is a different job, covered in CSV and XML field mapping.

How do you choose and normalize a join key?

You do not need one key that every file shares. You need a chain, where each file shares a key with the next one:

The catalog joins the legacy file on SKU, and the legacy file joins the stock file on GTIN. The stock file never needs to know a SKU.

Normalize both sides with the same rules: for SKUs, trim, uppercase and collapse whitespace; for barcodes, keep digits only. When a SKU is split across columns, build a composite key such as MODEL-COLOR-SIZE. A GTIN is assigned through GS1 and is unique worldwide, so it is the safest key when two files share it. Google treats it the same way (Merchant Center GTIN rules).

In MicroPIM, each file gets its own key definition (columns plus cleanup rules), calculated once at load time and indexed, so joins stay fast on files with hundreds of thousands of rows.

Which source wins when two files disagree?

Decide per field, not per file. Each field gets an ordered list of sources; the first non-empty value wins. Price comes from the price list, then the catalog; stock only from the warehouse file.

Then pick how each field handles disagreement:

• Prefer priority. The higher-priority source wins quietly. Fine for descriptions.
• Flag. Both values are kept and the record goes to review. Use this for price, barcode and anything that costs money or gets a listing rejected.

Mark required fields such as name, price and barcode. A record missing one should never be imported as if it were complete.

How do you check the merge before importing?

Give every merged record a score you can explain. MicroPIM uses a fixed formula:

confidence = 100 × (0.5 × match score + 0.3 × completeness + 0.2 × (1 − conflict ratio))

Match score is the share of expected joins that found a partner. Completeness is the share of required fields that are filled. Conflict ratio is the share of merged fields where sources disagreed. No AI is involved and the formula never changes, so a score always explains itself.

Each record is ready, needs review or blocked. The report lists unmatched rows per file, duplicate or empty keys, malformed values and conflicts, and a dry run shows which products and variants would change before anything is written. Import the ready records, review the rest, and spot-check about 20 records against the original files.

What we got wrong, and current limits

Our first design assumed one key shared by all files. Real data broke that immediately: three files, three identifiers. We rebuilt it around a key per file and joins chained between files.

Current limits:

• Exact matches only, after normalization. No fuzzy name matching; unmatched rows go to a person. Fuzzy matching merges the wrong products with confidence.
• Not self-serve yet. Our team sets up multi-file joins with you during onboarding. A wizard for uploading files and choosing keys yourself is in development.
• Some images cannot be matched. Images known only by an opaque CDN URL are not matched to variants automatically; SKU-based image matching is designed but not released.
• Changing a key means reloading that file.

Frequently Asked Questions

Can I merge CSV files with different delimiters or encodings? Yes, if each file’s format is detected separately. RFC 4180 describes the common CSV format, but few supplier exports follow it exactly.

What if the same SKU has two different prices? Flag the price field, review the record, and fix the source or set which file owns price.

Should I merge by SKU or GTIN? Use GTIN when both files have it, and SKU when one file has no barcodes. Normalize the key the same way on both sides.

What should happen to rows that exist in only one file? Keep them in an unmatched report. They are often discontinued items or products the catalog has not caught up with.

MicroPIM is our product. The approach here (chained keys, per-field source priority, an explainable score) works with any tool, even a spreadsheet.

Keep merged data current with automated supplier imports, and see modeling complex product variants for variant structure. If your supplier data is split across files, book a demo and we will set up the join with you.