The IRD Wizard: Structuring Client Data Requests for a Defensible Transfer Pricing File

Direct answer

The single most common source of rework in a transfer pricing engagement is not a miscalculated range or a mischaracterised entity  -  it is an incomplete or ambiguous initial information request that surfaces its gaps only after benchmarking has already started. An Information Request Document (IRD) that asks for “relevant financial statements and agreements” in general terms produces a client response that is genuinely incomplete in ways neither side notices until a reviewer asks a question the file cannot answer. TAIGA’s IRD wizard structures the request by transaction type and entity role from the outset, so the client is asked for what a specific transfer pricing analysis actually requires, not a generic document list.

What this guide covers

This article sets out why intake structure has an outsized effect on how much rework a transfer pricing engagement generates, what a genuinely structured information request should ask for by transaction type, and how TAIGA’s IRD wizard connects directly into the FAR and submission-check stages that follow it in a full engagement.

Why a generic document request produces incomplete responses

A client asked to “provide all related-party agreements and financial statements” will typically supply what is easiest to locate  -  the most recent signed agreement, the audited annual accounts  -  without necessarily supplying prior-year agreement amendments, internal cost allocation workings, or the segmental data that a specific transaction type actually requires to benchmark properly. This is not usually a case of a client withholding information; it is a structural problem with how the request was framed. A client without transfer pricing expertise cannot be expected to know that a management fee arrangement requires evidence of the actual services rendered and a benefit test, while a royalty arrangement requires the underlying licence agreement and evidence of how the royalty rate was originally benchmarked, unless the request specifies exactly that.

How TAIGA’s IRD wizard structures requests by transaction type

Rather than issuing one undifferentiated document checklist, TAIGA’s IRD wizard tailors the specific items requested to the transaction type identified at engagement setup  -  a different request set for a manufacturing arrangement, a distribution arrangement, an intra-group service, a royalty or licence arrangement, and an intra-group financing arrangement. For an intra-group service transaction, for instance, the wizard prompts for evidence of the services actually rendered (not just the agreement describing them), the cost base and allocation key used to charge for the service, and any benefit analysis performed  -  because these are precisely the items an examiner tests first when intra-group service charges are challenged. This transaction-specific structure means a client responding to the request is, in effect, being walked through what a defensible file for that specific arrangement actually requires, rather than guessing at what “relevant” means.

Tracking what has been supplied, and what remains outstanding

Beyond specifying what to request, the practical value of a structured IRD process is visibility into status  -  which items a client has supplied, which remain outstanding, and which have been supplied but flagged as incomplete or requiring clarification. TAIGA tracks this status against the same engagement record that later stages of the workflow reference, so a preparer moving into FAR analysis can see immediately whether a gap in the intake data explains an unusually thin rating for a specific function, rather than only discovering the connection when a reviewer asks why a function was rated Low with no supporting evidence attached.

Requesting evidence of conduct, not just evidence of agreement

A specific and frequently underestimated intake failure is requesting only the signed intercompany agreement for a given transaction, without also requesting the evidence that would show whether the entity’s actual conduct matches what that agreement describes. An agreement stating that a distributor bears full inventory and credit risk is not, by itself, evidence that the distributor actually does  -  that requires inventory ageing records, evidence of who absorbs write-offs, and the entity’s credit terms extended to its own customers, none of which a request limited to “the distribution agreement” will surface. This is the same contract-versus-conduct gap that later undermines a FAR analysis built only on the narrative an agreement provides, and it is considerably cheaper to close during intake, by asking for conduct evidence explicitly alongside the agreement itself, than to discover during FAR analysis that the two do not actually align. TAIGA’s transaction-specific IRD templates request this conduct-level evidence as a standard item for the transaction types where it matters most, rather than leaving it to an individual preparer’s judgment to think to ask for it separately.

Where intake gaps most often surface too late

A gap in the initial information request is cheapest to fix the moment it is identified  -  a follow-up email costs a client a few minutes. The same gap, discovered during benchmarking or at the second-reviewer stage, costs considerably more: the preparer has typically already built analysis on top of an assumption that turns out to be wrong, and the correction cascades through every step built on that assumption. This is exactly the failure pattern the submission check stage in a structured workflow is designed to catch before FAR analysis begins  -  but a submission check can only catch a gap that the original request made specific enough to notice was missing. A vague original request and a rigorous submission check are, in practice, in tension with each other; the IRD stage has to be specific enough that “missing” is a meaningful, checkable state.

How this reduces the number of follow-up rounds with a client

A less obvious cost of an unstructured information request is not the initial gap itself, but the number of back-and-forth rounds it takes to close it. A client who receives a vague request, supplies a partial response, is then asked a follow-up question, supplies a second partial response that still misses something specific to the transaction type, and is asked a third time, experiences the engagement as slow and disorganised regardless of how competent the underlying analysis eventually turns out to be  -  and each round adds calendar time to an engagement that may be running against a filing deadline. A request structured by transaction type from the outset tends to collapse this into one or two rounds rather than three or four, simply because the first request already specifies the items a generic one would only surface through iterative questioning. This matters as much for client relationship management as it does for engagement efficiency: a client who experiences one clear, comprehensive request is left with a materially different impression of the firm’s competence than one who experiences four incomplete ones.

Multi-entity groups: requesting once versus requesting per entity

A group with several related entities in scope for the same engagement  -  a parent and two subsidiaries, say, each with intercompany transactions to document  -  introduces a further intake design question: should common group-level information (the organisational chart, the group’s overall transfer pricing policy, group-wide intangible ownership) be requested once and shared across all entity-level analyses, or re-requested separately for each entity being assessed. Re-requesting identical group-level material for each entity is not merely inefficient; it creates a real risk that a client provides a slightly different version of the same document to two different entity-level requests, and nobody notices the discrepancy until a reviewer cross-references the two files. TAIGA’s IRD wizard structures group-level requests once at the engagement level and entity-specific requests separately underneath it, so common material is gathered a single time and made available to every entity-level analysis drawing on it, rather than being collected and potentially drifting across parallel intake threads.

What a well-structured request looks like by transaction type

The output of the IRD stage flows directly into FAR analysis and the submission check that precedes it, so a gap identified during intake is visible to every later stage of the engagement rather than being lost once the initial request is marked “received.” See the full platform overview for how intake connects to the rest of the workflow, or book a walkthrough on a transaction type relevant to your own client base.

How intake structure connects to the eventual filed document

A final, easy-to-overlook benefit of a transaction-specific intake process is that it shapes what the eventual Local File or Form 3CEB annexure is actually able to say. A Local File’s FAR narrative is only as detailed and evidence-backed as the underlying material the intake process actually secured  -  a file built on an intake process that only asked for the intercompany agreement will produce a FAR narrative that can only describe what the agreement says, not what the entity’s actual conduct demonstrates, which is a materially weaker document precisely where an examiner is most likely to probe. Designing the intake stage with the eventual filed document already in mind  -  working backward from what a defensible Local File chapter on functional characterisation needs to say, to what evidence would actually support saying it  -  is a more reliable way to structure a request than starting from a generic checklist and hoping it happens to cover what the final document will need.

Common gaps a poorly structured intake process produces

• A generic document checklist that does not vary by transaction type, producing responses tailored to what was easy to find rather than what the analysis requires
• No visible tracking of which requested items remain outstanding once the client has made a partial response
• A benefit-test requirement for intra-group services mentioned only in internal firm guidance, never actually included in the request sent to the client
• Gaps discovered for the first time during FAR analysis or benchmarking, well after the point where a quick follow-up would have resolved them cheaply

Frequently asked questions

Talk to TP DOC GEN AI

To see the IRD wizard structured around a transaction type from your own portfolio, book a walkthrough.

Further reading  -  official sources

• Income-tax Rules, 1962  -  Rule 10D (Information and documents to be kept and maintained)
• OECD Transfer Pricing Guidelines 2022

Editorial disclaimer

This article provides general educational information and is not tax or legal advice. Specific document requirements should be confirmed with a qualified transfer pricing adviser for each transaction and jurisdiction.