Agentic AI in Transfer Pricing Benchmarking: What a New Study's Error Rates Mean for Indian Practice

A study published in The International Tax Journal tests, with data rather than assertion, a claim commonly made for AI-driven transfer pricing benchmarking tools: that autonomous systems can produce faster analysis without a corresponding loss of rigour. The findings deserve closer attention from Indian practitioners than they are likely to receive.

The authors ran agentic AI, systems that execute a multi-step workflow such as a benchmarking search or functional analysis without step-by-step human prompting, against 20 simulated MNE cases across three sectors. They compared the outputs against a model of how tax administrations in 11 countries are deploying similar technology. The efficiency gain was substantial: agentic AI cut processing time by roughly 98% while increasing the depth of the functional analyses produced.

The same study reports three failure rates that merit attention before any TP head signs off on an AI-assisted benchmarking pipeline: a 15% error rate in complex functional characterisations, a 22% irrelevance rate in comparable selection, and a 15% hallucination rate in legal citations. The authors propose a governance framework they call "Tracer-Wire," under which every AI-generated conclusion must carry a visible, auditable path back to its source data, with a mandatory human checkpoint before any output is finalised.

Explainability-by-design and human-in-the-loop review are now standard features of AI governance proposals, so the framework itself is not the notable part of the paper. What is notable is the coincidence between the study's error rates and recent Indian tribunal outcomes.

This month alone, three decisions have turned on the same issue the study measures. The Delhi bench of the ITAT excluded two comparables from Dixon Technologies' set for functional dissimilarity, even though the taxpayer had itself flagged the issue years earlier. The Chennai bench devoted an entire order to whether a single internal comparable can still claim the statutory tolerance band. The Karnataka High Court's SAP Labs line of rulings has produced a further set of follow-on decisions this month on whether a TPO may discard a taxpayer's comparables in favour of a "standard set."

Each of these disputes falls within the 22% irrelevance-rate failure mode the study measured. If agentic AI misjudges comparable relevance roughly one time in five even in a controlled simulation, and Indian tribunals are already spending full orders correcting comparable-selection errors made by humans, the practical question for TP practice in 2026 is concrete rather than conceptual: whose signature appears on the local file when an AI-selected comparable turns out, on review by a TPO or an ITAT bench two years later, to be a functionally dissimilar entity such as a plastics manufacturer.

Coverage of AI in transfer pricing tends to avoid a question that is uncomfortable for vendors and practitioners alike: whether an audit trail reduces liability or merely relocates it. A Tracer-Wire log showing that an AI system considered and rejected a comparable for a documented reason does not make that rejection correct. It makes the error more visible, and it arguably shifts accountability toward whoever approved the workflow rather than toward the tool itself.

It is worth asking whether India's Master File and Form 3CEB documentation requirements are structured to capture this kind of AI-decision provenance at all. If they are not, practitioners may be looking at a new category of documentation gap in an area the OECD's Chapter V framework was never designed to address. Firms adopting agentic AI for benchmarking would do well to build a sign-off protocol now, one that fixes responsibility for each accepted comparable before a tribunal does it for them.

DEMPE's Human-Centric Assumptions Face a Test as AI Performs Development and Enhancement Functions

The DEMPE framework determines which group entity is entitled to the return on an intangible by examining which entity performed the Development, Enhancement, Maintenance, Protection and Exploitation functions, made the key decisions, bore the risk, and had the people and capability to control what was happening. The analytical apparatus, functional interviews, organisation charts, decision logs, and the contemporaneous email trail showing an engineer approving a design change, rests on an assumption that a human being performed the function. A recent piece of Australian tax commentary notes that this assumption is becoming harder to sustain. The Australian Taxation Office's guidance on intangibles migration, PCG 2024/1, sets out the evidence it expects a multinational to produce when documenting its DEMPE functions. That evidence regime, the commentary observes, presumes human decision-making and physical performance. It does not address what happens when the decision is made by a model.

PCG 2024/1 has been in force since January 2024. The law itself has not changed; what has changed is a growing recognition that the gap between the rule and the operating reality is becoming practically significant. AI systems are themselves valuable intangible assets under ordinary transfer pricing principles: the algorithms, the training data, and the fine-tuned models sitting inside a captive centre's codebase. A separate issue arises one level up. When an AI system performs the actual development and enhancement work, writing and testing code, running design iterations, flagging defects, optimising a process, the question is who counts as the DEMPE contributor. It could be the engineers who built and supervise the model, the entity hosting the compute, the parent that trained the underlying model elsewhere, or no clearly identifiable party if performance becomes diffuse. The commentary frames this as a mismatch between a human-centric international tax architecture and an operating reality that is automating functions the architecture was built to track.

The implications are likely to be more pressing for India than for Australia. India's transfer pricing landscape relies heavily on captive centres and GCCs performing the kind of granular, iterative technical work, software development, testing, engineering support, and increasingly research, that is most amenable to AI augmentation and, potentially, AI substitution. For two decades, the Indian TP dispute over these centres has centred on characterisation: whether a centre is a routine cost-plus service provider or a genuine value-creating R&D contributor, and which comparables support either position. That analysis has assumed the underlying question, who did the work, could be answered by examining headcount, job descriptions, and reporting lines. If an increasing share of the development and enhancement work inside these centres is performed by AI tools that the centre operates but did not necessarily build, the functional analysis becomes harder to write convincingly in either direction. A TPO could argue that the Indian entity performs less genuine DEMPE work than its cost base suggests, because the model does the underlying processing. A taxpayer could equally argue that the Indian entity deserves more than a routine cost-plus return, because supervising, curating, and directing an AI system that performs high-value technical work is itself a sophisticated function that current benchmarking studies are not equipped to price.

The functional analysis may need a distinct category, one that asks not only who performed the function but who exercised meaningful control and judgment over the system performing it. Whether existing documentation templates, functional interviews, organisation charts, decision logs, can capture that distinction without substantial revision is unclear.

A related institutional question follows. If DEMPE evidentiary standards assume human decision-makers, and the CBDT's own scrutiny and risk-selection processes are moving toward AI-driven flagging at the same time, the tax administration sits on both sides of the same conceptual gap: applying a human-centric framework through tools that are themselves not human-centric. For practitioners, the practical implication is to begin documenting, now, the extent of human supervision, curation, and judgment exercised over AI tools used in development and enhancement work inside Indian captive centres, since existing DEMPE templates may not capture that distinction without adaptation.

Aggregate or Segregate: Why the Choice Cannot Be a Default Setting in AI Benchmarking Tools

Transfer pricing benchmarking requires an early decision on whether to test a transaction on a standalone basis or aggregate it with other international transactions of the entity. Rule 10A's language on aggregation can support either approach depending on the facts, and taxpayers and tax authorities routinely take opposing positions on which approach the facts justify. A recent ITAT Mumbai ruling in the case of NTT India (formerly Dimension Data India) addressed this question directly, and its reasoning has implications for how AI-assisted benchmarking tools are being designed and used by Indian tax teams.

NTT India had benchmarked its management-fee payment to its Asian regional AE as part of an aggregate, entity-level TNMM analysis, arguing that the overall margin was at arm's length once all international transactions were considered together. The TPO disagreed, extracted the management-fee transaction from that aggregate analysis, applied the CUP method, found no comparable uncontrolled data, and valued the entire service at nil, resulting in an adjustment of nearly ₹93.23 crore. The ITAT deleted the adjustment. In November 2025, a separate ITAT Mumbai bench reached a similar conclusion in an unrelated case, holding that a TPO cannot accept TNMM for a taxpayer's transactions in aggregate and then isolate a single line item for independent nil valuation. The two rulings, from different benches and about ten months apart, apply the same underlying principle.

Rule 10A's aggregation language has not changed. What appears to have shifted is how often tribunals are being asked to police where the aggregation boundary sits, and the consistency with which they are ruling against the department on this point. For a TP practitioner, this strengthens the argument that once an aggregate TNMM position has been accepted, or at least not affirmatively rejected, for an assessee's transactions as a whole, the TPO's room to isolate and independently value a single line item is narrower than it may once have appeared.

This reasoning is also relevant to AI-assisted benchmarking and documentation tools, including agentic platforms and GenAI-based comparable-search products, that are being marketed to Indian tax teams and Big Four practices. Most of these tools make an implicit aggregation-or-segregation choice somewhere in their workflow. Some default to pulling entity-level financials and running margin comparisons across the whole profit and loss account. Others are built to isolate and test each intercompany transaction separately because that is easier to automate and audit.

Neither default is safe on its own. A tool that always aggregates risks reproducing the outcome favourable to the taxpayer in NTT India even in fact patterns where aggregation is not actually justified, inviting a TPO challenge on the opposite theory. A tool that always segregates transactions for cleaner, auditable output risks reproducing the same TPO error that was overturned twice within about a year, testing a management fee, a cost-contribution arrangement, or an IT service fee in isolation when it was never meant to be tested that way. The tribunals' reasoning indicates that this decision has to rest on how closely the transactions are linked on the specific facts, not on a default setting built into a product.

This has a direct implication for how TP teams evaluate any AI benchmarking tool they consider buying or building. Vendors are likely to emphasise comparable-search speed and documentation drafting, but the more relevant question for audit defensibility is narrower: does the tool make its aggregation-or-segregation choice explicit, does it require a person to record the specific factual basis for that choice, and would that basis survive a TPO challenge along the lines the TPO raised in NTT India.

As more Indian captives and GCCs adopt AI-assisted TP documentation workflows, practitioners should treat the aggregation-or-segregation call as a documented, fact-specific judgment that sits with a person on the team, not a default a vendor sets. The NTT India line of rulings gives that judgment more weight than it may have carried before, and it is a reasonable basis for reviewing any AI-generated benchmarking file before it is relied upon in a submission to the TPO or the DRP.

SAP Labs Ruling on Standard Sets and Its Implications for AI-Assisted Benchmarking

Transfer pricing practitioners frequently encounter this pattern: a taxpayer builds a comparable set, the TPO rejects most of it, and the replacement set resembles the set the TPO has used in assessments of similar taxpayers. The Karnataka High Court's ruling in the SAP Labs India appeals addressed this practice directly. The Court held that a TPO cannot reject a taxpayer's comparables merely to substitute a standard set of comparables routinely used by the Income Tax Department, and that the comparability exercise must be tied to the particular international transaction and conform strictly to Rule 10B. The Court also closed off another common approach, holding that the plus or minus 5% tolerance range under Section 92C is a threshold for determining when no adjustment is required, not an automatic deduction from the arithmetic mean once a transaction falls outside it.

Considered solely as a case about TPO conduct, this ruling restates a familiar principle: tribunals have long required that FAR analysis be conducted properly. Its significance is heightened by timing. A small but growing set of commercial platforms, including Tessera, ArmsLength AI, TPGenie and others, now offer a workflow similar to the one the Court found impermissible, without the government's involvement. These vendors market consistency: a fixed, repeatable accept or reject logic applied to a comparable-set export, uniformly across each row, with human review limited to exceptions. Vendors advertise measurable gains, including claims of freeing up preparation time substantially and achieving high accuracy rates on automated accept or reject decisions. The feature underlying this pitch, a single decision logic applied consistently across every candidate company, closely resembles the feature the Karnataka High Court held a TPO cannot rely on when substituting a standard set for taxpayer-specific analysis.

This ruling does not hold that AI-driven benchmarking is impermissible. Nothing in it addresses AI, and no Indian tribunal has yet evaluated an AI-generated comparable set on its own terms. Its relevance lies in the doctrinal language now available for testing a benchmarking study whose selection logic was a repeatable template rather than transaction-specific FAR judgment. A taxpayer whose TP study relied substantially on an automated accept or reject pass, and whose audit trail records only which template rule fired for which company, may find that this traceability does not, on its own, demonstrate that the comparable search was tailored to the taxpayer's controlled transaction. The same risk applies to the Department: if a TPO's office uses AI-assisted searches that effectively reconstitute the Department's familiar standard set under a different label, taxpayer's counsel could cite SAP Labs against that approach.

Practitioners advising on AI-assisted benchmarking need to consider what a defensible workflow looks like under this standard. One possibility is that a traceable, overridable accept or reject log is sufficient, provided a human reviewer documents transaction-specific reasoning for the final set. Another possibility is that the underlying decision logic itself must be shown to respond to the specific FAR profile of the tested party, rather than being applied uniformly across an unrelated population of candidate comparables. No case has tested this question yet, and vendors are unlikely to raise it themselves. Firms advising clients on adopting AI benchmarking tools, or defending a study built using one, would be well advised to build in an explicit, documented step where a reviewer records why the FAR profile of the tested party justified each inclusion or exclusion, independent of what the algorithm flagged, and to treat AI output as a first-pass screen rather than as the analysis itself.

Although the SAP Labs ruling does not mention AI, its reasoning on standard sets and transaction-specific comparability is likely to inform how AI-assisted benchmarking studies are tested going forward. Practitioners should document the human judgment behind each comparable decision accordingly, rather than relying on the traceability of an automated log as a substitute for that judgment.

Agentic AI in Transfer Pricing: The Practical Problem Is the Handoff Between Agents

Discussion of AI and transfer pricing has largely centred on whether a single autonomous agent could take a set of intercompany agreements, run a functional analysis, select comparables and produce a defensible benchmarking range with minimal human involvement. Vendors market toward that capability, and practitioner panels debate whether such an agent could meet the reliability standards implicit in Section 92C or Section 482. A hackathon held in Vienna earlier this year, organised with the WU Tax Law Technology Center, Microsoft and TPA Global and reported only this week, points to a different pattern taking shape in practice. Rather than building one model to perform the entire task, participating teams chained together several narrower agents, each handling a bounded function.

The case studies covered intra-group financing and intercompany services: arm's length interest rates, creditworthiness assessment, the benefit test, cost allocation, method selection and documentation. Teams built separate agents for data extraction, service classification, benefit testing, cost allocation, compliance monitoring, documentation and audit readiness, and linked them into a workflow. The organisers were explicit that the intent is not to replace professional judgment: outputs are meant to remain traceable to source, reviewed before use, and subject to human oversight at each step. This combination of decomposition and human-in-the-loop review appears to be the practical model emerging from the exercise, even as vendor marketing continues to emphasise single-agent capability.

This distinction matters for Indian TP practice because the architecture of contemporaneous documentation, under Rule 10D, the erstwhile Form 3CEB and now Form 48 under the 2025 Act, assumes a single preparer's judgment trail. A TPO can ask why a particular comparable was included and expect an answer from one analyst or one firm. A pipeline of five narrow agents does not fit that assumption. If a data-extraction agent misclassifies a transaction, a downstream benefit-test agent may inherit that error and proceed regardless, since it is not designed to question upstream inputs, only to execute its own task. The more likely failure mode in a multi-agent TP workflow is not a single agent producing a wrong answer, but an error propagating silently across a handoff that no one is specifically assigned to audit. India's TP documentation requirements, safe harbour disclosures and APA application forms do not currently address this scenario; they assume one preparer whose competence and good faith can be tested under cross-examination or TPO scrutiny.

Practitioners, and possibly CBDT, will need to consider what a chain-of-custody requirement for multi-agent TP work product should look like before a dispute forces the issue. Knowing that a benchmarking output traces back to a database source, as most current vendor claims are framed, is not sufficient. It would also require knowing which agent touched the data at each stage, what it changed or flagged, and whether a human actually reviewed the boundary between two agents' work rather than only the final output. India is already working through related questions, such as how DEMPE functions performed by AI systems fit within the intangibles framework, and whether GCC functional segmentation holds up against agentic AI restructuring inside captive centres. The handoff-audit issue sits a level below those debates: it concerns not whether AI can perform a TP function defensibly, but whether anyone can reconstruct, after the fact, which of several AI agents was responsible when something went wrong. Given how current documentation standards are framed, that question is more likely to surface first in a TPO's show-cause notice than in a policy paper, and practitioners relying on multi-agent tools would do well to build their own audit trail across agent handoffs before that happens.

India's New GCC Benchmarking Advice Meets an Agentic AI Problem It Has Not Addressed

For several years, the standard defensive approach for a captive Global Capability Centre (GCC) facing an Indian Transfer Pricing Officer (TPO) has been fairly mechanical: apply TNMM on an operating cost base, benchmark against routine service-provider comparables, and settle within the accepted cost-plus range. A jurisdiction briefing circulated this week for International Tax Review describes FY2025-26 as a year in which TPO scrutiny of GCC margins and intra-group services intensified, with officers moving toward fewer but deeper adjustments. The advisory response is to segment the GCC into three separately tested activities, namely support, delivery, and decision-rights, with each priced on its own terms rather than blended into a single entity-level margin.

This approach aligns with the OECD's current work at the multilateral level. The OECD has published the full set of public comments on its proposed rewrite of Chapter VII, which governs intra-group services, ahead of a consultation meeting scheduled for November in Paris. Practitioner submissions describe the draft as a substantive rewrite rather than a tidy-up: it requires accurate delineation of what was actually done, by whom, and under what conduct, as the necessary first step before any pricing method is chosen, and it expands the benefit test that has long been the fault line in service fee disputes. Read together, the Indian advisory and the OECD draft point in the same direction: MNEs are being asked to stop pricing services as a single blended category and instead demonstrate, activity by activity, that a real economic function occurred and that an independent party would have paid for it.

This advice may be harder to execute than it appears, not because of documentation gaps in the traditional sense but because of a shift underway in how GCCs operate. India's GCCs are moving away from task-by-task human execution toward agentic AI systems that plan and execute multi-step workflows autonomously. Industry commentary has described Google's move from single-task AI assistants to an agent platform that can be deployed, supervised, and audited across a company's systems as a development that could affect the labour-arbitrage economics on which the GCC sector was built. Separately, EY's GCC survey work finds a large majority of centres already testing agentic technology, with over half piloting agent-based systems specifically. Inside a GCC, this means a workflow once visibly split between a junior analyst performing support work and a senior lead exercising decision-rights judgment can now be executed end-to-end by a single agent, or by a human-agent pair, in a manner not observable from outside the system the way an organisation chart or job description made it observable five years ago.

The Indian TP advisory recommends segmenting the GCC into three tested activities before benchmarking. The OECD requires accurate delineation of the transaction before pricing it. Both instructions assume a documentable boundary between routine support and higher-value decision-making that a TPO or comparability analyst can observe and test. Agentic AI does not necessarily respect that boundary. If an exception-handling agent inside a GCC performs functions that combine what used to be tier-1 support and tier-2 judgment, the functional analysis section of the Local File, which describes who does what, would either need to become considerably more granular about which agent or human made a given call, or risk reverting to the blended, entity-level treatment that both the OECD and Indian practice are trying to move away from.

The practical question is not whether AI adoption in GCCs is occurring; the survey data and industry commentary indicate that it is. It is whether the functional-segmentation and accurate-delineation frameworks currently being refined by the OECD and recommended by Indian advisors were designed for a labour model that may be changing faster than the guidance can be finalised. If accurate delineation depends on establishing what was actually done and by whom, and 'whom' increasingly means a shifting combination of humans and autonomous agents operating across functional boundaries that were previously organisationally distinct, this raises a documentation question that neither the OECD's November consultation agenda nor the Indian safe harbour and Local File templates currently address in detail. For practitioners, the practical implication is to start building functional analyses capable of tracking agent-level activity now, rather than waiting for the guidance to catch up.

AI-Performed DEMPE Functions and the Limits of Transfer Pricing's Intangibles Framework

The OECD's DEMPE framework was designed to stop groups from parking valuable intangibles in a low-tax entity that holds legal title but performs none of the underlying work. The test traces the relevant functions, development, enhancement, maintenance, protection and exploitation, back to the people who exercise judgment over them: who decided to pursue a research direction, who approved a patent filing, who manages commercialisation risk. For two decades this test has worked reasonably well because those functions were, in fact, performed by identifiable people.

That assumption is being tested where AI systems perform DEMPE functions. Commentary in Australia has raised this issue in relation to the ATO's Practical Compliance Guideline 2024/1 on intangibles migration, which requires multinationals to self-assess and disclose where DEMPE activities for offshore-held intangibles actually occur, using a risk-zone framework that determines how closely the ATO will scrutinise a taxpayer's position. The commentary notes that the PCG's evidence requirements assume human decision-makers, leaving a gap where AI systems (training models, tuning algorithms, monitoring outputs, iterating on protection measures) perform these functions without a person who can be identified as the locus of judgment.

A companion piece extends this analysis to M&A due diligence. It argues that AI systems, including the algorithms, training data and infrastructure, are themselves valuable intangibles under transfer pricing principles, and that a target lacking DEMPE documentation for its AI footprint may carry dormant tax risk that an acquirer inherits on completion.

This is not confined to Australia, and it is not a distant issue for India. India's global capability centre sector has moved well beyond routine coding and support work. Commentary directed at India's GCC market has told clients that where a captive centre designs a core AI algorithm used across the global group, arm's-length pricing cannot be justified by comparing developer hourly rates; the pricing must reflect that creative, value-creating contribution. That is a DEMPE argument, framed in language close to the ATO's, applied to the kind of AI-first GCC that has become common in Bengaluru, Hyderabad and Pune over the last two years.

The timing adds to the difficulty. The Finance Act 2026 safe-harbour rationalisation consolidated software, ITeS, KPO and contract R&D into a single IT-services category, set a flat 15.5% margin, and raised the eligible transaction threshold to ₹2,000 crore. The change was presented as compliance simplification for routine captive units. A captive unit whose engineers are training or fine-tuning a model whose commercial exploitation happens offshore may not be 'routine' in the DEMPE sense, even if it fits comfortably within the new safe-harbour band. A group that elects into the safe harbour for five years on the strength of a routine cost-plus characterisation may be locking in a margin that a DEMPE-consistent functional analysis would not support. That exposure may surface only when the safe-harbour election lapses and a TPO examines what the unit was actually doing.

This raises a harder question about the DEMPE test itself. DEMPE and the 'significant people functions' concept exist to identify who exercises judgment over value creation. Where that judgment is distributed across a model's training run, a human supervisor who approves outputs in bulk, and an infrastructure team in a different jurisdiction, none of these resembles the risk-bearing decision-maker the framework was written for. Tribunals and tax authorities have decades of practice tracing DEMPE to people, but little developed practice for tracing it to a system.

Whether CBDT, the ITAT or the OECD develops a workable answer first, and whether India follows the ATO's disclosure-and-self-assessment approach or adopts something more prescriptive, remains unclear. For now, practitioners advising GCCs and AI-heavy captives should treat DEMPE documentation for AI-performed functions as a present compliance issue, and should examine whether a safe-harbour election understates the functional profile of a unit that is doing more than routine service delivery.