Quick answer: how is software IP priced for transfer pricing?
Software IP transfer pricing depends on the rights transferred, the software's stage of development, the business model, and the entities that perform and control DEMPE functions: development, enhancement, maintenance, protection, and exploitation. A simple license may be priced with a royalty benchmark. A platform model with unique contributions from several entities may need a profit split or valuation-based approach.
The starting questions are practical:
- What legal rights are being licensed, sold, contributed, or used?
- Which entity controls the product roadmap and technical architecture?
- Who employs the engineers, product managers, security teams, and data scientists?
- Who owns or controls data, models, customer relationships, brands, and distribution channels?
- Who bears product liability, cybersecurity, hosting, uptime, and market risks?
- Are the intercompany charges aligned with actual use, revenue, users, seats, transactions, or territory?
For intangibles documentation more generally, see TP documentation for intangibles. For profit split mechanics, see the profit split method guide.
Software IP is not one fact pattern
"Software" covers very different transfer pricing cases. The right method changes with the commercial model.
| Model | Common controlled transaction | Typical pricing issue |
|---|
| Internal enterprise software | Cost recharge or service fee | Benefit test, cost base, mark-up, ownership of improvements |
| Licensed on-prem software | Royalty or license fee | Comparable license data, territory, exclusivity, maintenance |
| SaaS product | Revenue-share, royalty, service fee, or residual allocation | Bundled software, hosting, support, updates, data, sales functions |
| Platform or marketplace | Profit split, commission, royalty, service fees | Network effects, local market contributions, data, multi-sided revenue |
| AI or data product | License, service fee, profit split, valuation | Training data, model development, compute, MLOps, product integration |
| Embedded software | Product price plus embedded IP return | Separating tangible goods return from software/intangible return |
HMRC's intangibles manual reflects the OECD approach: for transfer pricing, an intangible is not limited to accounting assets or registered rights. Software, know-how, data architecture, algorithms, and technical documentation may have value even when they are internally developed and not capitalized.
Define the controlled transaction first
Before selecting a method, define what moved between affiliates.
License
A license grants rights to use software or related IP. It may be exclusive or non-exclusive, territorial or global, perpetual or term-limited, source-code or object-code, with or without modification rights.
The license terms should match the pricing. A distributor with only reseller rights should not pay the same as an affiliate that receives source-code access, localization rights, and control over local commercialization.
Sale or migration of IP
An IP sale or migration usually requires a valuation. Early-stage software transfers are especially audit-prone because projections can move sharply after the transfer. If the software qualifies as a hard-to-value intangible, tax authorities may look at later outcomes as presumptive evidence unless the taxpayer has strong ex ante support and an applicable exception.
Development services
An engineering affiliate may provide contract software development services to the IP owner. That can be a routine service arrangement if the service provider does not control development risk or own resulting IP. If the affiliate controls architecture, roadmap, and core technology decisions, a routine cost-plus return may be too low.
Cost contribution or cost sharing
Under OECD Chapter VIII, a CCA is an arrangement where participants share contributions and risks in developing or obtaining intangibles, tangible assets, or services, expecting benefits for their businesses. In US rules, a qualified cost sharing arrangement under Section 1.482-7 has detailed requirements around intangible development costs, reasonably anticipated benefits, and platform contributions.
Do not call a recharge "cost sharing" unless participants actually share risks and expected benefits.
DEMPE analysis for software
OECD Chapter VI uses DEMPE to determine which entities should receive returns from intangibles. Legal ownership starts the analysis, but it does not decide entitlement to all residual profit.
| DEMPE function | Software evidence to collect |
|---|
| Development | Engineering headcount, repositories, technical design docs, sprint planning, architecture decisions |
| Enhancement | Product roadmap, release notes, feature prioritization, A/B testing, model retraining, localization |
| Maintenance | Bug fixing, uptime, security patches, cloud operations, technical debt management |
| Protection | IP registrations, access controls, cybersecurity, trade secret policies, open-source compliance |
| Exploitation | Licensing strategy, pricing, packaging, customer contracts, reseller programs, product-led growth metrics |
Control of risk
Risk control is more than signing a contract. For software, look at who makes and monitors decisions about:
- product-market fit and roadmap priorities
- engineering resource allocation
- cybersecurity and data governance
- model performance and bias controls for AI products
- cloud infrastructure and uptime standards
- pricing, bundling, customer segmentation, and territory rollout
- open-source licensing exposure
If a low-substance IP owner funds development but does not control these risks, it may be entitled to a financing return rather than the residual return from the software.
Royalty methods and CUP limitations
Many software IP policies use royalties. That may be right, but royalty benchmarking is fragile.
When a royalty benchmark may work
Royalty evidence can be useful when:
- the software category is mature and third-party licenses are available
- rights are comparable in scope, territory, exclusivity, duration, and field of use
- the license is not bundled with large services, hosting, support, data, or hardware
- the licensed IP is not unique relative to available agreements
- revenue base definitions can be aligned
Why CUP evidence often breaks down
Public royalty databases rarely give enough detail for proprietary software. Agreements may include patents, trademarks, maintenance, implementation, support, data feeds, updates, minimum guarantees, equity consideration, or settlement terms. A headline royalty rate can hide the economics.
Common comparability gaps:
| Gap | Why it matters |
|---|
| Source code vs object code | Modification rights change value |
| SaaS vs installed software | Hosting and continuous updates are bundled in SaaS |
| Exclusive vs non-exclusive | Exclusivity changes expected upside and risk |
| Mature product vs early-stage product | Projection uncertainty changes pricing |
| Territory and customer base | Local growth potential affects value |
| Brand and sales support | License may include more than software IP |
When CUP reliability is weak, consider valuation methods, TNMM for routine service/distribution entities, or profit split where multiple affiliates contribute unique value.
SaaS and platform businesses create transfer pricing pressure because software, hosting, sales, support, data, and user networks operate together.
SaaS
A SaaS group may have:
- a parent company that owns core code and controls roadmap
- a development hub that builds features
- a cloud operations team that runs infrastructure
- regional sales entities that sign customers
- support centers that handle onboarding and customer success
- data science teams that improve product performance
Routine entities can often be priced with TNMM or cost plus. The residual should follow the entities controlling and performing the valuable contributions. If two or more entities make unique contributions, a one-sided method may leave the wrong entity with residual profit.
Platform models add network effects, data, and local market roles. A local affiliate may do more than routine sales if it builds supply, demand, trust, compliance, or market liquidity that drives platform value. At the same time, central software, algorithms, brand, and data infrastructure may be the main source of scale.
The documentation should explain which effects are local and which are global. A generic distributor benchmark may be too thin for an affiliate that creates the local marketplace.
Profit split for software IP
Profit split can fit software and platform models when unique contributions come from more than one entity.
Indicators include:
- central engineering and local product teams both control valuable roadmap decisions
- one entity owns core architecture while another controls data, models, or market-specific IP
- global platform value depends on local network development
- several entities jointly control economically significant risks
- no reliable royalty or one-sided comparable captures the business model
The hard part is the allocation key. Useful evidence can include relative R&D spend, product headcount, engineering time, roadmap ownership, valuation of contributed IP, customer acquisition spend, data contribution, or a weighted contribution analysis. The key should be tied to value creation, not convenience.
For the method mechanics, see profit split method.
Hard-to-value intangibles
Software transfers often involve uncertain forecasts. HTVI issues arise when there are no reliable comparables and projections or assumptions are highly uncertain at the time of transfer. OECD HTVI guidance permits tax administrations, subject to safeguards, to use later outcomes as evidence about the reasonableness of ex ante pricing.
To defend a software IP transfer, keep the ex ante valuation file:
- product stage and technical readiness at transfer date
- forecast model and assumptions by revenue stream
- customer pipeline, churn, pricing, and conversion assumptions
- expected development roadmap and required spend
- market size, competition, and regulatory assumptions
- probability weighting for success, delay, pivot, or failure
- board materials and investor materials available at the time
- sensitivity analysis and reasons for selected discount rate
- later variance analysis separating forecast error from unexpected events
WarningHTVI risk increases when the transfer happens before product-market fit, regulatory approval, major customer adoption, or technical completion. A short memo with a single forecast rarely survives scrutiny.
Cost contribution and cost sharing at a high level
Cost contribution arrangements and US cost sharing arrangements can be appropriate for software development, but they require substance.
| Requirement | Practical software question |
|---|
| Expected benefits | Which territories, products, or user groups will each participant exploit? |
| Contributions | What engineering, data, existing IP, funding, or market access does each party contribute? |
| Risk control | Who makes decisions about roadmap, budget, quality, security, and commercialization? |
| Measurement | Are contributions valued at cost, market value, or another arm's length measure? |
| Adjustments | How are changing expected benefits, buy-ins, buy-outs, and balancing payments handled? |
For OECD CCAs, Chapter VIII focuses on contributions, risks, expected benefits, and arm's length conditions. For US CSAs, Section 1.482-7 is more prescriptive, including rules for intangible development costs and platform contribution transactions.
Documentation package
A software IP file should include both legal rights and product facts.
| Document | What it should show |
|---|
| IP register and legal agreements | Who owns code, patents, copyrights, trademarks, data rights, and license rights |
| DEMPE matrix | Who performs and controls development, enhancement, maintenance, protection, exploitation |
| Product architecture map | Which components create value and which teams build or operate them |
| Financial segmentation | Revenue, costs, users, products, territories, and intercompany charges |
| Benchmarking or valuation | Royalty search, valuation model, TNMM search, or profit split support |
| HTVI support | Ex ante forecasts, assumptions, sensitivities, and later variance tracking |
| CCA or CSA documentation | Participants, expected benefits, contributions, buy-ins, buy-outs, balancing payments |
| Audit trail | Board decks, roadmap approvals, repository evidence, customer contracts, support metrics |
Common audit issues
Tax authorities often challenge software IP policies where:
- The legal IP owner has little product, engineering, or risk-control substance.
- The royalty rate is benchmarked against agreements that bundle different rights.
- A regional affiliate pays a software royalty while also funding development or market-building without separate compensation.
- A SaaS policy treats hosting, updates, support, and IP as one charge without analysis.
- The group transfers early-stage IP using optimistic or unsupported projections.
- A cost sharing label is used without expected-benefit shares, buy-in analysis, or risk control.
- Local entities perform product localization or customer-data work that creates valuable intangibles but receive routine returns only.
The file should explain the business model in product language. Tax analysis that does not match how engineers, product teams, and sales teams describe the software will be vulnerable.
Worked example
Facts: USCo developed the first version of a cybersecurity SaaS product. IrelandCo now employs the core engineering team and controls the global roadmap. GermanyCo performs local sales, onboarding, and first-line support. The product is hosted centrally. GermanyCo does not modify code or control product strategy.
Transactions:
- USCo licenses legacy software IP to IrelandCo.
- IrelandCo performs ongoing DEMPE functions and operates the SaaS platform.
- GermanyCo provides sales and customer support services to IrelandCo.
Method selection:
- The USCo to IrelandCo license is valued using a royalty/valuation approach, with HTVI support because future adoption was uncertain at the transfer date.
- IrelandCo earns the residual platform return because it controls development, enhancement, maintenance, protection, and exploitation after migration.
- GermanyCo is tested under TNMM as a routine sales and support provider, using operating margin or cost-based service return depending on segmentation.
Audit-sensitive point: If GermanyCo starts building local product modules, owning customer data products, or controlling pricing and packaging for the German market, the routine return should be revisited.
Frequently asked questions
Can software royalties be benchmarked with CUP?
Sometimes. CUP is strongest when comparable uncontrolled software licenses have similar rights, exclusivity, term, territory, update obligations, support, and revenue base. Proprietary SaaS and platform arrangements often lack reliable CUPs.
Does legal ownership of code decide profit entitlement?
No. Legal ownership is important, but OECD DEMPE analysis asks who performs and controls the functions that create, maintain, protect, and exploit the software. A legal owner without substance may not be entitled to all residual returns.
When does profit split fit software IP?
Profit split may fit when two or more affiliates make unique and valuable contributions, such as core software architecture, data assets, AI models, platform network development, or market-specific product control.
What makes software IP hard to value?
Early-stage software often depends on uncertain adoption, churn, pricing, technical completion, regulation, funding, and competition. Those uncertainties can trigger HTVI risk if the transfer price depends heavily on forecasts.
Is cost sharing the same as cost recharge?
No. A recharge allocates costs. A cost contribution or cost sharing arrangement requires participants with expected benefits, contributions, and risk control. US cost sharing rules also impose detailed requirements under Section 1.482-7.
Borys UlanenkoCEO, ArmsLength AI
