Your Customer List Is Not
a Directory: Entity Resolution
for Business Data

Before you can collect any attribute about a customer, you have to match each record to a real place. We look at what a billing list contains, where map pins land, why a string-matching rule fails, and how a model reads the evidence instead. The numbers and the cases come from the same working prototype as the first article.

The first article in this series covered business data enrichment from street-level, satellite, and web imagery, with service bays as the worked example. This one covers the step before any of that: matching each record in a customer list to the real place it describes. That step quietly decides whether the rest is worth running. The third and last article returns to the cameras: what Street View and satellite imagery can show about a business once each record points to the right building.

It sounds like a lookup. It is not. A customer list is a billing system’s view of the world, and a map is a cartographer’s. The two disagree far more often than anyone expects. When they disagree and nobody notices, every later layer collects honest evidence about the wrong building, and the answer can come back wrong with high confidence. That is the worst failure a data pipeline can have because a wrong match can go unnoticed and spread into every result built on it. Below is what we learned from matching a sample of about a hundred small automotive customers of a parts distributor to the map and the open web.

Key Takeaways

• Customer names and addresses are not reliable identifiers on their own. Billing names carry route codes and payment terms, and one address in ten in our sample was a PO box.
• Geocoding finds coordinates, not necessarily the correct business. A pin can land on a courthouse, a cell tower, or the center of a ZIP code.
• Deterministic normalization belongs in code, before any model-based matching: strip the codes and terms, normalize the address, and flag PO boxes and mobile services.
• A strong entity resolution workflow needs several search paths and confidence-based escalation, so the strongest model reads only the records where the first answer is in doubt.
• Matching should return more than yes or no. Moved businesses, missing listings, and conflicting evidence each need their own verdict, and shared buildings need a note that the later steps must follow.
• Business classification should happen before expensive data enrichment or measurement. Four records in ten in our sample had no service bays to count.

What Is Entity Resolution?

Entity resolution is the process of determining whether records from different systems refer to the same real-world entity when they do not share a reliable unique identifier. The Splink documentation describes the same task, also called record linkage, as linking records from datasets without unique identifiers. For business entity resolution, the chain runs from a CRM or ERP record to a map listing, then to a website, and finally to a physical location. A billing list and a map share no identifier, so the pipeline has to infer every link in that chain from evidence.

Also Read: GTIN Product Matching in Web Scraping

What a billing list actually contains

A record in a CRM or an ERP exists for invoices, delivery routes, and payment terms, not for finding a building. In our sample, the names carried route numbers in front, store numbers behind, and payment terms as a suffix. The trade name on the sign often differed from the legal name on the invoice. One address in ten was a PO box, which no camera has ever photographed. Several customers were mobile mechanics who work out of a van and get their bills at home. A few were not businesses at all: city governments, a school district, and a hospital that buy parts for their own vehicles. The list also ages without telling anyone. According to survival data from the U.S. Bureau of Labor Statistics, 47.2% of the U.S. private-sector establishments that opened in the year ending March 2021 were still operating in March 2026. A closed customer stays on a billing list until someone removes it.

The patterns below are real; the names, codes, and numbers are invented.

What Customer Names Reveal Before Entity Matching

Before the pipeline pays for a single map query, a handful of rules on the cleaned name and address predict a surprising amount about what the search will find. We grouped the records by what their names looked like and compared each group with what the pipeline finally established about it.

The remaining share of each group was not on the map at all:

In our sample, the pipeline found chains and dealers every time, most likely because they maintain their listings. It never confirmed a PO box at the billing address because there is no building there. It found more than half of those records at another address, and the rest existed only on the web. A mobile service almost never had a map listing at all. These tables are the first thing that tells the pipeline where to look and how hard, before the expensive steps begin.

Why Map Pins and Geocoded Locations Can Be Wrong

The next trap is subtler. Even when the pipeline finds a listing, its pin is a hypothesis, not a fact. In our sample, the pin landed on a county courthouse and on a cell-tower compound beside a highway. Other pins fell on the geographic center of a ZIP code and on a residential street some fifteen kilometers from the billing address.

Three pins landed on three wrong buildings. Left: a listing with no street address gets a pin at the town center, which happens to be the courthouse. Middle: a listing found at another address has its pin on a cell-tower compound by the highway. Right: the geocoder could not resolve a rural road, so the pin fell on the center of the ZIP code, downtown. Every frame collected at these points is honest evidence about the wrong place. Satellite imagery © Google, Airbus, Maxar Technologies, CNES.

Each of these has a mundane cause. A listing without a street address, which is common for home-based and mobile businesses, gets the center of its town. A geocoder that cannot resolve an address falls back to the center of the postal code. The Geocoding API documentation describes a location type on every result. ROOFTOP marks a point precise to the street address, GEOMETRIC_CENTER marks the center of a street or a region, and APPROXIMATE covers anything looser. A “service-area” listing hides its real address and shows a pin somewhere in its service area. Google Business Profile Help tells businesses that do not serve customers at their address to remove it. None of this is an error on the map’s side. It only becomes an error when a pipeline treats the pin as a building.

In our prototype, the measurement step caught these four cases late. The model that reads the pictures saw a courthouse or a cornfield where a shop should have been and said so. That is the safety net working, but it is the expensive way to find out. The identity step had already recorded the source of each location: seven in ten came from a chosen listing, and three in ten from the address pin alone. Both groups produced wrong pins, and three of the four cases above came from chosen listings. The lesson we took is to check the pin itself, not its origin. Record its distance from the billing address, and flag any pin at a known town or ZIP center before the pipeline fetches a single picture.

Entity Resolution Pipeline: Step by Step

The steps below turn customer data matching from a lookup into a sequence of decisions. Code handles the first step, map searches handle the second, and models handle the rest.

Clean and Normalize the Customer Record

The cleanup belongs in code, not in a model. It is deterministic customer data cleansing, the kind of rule-based work that data engineering solutions are built for. The rules strip route codes and payment terms, normalize the address, and flag PO boxes and the word “mobile.” This step costs nothing, and it changes what every search returns.

Stripping a field from the search is not the same as deleting it.

“Every field in a billing record was put there for a reason that has nothing to do with location. Route codes and payment terms do not belong in the search string, but they still belong on the record, because a route number or a cash-only term says something about who the customer is.” — Alex Yudin, Head of Data Engineering at GroupBWT

Search the Name and Address Multiple Ways

We run three map searches per record rather than one: the cleaned name with the full address, the name with the city only, and the address alone. A record that carried coordinates would add a fourth input; ours did not. The searches overlap on purpose. The name with the city can find a business that has moved, and the address alone shows who else occupies the building. Map search still misses some businesses, and a fifth of our sample existed only on the web. For those records, the evidence comes from the web searches that the escalation step can order. This is the kind of open-web collection that our web scraping services handle at scale.

Compare Candidate Businesses

A model, not a string-matching rule, then reads everything that came back: every candidate with its name, address, category, rating, review count, website, and phone.

We started with string matching, the obvious first attempt, and it taught us why customer record matching needs a model. Its first version confirmed a record on a strong name match in the same city. Under that rule, the matcher confirmed a liquor store for an auto shop and a wood company for a motors business because the names shared a word. A version that required only the address and the business category silently accepted ten other businesses that happened to sit at the customer’s address. The rule that survived required the name and the address to agree, and it was right about almost everything it confirmed. What it could not do was reach the rest. A quarter of the real matches were records it could not place by design. They included PO boxes, businesses that had moved, listings with hidden addresses, and a few shops whose signs abbreviate or rebrand the name on the invoice.

This is what changed when a model replaced the rule. The rule’s confirmations held up, and the model gained the records a string rule cannot place at all. The rule’s first casualty had been a liquor store.

So the model’s instructions carry those lessons in plain words. Do not confirm on one shared generic word such as Auto, Garage, Tire, or Express. A business with the same name in another city is not a match. A liquor store or a trucking company does not become an auto shop because the name rhymes.

Escalate Ambiguous Matches

A cheaper model reads the candidates first and gives a verdict with a confidence. Anything short of a confident confirmation goes to the strongest model for an independent second opinion, with up to two follow-up web searches. The strongest model’s decision is final. In our sample, the pipeline escalated about half the records. Most of those needed a follow-up search, and the second opinion overturned the first in about one escalated case in ten.

This is the identity step. A cheaper model gives the first verdict; anything short of a confident confirmation goes to the strongest model, which may order two more web searches and whose decision is final.

Which model reads which records is an architecture decision, the kind we settle in AI consulting work before a pipeline like this runs at scale. Where the escalation line sits decides how much the identity step costs.

“Escalation should be triggered by doubt, not by difficulty. A cheap model that is confidently right closes half the list for a fraction of the cost, and the expensive model only earns its price on records where the first answer could be wrong in a way nobody would see.” — Dmytro Naumenko, CTO at GroupBWT

A 2026 study on labeling entity-matching training data with language models reached a related saving by a different route. Large models matched records well without task-specific training data, but they were slow and costly across large sets of candidate pairs. The authors trained compact matchers on pairs the large models had labeled. Those matchers competed with much larger models on most tasks and cut inference time by a factor of 34 to 459. The study does not test an escalation cascade like ours; it shows another way to keep the most expensive model away from most of the work.

Return a Match Verdict and Confidence

Whichever model decides, the record leaves the identity step with one of five verdicts, each with a confidence and a short note that the later layers read before they start. The next section shows the five verdicts, their shares in our sample, and what each one triggers.

Classify the Business Before Enrichment

Before the pipeline fetches any imagery, the same step also gives each record a business type based on the evidence it has already read. This is the cheapest point to learn that a customer is a city fleet, a mobile mechanic, or a used-car lot, none of which has service bays to count.

Five verdicts, not a yes or a no

A match is not binary, and each of the five verdicts changes what the later layers do.

The note is the part that pays for itself. For a county government billed at a PO box, the identity step wrote that the listing was an administrative office and that a road department elsewhere probably used the parts. The note told the measurement step to count no bays at the office. For a quick lube in a shared building, the identity step noted the neighbor in the adjacent suite. The measurement step turned that note into a rule: the neighbor’s space does not count. The later layers inherit these notes as constraints, not as suggestions.

Shared buildings

One record in ten in our sample sat in a shared building or a strip mall. The address usually gives the first hint in the form of a suite or unit number, but not always. The imagery never gives that hint on its own: a row of doors looks the same no matter who rents them.

Left: several suites share one roof. The quick lube occupies the end with the three drive-through bays. An independent garage rents the next suite, and its doors do not count. Right: the road face of this lot is a parts store, not the customer, who most likely occupies the rear units. The identity step flagged both lots as shared and named the neighbors; the street-level frames at the measurement step added what stands on the road face. Satellite imagery © Google, Airbus, Maxar Technologies.

The rule is simple to state and easy to break: a neighbor’s doors never count toward your record. Making it hold takes three things. The identity step flags the building as shared and names the other tenants it can see. The measurement step gets written instructions on which part of the building belongs to the customer. Finally, the estimate repeats the caveat so that a reviewer sees it next to the number.

Classify before you measure

The biggest surprise in the sample was not a matching failure. It was how much of a real customer base falls outside the bay count altogether.

This is what a parts distributor’s customer base turned out to be once the pipeline had identified and measured every record. The identity step alone had already placed nine records in ten in a type; the imagery settled the rest. Four records in ten have no service bays to count.

Four records in ten were fleets and institutions, non-automotive businesses, mobile mechanics, or used-car lots. They are genuine customers who buy parts for their own vehicles or for resale, and the question “how many bays” is meaningless for all of them. Next to the repair shops, we found two city governments, a county board, a school district, a hospital, and a post office. The list also included a state forestry commission, a locksmith, an appliance repairer, a crop consultancy, an aircraft de-icing contractor, and a portable-toilet rental company.

These two customers are not shops. Left: this city government, billed at a PO box, has the city hall as its listing and services its vehicles somewhere else entirely. Right: this mail-processing plant has no bay doors on any face a camera can see. Counting doors on either building answers a question nobody asked. Imagery © Google; satellite imagery © Airbus, Maxar Technologies. Signage is pixelated.

The right response is to segment first and measure second, with a different metric per segment. Size a municipal fleet by its vehicle count, not by the doors on the town hall. A used-car lot has a reconditioning area at most. A mobile mechanic has no building, so it needs a different measure or none at all. Dealers and chains usually publish their own locations. Only the independent shops, the tire and body shops, the truck repairers, and the quick lubes need the imagery pipeline at all, and they make up six records in ten.

The split pays off before the first image arrives.

“A city fleet garage and a four-bay independent shop can buy the same parts for very different reasons. Once the base is split by type, the visit plan, the offer, and even who makes the call can follow the segment, and none of that waits for a single door to be counted.” — Oleg Boyko, CCO at GroupBWT

How to Validate Entity Resolution Accuracy

A verdict is useful only if it is right often enough to trust. We propose five checks before a pipeline like this runs on a full customer base, each aimed at a failure the prototype produced. All five compare the pipeline’s verdicts with a sample of records that a person has matched by hand.

False Matches

A false match confirms the wrong business, and it looks like success. The string rule’s liquor store and wood company were false matches, and so were the ten businesses it accepted only because they sat at the customer’s address. To find them, a reviewer should check every confirmation where the names share only a generic word, or where the listing category does not fit the customer’s trade.

Missed Matches

A missed match is a real listing that the pipeline never found, so the record ends up as “Exists, not on the map” or “Not found.” The string rule missed records like these by design. The check we propose is to search a sample of records with those two verdicts by hand. Each listing found that way points to a search path the pipeline lacks, such as a trade name, a former address, or a web source that web scraping services can add to the collection.

Wrong-Location Matches

A pipeline can match a record to the right business and still measure it at the wrong place, which is the blind spot of business location matching. The guard is the pin check described above: the distance from the billing address and a flag for town and ZIP centers. Validation measures whether that guard works: how many of the pins it flags are truly wrong, and how many wrong pins it lets through. In our prototype, all four wrong pins reached the measurement step, which is the cost an earlier check should remove.

Confidence Calibration

Every verdict carries a confidence, and the confidence is useful only if it means what it says. The check is to group the hand-matched sample by the confidence the pipeline gave and compare how often each group was right. High-confidence verdicts should be right far more often than low-confidence ones. If they are not, the escalation line sits in the wrong place, and that line decides what the identity step costs. The rate at which the second opinion overturns the first is worth tracking whenever the line moves.

Human Review of Ambiguous Records

Some records need a human decision, not only a model’s. “Another business at the address” means the customer may have closed or moved, and the pipeline measures nothing until a person has looked. Shared buildings and conflicting customer records belong in the same review queue. Verdict and confidence should decide which records join the queue, so confident records stay out of it and the work stays small. The same idea carries over to entity resolution inside one company, where the problem is duplicate customer records rather than a map. In a Customer 360 project for a European bank, GroupBWT built matching in which high-confidence matches merge automatically and low-confidence ones go to a data steward.

Why Entity Resolution Comes Before Data Enrichment

Identification is not a preprocessing step. It is where most of the risk in an enrichment project sits because its errors can go unnoticed and spread into every result that follows. A billing list serves invoices, a map pin is a hypothesis, and a name is a weak key. The pipeline treats each of them as what it is. It cleans the record in code, searches several ways, lets a model read the evidence, returns one of five verdicts instead of a yes or a no, and classifies the base before measuring it. Together, these steps turn a customer list into a base that CRM data enrichment can build on. The attribute you came for is the second thing you get. The first is a classified base with a verdict, a resolved location, and a note on every record. That is business identity resolution in practice: knowing who your customers are and where they work.

FAQ

Why not just geocode the address?

A geocoder returns a point, not a business. It cannot tell you that the address is a PO box, that the shop moved, that another business occupies the building now, or that the point it returned is the center of the town. The identity step answers those questions, and the geocoded point is only one of its inputs.

Can a string-matching rule do the job on its own?

It can handle part of the list, but not all of it. The rule that required the name and the address to agree was right about almost everything it confirmed. Still, a quarter of the real matches were records it could not place by design: PO boxes, businesses that had moved, hidden addresses, and signs that abbreviate or rebrand the name on the invoice. A model that reads every candidate reaches those records.

How many records need the stronger model?

In our sample, about half of the records did. The pipeline escalated anything short of a confident first verdict. Most escalated records needed a follow-up web search, and the second opinion changed the verdict in about one escalated case in ten. A confident confirmation from the cheaper model is final.

What do we need in the list for this to work well?

Name and address are enough to start. Coordinates, phone numbers, and store codes improve matching, and a customer type field, even a rough one, lets the pipeline route records before searching. Suite and unit numbers matter more than they seem: they are the first sign of a shared building.

Can a wrong match still get through?

Yes, and the design assumes it. Every verdict carries a confidence, and the measurement step checks the signage in the imagery against the name. The final estimate repeats every identity caveat next to the number, so a reviewer sees it in seconds. In our prototype, that is how the measurement step caught the four wrong pins.