Benchmark Refresh: When and How to Re-run the Comparables Study

Definition

The benchmark refresh is the re-run of the comparables study on current data — the [search string] (/docs/glossary/search-string) re-executed (the same design, the current database), the [screens] (/docs/benchmarking/quantitative-screening) re-applied (the same bounds, the new candidates), the [accept-reject matrix] (/docs/glossary/accept-reject-matrix) re-built (the new decisions, the recorded reasons), and the arm’s length range recomputed on the fresh comparable set. It is the study’s maintenance act — the mechanism by which the contemporaneous documentation stays contemporaneous (the benchmark on the current year’s data, not the prior year’s), and the [Local File] (/docs/glossary/local-file-rule-10d) benchmarking annex carries the refreshed set for the year being documented. The refresh’s standing question is when: the triggers are the data age (the prior study’s comparable data is a year old — the new financial year’s comparables are available, the refresh is the contemporaneous duty), the range position (the tested party’s result sits at or outside the prior range’s edge — the year’s refresh is when the position is re-tested on current comparables, and the timing of the refresh relative to the result is itself a defensibility fact), and the structural change (the tested party’s FAR changed — the new product line, the acquired function — the design changes, not just the data). The record that makes a refresh defensible is the design continuity: the refresh re-runs the documented design (the same string, the same bounds, the same PLI, the same [multi-year rule] (/docs/glossary/multi-year-average)) on the new data — the design stable, the data current — and a refresh that quietly re-tunes the design to change the population is the stability objection in refresh form.

The benchmark refresh, in one cycle:
  1. The trigger (the data age — the new FY comparables are available / the range position / the FAR change)
  2. The re-run (the documented string, the same bounds, the current database)
  3. The new screens (the candidates, the quantitative and qualitative decisions, the matrix re-built)
  4. The new set and range (the comparable set, the IQR, on the current data)
  5. The record (the refresh date, the design-continuity statement, the prior-vs-current comparison)

The element	The content
The trigger	The data age (the new FY’s comparables available — the contemporaneous duty), the range position (the result at/outside the edge — the re-test), the FAR change (the design change)
The design continuity	The documented design re-run (the string, the bounds, the PLI, the multi-year rule — the same) on the current data (the new) — the stable/new distinction stated
The record	The refresh date, the prior-vs-current comparison (the old set vs the new, the old range vs the new — the change explained), the matrix re-built
The timing	The refresh completed before the year’s documentation is final (the contemporaneous discipline) — not after the result is known and uncomfortable

The working read (the benchmarking study guide): the refresh is where the comparability adjustments meet the calendar. The [extraordinary events] (/docs/glossary/extraordinary-events) of the comparables’ new year are re-identified in the refresh’s qualitative screen (the new one-offs, the new handleings); the [working capital] (/docs/glossary/wc-adjustment) ratios are recomputed on the new balance sheets (the WC position is a point-in-time measure — the refresh is when it is re-measured); and the [multi-year averaging] (/docs/glossary/multi-year-average) pool shifts a year (the 3-year window rolls, the averaged PLIs recomputed). The [contemporaneous documentation] (/docs/documentation/contemporaneous-documentation) discipline is the refresh’s deadline driver: the Local File for the year is built on the benchmark for the year — the refresh that lands after the documentation is final (after the result is known) is the timing the examination reads as the refresh aimed at the outcome, and the benchmarking mistakes checklist names the late refresh (as the post-result re-benchmark) as a line item. In Quartyl, the refresh is the re-run of the study’s pipeline on the new data (the screening pipeline re-executed, the comparables grid re-worked) — the design captured on the study, the refresh the new execution, the [audit trails] (/docs/product/audit-trails/audit-trails-overview) carrying the prior-vs-current record.

Example

An Indian distributor: the FY25 Local File was built on the FY24 benchmark (the search run in FY24, the range the FY24 comparables’ IQR). The FY26 cycle:

The step	The FY26 refresh
The trigger	The data age — the FY25 comparables’ annual filings are available; the FY26 documentation must be on the current benchmark
The re-run	The documented FY24 string (the NIC family, the keywords, the size band, the geography — unchanged) re-executed on the FY25 database
The new screens	61 candidates (was 58) → the screens → 20 reviewed (was 22) → 13 accepted (was 14); the matrix re-built — the 2 new rejects (the FY25 one-offs, the extraordinary events handleings), the 1 new accept (the company that entered the band)
The new set and range	The IQR recomputed on the 13 FY25-adjusted values — the range shifted 0.4 pts down (the comparables’ FY25 margins lower — the market, not the design)
The record	The refresh date (before the FY26 documentation final), the prior-vs-current comparison (the set change, the range shift, the design unchanged statement), the tested party’s FY26 result re-tested against the new range

The range shift is the instructive fact: the tested party’s result, comfortably inside the FY24 range, is now at the FY26 range’s lower edge — and the refresh’s timing (on the current data, before the documentation final, the design continuous) is what makes the new position a market fact rather than a search fact. The prior-vs-current comparison in the file is the record the examiner reads: the design stable, the data current, the shift explained.

See also

• Comparability Adjustments Beyond Working Capital
• Extraordinary Events
• Contemporaneous Documentation
• Multi-Year Averaging

FAQ

How often must the benchmark be refreshed? For the contemporaneous documentation, the practical answer is annually — the Local File for each financial year is built on the benchmark for that year (the year’s comparables data, the year’s [multi-year pool] (/docs/benchmarking/multi-year-averaging)), and the annual refresh is the duty that keeps the documentation contemporaneous. A study’s range is not a fixed number carried forward — it is the current comparables’ IQR, recomputed each cycle. The [compliance calendar] (/docs/documentation/india-compliance-calendar) carries the documentation deadline the refresh must land before; the refresh that misses it (the prior-year benchmark documented for the current year) is the contemporaneity gap the penalty question turns on.

Can a refresh change the method or the PLI? A refresh re-runs the documented design — the method and the PLI are part of the design, and changing them in a “refresh” is a new design, not a refresh. Where the FAR genuinely changed (the new function, the acquired business), the correct form is the redesign (the new tested party profile, the new PLI analysis, the [tested party selection] (/docs/benchmarking/tested-party-selection) re-run) documented as a change with the reason — not the silent method/PLI swap inside a refresh. The examination reads the refresh’s design continuity (the same string, bounds, PLI, multi-year rule) as the defensible form; the redesign is defensible as the documented change; the silent swap is the stability objection.

What is the record that makes the refresh defensible? Three things, in the file: (1) the design-continuity statement (the string, the bounds, the PLI, the multi-year rule — unchanged from the prior study, stated); (2) the prior-vs-current comparison (the old set vs the new, the old range vs the new, the change explained — the market moved, the candidates changed, the one-offs handled); and (3) the timing (the refresh date, before the year’s documentation final — the contemporaneous sequence). The audit trails in Quartyl carry the refresh as the study’s re-execution record (the pipeline re-run, the grid re-work, the prior-vs-current) — the three facts, on the record, are the refresh’s defence.