Where a transfer pricing database stops being enough

A transfer pricing database gives you a comparable set, a range and the names behind it, and for most Indian studies that output starts the work. It cannot answer the question a Transfer Pricing Officer puts to the file: whether the information and data behind that range are reliable and correct.

Section 92C(3)(c) allows the Assessing Officer to redetermine the arm's length price where the "information or data used in computation" is "not reliable or correct". Read those words for what they attack. The input is the figures and the search that produced them.

Benchmarking season ends with someone signing a study they may have inherited from a colleague or a consultant who has since moved on. Most assessments test the record behind the percentile: which database, which vintage, what date, which filters in what order, and why each rejected company was rejected.

This note covers what a downloaded set can carry into an assessment, where Indian coverage thins, and the search record we keep so that a later reader can defend the position. Where an inherited set is already under challenge, our team can read the record with you before the reply goes out.

• Section 92C(3)(c) lets the Assessing Officer redetermine the price where the data used is unreliable or incorrect, so the source and its vintage sit in issue beside the margin.

• The Karnataka High Court held in SAP Labs India Private Limited v ITO that selection and exclusion of comparables must conform to section 92C and Rule 10B.

• It upheld a Rs 200 crore upper turnover filter as rational, and held that the ±5% variation under section 92C is a tolerance which cannot do the work of an adjustment.

• A search that cannot be repeated from the file reads as if the comparables were chosen backwards from the range.

What a downloaded comparable set can and cannot prove

A search output carries two claims, and both are modest. It says that someone searched a named database on a stated date, and what that search returned once the filters were applied. Both can be checked by repeating the search.

The claims the same output cannot carry are the ones a study is judged on. Whether the companies in the set perform the same functions as the tested party belongs to whoever read the profiles and weighed the differences. The margin is not established as arm's length either: the most appropriate method under section 92C(1) has to be chosen for the nature of the transaction and the functions performed, and the database is silent on both.

Section 92C(3)(c) turns on the same point from the other direction. Where the officer forms the opinion that the data is unreliable, he may determine the price himself on the material he holds, and the section requires a show-cause notice before he does. That notice is when the record is read. By then the history is either in the file or absent from it.

The difference is clearest where the tested party is unusual. A contract manufacturer with one customer, a distributor carrying a global brand, a service company whose staff are seconded from the parent: each needs exclusions and adjustments that the raw output cannot make. Those judgments are what the file has to hold.

What an Indian database covers, and where its data thins

Indian comparable data is assembled from the filings a company lodges. That one fact explains both the strength of the data and the thin patch inside it. Where a company files full statements with segment notes and a related-party schedule, a database can carry enough for a comparability judgment. Where it files a balance sheet, a profit and loss account and little else, the database carries those and stops.

Listed companies sit in the first group, where continuous disclosure and an audit give the figures a date and a signatory. Unlisted and private companies are the harder reading. Segment revenue may be filed as one line for the whole company, so the division performing the tested function disappears, and related-party disclosures may record that transactions took place without amounts you can test.

Year-ends vary, so a twelve-month period closing in March is compared with one closing in December, and a currency movement or a demand cycle lands unevenly on the two. Policies that no database normalises reach it as reported: capital structure, depreciation, the split between traded goods and own manufacture. Reading ten profiles end to end tells you more about comparability than any filter count will.

A benchmarking database does one thing better than a manual exercise. It holds the filed numbers for companies in a form you can screen, and it will produce the same screen again next year. Treat that as the floor.

Ask whoever ran the search four things: the vintage of the data and its load date, where the margin came from in the filing, how many of the comparables are unlisted and how many of those carry audited figures, and what the last rejection said. That last answer usually separates a recorded search from a reconstructed one.

A database result is not an audited set

The word set carries more weight in a benchmarking file than the output supports. The search returns a list of companies that passed a filter, with figures attached to each name. An audited set is a different object: every entry has been read, explained, and either kept or dropped, with the reason on file. The person who signs the study can defend any line of it on the day it is questioned.

Filings are restated, so the same company can appear with two sets of numbers depending on the version loaded and when. Allocations and transfer prices inside a filing reach the database as the company reported them.

Judgment is the part no filter field captures. A company with a brand, a licence or a bargaining position the tested party does not have will show a margin that reflects those advantages. Our note on excluding high-brand-value entities from the comparables sets out how the Delhi High Court excluded two such entities from the set. A database can apply the exclusion once you tell it to, and it cannot tell you that the exclusion is needed.

The difference appears at the signature. A set assembled from a download, with the filters and rejections visible, can be defended by the person who signs it, and a colleague can pick it up next year. A set that arrived as a finished table has to be reconstructed for the file, and the reconstruction is always weaker.

How to record the search so that it can be defended

The record we keep is deliberately dull, and it takes an hour on the day of the search. It follows the order the work happens in. The Karnataka High Court's ruling of September 2026 in SAP Labs India Private Limited v ITO gives the reason to bother: selection and exclusion "must conform to Section 92C and Rule 10B" in TaxGuru's summary of it. The same summary records that the court upheld a Rs 200 crore upper turnover filter as rational.

1. Name the database, the vintage and the download date. The product, the edition or load date, the year of the statements covered, and the day the output was taken. Done looks like a line a stranger could use to order the same version. The common mistake is naming the product alone.

2. List each filter in the order applied, with the count left after it. Turnover, employee cost, related-party percentage, loss-making years, segment availability. Suppose a set falls from ninety companies to twenty-four across four filters: the counts make that a method, and the same filters without counts make it a preference.

3. Log every rejection and every acceptance with its reason. For a rejection, separate the ones a filter made from those you made after reading the profile, because the second kind carries the comparability judgment. For an acceptance, record the functions, assets and risks that make the company usable, the profit level indicator applied, and any adjustment made and why. A line that says accepted and nothing else turns a defensible set into an assertion.

4. Keep the raw output untouched beside the worked file. The download as it came, plus the working copy with the log, exported on the day. Regenerating the raw file a year later loses the one thing that made it evidence.

We keep this record on every set we build, and we ask for it first when we review a set assembled elsewhere. Our comparable company benchmarking work begins with the search log. The same history is what your transfer pricing documentation has to carry. Our note on the transfer pricing study report sets out where it lands, and it costs less to write now than to reconstruct under a notice.

The three things a Transfer Pricing Officer asks about the source

The questions settle into the same shapes, and each has an answer that a good record makes short.

Which database, and which vintage of it? The officer is testing reliability under section 92C(3)(c), so the answer names the product, the load date and the year of the statements. The same ruling accepted that later data can support inclusion or exclusion of a comparable where the statute allows it (TaxGuru).

Which filters, in which order, and what did each remove? The log answers in a page: the count before the filter, the count after, and the reason the threshold was set where it was. Rule 10B and section 92C govern how a set is selected and excluded, so a set that cannot show its filters cannot show that conformity either.

Were the differences adjusted, and where is that written? The ±5% variation under section 92C is a tolerance, and the same ruling held that it is not a standard deduction from the margin (TaxGuru), so it cannot do the work of an adjustment. Where a company differs on working capital, capacity use or a cost's accounting treatment, the file should show the adjustment, its basis and its effect on the range.

Those answers do not guarantee an outcome. They move the argument onto the comparables, which a benchmarking study can hold. The other argument is whether the data can be trusted at all, and a record either settles it or loses it.

Sources relied on. Section 92C of the Income-tax Act, 1961, as reproduced on SooperKanoon; the Karnataka High Court's ruling in SAP Labs India Private Limited v ITO, read in TaxGuru's summary of 21 September 2026; and our own notes on the exclusion of high-brand-value entities and on the transfer pricing study report. Research cut-off: 14 November 2026.