Loading...
Loading...
How to price contract R&D arrangements: distinguishing routine research services from entrepreneurial IP development, DEMPE and risk control, cost plus vs TNMM, cost-base and mark-up issues, tax/accounting caveats, documentation, audit issues, and examples.
Borys Ulanenko
CEO, ArmsLength AI
Continue exploring
Browse the full resource library or contact us if you want recommendations for your specific use case.
Contract R&D is usually priced as a routine service when the R&D entity performs research under another group company's direction, receives cost reimbursement plus a mark-up, does not own resulting IP, and does not control the risks that determine project upside or downside. In that profile, the R&D entity is often the tested party and a cost-based method is typical.
The same lab can become non-routine if it controls the research agenda, decides which technical paths to pursue, owns patents or know-how, funds development risk, or has meaningful upside from successful IP. In that case, a routine cost-plus return may underpay the entity doing the value-creating work.
For related guides, see cost plus transfer pricing, documentation for intangibles, and tested party selection.
The distinction turns on control, risk, and IP rights.
| Feature | Contract R&D provider | Entrepreneurial R&D / IP owner |
|---|---|---|
| Research agenda | Set by principal or agreed statement of work | Set or materially controlled by the R&D entity |
| Budget | Approved and funded by principal | Funded and controlled by R&D entity |
| Technical decisions | Executes within approved scope | Chooses technical direction and trade-offs |
| IP ownership | Resulting IP assigned to principal | Owns or co-owns resulting IP |
| Risk | Limited cost and execution risk | Bears development failure and upside risk |
| Return | Cost plus or TNMM routine return | Residual, royalty, valuation, or profit split may be relevant |
HMRC's cost plus manual notes that OECD cost plus examples involving contract research do not mean related-party R&D contracts are automatically arm's length. The arrangement still needs a fact-based analysis of functions, assets, and risks.
R&D creates or improves intangibles, so OECD Chapter VI is central. DEMPE asks which entities perform and control development, enhancement, maintenance, protection, and exploitation functions.
For contract R&D, the main DEMPE question is development:
A contract R&D provider can perform development work without controlling development risk. In that case, it earns an arm's length service return. If it controls the development program, hires the scientific leadership, chooses the technical route, and owns or controls resulting know-how, the DEMPE analysis points to a larger return.
Do not treat "people are in the lab" as the end of the analysis. The transfer pricing question is who performs the work, who controls it, who bears the risk, and who receives the resulting rights.
OECD risk analysis looks beyond contractual risk allocation. A funder that lacks capability to control development risk may be entitled to a financing return rather than the residual upside from successful IP. A service provider that performs research but lacks control over the risk may earn a routine service return.
Evidence of risk control includes:
If the principal controls those items, the contract R&D model is easier to support. If local R&D leadership controls them, the routine service model needs more scrutiny.
Both methods can appear in contract R&D policies. The right choice depends on data reliability and the transaction's profile.
Traditional cost plus starts from service costs and applies an arm's length gross mark-up. It may work where comparable contract research service agreements or internal uncontrolled service arrangements exist.
Cost plus is stronger when:
TNMM with Net Cost Plus tests operating profit over total costs. It is common where external data consists of independent R&D service providers' operating margins rather than transaction-level gross mark-ups.
TNMM is often selected when:
| Issue | Cost plus | TNMM with Net Cost Plus |
|---|---|---|
| Profit level | Gross mark-up on service costs | Operating profit over total costs |
| Evidence | Internal contracts or comparable service transactions | Comparable company data |
| Strength | Direct where comparable service pricing exists | Practical where net data is more reliable |
| Weakness | Sensitive to cost-base definitions | May hide differences in R&D risk and IP ownership |
Contract R&D pricing can fail through cost-base errors even when the mark-up looks reasonable.
Base salaries, employer taxes, bonuses, benefits, and pension costs are usually in the cost base if they relate to R&D services. Equity compensation needs jurisdiction-specific analysis. In US cost sharing, stock-based compensation has detailed treatment; in service models, inclusion should follow local law, accounting, and comparability.
Third-party CROs, freelancers, universities, cloud compute, lab testing, and prototype vendors may be pass-through or value-added costs depending on who manages them. If the R&D provider selects, supervises, and controls vendors, a mark-up may be appropriate.
Failed R&D is part of the economics. If the principal controls and funds the R&D portfolio, failed-project costs are often reimbursed. If the R&D entity chooses projects and bears risk, it may absorb more downside and need upside.
Accounting treatment does not decide transfer pricing. Software development, patents, or prototypes may be capitalized under local accounting rules, expensed for tax, or tracked in project systems. The transfer pricing file should reconcile the cost base to management accounts and explain timing differences.
R&D credits, grants, subsidies, and super-deductions require local analysis. Do not assume the benefit automatically belongs to the principal or the service provider. Consider legal entitlement, contract terms, local tax rules, and whether independent parties would share the benefit through pricing.
Benchmarks should match the actual service:
| Service type | Benchmark caution |
|---|---|
| Routine testing or QA | Do not compare to high-risk biotech or software product companies |
| Contract software development | Watch for companies owning platforms or products |
| Scientific research support | Separate routine lab services from IP-generating research |
| Clinical or regulatory support | Confirm whether comparables bear trial or regulatory risk |
A contract R&D file should make the project governance visible.
| Document | What it should show |
|---|---|
| R&D services agreement | Scope, IP ownership, risk allocation, cost base, mark-up, invoicing |
| Statements of work | Projects, deliverables, timelines, budgets, acceptance process |
| DEMPE matrix | Who performs and controls development and enhancement functions |
| Risk-control evidence | Steering minutes, budget approvals, go/no-go decisions |
| Cost-base mapping | Payroll, contractors, overhead, grants, credits, capitalized costs |
| Benchmarking study | Comparable service providers, screens, PLI, range |
| IP records | Patent filings, invention disclosures, assignments, repository ownership |
| Year-end true-up | Actual costs, mark-up, adjustments, invoices, local entries |
Use project names and systems of record. A useful R&D file can be traced from the intercompany agreement to the budget, ticketing or lab system, payroll cost center, invoice, and IP assignment.
Tax authorities often challenge contract R&D where:
The audit question is usually direct: who actually decided what research to do, and who had the capability to evaluate those decisions?
Facts: UKCo performs software R&D services for USCo. USCo owns the platform IP, sets the roadmap, approves budgets, and makes go/no-go decisions. UKCo employs engineers who implement agreed features and bug fixes. All code is assigned to USCo under the intercompany agreement and employment contracts.
Method selection: UKCo is the tested party. It has no product IP and does not control development risk. TNMM with Net Cost Plus is selected because external comparables report operating results rather than gross service mark-ups.
| Item | Amount |
|---|---|
| Engineering salaries and benefits | GBP 6,000,000 |
| Contractor costs | GBP 1,200,000 |
| Cloud testing and development tools | GBP 600,000 |
| Allocated R&D overhead | GBP 700,000 |
| Total cost base | GBP 8,500,000 |
| Arm's length NCP target | 8.0% |
| Intercompany charge | GBP 9,180,000 |
Calculation:
GBP 8,500,000 x (1 + 8.0%) = GBP 9,180,000
Audit-sensitive point: UKCo's CTO attends product steering meetings but does not approve the global roadmap or budget. The file includes minutes showing USCo's product committee made the final decisions. That evidence supports the contract R&D profile.
Transfer pricing should be coordinated with local tax and accounting teams:
These points do not replace local advice. They are prompts to prevent the transfer pricing policy from conflicting with the tax return, statutory accounts, and legal agreements.
No. Cost plus or TNMM can fit routine contract R&D, but only when the service provider does not control development risk or own valuable resulting IP. Entrepreneurial R&D may need royalty, valuation, or profit split analysis.
Legal ownership depends on contracts, employment law, assignments, and registrations. Transfer pricing then asks whether the legal owner also controls DEMPE functions and risks. Legal title alone does not decide all returns.
Often yes, if the principal controls and funds the R&D portfolio. If the R&D provider controls project selection and bears development risk, failed-project treatment may differ. The contract and conduct should match.
It depends on local law, the contract, and comparability. Some arrangements leave credits with the service provider; others share the benefit through pricing. The treatment should be explicit and consistent.
Look for independent contract research, engineering, software development, or technical service providers that do not own valuable IP or bear entrepreneurial product risk. Avoid product companies unless they can be reliably segmented.