Intercompany Pricing in D365: Where the Transfer Price Comes From and Who Owns the Margin

The planning article ended with planned purchase orders firmed into an intercompany chain. From that moment a number appears on the intercompany sales order and on the intercompany purchase order that nobody typed: the transfer price. In my experience it is the least understood field in the chain: supply chain assumes finance owns it, finance assumes it falls out of the trade agreements, and whoever built the trading relationship in the setup article clicked past the price search policy. This article covers where that number comes from, three ways to decide what it should be, and what each choice does to the margin in each legal entity.

WHY THE TRANSFER PRICE IS NOT JUST A NUMBER

Within one legal entity, moving stock between warehouses is a transfer order with no revenue or cost of sales involved. Across legal entities the same movement is a sale in one company and a purchase in the other, and D365 treats it as exactly that. The selling company books revenue at the transfer price and cost of sales at its own inventory cost. The buying company receives at the transfer price, which becomes its inventory cost and later its cost of sales. So the transfer price does three jobs at once: it splits group profit between two entities, it sets the cost basis of the receiving company, and it is the number a tax authority may one day ask you to justify.

WHERE THE PRICE IS ACTUALLY SEARCHED

When the intercompany purchase order is created in the buying company, the intercompany sales order is created in the selling company and the two documents exchange fields through the synchronisation described in the order chain article. Price is one of the synchronised fields, but only one side is allowed to find it; the other side copies it. Which side searches is decided by the price and discount search setting in the purchase order policies of the intercompany vendor in the buying company. The default is the intercompany sales order: the selling company runs its normal sales price search for the intercompany customer, finds the price in its sales trade agreements, and the result is written back onto the purchase order line. The alternative points the search at the intercompany purchase order, so the buying company's purchase trade agreements for the intercompany vendor decide and the sales order copies the result. A third option, original sales order, applies to direct delivery chains and carries the external sales price onto the intercompany documents, which is only right when the group wants the transfer price to equal the external price.

I nearly always leave the default in place and maintain prices on the selling side. The selling company knows its cost and will be asked to defend its revenue, so its sales trade agreements are the natural home for the transfer price. Searching on the purchase side only makes sense when a central purchasing entity dictates prices to many small supplying entities Pick one direction per trading relationship and document it..

WHAT THE SALES PRICE SEARCH SEES

Because the default search is an ordinary sales price search, everything you know about sales pricing applies to the intercompany customer. The search walks sales price trade agreements for the customer account, then the customer price group, then all customers, across item, item group, and all-items levels, and respects quantity breaks, date ranges, currency, and unit of measure. Line, multiline, and total discounts are evaluated the same way if the activation flags allow them. The intercompany customer is just a customer, so its price group, discount groups, and currency all affect the result. That is the strength and the risk: it is flexible, and it is easy for an intercompany customer to inherit a price group meant for external distributors. I give intercompany customers their own price and discount groups from day one, even when the first list is identical to the external one, so the two can diverge later without surprises.

Currency deserves a sentence of its own. The sales order is priced in the intercompany customer's currency and the purchase order in the intercompany vendor's. If they differ, both documents are created, but one carries a converted amount and the two sides drift by exchange rate and rounding. Keep the pair in one currency unless there is a strong reason not to.

THREE WAYS TO DECIDE THE NUMBER

The search mechanism tells D365 where to look, not what the price should be. In practice I see three approaches, and most groups use more than one depending on the item.

• Negotiated price. The supplying and receiving entities agree a price per item, sometimes per quantity break, and it is entered as a sales trade agreement for that intercompany customer. Simplest to implement, hardest to govern: every change is a conversation and a journal, and after a few years nobody remembers why item A carries a different margin than item B.

• Cost plus markup. The price is derived from the supplying company's cost. On the released product, the sales price model can be set to contribution ratio with the base price taken from the cost price, so the item sales price moves when the cost moves. For manufactured items I prefer the BOM calculation route: the cost version carries profit settings per cost group (the standard profit setting and up to three alternatives), the calculation produces a sales price alongside the cost, and that price is transferred into a trade agreement journal for the intercompany price group The markup is then explicit and recalculated with every cost roll..

• Fixed transfer price list. Finance or tax sets the prices in advance, typically once a year, and they are loaded as a price agreement journal against the intercompany price group with a validity period. The price ignores cost changes during the year by design, because the margin split was agreed with the tax position in mind and should not wander.

All three end in the same place: a sales trade agreement that the intercompany sales order finds. The difference is who maintains it, how often it changes, and how well you can explain it afterwards. I recommend cost plus markup for manufactured goods because it keeps the supplying entity whole on cost and shows the group margin as one percentage; fixed lists suit purchased goods resold between entities where stability matters more than a precise cost link.

WHAT HAPPENS TO MARGIN IN EACH COMPANY

Follow one unit through a chain with a twenty percent markup on a cost of 100. The selling company invoices 120, books revenue of 120 against cost of sales of 100, and shows a margin of 20. The buying company receives at 120, now its inventory cost. With a moving or weighted average method, the 120 flows into its average and into cost of sales when it sells outward at, say, 150, leaving a margin of 30. With standard cost the story differs: the gap between the item's standard and the 120 transfer price posts as a purchase price variance at receipt or invoice. A buying company whose standard still reflects last year's transfer price shows variances all year, and they are the first thing an auditor asks about. Whenever the transfer price changes, the receiving company's standard cost needs a matching cost version update, the same cutover discipline described in the standard cost article.

At group level the 20 the selling company earned is not real profit until the buying company sells the unit outward. While the unit sits in the buying company's warehouse, the group has 20 of unrealised intercompany profit in inventory, and consolidation has to eliminate it. D365 does not eliminate it from the trade documents; it is a consolidation exercise that needs the intercompany profit per item to be derivable, one more reason to prefer a formula-driven markup over scattered negotiated prices.

CHARGES, FREIGHT, AND THE EDIT POLICIES

Two smaller settings bite often. The first is charges. Freight or handling added to the intercompany sales order as a charge can be transferred to the purchase order if the trading relationship allows it, where it becomes part of the buying company's landed cost. If it is not transferred, the seller has revenue the buyer never sees as cost and the two sides will not reconcile. Decide this per relationship and keep charge codes consistent in both companies.

The second is the allow price edit settings in the sales and purchase order policies. With edits allowed, a user on either side can overtype the price after creation, and whether the change flows across depends on the field synchronisation you configured. I lock price editing on the purchase side in almost every design: the buying company should not decide what it pays its sister company. On the sales side I allow it only for a pricing role, and expect them to fix the trade agreement rather than the order.

WHAT GOES WRONG

• The intercompany sales order is created at a zero price. No matching sales trade agreement, no fallback, no base sales price on the item; the chain creates anyway and the mistake surfaces at invoicing. A trade agreement at the all-customers level for the intercompany price group as a safety net prevents this.

• The buying company pays external distributor prices. The intercompany customer was created by copying an external customer and inherited its price group. Give intercompany customers their own groups.

• Prices differ between the two documents. Somebody changed one side after creation with edit allowed and price synchronisation disabled in the other direction. Decide which document is master and align the edit and synchronisation settings with that decision.

• Purchase price variances every month in the buying company. The transfer price moved with a cost roll in the supplier and the receiver's standard cost was never updated. Tie the two updates to the same calendar.

• Margins look wrong after a direct delivery. The relationship prices from the original sales order, so the seller earns the full external price and the buyer shows no margin. Legitimate in some groups, an accident in others; make sure yours is the former.

Before going live, confirm: one search direction per relationship, dedicated price and discount groups for intercompany customers, a safety-net trade agreement so no line prices at zero, a documented rule for how prices are derived and who maintains them, matching currency and price unit on both sides, charge transfer decided, price editing locked where it should be, and a calendar that updates the receiving company's standard cost whenever the transfer price changes.

Next time I will look at intercompany invoicing and reconciliation: how the intercompany sales invoice and the purchase invoice are posted, due to and due from accounts, matching the two sides at period end, and the basics of eliminating intercompany profit in inventory.

In this series: previous article Intercompany Master Planning in D365: Planned Intercompany Demand and the Plan Run Sequence