A fast-growing pharmacy chain asked me a deceptively simple question:
"How many products do we actually sell?"
They couldn't answer it.
Online has one product catalog. The 100+ physical stores run another. Every supplier ships data in its own format with its own names. The same paracetamol — same molecule, same strength — exists as a dozen disconnected records, and nothing in the system knows they're the same thing.
Why "paracetamol" is already two products before you start
Begin with the molecule. Acetaminophen (the US Adopted Name) and paracetamol (the WHO International Nonproprietary Name) are two official names for the identical compound, N-acetyl-para-aminophenol. [1] A supplier in one market labels it one way; a supplier in another labels it the other; your catalog now has two products that are the same drug.
Then it fractures further. Each manufacturer, strength, and pack size gets its own NDC. [2] The FDA's NDC Directory currently holds over 4,000 distinct product records whose generic name is simply "acetaminophen" — one ingredient, thousands of identities. [3] Add a brand layer, a pack-size layer, and a different supplier string for each, and "the same paracetamol" really does become a dozen rows.
This is a product-master-data problem, and it's expensive
None of this is unique to pharmacy — it's the well-documented cost of bad product data, just in a domain where the SKUs are drugs. Gartner pegs the average cost of poor data quality at $12.9 million per year per organization. [4] A 2026 GS1 India / Kanvic study found inconsistent and inaccurate product information costs Indian e-commerce roughly ₹5,000 crore a year, including about ₹2,000 crore in margin erosion. [5] And shoppers punish it: in Syndigo's 2025 survey, 75% of consumers think less of a brand over inaccurate online product info, and 44% have abandoned a purchase due to insufficient product information. [6]
The revenue actually walking out the door
Here's where it bites in pharmacy specifically. When a customer searches online and the item's "out of stock," the system can't say "here's the identical drug from another brand, in stock" — because it doesn't know it's identical. That's not a missed feature. That's a sale lost on a channel that's now half the business.
The numbers around stockouts are brutal: out-of-stocks account for roughly $1.2 trillion of global inventory-distortion losses. [7] AlixPartners found 66% of shoppers leave when an item is out of stock, and 34% buy from a different retailer online. [8] Every one of those is a customer you'd have kept if your catalog knew that the in-stock generic on shelf B is the same drug as the out-of-stock brand they searched for. With the online pharmacy market projected to grow from about $112B in 2024 toward $543B by 2033, that gap only widens. [9]
Why this is an entity-resolution problem, not a search problem
Entity resolution is the task of deciding which records — across systems, vocabularies, and owners — refer to the same real-world thing: the same molecule, the same device, the same patient, the same product. It sounds like deduplication. It isn't. Deduplication assumes the duplicates are obvious. Entity resolution is the hard version, where the "same thing" wears a different name, code, and owner in every system it touches, and nothing in your data records that they're connected.
Two properties make it genuinely hard. First, it's quadratic: to know whether any record is a duplicate, you in principle have to compare it against every other record. As Papadakis and colleagues put it in the VLDB literature, entity resolution "typically scales to large volumes of data through blocking… each entity has to be compared with all others in order to find its matches." [ER-1] A thousand records is half a million comparisons; a million records is half a trillion. Double the data and you roughly quadruple the work.
Second, the right answer for one record depends on all the others — entity resolution needs global consistency. Whether record A and record B are the same can hinge on what C, D, and E say. This is exactly where throwing a bigger language model at it disappoints: large models reason locally, one context window at a time. They will confidently link two records that, seen against the whole dataset, obviously shouldn't be — and miss links that only become clear once you hold the full graph in view. The semantic layer that makes messy data usable isn't built by a model guessing one row at a time. It's built by deciding, consistently and across the whole set, that these N records are one thing.
Why scaling makes it worse, not better
Pharmacy retail has the brutal version of this: dirty data multiplied by every store, every supplier, and every new channel. And the reconciliation cost doesn't scale linearly with the business — it scales quadratically. Entity resolution is, in the words of the database literature, inherently quadratic: "each entity has to be compared with all others in order to find its matches." [ER-1] Comparing every pair of records is n(n−1)/2 comparisons — so a thousand records is half a million comparisons, and a million records is half a trillion. Double the catalog and you roughly quadruple the mess. Scale the business 2x and the relationship problem scales 4x.
The chains that win online won't be the ones with the most SKUs. They'll be the ones whose catalog finally knows that twelve records are one drug — so it can answer "how many products do we sell," and tell a customer the in-stock equivalent of an out-of-stock product without a human in the loop.
Retail leaders: can your system tell a customer the in-stock equivalent of an out-of-stock product? If not — that's the gap.