Shared Services TP: Benefit Test, Cost Pools and Allocation Keys

A shared service centre (SSC) — or a low-value-adding service arrangement (LVAS) between group companies — is the fact pattern where transfer pricing spends its time on the benefit and the allocation rather than on a price. There is no market price for “the group’s finance function serving three entities”. What there is instead is a cost pool, a key, and a benefit analysis that justifies both. Each of the three is examinable, and the file is built around all three.

The benefit test: is a charge owed at all?

The first question is not how much — it is whether. The OECD standard is the benefit test: a service is chargeable only where the recipient would pay an independent third party to provide it — where the service confers an economic or commercial benefit, considering the recipient’s circumstances as a whole.

Service type	Benefit analysis	Charge
Would the recipient outsource this if it stood alone? (payroll, AP/AR, IT support, legal compliance)	Yes — the benefit is obvious	Cost + an arm’s length mark-up (or the safe harbour where available)
Purely intra-group, or a compliance obligation of the provider (group reporting, internal audit for the group, the parent’s own governance)	No benefit to the recipient; the cost is the provider’s own	No charge — or the cost stays with the provider
The recipient gets a service it could buy, but cheaper to ignore (the “soft” benefit)	Arguable — document the hypothetical-outsourcing test with the market rates for the alternative	Charge, with the benefit memo carrying the hypothetical comparison

The double counting trap is the reverse failure: charging the service to every entity that touches it, so the cost is recovered more than once. The cost pool is allocated once, in full, across the benefited entities — 100% of the cost, split among the recipients — not “a share” to each.

Cost pool design

The pool is the base the key divides, and the pool’s boundaries are a method decision:

1. Direct costs in. The costs of performing the service: staff cost (salaries, benefits, statutory dues) of the service centre team, the dedicated technology, the dedicated overheads.
2. Overhead allocation — stated and applied. The centre’s share of the provider entity’s common overheads (premises, IT infrastructure, administrative support) enters via a stated allocation basis (headcount, floor space, usage), applied consistently. The basis is documented; the application is arithmetical.
3. What stays out. The provider’s own governance and headquarters costs (the board, the parent’s own administration), costs with no service content, and — critically — profits: the pool is a cost pool. The mark-up (where one is owed) is applied to the pool, not embedded in it.
4. Consistency across years. The same pool definition, same overhead basis, every year. A pool that quietly grows its content (a new cost line added without disclosure) is a pool the TPO will reconstruct and find different.

Allocation keys that match the benefit

The key answers how much of the pool each recipient bears. The standard: the key must approximate the benefit received — and the common keys are:

Key	Fits when	Watch out for
Headcount / FTE	The service is per-employee (payroll, HR, basic IT support)	Part-timers, contractors and the definition of “headcount” must be stated
Revenue	The service scales with the recipient’s commercial activity (order processing, credit management)	Revenue definitions must match across recipients (gross vs net, related vs third-party)
Usage / volume	The service is meterable (transactions processed, calls handled, GB consumed)	The meter must exist and be neutral — a usage key built on the provider’s estimates is a headcount key in disguise
Asset base	The service relates to assets (property management, fleet, insurance processing)	The asset definition and valuation basis, stated

The choice is documented with the reasoning — why this key approximates the benefit for this service — and where a blend is used (say, 70% headcount / 30% revenue for a blended HR+payroll service), the blend and its rationale are stated too. A key applied without the benefit link is the first thing the examination questions: “why headcount, when the service scales with transactions?”

LVAS: the low-value-adding corner

Where the intra-group services are genuinely low-value — routine, administrative, no significant intangibles or risk — the fact pattern qualifies for the LVAS treatment:

• OECD approach: for ancillary, low-value services where no significant intangibles or risks are transferred, cost-only compensation (no mark-up) is appropriate — documented as LVAS in the Local File.
• India safe harbour: the safe harbour regime covers low-value-adding intra-group and ancillary services at a margin not exceeding 5% of the total value (within the transaction limit) — see the safe harbour guide for the current circumstances and the Form 3CEFA election. The LVAS safe harbour is the Indian fact pattern where “cost + a small margin, no benchmark” is a prescribed position rather than an argued one.

The LVAS classification is a claim, not a description: the file must show the service is low-value-adding (the function list, the absence of intangibles and risk in the service itself), and a service that is not low-value-adding priced as LVAS is an under-charge the examination will find.

The documentation pack

The shared-services file is a small, tight pack:

1. The service agreement(s) — scope, term, the pricing mechanism (cost plus X%, the LVAS margin), the allocation method. See intercompany agreements for the clauses that carry the weight.
2. The benefit memo — per service: the benefit analysis, the hypothetical-outsourcing test, the conclusion (charge / no charge / LVAS).
3. The cost pool schedule — the lines in, the overhead allocation basis, the lines out, year by year.
4. The allocation working — the key(s), the recipient data (headcount, revenue, usage), the per-recipient charge.
5. The mark-up — where a mark-up is owed (non-LVAS services): the benchmark (TNMM on OP/OC for the service function, or the safe harbour margin where elected), with the matrix.

The TPO’s recurring challenges

• The benefit denied — “the recipient would not have paid for this” — met with the hypothetical-outsourcing evidence and the market rates for the alternative.
• The key substituted — the TPO re-allocates on its own key (usually a simpler one), moving the charge between entities. The defence is the benefit-link documentation for the chosen key.
• The pool rebuilt — overhead lines questioned (the “group headquarters cost” inside a service pool), the mark-up benchmarked fresh. The defence is the pool schedule and the stated mark-up method.
• The LVAS claim examined — the service re-characterized as non-routine. The defence is the function list and the absence of intangibles/risk in the service itself.

See also

• Intercompany agreements
• India safe harbours
• Functional analysis (FAR)