Benchmark Search Design: NIC/NACE Codes, Size and Industry Filters

A benchmark search is a set of filters applied to a candidate population, and the quality of the pool is decided before any company is examined: by the code, the string and the size bounds. A search that is too broad produces a pool of false comparables that no amount of qualitative review can rescue — the function is different at the root. A search that is too narrow produces a pool of three companies, and a pool of three is a pattern, not a distribution.

The industry code is the load-bearing filter

For Indian comparables the classification is NIC-2008 — the National Industrial Classification at 5-digit granularity (1,297 codes). The code does three jobs the free-text industry label cannot:

1. It is the common language between the database, the filing and the Local File. “Software development” as a label means different things in different databases; NIC 62011 (computer programming activities) means one thing.
2. It supports the hierarchy. The 5-digit code sits under 4-digit, 3-digit and 2-digit groupings, so a thin pool at 5-digit can be widened stepwise and documented — from 62011 to 6201 (computer programming) to 62 (computer programming, consultancy and related activities) — with each widening a stated, examinable decision.
3. It maps to the tested party’s own filing. The tested party’s registered/declared activity gives the anchor code; the pool is built around it.

For non-Indian comparables the equivalent is NACE (2-digit for the search, finer levels where the source supports it), with the NIC↔NACE correspondence documented in the file.

The NIC code for the tested party is the first decision in the study. Use the NIC code finder to pin the 5-digit code against the actual function — not the registered business activity, which often describes the entity’s history rather than its current function:

The search string

The string is the free-text net cast over business descriptions, product lines and revenue sources. It works with the code, not instead of it:

• Code first, string second. The code sets the population; the string narrows it to the function (“cloud platform development”, “KPO — research and analysis services”).
• Positive and negative terms. Include the function words; exclude the adjacent-but-different words (for a contract developer: exclude “product software”, “SaaS”, “gaming” — companies that develop their own product are not comparable to a contract developer, whatever the code says).
• Revenue-mix evidence, not the name. A company named “XYZ Technologies” can be 90% product revenue; a company with a generic name can be a pure contract shop. The string is the first look; the segment and related-party disclosures are the decision.

The size screen

Size enters as a proxy for risk-bearing and scale economics: revenue, total assets, and where available employee count. The discipline:

Bound	Purpose
Not too small	Micro-comparables carry disproportionate single-customer and single-asset risk; their margins are not the market’s routine margins
Not too large	Mega-comparables carry scale economies (and diversified portfolios) the tested party does not have
Order of magnitude	Practice: keep comparables within roughly one order of magnitude of the tested party on the relevant proxy, and say so

The size screen is a quantitative filter — it removes companies before the qualitative review, and every removal is logged. A size gap that survives to the qualitative stage (one comparable at 10× the tested party’s revenue) is either accepted with a documented reason or adjusted — not silently included.

The over-inclusion and under-inclusion traps

Over-inclusion (the pool is too broad):

• The code is used at the wrong level (2-digit “manufacturing” for a specialized chemical producer).
• The string omits the negative terms, so product companies sit in a contract pool.
• No size screen, or a screen so wide it removed nothing.
• The segment check is skipped: consolidated financials of a conglomerate enter the pool as if they were the segment’s.

The symptom: a wide, noisy range where the tested party is “comfortably inside” — comfort that evaporates when the TPO rebuilds the pool on the function.

Under-inclusion (the pool is too narrow):

• The 5-digit code is applied with no documented widening, and the industry is genuinely thin (specialty services, niche products).
• The string is over-specific (three keywords that only the tested party’s own description matches).
• The size bounds are set at the tested party’s exact scale.

The symptom: a pool of 2–4 companies. The fix is the documented, stepwise widening (code level, string terms, size band) with the comparability reasoning at each step — a thin pool that is explained is defensible; a thin pool that is accidental is not.

The search design, documented

The Local File carries the search as a decision record:

1. The tested party’s NIC/NACE code and the basis for it (function, not registration).
2. The string — positive and negative terms.
3. The size bounds and the proxy.
4. The candidate count at each stage: population → code → string → size → quantitative thresholds → qualitative screen → final pool.
5. Each widening or tightening, with the reason.

That record is what turns the pool from a result into a method — and it is the first exhibit the TPO requests, because it is where over-inclusion and under-inclusion show up. See quantitative screening for the threshold stage that follows the search, and defending the Accept-Reject matrix for how the record performs in examination.