Matching supplier products to your internal catalog

The same product in a different pack

Suppose a supplier offers a six-pack of identical markers. The internal catalog contains two records: a single marker and a six-pack from the same manufacturer, with the same model. Their names start the same way, but the employee has to open each record to see the pack quantity. The supplier’s item code does not appear in the internal catalog.

A useful suggestion would bring up both records together, clearly showing the pack quantities and available identifiers. The employee could rule out the single marker, then check whether the six-pack matches the supplier’s offer. Similar names alone do not settle that question.

What an identifier refers to also matters. A GTIN identifies a trade item. GS1 UK explains that each packaging level should have its own GTIN. The number for an individual product therefore should not be used to confirm the identity of a multipack. Source: GS1 UK.

If the supplier leaves the packaging field blank, a list of similar products can still help with the search. It does not establish whether to choose the single item or the pack. Someone needs to check the supplier’s documentation or ask for clarification. That uncertainty should remain visible alongside the suggested records.

When ordinary search is enough

If both sides have the same verified identifier for the relevant trade item, looking it up may resolve the match without a model. An existing, approved link between a supplier code and an internal item number can do the same. When the next catalog arrives, the employee should not have to establish that link all over again, provided the codes still refer to the same items.

Start by looking at why searches fail. Perhaps the code is stored in a different field, the catalog has duplicate records, or approved matches exist only in individual buyers’ spreadsheets. Organizing those records may remove much of the manual searching. A shared record of known matches does not require AI.

Items without a common identifier are harder. A supplier may abbreviate the name while the company uses a full description, or list the product’s features in a different order. Search that accounts for meaning can suggest records an exact phrase search would miss.

What the model should find

Here, the model helps locate existing catalog records. It returns a short list for someone to review. In the marker example, that list is useful if the employee quickly reaches the correct pack and can see how it differs from the single item.

A model can find descriptions that mean similar things even when their wording differs. The supplier and the employee may use different names for the same product, yet the search can still surface a relevant record to check.

Google distinguishes between using models for information retrieval and for assessing text similarity. Its documentation also describes adapting models using examples relevant to a particular task. Neither capability establishes that two similarly described items are identical. See Google’s documentation on embedding task types and model tuning.

You do not need to choose a search technique before speaking with a developer. You do need to describe the help employees should receive. A useful suggestion leads to a specific item record and shows the information needed to check it. A list of similar names leaves much of the original work unfinished.

What would justify customization?

First, try an off-the-shelf model on searches that currently give the team trouble. If it finds appropriate records and employees can readily select the right one, further training may be unnecessary.

Customization becomes more relevant when particular mistakes keep recurring. The model might miss supplier abbreviations or place single items near the top of the results while the matching multipacks appear much farther down. The company then needs reliable examples of correct matches, reviewed by someone who knows the catalog. Previously linked records deserve scrutiny too: an old match may have been a mistake.

Before extending the system, employees should compare its suggestions with ordinary search on additional items that were not used to customize the model. Look at whether the correct product appears on the short list and how much work it takes to confirm. Include products the company does not yet carry. A useful search tool must let the employee finish without a match rather than push them toward the closest name.

Once an employee approves a link, saving it can avoid another search for the same item when the next file arrives. The person responsible for the catalog still decides whether to link the records, clarify the supplier’s information, or create a new item. Checking changes to purchasing terms comes later; our article on supplier price list checks covers that separate task.

A Syntalith project for one part of the catalog

Syntalith builds AI applications and adapts models. For a catalog team, we propose starting with one product group where employees repeatedly search for the same or similar items. We examine what better identifier handling and ordinary search resolve, then compare model suggestions with those approaches. A customization trial should show whether the improvement over simpler methods warrants deployment and maintenance.

The result should fit into the place where employees review supplier items, allowing them to open a suggested record and approve the link. For the first conversation, describe how you search today and where you most often get stuck. You do not need a completed specification or your entire catalog ready to share. Offer information is on Syntalith’s pricing page.