Why B2B Supplier Matching Is Harder Than Search

A buyer needs a supplier for a specific product. They type a description into a B2B platform and get back a list of companies. Most of the list is irrelevant, several entries describe something adjacent but not the same, and the one supplier who could actually fulfil the order does not appear because they described their product differently.

This is the standard experience of B2B sourcing online, and it persists because the problem is usually built as a search problem. It is not. Search retrieves documents that resemble a query. Sourcing requires deciding whether a specific supplier can deliver a specific thing to a specific buyer under specific conditions — which is a sequence of judgements, and only the first of them looks anything like search.

The judgements a match actually requires

Separate them out and the engineering becomes tractable.

Is this the same product? The buyer's description and the supplier's description have to resolve to the same thing. This is harder than it sounds and is treated below.

Can this supplier actually deliver it? Listing a product and being able to supply it at the requested volume, specification and timeframe are different claims. A catalogue entry is a statement of intent.

Is this supplier real? An unverified listing is an assertion by an anonymous party. Sourcing decisions carry money and risk, and identity is the precondition for both.

Does the commercial frame fit? Minimum order quantity, payment terms, incoterms, certification requirements, lead time. A supplier who matches on product and fails on minimum order is not a match.

Can the goods legally move between these two parties? Classification, licensing, restricted party status, route feasibility. A perfect commercial match that cannot clear customs is not a match either.

A system that only answers the first question returns a list. A system that answers all five returns a decision. The gap between those two outputs is most of the value.

The resolution problem

Start with the first judgement, because everything downstream depends on it.

The same physical product is described differently by every party that touches it. A manufacturer describes it by its production specification. A trader describes it by its commercial category. A buyer describes it by the application they need it for. Each description is correct and none of them matches the others as text.

Three further layers sit on top of that.

Language. Descriptions are written in whatever language the writer works in. The equivalent terms across languages are frequently not direct translations, because technical and commercial vocabulary develops independently in each market. Machine translation is optimised for fluency rather than terminological precision, so it substitutes near-synonyms freely — which is harmless in prose and destructive when the near-synonym denotes a different grade, standard or category.

Classification codes. Harmonized System codes are the nearest thing to a universal product identifier in trade, and they are applied inconsistently. The first six digits are international; beyond that, each country extends them for its own purposes. Two parties describing the same goods can legitimately arrive at different codes, and a system that treats a code as a reliable join key will produce confident wrong matches.

Attributes and units. Specifications are expressed in different units, different tolerance conventions and different standards regimes. A match requires normalising these before comparison, not after.

The result is that two descriptions of one product almost never resolve to the same entity by text comparison. Deciding that they refer to the same thing is the core technical problem in B2B matching, and it is a resolution problem rather than a retrieval problem.

Why keyword and embedding search each fall short

Keyword matching fails on the obvious axis — different words for the same thing — and also on a less obvious one: it succeeds on the wrong things. Two products sharing a material name match strongly while being entirely different goods, and a code appearing in both descriptions produces a match regardless of context.

Embedding search handles paraphrase and some cross-lingual meaning, which is why it is the common answer. Its weaknesses in this domain are specific. Alignment quality across languages varies, and degrades on technical vocabulary that appears rarely in general text — which is exactly the vocabulary that distinguishes one grade of a product from another. Embeddings also blur precise identifiers: a standard number, a grade designation, a model code are the details that determine whether two products are the same, and vector similarity treats them as approximately interchangeable.

The practical consequence is that embeddings return things that are about the same subject, and sourcing requires things that are the same product. Those are different questions.

What a working design looks like

Hybrid retrieval. Lexical search catches exact identifiers — standards, grades, codes, model numbers — that embeddings blur. Dense search catches paraphrase and cross-lingual meaning that lexical misses. Each covers the other's failure mode, and in this domain both failure modes are common.

An explicit product ontology. A curated structure that defines what attributes a product category has, which units they are expressed in, and how terms in different languages map to the same concept. This is slow manual work and it outperforms a better embedding model on precisely the cases that matter, because it encodes knowledge that general-purpose training data does not contain.

Normalisation before comparison. Units, tolerances and standards converted to a canonical form at ingestion, so that comparison happens between like and like rather than between two differently expressed versions of the same figure.

Reranking. Retrieve a wide candidate set, then score query and candidate together with a model that reads both. Much of the accuracy in cross-lingual matching is recovered at this stage, because a reranker compares the texts jointly rather than comparing two independently produced vectors.

A confidence level, and the ability to refuse. The output of a matching decision should carry how certain it is and what the decision rested on. A system that returns a ranked list for every query, including the ones where nothing matches, teaches its users to distrust the ranking. A system that says the available data does not support a match is more useful than one that produces a plausible fifth-best option.

Stated reasons. A buyer deciding whether to contact a supplier needs to know why this supplier was proposed — which attributes matched, which did not, and what remains unverified. An unexplained ranking is a recommendation the buyer has to check from scratch, which means the system saved nothing.

Verification is part of the matching problem

Identity is usually treated as a separate concern from matching, handled by a compliance team after a shortlist exists. In B2B sourcing it belongs inside the matching system, for a straightforward reason: an unverified listing contains no reliable information about delivery capability, and a match to a supplier who does not exist as described is worse than no match.

Verified identity also makes the downstream judgements possible. Screening a counterparty against restricted party lists requires knowing who the counterparty actually is. Assessing whether a supplier can deliver at volume requires a real entity with a traceable history. Matching against unverified listings produces a list of claims rather than a set of options.

Profile completeness is the related problem. Suppliers describe themselves sparsely, because filling in a structured profile is work that returns nothing immediately. The practical answer is to construct the profile from material the supplier already has — their website, their catalogues, their existing documentation — into structured attributes with a review step, rather than asking them to type it.

Structuring the demand side

Matching has two inputs, and the buyer's side is usually the weaker one.

A request for quotation arrives as prose, as an attachment, or as a two-line message. It mixes specification with commercial terms and leaves most of the determining attributes unstated, because the buyer assumes context the system does not have.

Reading an RFQ into a structured specification — product, attributes, quantity, destination, timeframe, terms — is a prerequisite for matching rather than a convenience. It also surfaces what is missing. A system that identifies the three attributes required to narrow the field, and asks for them, outperforms one that matches against an underspecified request and returns a long list.

The general principle, as with classification: when a decision depends on facts the input does not supply, the correct output is a question.

Evaluating a matching system

Aggregate match-rate statistics are close to meaningless here, because they are dominated by the easy cases.

Measure in segments. Matching accuracy by language pair, by product category, by whether the parties used the same classification code. Systems that look healthy in aggregate routinely fail badly in one segment, and the segment is usually the cross-lingual one that the system exists to handle.

Measure retrieval separately from ranking. Was the correct supplier in the candidate set at all? If not, no amount of reranking recovers them, and the problem is in retrieval rather than in scoring.

Build the evaluation set from real sourcing cases with known outcomes, judged by someone who knows the trade. And include the negative cases — queries where no supplier in the set can fulfil the request — because correctly returning nothing is a capability that has to be tested or it will not exist.

How we approach it

Hublinkly is a B2B trade network built on verified identity. Companies and people are verified through KYC before they trade, an AI profile builder constructs each member's commercial profile from their own material, and requests for quotation are read into structured specifications rather than passed along as prose. Matching runs against verified parties, and the dashboard carries business intelligence and PESTLE analysis so that a buyer assesses a market and a counterparty in the same place they find them.

Ara is the AI B2B trade engine developed by HublinkTech. It decides whether two descriptions — written in different languages, under different naming conventions and customs codes — refer to the same product or company, and builds trade answers on that decision. The approach uses no translation layer: multilingual embeddings in a shared meaning space, plus a trade ontology built in-house that normalises attributes, units and HS codes, with a confidence level and the option to refuse. Ara runs inside HublinkTech's own platforms first and is designed to be licensed to other organisations as an API. Ara is in development.

The summary for anyone building in this space: supplier matching is not a better search box. It is a resolution problem with a verification problem attached, and the system's most valuable output is often a clear statement that nothing in the available data supports a match.

“a system that treats a code as a reliable join key” → /en/blog/ai-hs-code-classification-why-it-is-hard “Alignment quality across languages varies” → /en/blog/multilingual-retrieval-ai-search-across-languages “Measure retrieval separately from ranking” → /en/blog/evaluating-ai-output-llm-evaluation-methods “Ara” → /ara “Hublinkly” → /platforms/hublinkly