Every transfer pricing study starts with a functional analysis. The industry calls it FAR: functions, assets, risks. It answers the question that everything else depends on: what does each entity in the transaction actually do, what does it use, and what does it risk?
The characterization that comes out of the FAR analysis determines the transfer pricing method, the profit level indicator, and the benchmarking search criteria. A FAR that says “limited-risk service provider” leads to TNMM/CPM with net cost plus markup. A FAR that says “full-risk entrepreneur” leads to a completely different analysis. The rest of the study follows from this step. If it is wrong, everything built on top of it is wrong too.
A Concrete Example: Software Engineering Services
Abstract explanations of functions, assets, and risks are less useful than seeing how a FAR analysis works on a real fact pattern. Take a common one: a US subsidiary (Entity A) provides software engineering services to its German parent (Entity B).
Functions. Entity A employs 120 software engineers. They perform custom application development, systems integration, QA testing, and deployment support. Project specifications come from Entity B. Technical architecture decisions are shared: Entity B defines the product requirements, Entity A’s engineering leads determine the implementation approach. Entity A manages day-to-day project execution, hiring, and technical staff development.
Notice what matters here: not just what Entity A does, but where the decision-making authority sits. If Entity A only writes code to Entity B’s exact specifications with no discretion, that is a different characterization than if Entity A’s engineers make architectural decisions and manage delivery risk. Both are “software engineering services.” The FAR needs to distinguish them.
Assets. Entity A uses office space, workstations, and standard development tools, all relatively low-value tangible assets. The more important question: does Entity A own any intangible assets? Does it use proprietary frameworks, testing tools, or accumulated code libraries that it developed itself? Or does it work exclusively with Entity B’s technology stack?
If Entity A has developed proprietary development tools over several years that make its engineers more productive, those tools are intangible assets that affect Entity A’s characterization. An entity that contributes its own intangibles is entitled to a higher return than one that provides labor alone. The OECD’s DEMPE framework asks: who developed these tools, who maintains them, who benefits from them? If the answer is Entity A on all counts, the tools belong in Entity A’s asset profile.
Risks. What risks does Entity A actually bear? Not contractually allocate, but genuinely control and have the financial capacity to absorb?
If Entity A is paid on a cost-plus basis regardless of whether the project succeeds commercially, it bears limited risk. It faces operational risk (employee turnover, capacity constraints) but not market risk or development risk. If Entity A commits to fixed-price deliverables and absorbs cost overruns, it bears delivery risk. If Entity A’s compensation depends on the commercial success of the software it builds, it bears a share of market risk.
Each of these produces a different characterization and a different arm’s length range.
The characterization. Based on this analysis, if Entity A works to Entity B’s specifications, uses Entity B’s technology, and is compensated on a cost-plus basis: limited-risk service provider. Benchmarked using TNMM/CPM with net cost plus markup, against comparable companies providing similar engineering services. The CompPress library covers this exact profile under “Software Engineering Services.”
If Entity A makes architectural decisions, uses its own proprietary tools, and bears delivery risk: something closer to a specialized service provider or even a contract developer with its own IP. The arm’s length return would be higher, and the benchmarking search would target a different comparable set.
Same entity. Same services. Different FAR analysis, different outcome. This is why the FAR matters more than any other step in the study.
The Contract vs. Reality Problem
The single most consequential error in transfer pricing is a FAR analysis that describes the intercompany agreement instead of the actual operations. The OECD Guidelines are explicit: when the contractual terms and the actual conduct diverge, the actual conduct governs.
This is not an abstract problem. A subsidiary’s intercompany agreement says “limited-risk service provider.” The agreement was drafted five years ago. Since then, the subsidiary has hired senior engineers who make design decisions independently, developed internal tools that the parent now depends on, and started managing relationships with the parent’s external clients. The entity still files its transfer pricing documentation under the original characterization. The markup has not changed.
On audit, the tax authority interviews the subsidiary’s management. The picture that emerges does not match the documentation. The authority recharacterizes the entity, selects a higher arm’s length return, and makes an adjustment. The adjustment is not just for the current year. It applies retroactively to every open year where the characterization was inaccurate.
From FAR to Characterization: The Common Profiles
The FAR analysis produces a characterization. For intercompany services, the most common ones:
A limited-risk service provider performs defined functions, uses the principal’s intangibles, bears limited risk, and earns a cost-based return. This is the default for routine intercompany services: software engineering to specification, contract R&D, administrative support, sales and marketing execution.
A specialized service provider performs complex functions, contributes its own know-how or tools, bears some delivery or performance risk, and earns a higher return than a pure cost-based entity.
A contract manufacturer produces goods to the principal’s specifications, does not own product IP, bears limited risk, and earns a cost-based return.
A limited-risk distributor sells the principal’s products, does not own significant intangibles, bears limited market risk, and earns a margin-based return.
Each characterization maps to a transfer pricing method and a profit level indicator. The method follows from the characterization. The characterization follows from the FAR. The FAR follows from the facts.
A Closing Note
The FAR analysis is not a section of the report to be filled in after the benchmarking is done. It is the analytical step that determines whether the benchmarking means anything. Thirty minutes spent interviewing the people who actually run the subsidiary’s operations is worth more than thirty hours of comparable company screening built on a characterization that does not reflect reality.
Frequently Asked Questions
What is the difference between a FAR analysis and a DEMPE analysis?
A FAR analysis covers functions, assets, and risks across all intercompany transactions. A DEMPE analysis applies the same logic specifically to intangible assets: which entity develops, enhances, maintains, protects, and exploits the intangible? DEMPE was introduced in the OECD's 2015 BEPS revisions to allocate returns from intangibles based on substance, not just legal ownership.
How detailed does a FAR analysis need to be?
Detailed enough to support the characterization and distinguish the entity from other possible characterizations. A FAR that says 'Entity A provides IT services' is insufficient. What kind of IT services? Does it write custom code or reset passwords? Does it own any of the resulting IP? The level of detail should match the significance of the transaction.
What happens if the FAR analysis does not match the actual conduct?
Tax authorities will delineate the transaction based on actual conduct, not contractual terms. If a subsidiary is characterized as a limited-risk service provider but actually makes strategic decisions and bears commercial risk, the authority can recharacterize it and apply a higher arm's length return.
Can the FAR analysis change from year to year?
Yes, and it should be reviewed annually. Business operations evolve. An entity that was a routine service provider two years ago may now own proprietary tools, manage client relationships, or bear delivery risk. The documentation should reflect current operations.