Match the item you can actually buy
Match a supplier row to a specific sellable item. Check its identifier, variant and packaging level. If those details disagree, leave the row in a review queue and record the reason. Keep it out of product, price and stock updates until someone resolves the conflict.
A similar title can help you find candidates. It cannot tell you whether the offer is for one item, a case, or a different size. This guide starts after the file has been read into the intended columns. It deals with product identity. Use the CSV import guide for file structure and the supplier price update guide for what happens after a match is approved.
Record what each identifier means
A supplier SKU is the supplier's reference for a row or offer. Store it with the supplier's identity. Two suppliers can use the same string for unrelated items. A manufacturer part number, or MPN, needs the correct manufacturer or brand context. It can help narrow the search when a barcode is missing. Confirm the variant as well. Google's Merchant Center MPN guidance describes why the exact manufacturer value matters and gives examples where variants share a part number.
A Global Trade Item Number, or GTIN, identifies a trade item. Keep the original identifier as text. Preserve leading zeros and check that the source field really contains a GTIN before applying any normalization. A check digit helps validate the structure. Confirm the item separately with the package, manufacturer information or a source your team has approved. GS1's verification guidance explains that a registry lookup can return the allocating organization, with product details when available. If product details are missing, record what the lookup did establish and obtain the remaining evidence from another source.
Identify the package in the offer
Record the sellable level, such as each, manufacturer pack or case. Also record the count within the package. The GS1 GTIN Management Standard distinguishes changes in declared net content and changes to pack or case quantity. Do not copy a consumer-unit identifier into a case identity field because the inner items match. Keep a separate relationship from case to unit if you need it.
Keep platform rules separate from your identity record. For example, Google Merchant Center's GTIN guidance treats a manufacturer-created multipack differently from a merchant-created one. Verify the destination's rule before you export the match. A feed rule about which identifier to submit does not change what was actually ordered.
Give each row a clear decision
- Find candidates. Look for a verified identifier for the same sellable level. If it is unavailable, try an approved supplier mapping or a brand and part-number pair. Use titles to suggest candidates for review.
- Check conflicts. Compare the required attributes for this product type. For a water bottle, they may include capacity, color, sellable level and package count. Store normalized values separately from the original text. Treat a required blank as unknown.
- Resolve or hold. Mark a row ready only when the required evidence supports one destination and the attributes agree. Hold conflicting or incomplete rows. Use a separate no-match result when you have no candidate. Never let a tie or a high text-similarity score select a product for you.
- Record the evidence. Save the input version, row key, candidate ID, reason, reference and reviewer. A previously approved mapping can be reused when its required facts still agree. A changed identifier or package count sends it back to review.
If one row contains the inner unit's barcode but describes a case, keep both facts. Ask the supplier for the case identifier and packaging details. If the offer and destination cover different levels by design, create an explicit package relationship. Do not approve the row as an exact product match.
Fictional example with four supplier rows
This example is fictional. An invented distributor supplies blue and sand-colored bottles. The reference labels below stand for records in a test catalog. They are not real identifiers. The test assumes you have verified one target for each listed reference.
| Supplier row | Offer and reference | Candidate record | Expected decision |
|---|---|---|---|
| S-01 | Blue, 500 mL, one bottle, REF-A | Blue, 500 mL, one bottle, REF-A | Ready. Reference and required attributes agree. |
| S-02 | Blue, 500 mL, case of 12, REF-A | Blue, 500 mL, one bottle, REF-A | Hold. The reference is for the inner unit. |
| S-03 | Sand, 500 mL, one bottle, REF-A | Blue, 500 mL, one bottle, REF-A | Hold. The color conflicts with the reference. |
| S-04 | Blue, 750 mL, one bottle, no reference | None with confirmed identity | No match. Ask for identifying evidence. |
Only S-01 is ready under these rules. S-02 could be correctable if the supplier confirms a case reference. S-03 needs evidence to decide whether the color or reference is wrong. S-04 should stay separate from the blue 500 mL product even if both have the same supplier title. The test does not submit a feed or change a listing.
Run these checks before enabling writes
- One exact supported identity with agreeing attributes resolves to one candidate.
- A reused inner-unit reference cannot turn a case into a single item.
- A different required color or size blocks a shared-reference match.
- A missing required attribute is recorded as unknown and cannot count as agreement.
- A supplier SKU reused by a different supplier does not inherit the old mapping.
- A damaged identifier, a duplicate reference or two equally plausible targets goes to review.
- A repeat file with a changed package count reopens a previously approved match.
- Held rows and no-match rows cannot write a product, price or stock change.
SUPPLIER PRODUCT MATCH — REVIEW WORKSHEET Supplier and input version: Row key and raw description: Raw identifier, type and issuer: Required variant attributes and source: Sellable packaging level and count: Destination candidate and its reference: Conflicting or unknown fields: Decision: ready / hold / no match Reason and evidence to keep: Reviewer and date: Expected next action: Check | expected decision | actual decision | pass/fail/not run
Compare the exact decision and reason for each test case. A row can end in the right queue for the wrong reason, which makes it harder to fix later. Bring a redacted example of one disputed match to a free fit call to discuss seller operations tools with a review step.