Business location data begins with the right record grain.

Reliable business location data keeps the legal organization, customer-facing brand, physical site, source listing, and dated observation as separate records. Combining them into one “business row” makes a directory look simple, but it hides which source made which claim, whether two listings describe the same place, and whether an address is legal, postal, or operational.

Three boundaries prevent most of the expensive mistakes:

• A source listing is not a physical location.
• An address is not a stable ID.
• Not observed does not mean closed.

Treat every current directory view as a projection over evidence and matching decisions. Then a user can ask for open sites, organizations registered in a region, a brand's store network, or recently changed listings without silently mixing those concepts.

Business location data: the short answer

Build the dataset in this order:

1. Name the decision, geography, location types, and time window the data must support.
2. Define separate grains for organization, brand, physical site, source listing, and observation.
3. Register each source with its scope, field authority, access basis, expected cadence, and known limits.
4. Issue internal IDs that do not depend on names, URLs, addresses, or coordinates.
5. Retain source-native identifiers and values before normalization.
6. Generate match candidates, record the evidence, and preserve accepted, rejected, ambiguous, and unreviewed states.
7. Parse addresses into components without deleting the source representation or its meaning.
8. Store geocodes as provider-generated assertions with precision, method, coordinate reference, and time.
9. Map source categories through versioned crosswalks instead of replacing them.
10. Build lifecycle states from dated observations and explicit evidence, not from one disappearance.
11. Resolve conflicts separately for each field and use case.
12. Measure collection, extraction, identity, address, geocode, lifecycle, and delivery quality with visible denominators.
13. Publish versioned snapshots and deltas while retaining the evidence needed to reconstruct them.
14. Review licenses, terms, privacy, security, retention, and attribution before collection begins.

This guide owns the informational design problem: how to model and operate a business-location dataset. If the need is a maintained collection rather than an internal build, use the public business directory data service. For the delivery layer—manifests, atomic publication, replay, and recovery—continue with the custom data feed guide.

Start with the decision and geography

“Build a database of businesses” is a subject, not a specification. A site-selection team may need operating locations with precise coordinates and opening evidence. A supplier-screening team may need legal organizations and registered offices. A local-search product may need customer-facing names, categories, service areas, hours, and listing provenance. Those datasets overlap, but they are not interchangeable.

Write a decision contract before choosing sources:

Define geography with codes and boundary versions, not only labels. “Portland” is ambiguous; postal areas, municipalities, counties, metropolitan areas, and sales territories have different boundaries. Store the source country and administrative components, the normalized codes used by the project, and the boundary or taxonomy version behind derived regions. A point-in-polygon assignment should be repeatable when boundaries change.

Define what “located in” means too. It might mean a legal address, headquarters, mailing address, staffed operating site, customer entrance, warehouse, service area, or delivery coverage. If the decision requires a visitable place, a registered office alone is insufficient. The UK Companies House endpoint, for example, returns the company's current registered office address. That is useful registry evidence, but its endpoint and field semantics do not establish that the address is a customer-facing operating site.

Finally, make time part of the contract. A current directory, a historical location panel, and a change feed require different retention. “Current” should mean current under a documented acceptance rule as of a publication time, not “whatever the last successful run happened to return.”

Separate organizations, brands, sites, and listings

The data model should represent five related grains:

• Organization: a legal or administrative entity. Its identifiers and status belong to a jurisdiction and issuer.
• Brand: a customer-facing identity that may be owned, licensed, franchised, or operated by one or more organizations.
• Physical site: a real-world place or bounded service location used for a defined purpose.
• Source listing: one source's representation of an organization, brand, or site, with a source-scoped key and URL or endpoint.
• Observation: what that listing or source showed at one time, including the payload or evidence reference and collection method.

The US Census Bureau's 2022 NAICS manual gives this distinction a useful statistical frame: an establishment is generally one physical location, an enterprise can contain multiple establishments, and more than one establishment can occupy the same physical location. That definition is not a universal directory schema, but it demonstrates why “company” and “place” cannot share one unqualified row grain.

Add relationships instead of squeezing all five into one row. An organization can own a brand. A brand can be displayed at many sites. A franchisee can operate a branded site. Several listings can describe one site, while one source record can occasionally represent a campus or service area rather than one point. Store relationship type, role, validity interval, source evidence, and review state.

Schema.org makes the address boundary explicit: legalAddress is the registered legal or tax address and can differ from the place where business takes place. The same vocabulary defines branchCode as a parent-assigned identifier for a place of business. These are useful semantics, but neither field should become the internal site key unless its scope and stability are proven for the project.

A minimal relational design can start here:

Keep addresses and coordinates in assertion tables if a place can have several concurrent claims. A location might have a postal address, entrance address, centroid, rooftop point, and source-provided pin. A single mutable address column discards that distinction and makes correction history difficult to reconstruct.

Build a source register before collecting rows

A source register is an operating contract, not a bookmarks file. For every source, record:

• source ID, owner, canonical entry point, source type, geography, language, and subject grain;
• approved access method, authentication, rate policy, terms or license, attribution, and review date;
• which fields it directly asserts and which questions it cannot answer;
• source-native identifiers, address semantics, category scheme, and time semantics;
• expected record universe or partitions, cadence, normal quiet periods, and freshness target;
• capture type, parser or mapping version, raw-evidence retention, and known limitations;
• personal-data posture, security classification, escalation owner, and active, paused, or retired state.

Use each source within its stated scope:

• A company registry can support legal identity, registration status, and registered addresses within its jurisdiction. It usually does not prove storefront status.
• A brand-controlled locator can be strong evidence that the brand presents a site as part of its network. It may not identify the legal operator.
• A map or directory listing can provide a source's claim about a place, category, hours, or contact route. It is evidence from that source, not independent proof of every field.
• A postal reference can support component rules or deliverability-related normalization. It does not prove business occupancy.
• A geocoder produces a derived spatial claim from an input and its own reference data.
• A classification standard supplies category definitions; it does not prove that a specific establishment belongs in a category.

The Global Legal Entity Identifier Foundation's Level 1 LEI data format covers “who is who” fields including legal name, legal address, headquarters address, entity status, events, and registration status. Its definitions are a useful warning against overreach: a registration status of LAPSED means the registration was not renewed, not that the entity is known to have ceased. Preserve that source status rather than translating it into “closed.”

Google's Business Profile API has a different boundary. Its location-data documentation describes locations associated with an authenticated account, including those directly owned or managed by the account. That is an account-management interface, not evidence that the API is a general public directory of every business. Record access scope alongside the fields so downstream users do not mistake a partial authorized universe for market coverage.

Source authority belongs at field level. A registry may be preferred for legal name, a brand locator for customer-facing hours, and a postal authority for formatting rules. There is rarely one globally “best” source. Store the source role on each assertion or in a versioned resolution policy.

Retain raw evidence where permitted and proportionate. At minimum keep the source reference, source-native key, observed time, response status, media type, content hash, and collector or parser version. A hash demonstrates that two byte sequences match; it does not prove that the contents are complete, true, current, or lawfully reusable.

Design stable identifiers and match states

Issue opaque internal IDs for organizations, brands, locations, listings, and observations. These IDs should survive a rename, URL migration, corrected address, new map pin, change of operator, or source retirement. An address is not a stable ID. Addresses are reused, reformatted, subdivided, consolidated, and sometimes published incorrectly. Coordinates also move when a provider improves a geocode or when a complex gains a more precise entrance point.

Store external identifiers as scoped aliases:

• the identifier value;
• identifier scheme and issuer;
• subject type and source;
• jurisdiction or account scope;
• valid-from and valid-to times when known;
• observation or document that supplied it;
• verification and review state.

A company number can identify a legal entity in one registry. A store code may identify a branch within one brand or account. A map place ID belongs to a provider. A listing URL may be replaced. These are valuable matching features, but their scopes must remain attached.

Provider identifiers also have lifecycles. Google's Place ID guidance says one place can have multiple IDs and that an ID can change or become obsolete. Keep the provider namespace, observation time, replacement or redirect state, and matching evidence; do not promote a convenient external key into a permanent universal location ID.

Generate candidates before deciding matches. Useful features can include exact scoped identifiers, normalized organization and brand names, domains, phone numbers where appropriate, address components, spatial distance, site type, and parent-child relationships. Hard conflicts—different verified registry IDs, incompatible country codes, or evidence that the records are distinct co-located businesses—should outweigh fuzzy similarity.

Use explicit match states:

1. Accepted: evidence meets the rule for the stated use case.
2. Rejected: evidence or a hard conflict supports separate subjects.
3. Ambiguous: plausible evidence exists, but it does not support a safe decision.
4. Unreviewed: a candidate exists but has not passed a rule or human review.

Store the feature values, rule or model version, score components if used, threshold, outcome, reason codes, and reviewer. A single similarity score is not provenance. Nor is one threshold universally safe: false merges are especially damaging because they combine observations from different places and can fabricate moves, closures, and ownership changes.

NIST's 2026 entity-resolution discussion treats matching as a process involving cleaning, labeling, feature extraction, and evaluation. Follow that discipline with a representative labeled set. Measure precision and recall separately by geography, script, category, source pair, and difficult cases such as malls, shared offices, franchises, and near-duplicate brand names. Do not tune and report on the same examples.

Identity can change without a location changing. A rebrand may keep the site and operator. An acquisition may change the legal operator while preserving the brand. A relocation may close one site and open another even if a source reuses its store code. Keep those as typed, dated relationship or lifecycle decisions rather than overwriting the current row.

Normalize addresses without overwriting source evidence

An address pipeline should create layers, not a replacement string:

1. Source value: exact text or structured components as observed, with language and source semantics.
2. Parsed value: components extracted under a named parser and version.
3. Normalized value: project or postal conventions applied to eligible components.
4. Resolved address: a reviewed or policy-selected assertion for a specific use case.
5. Display value: presentation formatting generated for a locale or consumer.

Keep legal, headquarters, mailing, billing, entrance, delivery, operating, and service-area addresses distinct. “Headquarters” is an organizational role; “store entrance” is a physical access point. A PO box can be a valid mailing address and still be unsuitable for mapping an operating site.

Do not erase punctuation, unit designators, local scripts, or source ordering before retaining the original. Normalize Unicode and whitespace carefully; parse components with country-aware rules; preserve house-number suffixes, building names, floors, units, and locality variants. Transliteration can aid search, but it should be an additional alias with method and language metadata, not a replacement for the native-script value.

The US Postal Service's Publication 28 defines postal-addressing standards for United States mail. It can guide component abbreviations and output conventions within that scope. A postal-standardized string does not prove that a business occupies the address, that the address is public-facing, or that two records describe the same site.

Model validation outcomes precisely:

• syntactically parsed;
• components meet country-specific rules;
• locality or postal code reconciled to a reference;
• deliverability claim supplied by a named provider;
• exact, building, street, locality, or unresolved geocode;
• conflicting or incomplete;
• not applicable, such as a pure service area.

Avoid one boolean called valid_address. It hides which test ran, under which reference version, and what “valid” meant. Record the input assertion, method, reference version, time, output, and reason code for every derived validation.

For deduplication, address similarity is evidence, not identity. Two tenants can share a building, several storefronts can share a postal complex, and one site can have multiple entrances or unit strings. Combine the address with scoped IDs, brand and organization relationships, contact or domain evidence where appropriate, and spatial context.

Treat geocoding as a derived claim

A coordinate is the output of a method applied to an address, place name, source pin, parcel, or geometry. Store it as a versioned assertion:

• input address or listing assertion;
• provider, dataset, endpoint, and method version;
• request and result times;
• longitude, latitude, altitude if meaningful, and coordinate reference system;
• match type and precision, such as rooftop, entrance, parcel, interpolated street, postal area, or locality;
• provider confidence or quality code in its native semantics;
• normalized provider result and any differences from the input;
• license, attribution, redistribution constraints, and review outcome.

Do not translate every provider score into a universal probability. Scores and precision labels have provider-specific definitions. Keep the native code, then map it through a documented project policy if consumers need a common tier.

Coordinate order must be explicit. RFC 7946 defines GeoJSON positions as longitude then latitude using WGS 84. Many business tools display latitude first. Name columns longitude and latitude, validate ranges, declare the coordinate reference system for non-GeoJSON data, and test round trips through every delivery format.

Spatial validation should reflect the decision:

• Is the point in the expected country and administrative area?
• Does it fall near the supplied street or postal region?
• Is it a building, entrance, parcel centroid, road interpolation, or broad-area centroid?
• Do several supposed sites share an implausible generic centroid?
• Does a source pin disagree materially with a geocoded address?

Flag conflicts rather than snapping silently. A brand locator pin may mark the customer entrance while an address geocoder returns a parcel centroid; both can be legitimate for different uses. Keep geometries and their roles separate.

Reverse geocoding is also derived. A point-in-boundary result depends on a boundary dataset and version. Store the derived district or territory with the geometry version, operation, and time so historical assignments can be rebuilt after boundary updates.

Map categories with versioned crosswalks

Source categories answer source-specific questions. A directory label, brand taxonomy, regulator classification, and statistical industry code may differ in granularity, purpose, and update cycle. Preserve the native category ID and label before mapping.

The North American Industry Classification System is the standard used by United States federal statistical agencies to classify business establishments for statistical purposes. It is a useful controlled vocabulary in that context, not a universal replacement for every source's categories or proof of how a location currently operates.

A crosswalk needs:

• source taxonomy, category ID, label, language, and source version;
• target taxonomy, category ID, label, and target version;
• mapping relation: exact, narrower, broader, related, or unmapped;
• applicability conditions such as country, site type, or business function;
• method, evidence, confidence or review state, author, and effective interval.

Do not force a many-to-many category into one “best” label without preserving the alternatives. A supermarket can contain a pharmacy, café, parcel counter, and fuel station. Those might be departments, co-located businesses, or separate sites depending on the source and decision contract.

Separate organization industry from site function. A legal entity's primary industry does not automatically describe every warehouse, office, store, clinic, or manufacturing site it operates. Category assertions should name their subject grain and source.

Version the crosswalk and publish its coverage. When a source adds categories or the target standard changes, unmapped rows should enter a review queue rather than inheriting a misleading parent by default. Backfills must record whether history was reclassified under the new map or retained under the map active at observation time.

Model location lifecycle with observations

A location's lifecycle is a conclusion built from evidence over time. Keep the underlying observations and represent current status as a reviewable projection.

Useful states can include:

• candidate: discovered but not yet matched or admitted;
• observed active: a qualified source currently presents the site as operating under the project rule;
• temporarily unavailable: evidence indicates a temporary interruption;
• stale: the last accepted evidence is older than the field- or source-specific target;
• possibly inactive: repeated expected observations are absent or conflicting, but closure is not confirmed;
• confirmed closed: an approved source or reviewed evidence supports closure;
• relocated: evidence links a closing site to a distinct new site;
• merged duplicate: two internal records were resolved as one site;
• reopened: accepted evidence follows a prior closure or inactive state.

Not observed does not mean closed. A listing can disappear because of an outage, access change, pagination defect, search-ranking change, source redesign, temporary suppression, or collector failure. Record “not observed in this accepted run” and apply a source-specific absence policy. Require successful coverage of the relevant source partition before absence can contribute to a lifecycle decision.

Keep separate clocks:

• source_effective_at: when the source says a change applies;
• source_published_at: when the source published or revised it;
• observed_at: when the collector retrieved the evidence;
• processed_at: when parsing or matching completed;
• decision_at: when a rule or reviewer accepted the lifecycle state;
• published_at: when the dataset exposed the result.

Only observed and processed times are normally under the pipeline's control. If the source does not supply an effective or publication time, leave it unknown. “First observed” is not the same as “opened,” and “last observed” is not the same as “closed.”

Make transitions append-only. Each transition should reference the prior state, candidate state, evidence observations, rule or policy version, reason codes, and review decision. The current location table can cache the latest accepted state, but it should be rebuildable from retained history.

Model relocations carefully. Similar name, phone, or source code at a new address can generate a candidate relationship; it does not by itself prove that one physical site moved. Preserve the old and new location_id values and create a reviewed relocated_to relationship when the evidence supports it.

Resolve conflicts by field, not source

Two credible sources can disagree because they describe different grains, times, or meanings. Do not assign one master source for an entire record. Resolve legal name, display name, operating status, hours, address role, coordinates, category, and contact fields independently.

Use three layers:

1. Source assertions: immutable claims tied to observations.
2. Resolution decisions: rules or reviews that select, combine, defer, or reject claims for a named use case.
3. Published views: replaceable projections built from accepted decisions.

A resolution policy should specify field, subject grain, geography, source roles, recency rule, hard conflicts, comparison method, tie behavior, and policy version. “Newest wins” is unsafe when timestamps have different meanings or a weak secondary source republishes stale data more recently.

Preserve unresolved conflicts. A consumer may prefer two attributed values over one invented value. Expose a conflict state, candidate values, source roles, observation times, and review status. High-impact conflicts—identity, closure, legal operator, or precise site position—can block publication while lower-impact fields remain available.

Corrections need their own provenance. If a parser assigned the street number incorrectly, supersede the derived assertion and retain the old one with a correction reason. The source did not change. If the source itself revised an address, create a new observation and change record. Those histories answer different questions.

Missingness also needs reason codes:

• field is not applicable;
• source does not publish it;
• expected source partition was not collected;
• extraction or validation failed;
• value was withheld, removed, or restricted;
• match or review remains unresolved;
• value is genuinely unknown.

One null cannot drive the right recovery or disclosure. The competitive intelligence database guide applies the same evidence-first separation to broader market signals; the location model here specializes it for place identity, address semantics, geocoding, categories, and lifecycle.

Measure quality at each boundary

Quality is fitness for the decision contract, not the number of non-null cells. Measure the boundaries where an error can enter or become consequential:

Always publish the numerator, denominator, window, exclusions, and segmentation. “Addresses are complete” is meaningless unless the reader knows whether service-area listings were excluded and whether completeness means source-presence, successful parsing, or postal validation.

Use representative gold sets for matching, categories, geocodes, and lifecycle transitions. Sample across countries, scripts, rural and dense urban areas, co-located businesses, franchises, campuses, units, brands with similar names, and sources with different semantics. Report support counts; a perfect result on a tiny easy slice does not establish production quality.

Distinguish precision from recall. High match precision protects against merging different sites; recall shows how many true cross-source links remain separate. For closures, precision limits false “closed” labels while recall measures how many independently confirmed closures the pipeline detects. Set thresholds around the harm of each error and route uncertain cases accordingly.

Monitor distributions, not only pass rates. Sudden shifts in record counts, null reasons, category maps, coordinate precision, centroid reuse, match scores, stale ages, or review backlog can reveal a source or parser change before a consumer reports it.

The web-scraping data-quality framework covers completeness, validity, duplicates, freshness, fidelity, and release gates in more depth. The monitoring runbook covers schedules, incidents, and recovery. Apply those controls to each registered source, then add the identity, spatial, taxonomy, and lifecycle tests specific to business locations.

Publish snapshots, deltas, and evidence

Consumers usually need convenient current records, but operators need history. Publish both through an explicit contract:

• a snapshot containing the accepted current projection as of a named cutoff;
• a delta containing stable change IDs, operation type, prior and new version references, and publication time;
• an evidence index linking each published assertion or transition to source observations where access rules permit;
• a manifest with dataset ID, release ID, schema and policy versions, coverage window, files, row counts, byte counts, hashes, and quality status.

Use deterministic keys and ordering so retries are idempotent. Publish files to temporary or versioned paths, validate them, write the manifest, and only then update the pointer that declares the release current. Never let a consumer read half of a multi-file release as if it were complete.

State change semantics clearly:

• Is a missing row in a full snapshot a deletion, an exclusion, or an incident?
• Does an update replace the whole record or only named fields?
• Are address, coordinate, category, and lifecycle histories delivered separately?
• Can a correction restate an earlier effective interval?
• How are merged IDs, split sites, and redirects represented?
• How long can consumers replay deltas, and how do they recover a missed release?

Prefer tombstones and redirect records to silent disappearance. If two duplicate location IDs are merged, retain both historical IDs and point the retired ID to the survivor with decision provenance. If one record is split into two sites, do not reuse the old ID for whichever child happens to be processed first.

The W3C PROV overview models provenance through entities, activities, and agents so users can assess quality, reliability, and trustworthiness. A business-location feed can apply that discipline without adopting the full vocabulary: identify the source evidence, the extraction or normalization activity, and the software or reviewer responsible for the result.

Document known limitations in the release, not only in a distant data dictionary. Name the covered geographies, source universe, excluded site types, field freshness rules, match and status policies, and known degraded sources. A directory represents the defined sources and acceptance rules; it should not be described as a complete census unless an authoritative universe and measurement support that claim.

Limit contact data and respect source rights

Public visibility does not by itself create permission to collect, combine, republish, or retain every field. Review the precise sources, methods, licenses or terms, jurisdictions, purposes, recipients, and retention with qualified counsel where needed.

Minimum controls include:

1. document the decision purpose and lawful, approved source access;
2. collect organization and location fields needed for that purpose, not everything visible;
3. distinguish business contact points from personal data and restrict sensitive fields;
4. record license, attribution, database-rights, contractual, and redistribution conditions by source and field;
5. do not bypass access controls or misrepresent identity or authorization;
6. limit raw evidence access and encrypt data in transit and at rest;
7. log administrative review, correction, and export actions;
8. define retention and deletion for raw captures, identifiers, contact data, and derived assertions;
9. provide a correction, suppression, and challenge process with evidence;
10. re-review the program when its source, purpose, geography, field set, model, or recipient changes.

Open data still has conditions. OpenStreetMap states that its data is available under the Open Data Commons Open Database License, with attribution and share-alike requirements described on its copyright page. Check the current license and the way a proposed product uses or derives from the database; “open” is not the same as “no obligations.”

Personal data can appear in small-business, sole-trader, professional, contact, or review records. The UK Information Commissioner's Office summarizes principles including purpose limitation, data minimization, accuracy, storage limitation, and security in its guide to data-protection principles. Even where another regime applies, these are useful engineering prompts: can the purpose be met without the field, is its source and status clear, who can access it, and when will it be deleted?

Separate sourced facts from inference. A category predicted by a model, a likely headquarters, or a closure score should be labeled as derived, with inputs, method version, uncertainty, and review state. Do not let an inference become indistinguishable from a registry or brand assertion.

WebTruffle's responsible data and security principles describe the boundary used for managed work. This section is an operating checklist, not legal advice.

Business location data checklist

Before production, confirm all of the following:

• [ ] The decision, geography, location types, coverage universe, freshness needs, and exclusions are documented.
• [ ] Organization, brand, physical site, source listing, observation, relationship, and decision grains are separate.
• [ ] Legal, headquarters, mailing, operating, entrance, and service-area addresses are not conflated.
• [ ] Internal IDs survive name, URL, address, coordinate, operator, and source changes.
• [ ] Source-scoped identifiers retain their issuer, scope, valid interval, and evidence.
• [ ] Accepted, rejected, ambiguous, and unreviewed match states are preserved.
• [ ] Match precision and recall are measured on representative labeled examples with support counts.
• [ ] Source-native address values survive parsing, normalization, display formatting, and correction.
• [ ] Geocodes retain their input, provider, method, precision, coordinate order, reference system, and license.
• [ ] Native categories survive versioned crosswalks, and organization industry is separate from site function.
• [ ] “Not observed,” “stale,” “possibly inactive,” and “confirmed closed” are distinct lifecycle states.
• [ ] Every absence decision requires successful coverage of the relevant expected source scope.
• [ ] Source, effective, observed, processed, decision, and publication times are not substituted for one another.
• [ ] Conflicts are resolved per field and use case; unresolved values remain attributed.
• [ ] Corrections to derived data do not masquerade as changes in the source.
• [ ] Quality metrics publish numerators, denominators, windows, exclusions, and relevant segments.
• [ ] Current views can be rebuilt from retained observations and resolution decisions.
• [ ] Snapshots, deltas, manifests, tombstones, redirects, and replay behavior are documented.
• [ ] Source rights, privacy, security, attribution, retention, and correction controls have approved owners.
• [ ] A consumer can trace a location, status, category, address, or coordinate to its exact evidence and transformation path.

Frequently asked questions