LinkedIn highlights

Most debates about PLIs miss the point entirely.

"We always use Operating Margin for distributors." "Berry Ratio is standard in our firm." "Our template says Net Cost Plus."

But PLI selection has never been about preference. The OECD doesn't prescribe a single preferred PLI - selection depends on which indicator provides the most reliable measure in your specific circumstances.

In practice, the decision comes down to one question:

What does this entity get paid for?

→ Sales execution? → Operating Margin → Cost efficiency? → Net Cost Plus → Capital deployment? → Return on Assets → Low-risk intermediation with value in OPEX? → Berry Ratio (maybe)

That "maybe" matters. Berry Ratio works only when COGS is pass-through and operating expenses capture the value-add. Yet it's heavily litigated in India, less commonly accepted in Germany, and requires careful documentation of OECD conditions.

Here's what most people overlook:

Your denominator definition often matters more than the PLI name.

Same company, same economics. Classify €40 differently between COGS and OPEX:

→ Berry Ratio moves from 1.25 to 1.375

That swing alone can push you from "in range" to "adjustment required."

If your PLI analysis "works" only under one convenient denominator mapping - expect audit scrutiny.

So document: 1. Why this PLI matches your tested party's value driver 2. What's included/excluded in your denominator (and why) 3. How you applied the same definitions to comparables 4. What happens if classifications shift

When did you last check whether your PLI actually matches the tested party's economics - rather than just what the template says? | 10 comments on LinkedIn

The most common "testing" I see in local files:

"Our policy applies a 3% cost-plus markup. Therefore, the transaction is arm's length."

That's not testing. That's circular reasoning.

Here's how it usually works: - Take the transaction amount - Subtract 5% - Call the result "Costs" - Calculate that a 3% markup was achieved - ??? - Declare compliance

You've proven nothing. You've just shown that your arithmetic is correct.

Actual testing means comparing results against independent benchmarks at the function level - the contract manufacturing activity, the distribution function, or the service provision.

Sometimes you can test at the individual counterparty level if your data allows proper segmentation. But the baseline is testing the function performed by the entity.

For a contract manufacturer:

- What was the actual result on the manufacturing function for the year? - How does it compare to the benchmark range? - If it's outside the range, why?

If your local file only says that policy was "applied", you haven't demonstrated arm's length results.

How many local files have you seen where "testing" is just arithmetic proving the policy was followed?

Your transfer pricing setup is like a house. Documentation is the paint job - visible, but it won't fix a crumbling foundation.

Problems flow upward:

Bad foundation: - No economic substance behind legal structures - Value chain that doesn't reflect how the business actually operates - Complex arrangements with no commercial rationale

Bad implementation: - ERP systems that can't execute your policies - Finance teams making manual workarounds - Year-end adjustments nobody fully understands

Bad documentation: - Local files that describe what should happen, not what does - Benchmarking studies with generic search strategies - Calculations that even internal teams struggle to explain

You might pass a desktop review. Your local files might tick every compliance box. You might even have sophisticated automation tools.

But when tax authorities start asking real questions:

"Show me how these prices are actually calculated." "Walk me through your value chain." "Explain this year-end adjustment."

That's when foundations get tested.

Start there:

1. Align economic substance with legal form 2. Design policies your finance team can actually implement 3. Build monitoring that catches problems during the year 4. Create intercompany agreements that reflect reality 5. Run benchmarks with defensible, documented methodology

What's your experience? Have you seen transfer pricing structures that looked solid on paper but crumbled under audit pressure?

Your transfer pricing policy looks perfect on paper. Clean documentation, robust benchmarks, proper method selection.

Then you check how your finance team actually implements it.

You find:

- Wrong cost base calculations - Outdated Excel sheets with hardcoded numbers - Manual price adjustments that never happened - Currency effects nobody accounted for - Budget figures from two years ago - Missing transaction data - Year-end adjustments that make no sense

Transfer pricing isn't just policy design. Implementation makes or breaks your position.

The fix starts upstream:

1. Involve your finance team before finalizing policies 2. Map how data flows through your ERP 3. Build calculation rules that can actually be executed 4. Create monthly monitoring - not just year-end reconciliation 5. Document pricing updates as they happen 6. Test actual transactions against policy regularly

As a transfer pricing advisor, bridging this gap is part of the job. A policy nobody can implement correctly is just expensive paperwork.

When was the last time you checked how your client actually executes their transfer pricing? Pull 5 random transactions today. You might be surprised what you find. | 11 comments on LinkedIn

Every transfer pricing audit eventually gets to this question:

"Is your policy actually applied?"

The honest answer from most TP teams: "We should ask Finance."

The problem is that tax authorities won't accept "I'm not Finance" as a defense.

Your policy document means nothing if you can't demonstrate how it translates into actual invoices, actual cost bases, and actual margins in the books.

When was the last time you pulled 5 random intercompany transactions and checked if they match your policy?

You've seen it. And you've lived it (I did).

"Quick! We need a benchmark study!" "Just do a year-end adjustment." "Copy-paste last year's Local File." "Tax audit notice - all hands on deck!"

This is transfer pricing by panic. Reactive. Disconnected. Exhausting.

The symptoms are everywhere:

→ Intercompany agreements that nobody can find → Invoices that don't match the policy → Entity classifications that change depending on whom you ask → Markups adjusted on the fly with no documentation → Local files that could belong to any company in the industry

The root cause is always the same: Tax, Legal, Finance, and Operations working in silos. Each team solves its own problem. Nobody owns the system.

A transfer pricing system looks different:

Strategy layer: → Global TP policy that defines the rules → Value chain analysis aligned with economic substance → Intercompany agreements that reflect reality

Operations layer: → Prices embedded in ERP with real-time monitoring → Documentation generated from actual data → Single source of truth for financial reporting

Defense layer: → Audit-ready files built throughout the year → KPIs that flag problems before they become adjustments

The difference between the two comes down to timing.

Random acts happen at year-end. Systems run all year.

Random acts react to audits. Systems anticipate them.

Random acts check boxes. Systems create defensible positions.

Building the system takes effort upfront. But it costs far less than the alternative - explaining why your transfer pricing "strategy" is actually just a collection of disconnected fixes held together by hope.

When you look at your current setup, is it a system or a series of random acts?

Every January, the same articles appear.

"AI will transform transfer pricing!" "Real-time reporting is coming!" "Pillar Two changes everything!"

The headlines are right. But the sequencing is often wrong.

What will make noise in 2026: Foundational AI progress (ClawdBot anyone?). Real-time reporting. Pillar Two tools. Big Data analytics. Automated compliance dashboards.

These technologies are genuinely powerful. The question is what you point them at.

What will actually matter:

Operational TP that works. Documentation generated from real data. Controversy cases that need defending. Value chain alignment. Policy consistency across entities. Data you can actually trust.

This is where AI creates real leverage - automating the tedious, catching inconsistencies early, scaling what used to require armies of analysts.

What never changes:

Arm's length principle. Substance over form. Functional analysis. Comparability. Economic rationale. Intercompany agreements that reflect reality.

The foundations. The stuff auditors still ask about, regardless of what tools you use.

AI works best when pointed at solid foundations. Strong foundations plus automation equals defensible positions at scale. Weak foundations plus automation equals faster mistakes.

The audits still come down to the same questions: "What does this entity actually do?" "Why is this price arm's length?" "Show me how this works in practice."

If your 2026 priorities focus only on the top tier without fixing the middle and bottom, you're automating the wrong things.

What's your biggest transfer pricing priority this year - and which tier does it fall into?

When I worked at Big4, a client asked why we selected TNMM for their distribution company.

My response?

"Because it's standard practice for distributors."

I regretted those words immediately. And made sure I never said them again.

That answer wouldn't survive a tax audit. Method selection needs economic reasoning, not just convention.

Your TNMM choice demands justification:

1. Start with CUP - Document why internal CUPs don't exist - Explain why external CUPs aren't available - If comparable transactions exist, justify why they're not reliable enough

2. Consider Resale Price Method - Check if internal comparables are available - Explain data availability constraints - Show why gross margins aren't comparable - Document market differences affecting gross profitability

3. Only then move to TNMM - Analyze all relevant PLIs - Demonstrate why operating margin comparison works better (if it does) - Explain how it accounts for functional differences - Show why it's more reliable given available data

Tax authorities challenge lazy method selection. "TNMM is standard practice" won't protect you.

Your method selection section should read like a process of elimination. Each rejected method needs specific reasons tied to your facts.

What's your experience? Have you defaulted to TNMM without proper analysis?