A company manufactures medical devices, sells monitoring software, runs a clinical consulting team, and operates a direct-to-consumer store for replacement parts. The CRM wants one business vertical. Marketing wants segment filters. Compliance wants the regulated industry. Sales wants comparable accounts.
The dropdown has four choices that all look defensible: manufacturing, healthcare, technology, retail. Picking one makes the record easier to store and worse to use.
Business vertical classification categories work cleanly in aggregate reporting. NAICS, SIC, GICS, NACE, ANZSIC, and similar systems were built to make populations of companies analyzable. Operational systems ask a harsher question: what should this specific company unlock, route to, benchmark against, comply with, or be compared to?
That is where the taxonomy starts leaking.
The Primary Vertical Problem
A single primary_vertical field looks harmless in the first schema, the same way many master data models look clean before production edge cases arrive.
class Company:
def __init__(self, name, primary_vertical):
self.name = name
self.primary_vertical = primary_vertical
medtech_company = Company("MedTech Inc", "MANUFACTURING")Now healthcare searches miss the company. Technology searches miss it. Retail analysis misses its direct sales channel. The record is valid and incomplete.
Adding multiple verticals fixes the omission and creates a new problem.
class Company:
def __init__(self, name, verticals):
self.name = name
self.verticals = verticals
medtech_company = Company("MedTech Inc", [
"MANUFACTURING",
"HEALTHCARE_SERVICES",
"TECHNOLOGY",
"RETAIL"
])The company now appears in every vertical. Segment metrics inflate. Vertical filters include businesses that only partly belong. A taxonomy that was too narrow becomes too broad.
Production systems usually need weight, source, and purpose. Manufacturing may be 55% of revenue. Technology may be 60% of workforce. Healthcare may drive regulatory exposure. Retail may matter only for channel analysis.
Boundaries Depend on the Question
A grocery store with an in-store pharmacy can be retail for merchandising and healthcare for compliance. A bank with investment advisory services can be banking, wealth management, or financial services depending on the report. A software company that earns half its revenue from implementation consulting sits between technology and professional services.
Revenue, headcount, assets, licensing, customer base, and operating model can all point to different classifications.
SELECT company_id,
CASE
WHEN healthcare_revenue > software_revenue
AND healthcare_revenue > manufacturing_revenue
THEN 'HEALTHCARE'
WHEN software_revenue > manufacturing_revenue
THEN 'TECHNOLOGY'
ELSE 'MANUFACTURING'
END as primary_vertical
FROM company_revenue;The same company can classify as healthcare by revenue, technology by workforce, manufacturing by assets, and healthcare again by license. None of those answers is fake. Each is answering a different operational question.
A single vertical field hides the question that produced it.
Classifications Age Badly
Businesses move faster than taxonomies. Amazon started as online retail, then added cloud computing, streaming media, logistics, advertising, hardware, and healthcare. Netflix moved from DVD rental to streaming media to content production. Tesla is automotive until the analysis cares about energy storage.
Static classifications preserve an old version of the company.
company_verticals = {
'amazon': 'RETAIL',
'netflix': 'DVD_RENTAL',
'tesla': 'AUTOMOTIVE'
}Historical classification may be correct for historical analysis and wrong for current segmentation. Updating the value fixes current queries and breaks old trend analysis.
A more honest model stores time, because sequence and history carry meaning once downstream systems rely on them.
company_vertical_history = [
{'company': 'netflix', 'vertical': 'DVD_RENTAL', 'valid_from': '1999-01-01', 'valid_to': '2007-12-31'},
{'company': 'netflix', 'vertical': 'STREAMING_MEDIA', 'valid_from': '2008-01-01', 'valid_to': '2012-12-31'},
{'company': 'netflix', 'vertical': 'CONTENT_PRODUCTION', 'valid_from': '2013-01-01', 'valid_to': None}
]The model is harder to query because the business reality is harder to query. Trend lines now have to decide whether to follow the company, the vertical, or the classification system that changed underneath both.
Regulatory, Operational, and Analytical Labels Diverge
A fintech company may be regulated as financial services and operated like a technology company. Compliance needs PCI DSS, GLBA, FFIEC, FINRA, or similar obligations. Hiring and delivery need cloud infrastructure, DevOps, product engineering, and agile workflows.
def get_compliance_requirements(company):
if company.regulatory_vertical == 'FINANCIAL_SERVICES':
return ['SOC2_TYPE2', 'PCI_DSS', 'FFIEC_AUDIT', 'GLBA_COMPLIANCE']
def get_operational_processes(company):
if company.operational_vertical == 'TECHNOLOGY':
return ['AGILE_DEVELOPMENT', 'CONTINUOUS_DEPLOYMENT', 'CLOUD_INFRASTRUCTURE']Vendor categorization, benchmarking, market sizing, hiring analysis, and compliance may all need different vertical answers for the same company. The record needs context, not just category.
Hierarchies Miss Cross-Cutting Businesses
Hierarchical taxonomies make navigation easier and cross-cutting analysis harder.
A healthcare software company can sit under technology/software or healthcare/technology. Both placements are reasonable. Both make some queries wrong.
TECHNOLOGY
SOFTWARE
ENTERPRISE_SOFTWARE
Healthcare_Software
HEALTHCARE
PROVIDERS
PAYERS
PHARMACEUTICALS
TECHNOLOGY
Healthcare_SoftwareA query for all healthcare businesses misses medical device manufacturers under manufacturing, health insurance under financial services, and healthcare software under technology. A query for all technology companies has the opposite problem.
The hierarchy encodes one path through the business. Real companies often need several paths.
Geography Adds Another Translation Layer
International classification introduces approximate mappings. NAICS in North America does not line up perfectly with NACE in Europe, ANZSIC in Australia/New Zealand, or ISIC internationally.
classification_mappings = {
'NAICS_541511': {
'NACE': '62.01',
'ANZSIC': 'M6921',
'ISIC': '6201'
}
}The mapping is useful. It is not identity, and treating approximate mappings as exact is one way data strategy fails in production. Aggregation levels differ. Some subcategories exist in one system and disappear in another. Edge cases move when the jurisdiction changes.
Global analysis has to choose between imperfect mappings, manual reclassification, or coarse categories that lose specificity.
What the Schema Becomes
The naive schema starts as an enum.
CREATE TABLE companies (
company_id UUID PRIMARY KEY,
name VARCHAR(255),
vertical VARCHAR(50)
);The production schema usually grows into provenance, time, weight, and system context.
CREATE TABLE company_verticals (
company_id UUID REFERENCES companies(company_id),
vertical_code VARCHAR(50),
classification_system VARCHAR(50),
percentage_of_revenue DECIMAL(5,2),
valid_from DATE,
valid_to DATE,
source VARCHAR(100),
confidence_score DECIMAL(3,2)
);Then even simple questions need policy.
SELECT DISTINCT c.company_id, c.name
FROM companies c
JOIN company_verticals cv ON c.company_id = cv.company_id
WHERE cv.vertical_code IN ('HEALTHCARE', 'MEDICAL_DEVICES', 'PHARMACEUTICALS')
AND cv.valid_to IS NULL
AND cv.percentage_of_revenue > 25
AND cv.classification_system = 'NAICS';The 25% threshold is a business decision disguised as a query predicate. Companies near the threshold appear or disappear because revenue moved, not because the company suddenly changed identity.
Feature Access Should Not Depend on One Vertical
Vertical classification often gets reused for product behavior: healthcare modules, financial services controls, retail inventory features.
def get_available_features(company):
features = ['CORE_PLATFORM']
if company.primary_vertical == 'HEALTHCARE':
features.extend(['HIPAA_COMPLIANCE', 'CLINICAL_WORKFLOWS'])
elif company.primary_vertical == 'FINANCIAL_SERVICES':
features.extend(['AML_MONITORING', 'TRADING_COMPLIANCE'])
elif company.primary_vertical == 'RETAIL':
features.extend(['INVENTORY_OPTIMIZATION', 'POS_INTEGRATION'])
return featuresThe medtech retailer needs healthcare compliance and inventory optimization. The single vertical grants one and hides the other. At that point feature selection should be based on attributes, contracts, regulatory exposure, and enabled modules, not the broad industry label. Otherwise the taxonomy becomes a strategy database by accident: a piece of data that quietly controls product behavior.
Attribute Models Are Messier and More Useful
Attribute-based classification keeps the facts separate.
class BusinessAttributes:
def __init__(self, company_id):
self.company_id = company_id
self.attributes = {
'regulated_as': ['FINANCIAL_SERVICES', 'HEALTHCARE'],
'primary_revenue_sources': ['SOFTWARE_LICENSING', 'PROFESSIONAL_SERVICES'],
'asset_types': ['INTELLECTUAL_PROPERTY', 'REAL_ESTATE'],
'workforce_composition': ['ENGINEERS', 'HEALTHCARE_PROFESSIONALS'],
'customer_verticals': ['HOSPITALS', 'INSURANCE_COMPANIES'],
'geographic_markets': ['NORTH_AMERICA', 'EMEA']
}The system no longer has to declare “this is a healthcare company” for every use case. It can ask for companies regulated as healthcare, selling to hospitals, employing healthcare professionals, or earning meaningful healthcare revenue.
That trades dropdown simplicity for query flexibility. For operational systems, the trade is often worth it.
Business vertical classification categories are useful when ambiguity washes out at scale: statistical reporting, market research, portfolio allocation, initial segmentation. They break when used as precise routing logic for individual companies.
The durable design is to store classification as approximate, temporal, sourced, weighted, and contextual. Anything cleaner is usually clean because it has thrown away the part of the business someone later needs.
Where Industry Taxonomies Actually Work
Despite their limitations, industry classification systems solve real problems extremely well.
National statistical agencies use them to measure economic activity. Investors use them to compare companies within similar markets. Researchers use them to analyze employment, productivity, and industry trends across thousands or millions of businesses.
At that scale, small classification errors rarely change the overall picture. The objective is consistency across large populations rather than perfect representation of every individual company.
Operational software has a different goal. It needs classifications that drive routing, permissions, workflows, compliance, pricing, and feature availability for a single business. That is where broad industry taxonomies begin to break down.
Large Datasets Often Need Probabilistic Classification
Assigning industries manually works for hundreds of companies. It becomes impractical for millions.
Many commercial data providers instead combine multiple signals, including company descriptions, websites, products, regulatory filings, revenue sources, and historical classifications, to estimate the most likely industry.
Rather than producing a single definitive answer, these systems often assign confidence scores or ranked candidates.
Healthcare 0.82
Medical Devices 0.74
Manufacturing 0.68
Software 0.51Human reviewers may validate high-value records, while lower-confidence classifications remain subject to review as new information becomes available.
This shifts the problem from storing “the correct vertical” to managing uncertainty explicitly, a familiar boundary when deterministic systems start consuming probabilistic outputs.
Official Classification Systems
The classification systems mentioned throughout this article each serve different administrative or analytical purposes.
| System | Primary Purpose |
|---|---|
| NAICS | Industry classification for businesses in the United States, Canada, and Mexico. |
| SIC | Older industry classification system still used by some organizations and historical datasets. |
| NACE | Statistical classification of economic activities within the European Union. |
| ANZSIC | Industry classification standard used in Australia and New Zealand. |
| ISIC | United Nations international framework used to map industries across countries. |
| GICS | Global industry classification used primarily by investment managers and financial markets. |
Although these systems often describe similar industries, they were created for different purposes and do not map perfectly between one another.
Single Vertical
Company
│
▼
primary_vertical = HEALTHCARE
│
▼
Routing, reporting, permissions,
benchmarking, compliance
One answer for every question
──────────────────────────────────────────────
Attribute-Based Model
Company
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Regulated As Revenue Sources Customers
│ │ │
Healthcare Software Hospitals
▼ ▼ ▼
Feature flags Reporting Compliance
Different questions use different attributes.References
The classification standards discussed in this article are maintained by their respective organizations:
- NAICS - U.S. Census Bureau
- SIC - U.S. Occupational Safety and Health Administration search for the 1987 Standard Industrial Classification manual
- NACE - Eurostat
- ANZSIC - Australian Bureau of Statistics
- ISIC - United Nations Statistics Division
- GICS - MSCI and S&P Dow Jones Indices
These standards define consistent industry taxonomies for statistical and analytical purposes. The challenge discussed in this article is not that the standards are incorrect, but that operational software often needs richer, context-dependent models than a single industry classification can provide.
