Anyone who has been to a transfer pricing seminar recently must have been exposed to the concept of the Principal Operating Company, or POC. In some cases, they may be called Hub Companies, or Entrepreneur, but the essence of a POC is always the same: an intellectual and financial management company responsible for all product development, production, and sales. POCs have evolved significantly over the span of my transfer pricing career, they now pack a lot more “substance,” i.e., reasonably high level executives, and are often accompanied by R&D and/or manufacturing facilities.
The transaction flows of a POC may be a bit complex, and unless you had drawn them tens of times before, as I had done, you may forget a flow or two. But the challenge of POCs is not so much in establishing the transaction flows, or figuring out the appropriate transfer pricing policies, but designing and implementing them in a way to match the commercial reality. The slide below shows how ABC Advisors presented the idea of a company called MSell-CBT to assume the role of the Global Principal within MSell:
In general, I see two important challenges in implementing POC structures:
- Is the POC really controlling the risks it is supposed to assume?
- Is the transfer pricing implemented properly in the company’s system so that the risks are borne as they were intended.
Here is an excerpt from the book where Jay, MSell Tax Director, is discussing how to implement his intended transfer pricing policies in MSell’s information technology systems.
Jay showed the proposed terms of the agreement to Daron, MSell’s Chief Information Officer, and asked him to set transfer prices accordingly. Daron, thin as a rod, always dressed in slim-cut black suits, white shirts, and retro-fifties thin black ties. To complete the picture, he sometimes donned black framed glasses. He flipped through the agreement, and read out the transfer-pricing article: “‘Transfer prices shall be set at certain discount off of the Retailer’s average resale price so as to leave Retailers with an arm’s length Operating Margin for the current fiscal year.’ Is this what you want me to code into the system?’”
Jay explained that this sentence provided the basics of transfer pricing. What Daron needed was simply the prices for each and every SKU they had. Daron elaborated, “That is what the system understands. Either a number or a formula linking to some other information related to that SKU, such as standard cost. We do not track average selling prices. I can have a set report for you to run periodically to get average selling prices. But you have to convert them to transfer prices and enter them manually.”
Jay, of course, did not want to invent a new task of manually updating and entering price lists. He pressed Daron to design the system to pick up average selling prices. Daron just shrugged it off, “My system will not know what price they put on a piece of merchandise in France unless, of course, someone bothers to enter it.”
Jay replied, “Doesn’t make sense to me. How do you then come up with revenue if we do not know the sales price?”
“Apparently by not multiplying prices and units sold.”
“Then how do we know what a store sold?”
“We don’t. A system that tracks every piece of merchandise through and through would run us another $10 million. Do you have that kind of budget?”
Jay could not come up with the $10 million and ended up settling for a different way to implement his intended transfer pricing policy. After some back and forth, he revised his agreement to read “Transfer prices shall be set monthly as a markup on standard cost of merchandise, targeting an arm’s length Operating Margin for the Retailers for the current fiscal year.”