Intercompany Trade Setup in D365: Trading Relationships, Order Policies, and Defaults
With the asset management thread wrapped up in the asset analytics article, I am starting a new series on a subject that touches almost every multi-entity D365 implementation and is still set up badly more often than well: intercompany trade in Finance and Supply Chain Management. Over the coming articles I will walk the order chain, planning, pricing, accounting and reconciliation, returns, warehouse flows, and the failure patterns. Today is the foundation: what a trading relationship is, how the intercompany customer and vendor pair works, what the order policies do, and where the values on an intercompany order come from. Get this layer right and the rest of the series is about behaviour; get it wrong and every later article becomes a troubleshooting guide.
WHAT INTERCOMPANY TRADE MEANS IN D365 TERMS
Two legal entities in the same D365 environment trade with each other. The selling entity sees the buying entity as a customer; the buying entity sees the selling entity as a vendor. Intercompany trade ties those two master records together so that a purchase order in the buying entity produces a matching sales order in the selling entity, and so that documents posted on one side (confirmation, packing slip, invoice) update the other side without anyone retyping anything. It is not a consolidation feature, not a transfer order, and not a substitute for intercompany accounting in the general ledger, which comes later in the series. It is a document synchronisation mechanism between a customer and a vendor who happen to be the same group, and because both live in one database, D365 can create the counterpart order and post documents in both companies from a single action. Those conveniences are what the setup governs.
THE PREREQUISITES PEOPLE SKIP
Before you touch the intercompany form, four things need to be true.
• The products are released in both legal entities with the same item number. Intercompany does not translate item numbers; the two sides must agree on the product identity, its dimension groups, and its unit of measure.
• The buying entity has a warehouse with a real address. The intercompany sales order takes its delivery address from the purchase order, which takes it from the receiving warehouse (or from the original customer in direct delivery). Warehouses without addresses produce orders without addresses.
• Number sequences exist on both sides and you have decided how intercompany orders should be numbered (more below). If both entities share one sales order sequence, some options will collide.
• Currency, exchange rates, sales tax groups, and posting profiles are in place on both master records. If the vendor has no payment terms, the intercompany purchase order has none either, and the invoice fails at the end of a chain that otherwise worked.
CREATING THE CUSTOMER AND VENDOR PAIR
Start with the master records. In the selling entity, create a customer that represents the buying entity with a proper customer group, currency, and terms. In the buying entity, create a vendor that represents the selling entity in the same way. I name both records after the legal entity they represent and put the entity ID in the account number, because in a group with ten entities and forty relationships you will otherwise spend your life hovering over account numbers.
Then open the Intercompany action on either record. The form is the same from both sides, and once saved it appears on both records. On the trading relationship tab you mark the relationship active and point the record at its counterpart: from the customer you choose the vendor company and the vendor account that represents this selling entity there; from the vendor you choose the customer company and customer account. Save, and you have a trading relationship.
One relationship, two master records, one set of policies. Do not create it from the customer side and again from the vendor side "to be safe": that gives you two competing relationships and a confusing week. Set it up once and verify it shows on the other record.
SALES ORDER POLICIES: WHAT THE SELLING ENTITY WILL DO
The sales order policies tab governs the intercompany sales order created in the selling entity. The decisions that matter most:
• Numbering. The intercompany sales order can take a number from the selling entity's own number sequence, reuse the original purchase order number, or use the purchasing company ID plus the original number. I almost always choose company plus original number, because it makes the chain readable at a glance: sales order DEMF-000123 in the selling entity is obviously the twin of purchase order 000123 in DEMF. The original number option is tempting for the same reason, but it breaks as soon as two buying entities share a sequence or the selling entity's own sequence produces the same number.
• Reference fields. The policies decide what lands in the customer requisition and reference fields on the intercompany sales order. Carrying the purchase order number there gives warehouse and finance users a visible link to the buying entity.
• Automatic creation. In the standard flow the intercompany sales order is created when the purchase order is confirmed, and the policies together with the intercompany settings on the order header decide whether that happens on its own or waits for a user to trigger it from the intercompany menu. I prefer creation on confirmation and nothing earlier, because it gives the buyer a moment to fix the purchase order before it becomes visible to the other entity's planners, and because a purchase order that has already spawned a sales order is a common source of orphaned demand when someone deletes the wrong side.
• Direct delivery behaviour. When an original sales order is flagged for direct delivery, the chain grows a third document, and the policies decide whether the selling entity may post the packing slip and invoice for the original customer as a summary update. I leave direct delivery off in the first phase and switch it on once the basic chain is stable; it will get its own article.
PURCHASE ORDER POLICIES: WHAT THE BUYING ENTITY WILL ACCEPT
The purchase order policies tab is the mirror image: it governs what happens to the intercompany purchase order when the selling entity posts something. The switches that matter most are the automatic posting ones. When the intercompany sales order posts an invoice, the buying entity's purchase order can post its invoice automatically, so that the payable in one company and the receivable in the other appear in the same second with the same amounts. The same idea applies to the product receipt when the packing slip is posted. Whether you want that depends on who owns receiving in the buying entity: a company with Advanced WMS and a physical dock does not want product receipts posted by a packing slip in another company, because nothing has arrived yet; a company that buys services, or treats intercompany stock as available on shipment, usually does.
The other policy I always set deliberately is whether indirect creation of intercompany orders is allowed, which is what lets a chain continue through a third entity: the intercompany sales order in the middle entity itself triggers a purchase order to a further entity. It is powerful in a group with a central procurement company and a nightmare when switched on by accident, because one customer order can create six documents across three companies before anyone notices.
VALUE MAPPING: TRANSLATING CODES BETWEEN ENTITIES
Two legal entities in one database still have separate code tables for modes of delivery, delivery terms, payment terms, and charges codes. When the intercompany sales order is created, D365 copies these from the purchase order, and if a code does not exist in the selling entity the order is created without it or the creation fails, depending on the field. The value mapping tabs on the intercompany form let you map the codes through external codes so that a mode of delivery called TRUCK in one entity becomes ROAD in the other. Harmonising the code tables is the better answer when you control both entities; if you have inherited different setups from different rollouts, mapping is the pragmatic route, and it is worth doing before the first order rather than after the first failure.
WHERE THE ORDER DEFAULTS REALLY COME FROM
The question I am asked most is why a value on the sales order side does not match the purchase order side: a different warehouse, date, or price. The answer is almost always that the value did not come from the trading relationship at all.
The trading relationship supplies numbering, automation, and mapping; everything else defaults as on a normal order. The intercompany sales order takes its site and warehouse from the released product's default order settings in the selling entity, or from the intercompany customer's default delivery settings if you have set them. The purchase order takes its receiving site and warehouse from the released product's default order settings in the buying entity, or from the vendor. Prices come from the trade agreements each entity holds for its own intercompany customer or vendor. Sales tax comes from the customer, vendor, and item sales tax groups in each entity. If the two sides disagree, look at the master data in each entity before the intercompany form, because the form does not decide those values.
That also explains a design rule I apply everywhere: maintain the intercompany price on one side only. If both the selling entity and the buying entity hold trade agreements for the relationship, you have two prices and one of them will be wrong. The pricing article in this series will cover which side should own it and how transfer pricing approaches map onto the options; for now, decide who owns it and leave the other side empty so the order chain can fill it.
A SETUP CHECKLIST THAT SURVIVES CONTACT WITH USERS
1. Release the products in both entities with matching item numbers, dimension groups, and units, and check default order settings name a real site and warehouse in each.
2. Create the intercompany customer and vendor with complete financial defaults, then activate the relationship from one record and verify it appears on the other.
3. Set numbering to company plus original number, decide the reference fields, and choose creation on confirmation for the first phase.
4. Enable automatic posting only where the buying entity's receiving process wants it; leave indirect creation off unless a three-entity chain is a stated requirement.
5. Harmonise or map the code tables, decide which entity owns the price, and remove competing trade agreements on the other side.
6. Create one purchase order for one line, confirm it, and follow the chain: check the sales order number, address, warehouse, date, and price before anyone creates a real one.
WHAT GOES WRONG
• The relationship is created twice, once from each side, and orders start pairing with the wrong counterpart or failing to create at all.
• Numbering uses the original number while two entities share a sequence, and the second entity's orders fail because the sales order number already exists.
• The item is not released in the selling entity, or has a different unit, and sales order creation fails with an error the buyer never sees because it fires in a company they cannot access.
• Automatic product receipt is switched on for an entity that runs a physical receiving process, and stock appears on hand in the buying warehouse before the truck has left the selling one.
• Both entities carry trade agreements for the same relationship, and the two invoices in the chain post at different prices that reconciliation later has to unwind.
• Indirect creation is left on, and a routine external sales order creates a purchase order to a sister company nobody asked for.
Next time I will look at the intercompany order chain itself: what happens when a purchase order is confirmed, which fields are synchronised from the purchase order to the sales order and back, how direct delivery adds the original sales order to the chain, and what you can and cannot change on each document once the chain exists.
In this series: previous article Asset Analytics in D365 Asset Management: Lifetime Cost, MTBF, and the Replace or Repair Decision
With the asset management thread wrapped up in the asset analytics article, I am starting a new series on a subject that touches almost every multi-entity D365 implementation and is still set up badly more often than well: intercompany trade in Finance and Supply Chain Management. Over the coming articles I will walk the order chain, planning, pricing, accounting and reconciliation, returns, warehouse flows, and the failure patterns. Today is the foundation: what a trading relationship is, how the intercompany customer and vendor pair works, what the order policies do, and where the values on an intercompany order come from. Get this layer right and the rest of the series is about behaviour; get it wrong and every later article becomes a troubleshooting guide.
WHAT INTERCOMPANY TRADE MEANS IN D365 TERMS
Two legal entities in the same D365 environment trade with each other. The selling entity sees the buying entity as a customer; the buying entity sees the selling entity as a vendor. Intercompany trade ties those two master records together so that a purchase order in the buying entity produces a matching sales order in the selling entity, and so that documents posted on one side (confirmation, packing slip, invoice) update the other side without anyone retyping anything. It is not a consolidation feature, not a transfer order, and not a substitute for intercompany accounting in the general ledger, which comes later in the series. It is a document synchronisation mechanism between a customer and a vendor who happen to be the same group, and because both live in one database, D365 can create the counterpart order and post documents in both companies from a single action. Those conveniences are what the setup governs.
THE PREREQUISITES PEOPLE SKIP
Before you touch the intercompany form, four things need to be true.
• The products are released in both legal entities with the same item number. Intercompany does not translate item numbers; the two sides must agree on the product identity, its dimension groups, and its unit of measure.
• The buying entity has a warehouse with a real address. The intercompany sales order takes its delivery address from the purchase order, which takes it from the receiving warehouse (or from the original customer in direct delivery). Warehouses without addresses produce orders without addresses.
• Number sequences exist on both sides and you have decided how intercompany orders should be numbered (more below). If both entities share one sales order sequence, some options will collide.
• Currency, exchange rates, sales tax groups, and posting profiles are in place on both master records. If the vendor has no payment terms, the intercompany purchase order has none either, and the invoice fails at the end of a chain that otherwise worked.
CREATING THE CUSTOMER AND VENDOR PAIR
Start with the master records. In the selling entity, create a customer that represents the buying entity with a proper customer group, currency, and terms. In the buying entity, create a vendor that represents the selling entity in the same way. I name both records after the legal entity they represent and put the entity ID in the account number, because in a group with ten entities and forty relationships you will otherwise spend your life hovering over account numbers.
Then open the Intercompany action on either record. The form is the same from both sides, and once saved it appears on both records. On the trading relationship tab you mark the relationship active and point the record at its counterpart: from the customer you choose the vendor company and the vendor account that represents this selling entity there; from the vendor you choose the customer company and customer account. Save, and you have a trading relationship.
One relationship, two master records, one set of policies. Do not create it from the customer side and again from the vendor side "to be safe": that gives you two competing relationships and a confusing week. Set it up once and verify it shows on the other record.
SALES ORDER POLICIES: WHAT THE SELLING ENTITY WILL DO
The sales order policies tab governs the intercompany sales order created in the selling entity. The decisions that matter most:
• Numbering. The intercompany sales order can take a number from the selling entity's own number sequence, reuse the original purchase order number, or use the purchasing company ID plus the original number. I almost always choose company plus original number, because it makes the chain readable at a glance: sales order DEMF-000123 in the selling entity is obviously the twin of purchase order 000123 in DEMF. The original number option is tempting for the same reason, but it breaks as soon as two buying entities share a sequence or the selling entity's own sequence produces the same number.
• Reference fields. The policies decide what lands in the customer requisition and reference fields on the intercompany sales order. Carrying the purchase order number there gives warehouse and finance users a visible link to the buying entity.
• Automatic creation. In the standard flow the intercompany sales order is created when the purchase order is confirmed, and the policies together with the intercompany settings on the order header decide whether that happens on its own or waits for a user to trigger it from the intercompany menu. I prefer creation on confirmation and nothing earlier, because it gives the buyer a moment to fix the purchase order before it becomes visible to the other entity's planners, and because a purchase order that has already spawned a sales order is a common source of orphaned demand when someone deletes the wrong side.
• Direct delivery behaviour. When an original sales order is flagged for direct delivery, the chain grows a third document, and the policies decide whether the selling entity may post the packing slip and invoice for the original customer as a summary update. I leave direct delivery off in the first phase and switch it on once the basic chain is stable; it will get its own article.
PURCHASE ORDER POLICIES: WHAT THE BUYING ENTITY WILL ACCEPT
The purchase order policies tab is the mirror image: it governs what happens to the intercompany purchase order when the selling entity posts something. The switches that matter most are the automatic posting ones. When the intercompany sales order posts an invoice, the buying entity's purchase order can post its invoice automatically, so that the payable in one company and the receivable in the other appear in the same second with the same amounts. The same idea applies to the product receipt when the packing slip is posted. Whether you want that depends on who owns receiving in the buying entity: a company with Advanced WMS and a physical dock does not want product receipts posted by a packing slip in another company, because nothing has arrived yet; a company that buys services, or treats intercompany stock as available on shipment, usually does.
The other policy I always set deliberately is whether indirect creation of intercompany orders is allowed, which is what lets a chain continue through a third entity: the intercompany sales order in the middle entity itself triggers a purchase order to a further entity. It is powerful in a group with a central procurement company and a nightmare when switched on by accident, because one customer order can create six documents across three companies before anyone notices.
VALUE MAPPING: TRANSLATING CODES BETWEEN ENTITIES
Two legal entities in one database still have separate code tables for modes of delivery, delivery terms, payment terms, and charges codes. When the intercompany sales order is created, D365 copies these from the purchase order, and if a code does not exist in the selling entity the order is created without it or the creation fails, depending on the field. The value mapping tabs on the intercompany form let you map the codes through external codes so that a mode of delivery called TRUCK in one entity becomes ROAD in the other. Harmonising the code tables is the better answer when you control both entities; if you have inherited different setups from different rollouts, mapping is the pragmatic route, and it is worth doing before the first order rather than after the first failure.
WHERE THE ORDER DEFAULTS REALLY COME FROM
The question I am asked most is why a value on the sales order side does not match the purchase order side: a different warehouse, date, or price. The answer is almost always that the value did not come from the trading relationship at all.
The trading relationship supplies numbering, automation, and mapping; everything else defaults as on a normal order. The intercompany sales order takes its site and warehouse from the released product's default order settings in the selling entity, or from the intercompany customer's default delivery settings if you have set them. The purchase order takes its receiving site and warehouse from the released product's default order settings in the buying entity, or from the vendor. Prices come from the trade agreements each entity holds for its own intercompany customer or vendor. Sales tax comes from the customer, vendor, and item sales tax groups in each entity. If the two sides disagree, look at the master data in each entity before the intercompany form, because the form does not decide those values.
That also explains a design rule I apply everywhere: maintain the intercompany price on one side only. If both the selling entity and the buying entity hold trade agreements for the relationship, you have two prices and one of them will be wrong. The pricing article in this series will cover which side should own it and how transfer pricing approaches map onto the options; for now, decide who owns it and leave the other side empty so the order chain can fill it.
A SETUP CHECKLIST THAT SURVIVES CONTACT WITH USERS
1. Release the products in both entities with matching item numbers, dimension groups, and units, and check default order settings name a real site and warehouse in each.
2. Create the intercompany customer and vendor with complete financial defaults, then activate the relationship from one record and verify it appears on the other.
3. Set numbering to company plus original number, decide the reference fields, and choose creation on confirmation for the first phase.
4. Enable automatic posting only where the buying entity's receiving process wants it; leave indirect creation off unless a three-entity chain is a stated requirement.
5. Harmonise or map the code tables, decide which entity owns the price, and remove competing trade agreements on the other side.
6. Create one purchase order for one line, confirm it, and follow the chain: check the sales order number, address, warehouse, date, and price before anyone creates a real one.
WHAT GOES WRONG
• The relationship is created twice, once from each side, and orders start pairing with the wrong counterpart or failing to create at all.
• Numbering uses the original number while two entities share a sequence, and the second entity's orders fail because the sales order number already exists.
• The item is not released in the selling entity, or has a different unit, and sales order creation fails with an error the buyer never sees because it fires in a company they cannot access.
• Automatic product receipt is switched on for an entity that runs a physical receiving process, and stock appears on hand in the buying warehouse before the truck has left the selling one.
• Both entities carry trade agreements for the same relationship, and the two invoices in the chain post at different prices that reconciliation later has to unwind.
• Indirect creation is left on, and a routine external sales order creates a purchase order to a sister company nobody asked for.
Next time I will look at the intercompany order chain itself: what happens when a purchase order is confirmed, which fields are synchronised from the purchase order to the sales order and back, how direct delivery adds the original sales order to the chain, and what you can and cannot change on each document once the chain exists.
In this series: previous article Asset Analytics in D365 Asset Management: Lifetime Cost, MTBF, and the Replace or Repair Decision
No comments yet. Be the first to comment!
