Tested Party Selection: The "Less Complex" Principle, Applied

The tested party is the entity whose profit level gets compared against the pool — which means it is the entity whose functions, assets and risks the study treats as routine. Choose it wrong and the method, the PLI and the range are all built on the wrong foundation, and the failure is invisible in the arithmetic. This is the first substantive decision in a TNMM study, and the one a Transfer Pricing Officer re-litigates before anything else.

The rule: benchmark the least complex

The OECD’s position (Ch. 3, paras 3.4–3.5) is that a tested party should be the entity for which the most complete and reliable data exists and whose functions and risks are the least complex — so that the one-sided comparison has the best chance of being meaningful. The practical content of that rule:

• Do not benchmark the party that owns the unique or valuable intangibles.
• Do not benchmark the party that controls the key risks.
• Do not benchmark the party whose data is the thin one, “because it is easier”, if the other party is cleaner and comparable.

Indian practice follows the same logic, and the TPO tests it directly: the typical opening question in a transfer pricing examination is “why is this the tested party, and where is the analysis that says so?”

The six-question test

Run each question for each candidate entity. The tested party is the one that comes out least-complex on this set:

#	Question	Points toward being the tested party	Points away
1	Functions	Narrow, specified, service-level scope; execution against a contract	Broad discretion; end-to-end P&L ownership
2	Assets	Tangible assets; no valuable intangibles; no unique data assets	Owns patents, brands, customer relationships, proprietary processes
3	Risks	Fixed or bounded risks (price, volume, input cost passed through)	Controls pricing, bears inventory or demand risk, has uncapped upside
4	Intangibles & DEMPE	No development, enhancement, maintenance, protection or exploitation role	Performs or controls DEMPE functions — see routine vs entrepreneurial
5	Data	Clean financials, the PLI denominator available, audited	Missing segments, unexplained mix, no reliable cost data
6	Uniqueness	A pool of standalone companies with the same profile actually exists	“Unicorn” profile — if no comparables exist, the party is not benchmarkable at all

Question 6 is the check that kills the other five: a party that passes as “least complex” but has no comparable pool is not a tested party — it is a sign that the method needs to change (usually to a two-sided approach).

Documenting the selection

The Local File should contain a side-by-side FAR comparison of the candidate entities, with the six questions answered per entity, and a conclusion that reads like a decision record:

1. The candidates — the two (or more) parties in the controlled transaction, each with a one-paragraph FAR summary.
2. The comparison — the table above, filled in with the facts.
3. The considered-and-set-aside pattern — “Entity B was considered as the tested party and set aside because it performs the DEMPE functions for the group’s X intangible and controls Y risk; Entity A was selected because…”
4. The consequence — which PLI follows from the selection, and why that PLI isolates the routine contribution of the chosen party.

A selection documented this way turns the TPO’s first question into a page reference. A selection that is merely asserted (“we benchmarked the service provider”) turns it into a fight.

Common TPO objections, and what causes them

Objection	What actually happened	How the record prevents it
“You benchmarked the wrong entity”	The more complex party was chosen because its data was cleaner, or because last year’s study did it	The six-question comparison, answered this year with current facts
“Your tested party is not as routine as you say”	The FAR section of the file understates functions (a hidden pricing role, a shared risk)	The FAR drawn from the actual contracts, not the study’s needs
“The tested party changed but the study didn’t”	A reorganisation or new business line moved functions; the study was rolled forward	Re-scoping triggered by the change — the study is void, not stale
“Your pool contains the tested party’s real competitors”	The selection was made against a pool that does not match the chosen party’s actual profile	Pool criteria derived from the tested party’s FAR, not from what the database offers

When there is no routine party

If both parties are entrepreneurial — both carry unique intangibles, or both control key risks — there is no tested party to select. The honest output is a method change, typically to a profit split, documented with the DEMPE and risk-control analysis that shows why one-sided testing fails. See how to choose a method for the decision framework; the tested-party decision and the method decision are the same decision seen from two sides.

FAQ

Is the tested party always the lower-margin entity? No. The test is complexity and comparability, not the level of the margin. A higher-margin entity with a narrow, specified, contract-based role is a fine tested party; a low-margin entity that happens to own the group’s core IP is not.

Can the tested party change between years? Yes — when the facts change (reorganisation, new product, changed risk allocation). The change must be identified, the FAR re-drawn, and the selection re-made and re-documented. Silent roll-forward across a structural change is one of the fastest routes to a full recomputation by the TPO.

Does the tested party have to be the taxpayer itself? No. Indian practice allows benchmarking the foreign related party where the data is better and the party is the less complex one; the analysis (and the reason for the cross-border selection) must be in the file.