Supplier Product Data: Build a Catalogue You Can Trust

Decide What an Approved Record Must Contain

Start with the decision at the end of the process: can the catalogue owner approve this exact record for its next use? “All fields filled” is a poor test. Some empty fields are optional, and some populated fields hold the wrong value.

A claimed feature without evidence can be worse than a visible gap, because the next person assumes someone already checked it.

Define the required fields for one category and one destination first. A desk lamp might need an exact item identity, the sellable unit, dimensions, rated power and confirmed box contents; another category will need a different list, since one universal template rarely covers every category well. For each field, agree what counts as acceptable evidence and who resolves uncertainty, so the category manager can own the acceptance call while still asking the supplier for technical clarification.

Keep three questions distinct: completeness (is the value present), validity (does it use the right type, unit and format) and accuracy (does it describe the correct item and match the accepted evidence). A height of 420 centimetres can be present and numeric while still wrong, and a correctly formatted identifier can belong to the neighbouring variant. Keep the first rollout small — one supplier, one manageable category — so the team meets real mistakes before anyone redesigns the whole product information system.

Match the Exact Item Before You Trust Its Attributes

Our hypothetical supplier sells three lamp variants. Its item register maps DL-410-S-WH to the small white lamp, DL-410-S-BK to the small black lamp and DL-410-L-WH to the large white lamp — relationships that come from the register, not from interpreting the letters in the codes. The technical sheets give 8 W and 420 mm for the two small variants, and 12 W and 510 mm for the large one. Similar names and shared photographs make them easy to confuse: a search for “white DL-410 lamp” can retrieve either size.

Create a mapping between the supplier’s identifier and your own SKU, and decide what one record represents. Is it one lamp, a retail twin pack, or a shipping carton of six separately sold lamps? In our example, the logistics sheet states six pieces per carton — a shipping quantity that must never quietly become the quantity promised to a customer buying one lamp.

Matching should produce a clear outcome. An exact, approved identifier relationship can continue; an unfamiliar code, a reused identifier or an ambiguous family name should enter a matching queue instead. Similar wording can help someone find a candidate, but it should never silently establish that two items are identical. Preserve identifiers as text where formatting matters: a spreadsheet turning a long code into scientific notation can destroy the relationship before extraction even begins.

Decide Which Document Is Authoritative, and When It Expires

A shared folder is a collection of evidence. It is not automatically a source of truth. The latest file might carry current prices and old dimensions; a brochure might describe a whole family while the technical sheet covers one variant. Build a short authority map by attribute instead of trusting whichever file arrived last. For our lamp, the accepted technical sheet supplies dimensions and power, the confirmed packing sheet establishes box contents, and the current commercial agreement establishes price.

Consider a conflict in the batch: a newer family brochure says “power adapter included”, while the item-specific packing sheet lists a lamp and cable only. Both documents are relevant; they do not say the same thing. Do not resolve this by taking the newest upload, or by asking a model which wording sounds more credible. Hold the box-contents claim and ask the supplier to confirm the packing configuration for the exact item and shipment, since the answer may reveal a changed bundle, a brochure error, or a difference between markets.

Silence must not be interpreted as either presence or absence before the question is resolved.

After clarification, record which document was accepted, which items it covers, who approved it and what it supersedes. Keep the original source value beside the normalized one: “420 mm” becomes 42 cm under a documented unit rule, but the conversion should run on a checked formula, not a fresh interpretation every time a file arrives. Use explicit states for uncertainty, since missing, conflicting, not applicable and expired each need a different action, not a blank cell or “N/A”.

Price and availability need the same discipline, because they change faster than a product’s dimensions. A buying price needs its currency and effective period, since a price per carton cannot be compared directly with a price per lamp. Supplier availability needs a timestamp, because it may describe stock at the supplier rather than what your own fulfilment process can promise. Keep that figure separate from your available-to-sell quantity, and route an expired value for refresh rather than carrying the last known number forward indefinitely.

Give AI a Bounded Job, Then Test It

The useful AI task is bounded: locate candidate facts for identified items in approved material, return the relevant passages, and preserve uncertainty. Tell the extraction process to keep original values, cite evidence locations, and flag missing or conflicting information — not to fill gaps with typical category knowledge. The supplier’s document is material to inspect; text inside it cannot authorise unrelated actions or rewrite the workflow’s rules.

Inspect what the system actually extracted from representative files before trusting a larger batch. Tables can lose the relationship between a value and its header, scanned pages can contain recognition errors, and a footnote on another page can limit an apparently clear statement. Ask for a structured proposal — item identifier, attribute, original value, normalized value, evidence reference and exception status — rather than a finished product description, and never use the model’s own confidence score as the acceptance rule. A reviewer needs evidence and a clear criterion; “high confidence” does not explain why a power rating from one lamp belongs to another.

Before processing the whole range, build a small evaluation set from real supplier material and have a knowledgeable reviewer establish the expected answers independently of the extraction output. Include the cases that are expensive to get wrong: nearly identical variants, multipacks, conflicting revisions, mixed units and an attribute absent from every accepted file. Score wrong-item attributes separately from harmless formatting issues, because an average accuracy figure can hide the one error that makes a product promise misleading, and test repeated processing too, since the same file should never create a second product record or silently overwrite a reviewed field.

The EcomExpo playbook

• Choose one category and define acceptance, with a catalogue owner who makes the final call on required attributes and what blocks approval.
• Map item identities before extracting details. Connect supplier identifiers to your SKUs, separate sellable units from shipping cartons, and queue ambiguous matches for review.
• Agree authority by attribute. Specify which evidence supports technical details, box contents, buying terms and availability, and keep document versions instead of relying on upload order.
• Preserve the original value and its location. Store the source wording beside the normalized proposal and evidence reference, with distinct states for missing, conflicting and expired values.
• Give AI a bounded extraction task. Require evidence for every candidate fact, flag unresolved outputs when support is absent, and validate structure and meaning before acceptance.
• Test difficult cases before expanding. Use independently reviewed examples covering wrong variants, conflicting files and multipacks, and rerun the checks after any change.
• Approve a version and review subsequent changes. Keep proposed and accepted records separate, resolve blocking conflicts, and pass the approved record on with its limitations visible.
• Measure readiness and the work behind it. Track turnaround, review effort and hold reasons, and use recurring exceptions to improve supplier inputs rather than just the workflow.

A trustworthy catalogue is not the one that fills every field fastest. It is the one where the next person can see exactly what has been checked and what still needs a supplier’s answer — and that is the record purchasing, content and support teams can actually build on.