The Arm’s-Length Question

A software company recently approached us with what appeared to be a straightforward question:

“We provide software services to our US group company. What mark-up should we charge?”

At first glance, this looked like a benchmarking exercise.

Find comparable companies. Calculate their margins. Select an arm’s-length mark-up. Prepare the Transfer Pricing report.

But after our first discussion, it became clear that the real issue was not the percentage.

The real issue was understanding exactly what the Indian company was supplying.

The arrangement included a mixture of:

• Software-development services

• Technical and operational support

• Access to software and technology

• Contributions toward product development

• Certain shared responsibilities relating to intellectual property

The company had agreements, invoices and accounting records. However, those documents did not clearly separate the different elements of the transaction.

That distinction mattered.

A routine software service, a software licence and a contribution toward jointly developed intellectual property may require entirely different Transfer Pricing treatment.

Before determining the price, we first had to understand the transaction.

The client’s identity and commercial figures have been withheld. Certain facts have been simplified for confidentiality.

The client had been following a cost-plus approach for its invoices.

The Indian company calculated its expenses, added a mark-up and raised invoices on the US company.

This is a common arrangement within India–US technology groups. It can also be commercially reasonable.

But there was no documented answer to several important questions:

• Which costs should form part of the mark-up base?

• Was the Indian company merely executing instructions?

• Did it contribute to product strategy or software architecture?

• Who controlled development priorities?

• Who bore the risk of project failure or rework?

• Who owned or economically controlled the software IP?

• Was part of the payment actually connected with a licence or intangible?

• Would independent companies have structured the arrangement in the same way?

The invoices recorded the amount charged.

They did not explain why that amount was at arm’s length.

That gap may remain unnoticed during routine compliance. It usually becomes visible when the company faces a tax assessment, audit, investor due diligence or business restructuring.

Transfer Pricing studies sometimes begin with a search for comparable companies.

Our work began with conversations.

We spoke with the finance and operational teams to understand how the business actually functioned.

We examined:

• How customers were acquired

• Who negotiated commercial terms

• Who determined product pricing

• Where the software developers were located

• Who designed the product architecture

• Who approved new features

• Who controlled development budgets

• Who was responsible when a project failed

• Who funded research and product development

• Who legally owned the software

• Who made the decisions that increased the value of the technology

This exercise is generally described as a functional, asset and risk analysis.

For a technology business, however, the analysis must go beyond job titles and contractual wording.

If an agreement describes the Indian company as a “service provider,” but its team is making critical product decisions and developing valuable technology, the agreement may not reflect the economic reality.

Transfer Pricing follows the substance of the arrangement—not merely the label placed on it.

The existing arrangement treated most payments as one combined software transaction.

We separated it into distinct streams.

This stream covered activities performed according to defined requirements, where the Indian company did not independently control the product or exploit the resulting IP.

For this part of the arrangement, a cost-plus model could be commercially and technically appropriate.

Where one group entity permitted another entity to use proprietary software, platforms or technology, the payment could not automatically be treated as part of a normal service mark-up.

The rights granted, geographical scope, exclusivity, duration and commercial value of the technology needed separate consideration.

This was the most sensitive area.

Both companies had participated in certain development and decision-making activities. We therefore examined who performed and controlled the functions responsible for developing, enhancing, maintaining, protecting and exploiting the software.

The objective was not simply to identify the legal owner.

We needed to understand which company was creating and controlling the economic value.

By separating these transaction streams, the group could avoid forcing every payment into a single cost-plus formula.

Once the routine service component was clearly identified, we could begin the benchmarking exercise.

For that stream, the Indian entity was evaluated as the potential tested party. Its operating margin on relevant operating costs was compared with the margins earned by independent software-service companies performing reasonably similar functions.

However, identifying comparable companies is not a mechanical exercise.

A company should not be selected merely because its annual report contains the words “software” or “IT services.”

We screened potential comparables for several factors, including:

• Nature of services

• Related-party transactions

• Availability of financial information

• Employee-cost profile

• Persistent losses

• Ownership of valuable products or IP

• Extraordinary business events

• Functional differences

• Revenue from software products versus services

Product companies, knowledge-intensive businesses and companies owning valuable proprietary technology could distort the comparison with a routine service provider.

Each accepted and rejected company therefore needed a documented reason.

The result was not just a list of names.

It was an evidence-based comparable set that could explain why each company belonged—or did not belong—in the analysis.

Another difficulty emerged during the exercise.

The company’s financial statements combined the costs and revenue of different activities.

Without segmental information, the operating margin of the routine service stream could be affected by:

• Product-development expenditure

• Licence-related income or costs

• Non-operating foreign-exchange movements

• Exceptional expenditure

• Pass-through costs

• Activities performed for unrelated customers

We worked with the finance team to create a more reliable segmental profitability statement.

The objective was to ensure that the margin being tested related to the same activity that was being benchmarked.

This is an important but frequently overlooked point:

A sophisticated benchmarking study cannot repair an unreliable cost base.

The underlying accounts, cost allocation and transaction classification must support the final conclusion.

Safe harbour can offer greater certainty for eligible transactions when the prescribed conditions and margins are satisfied.

But certainty has a commercial price.

A company should not select safe harbour only because it appears simpler.

We compared:

• The company’s actual operating margin

• The arm’s-length result from benchmarking

• The applicable safe-harbour requirements

• The additional margin cost

• The expected duration of the arrangement

• The possibility of future changes to the business model

• The potential effect on dispute-resolution options

The decision had to reflect the client’s actual business and risk appetite.

For some businesses, paying a higher accepted margin may be worthwhile for certainty. For others, a properly maintained annual benchmarking study may be more commercially suitable.

Importantly, safe-harbour analysis was considered only for the eligible service stream. It was not treated as a blanket answer for the licence or shared-IP elements.

A Transfer Pricing report cannot operate in isolation.

If the agreement says one thing, the invoices say another and the accounting records show something different, the documentation becomes difficult to defend.

We therefore aligned the following records:

• Intercompany service agreement

• Software and IP-related clauses

• Scope-of-work documents

• Invoicing descriptions

• Cost-allocation policy

• Segmental profitability

• Transfer Pricing method

• Benchmarking conclusion

• Accountant’s report and tax disclosures

The language was revised to reflect what the parties were genuinely doing.

This did not mean rewriting the history of the transaction.

It meant ensuring that future documentation accurately captured the commercial arrangement.

The final result was more than a Transfer Pricing report.

The client received a practical intercompany pricing framework covering:

• Classification of each transaction stream

• Functions and responsibilities of both entities

• Treatment of the routine service component

• A defined operating-cost base

• A supportable service mark-up methodology

• Separate consideration of licence and IP-related elements

• A process for maintaining segmental accounts

• An annual benchmarking and documentation calendar

• Alignment between contracts, invoices, accounts and tax reporting

The company could now explain not only what it charged, but also why it charged that amount.

The finance team also had a framework for raising future invoices instead of revisiting the pricing question at the end of every financial year.

That was the most useful outcome.

The exercise transformed Transfer Pricing from a year-end compliance document into an operating policy.

Many cross-border software groups begin informally.

The founders know each other. The teams collaborate across countries. Developers in India work closely with sales and product teams in the United States.

Payments are initially made using a convenient cost-plus formula.

As the business grows, however, the arrangement becomes more complex.

The Indian team may begin contributing to product architecture. New software may be jointly developed. Customer and market risks may shift. Valuable IP may emerge without a corresponding change in the agreements.

A pricing model that was reasonable during the company’s early stage may no longer reflect its economic reality.

That is why Transfer Pricing should be reviewed when:

• The functions of either company materially change

• A new product or technology is developed

• IP ownership or control changes

• The group enters new markets

• The Indian company begins serving external customers

• Senior decision-makers move between jurisdictions

• New licence or royalty arrangements are introduced

• The group raises investment or undergoes due diligence

Annual compliance is necessary.

Periodic business-model review is equally important.

The most important Transfer Pricing question is rarely:

“What mark-up do other companies charge?”

The better starting point is:

“What does each company actually do, own and control?”

Once the transaction is properly understood, the method, comparables and pricing range become easier to determine.

A filed form records the position taken by the company.

A properly structured arrangement explains and defends that position.

At SilverSiX Consultant, we assist India–US and other cross-border business groups with Transfer Pricing benchmarking, intercompany agreements, safe-harbour evaluation, Form 3CEB support and wider international-tax documentation.

Price it correctly. Document it consistently. Review it as the business evolves.

📩 contact@silversix.pro
🌐 www.silversix.pro

This article is intended for general informational purposes and does not constitute legal or tax advice. Transfer Pricing treatment depends on the facts, applicable law and documentation of each case.