Setting Up the Tested Party Profile (FAR, Functions, Assets, Risks)

The tested party is the entity the study benchmarks — the company whose transfer pricing is being tested against a population of comparables. Everything a benchmarking study claims, it claims about this entity, and the profile the wizard captures is the record that claim rests on: who the entity is, what it does, and the functional analysis that characterizes it. Set up the profile accurately and the search, the screening and the report all work from a defensible base; get it thin and every downstream step inherits the gap.

What the profile is, and what it is not

The profile is two things at once:

• The identity of the benchmark. The entity name, the jurisdiction the study complies with, the financial year, the function selection and the product-or-service flag. This is what reviewers see in lists and queues and what the report states up front.
• The functional input to the screening. What the entity does — its nature of business, its function type, whether the transaction is a product or a service — is the reference the pipeline screens the comparables against, and the reference the report engine uses to check that the chosen method and PLI fit the function.

What it is not: it is not where the FAR characterization is typed in. The functional analysis — functions performed, assets employed, risks borne — is derived from the profile and the run, never free text pasted into a field. The pipeline’s screening steps produce the characterization against each comparable, and the report engine’s decision engine derives the tested party’s characterization from that affinity, deterministically. A characterization that did not come from the recorded data is a characterization the record cannot defend; the product is built so that cannot happen.

The profile fields

Captured across steps one and two of the configuration wizard:

Field	Step	What it records
Entity Name	1 (Info & Upload)	The legal name of the entity under study — the tested party itself
Financial Year	1 (Info & Upload)	The period the benchmarking data covers
Tax Jurisdiction	2 (Context)	The compliance context of the study — the ruleset the study is designed to
Product / Service	2 (Context)	Which side of the transaction is being tested; it also selects the function list the next field draws from
Function Type	2 (Context)	The functions the entity performs, multi-select and required — the structured input the FAR affinity scoring reads
Nature of Business	2 (Context)	What the entity does, in prose — required, with a 30-character minimum, because it is the text the qualitative screening reads
Screening scope	2 (Context)	Optional: product scope, channel, accepted and excluded business models, geographies, IP ownership, RPT profile, exclusion criteria, materiality note

There is deliberately no industry-classification field on the study. The classification data lives in the comparables file — the dump’s industry, NACE and national-classification columns — and is scored per company, not declared once for the tested party. Together the fields above are the profile: identity, function, and the narrative the screening reads.

How the FAR characterization is derived

The functional analysis is the lens the screening applies, in three passes:

1. The qualitative screening compares each candidate comparable’s business description against the tested party’s profile. The comparison runs on embeddings generated locally in the worker — no external service is called and no language model is consulted — and the semantic match is what separates a genuine comparable from a same-industry non-comparable. Companies with no usable description cannot be matched at all, so they are flagged for human review rather than silently dropped or kept.
2. The AI screening (FAR analysis) reads each candidate’s functions, assets and risks against the tested party’s profile and records the reasoning per company, quoting the description text it relied on. Where the tenant’s plan carries it, a second, deeper FAR pass runs after this one against a different model family and fails closed — a company it cannot assess stays flagged rather than accepted. This is the pass that produces the characterization the report cites.
3. The decision engine — at report time — derives the tested party’s characterization from the recorded FAR affinity: the function profile, the asset intensity, the risk profile. The derivation is rule-based and deterministic: the same record always produces the same characterization, and the method and PLI fit is checked against it.

The net effect: the profile is the input, the characterization is the derived output, and the derivation is on the record. The functional analysis reference has the FAR model itself; the tested party definition has why this entity is the one being benchmarked.

How the profile drives the run

Profile element	Drives
Nature of Business	The qualitative screening’s semantic match, and the PLI matching at report time
Function Type / product-vs-service	The function characterization the decision engine derives, the method-PLI fit check, and the function boost in the semantic screen
Jurisdiction	The compliance context — the rules the study’s conclusions are stated under — and the arm’s-length range convention
Financial Year	The period of the data, and the clock the multi-year choice binds to

One thing the profile does not do is choose the pool. The comparable population is exactly the companies in the file you upload: the screening never filters rows out by country or by industry code. The dump’s classification columns (industry, NACE Rev. 2, the national primary code) travel with each company as metadata and carry a small industry-match component in the semantic screen — they narrow who matches, not who is eligible. The jurisdiction sets the range convention: where the platform carries a curated rule for it, that rule applies; elsewhere the OECD interquartile default does. It does not delete comparables.

The search parameters — the PLI, the size filters, the percentiles — are configured in the parameters step and are stored on the study alongside the profile; together they are the complete record of what the run did. The method-level logic for choosing between the PLIs, given the function, is in How to Choose a Method.

Getting the profile right

• Write the nature of business as the screening will read it. The field has a 30-character floor for a reason: one sentence that says what the entity does, with its role (distributor, service provider, manufacturer), is worth five adjectives. The qualitative screening matches candidates against this text; vague text matches everything and the screen does less work.
• Keep the functions and the description telling the same story. A function selection that contradicts the narrative — “Sales and Distribution” against a description of contract manufacturing — is a flag the reviewer will find at the grid, not at the draft.
• The tested party margin is set in the parameters step, not here — it is the position the range is measured against, and it belongs with the other benchmarking parameters.

FAQ

Is the profile editable after the run? The fields stay editable on any study that has not been archived. Editing them is not the same as re-running: the pipeline can only be dispatched again while the study is in Draft, Study Initialized, Rejected or Failed, so a profile corrected at review changes the record without recomputing the range until the study is sent back and re-screened. Once a study is archived it is immutable, and a corrected profile means a new study.

Do I need a complete FAR statement to create a study? No. The profile fields the wizard captures are the inputs — identity, a nature-of-business description, the function selection and the product-or-service flag. The FAR characterization itself is derived by the pipeline from those inputs and the screening record; that is the design, and it is why a pasted-in FAR paragraph is not a field.

Why is the jurisdiction a profile field and not a parameter? It is both, in effect: it is the compliance context of the study (the profile) and it is recorded in the parameters block that drives the run. The wizard surfaces it in the context step because it is part of what the tested party is for this study.