The Order Is in One Company. The Stock Is in Another.

One of the hardest design questions in D365 SCM is what to do when the legal entity taking the customer order doesn’t own the inventory needed to fulfil it.

Ask a supply chain lead where the stock is and you’ll get an answer in seconds. Ask which company is allowed to sell it, at what price, and what that does to the group’s numbers, and the room goes quiet.

That second question is the design problem. It’s also the one most multi-entity D365 programmes discover after go-live, usually when a customer in one country is told “out of stock” while a warehouse two hours away, owned by a sister company, is holding six pallets of it.

The instinct at that point is to build something. It usually shouldn’t be.

Three questions that are always answered separately

Every cross-entity fulfilment scenario has three layers, and almost every design I review treats them as three unrelated workstreams.

Who owns the inventory. A legal entity in D365 isn’t an organisational convenience. It’s a balance sheet. The stock sitting in that warehouse belongs to one company, and moving it to a customer of another company is a sale, whatever the org chart says.

What the financial impact is. The moment goods cross an entity boundary, you’ve created a purchase in one company and a sale in another. There’s a transfer price, a margin sitting somewhere, an intercompany balance to reconcile, an elimination at consolidation, and — if the two entities are in different countries — a cross-border supply with its own VAT and customs treatment.

Who physically fulfils. Which warehouse picks, packs and ships, and how that decision gets made at scale, in seconds, across hundreds of locations.

Supply chain owns the third question. Finance owns the second. Nobody in the room owns the first, because it sits between them. So it gets decided by whoever configures the sales order form first.

The part that changed

For most of the last decade, cross-company fulfilment in F&O meant one of two things: an intercompany chain someone drove manually, or a custom sourcing engine somebody wrote.

That’s no longer the only route. Cross-legal-entity fulfilment is now a configured product capability inside Distributed Order Management.

Here’s what Microsoft actually shipped. DOM’s fulfilment optimisation no longer stops at the company boundary. You define cross-legal entity fulfillment groups containing warehouses and stores from multiple legal entities, add every participating entity to a DOM fulfilment profile, and map each legal entity pair in DOM intercompany vendor mapping. When the solver picks a location in another company, the system creates the intercompany purchase order in the source entity and the intercompany sales order in the fulfilling entity, and keeps the chain synchronised through picking, packing, shipping and invoicing. Partial shipments cascade down the chain. A rejected line gets reassigned — to another warehouse in the same entity, or another entity entirely.

The release plan entry is worth reading in full, because the feature list tells you what Microsoft thinks the problem is: fulfilment groups across entities, inventory visibility across entities, intercompany order automation including exception handling, POS support for orders assigned into another company’s store, and direct delivery.

There’s a related capability that already landed and gets confused with it. From version 10.0.47, cross-company inventory lookup for POS lets a store associate see availability across legal entities. Read the limitations section carefully: it’s visibility only. The associate can see the stock in the other company. They cannot select that location as the fulfilment or pick-up point. Visibility and fulfilment are two different features and they arrived on different dates.

Where the edges still are

This is a capability with a defined shape, and the shape matters more than the headline.

It’s a Commerce capability first. The documentation sits under Commerce, the setup path runs through Retail and Commerce, the enabling configuration key is the Distributed Order Management one, and Microsoft’s own August 2026 post states that it currently supports retail orders, with broader Supply Chain Management sales order scenarios on the roadmap. If your operating model is B2B distribution or project-based supply, this is a direction of travel worth designing towards — not a switch you flip this quarter. Confirm the licensing position for your own estate before you assume access to it.

The Production Solver is required. The Simplified Solver doesn’t support cross-entity scenarios, and the distance logic needs either warehouse addresses carrying latitude and longitude or a configured Azure Maps key.

The profile is the boundary. DOM will not consider a location in a legal entity you didn’t add to the fulfilment profile. That’s a one-line configuration fact with an architectural consequence: your fulfilment network is defined in a profile, not in your warehouse master.

And the labelling is still moving. The release plan lists general availability in June 2026; the documentation page still carries a preview banner; the August post describes public preview in 10.0.49. That’s normal for a capability expanding in scope, and it’s exactly why you check the current documentation before you design against it rather than quoting a slide from a partner deck.

The finance half nobody designs

Configure everything above and the orders will flow. Whether the numbers make sense is a separate question, and it’s the one that generates recovery work.

Products must be released in every participating entity. Intercompany trade assumes both sides of every relationship were designed as a pair: an intercompany customer in the fulfilling entity, an intercompany vendor in the source entity, order policies on both, value mapping on both. If your entities onboarded their own master data independently, this is where you find out.

Transfer price is a design decision, not a default. The intercompany parameters include an option to set unit price equal to cost price, plus controls over price and discount search and whether users can edit either. Choose one way and the margin lands in the selling entity. Choose another and it lands in the fulfilling one. Both are defensible. Only one of them matches what your group tax position assumes, and nobody in the design workshop is usually qualified to say which.

Synchronisation is one-directional. The same documentation states plainly that the order header is controlled from the original sales order, and changes made on the intercompany sales order aren’t synchronised back to it. Design your exception process on that basis, not on the assumption that the two documents converge.

Every cross-entity shipment is an intercompany balance. If your due to/due from accounts don’t carry a trading partner dimension, you’ve just industrialised the creation of balances your close team can’t slice. Cross-entity fulfilment turns intercompany reconciliation from an occasional task into a daily volume. That’s a good problem to have designed for and an expensive one to discover.

Demand has its own version of this. On the supply side, intercompany planning already lets an upstream company’s master plan see planned downstream demand, so supply orders get created for demand that hasn’t been firmed yet. It runs sequentially, downstream entity first. Same principle as DOM: the entity boundary is a modelling choice, not a wall.

The cheapest cross-company problem is the one you never created

Before designing cross-entity fulfilment, check whether you needed the entities.

Microsoft’s organisational strategy guidance is blunt about this: don’t create separate legal entities for divisions or business units that are legally the same entity, and where the requirement is multiple balance sheets, use a balancing financial dimension instead. Every entity you add multiplies the intercompany relationships you maintain, the master data you duplicate, and the fulfilment decisions you now have to automate.

I’ve written before about the multi-entity decisions you can’t undo after go-live. Entity count is the first of them, and cross-company fulfilment complexity is the compound interest on getting it wrong.

My position: prove the standard model can’t hold it

Here’s the opinion, stated plainly.

Don’t customise cross-company fulfilment until you’ve demonstrated, with a documented scenario, that the standard capabilities cannot model your operating model.

Three reasons.

The first is cost of ownership. Custom cross-company sourcing logic touches sales orders, inventory transactions, intercompany documents and posting. That’s the part of the application that changes most, on a platform that ships four service updates a year. Every one of those updates is now a regression cycle you own forever.

The second is that the product is moving into this space deliberately. Microsoft has shipped fulfilment groups across entities, intercompany automation, cross-company POS visibility and cross-entity planning, and has stated that broader sales order scenarios are on the roadmap. Custom logic written today in that same lane is on a collision course with capability arriving tomorrow. You’ll either carry it forever or pay to remove it.

The third is the one that actually decides most projects. Nine times out of ten, when I take a “we need custom cross-company logic” requirement apart, the real blocker isn’t the sourcing engine. It’s that products aren’t released in both entities, or the intercompany customer and vendor pair was never built, or nobody decided the transfer price, or two entities exist that shouldn’t. Custom code doesn’t fix any of those. It hides them, at a rate of several hundred pounds a day.

Prove it can’t be configured. Write the scenario down. Then, and only then, build something.

The questions to ask before your next design workshop

1. For each fulfilment scenario, which entity owns the stock, which entity holds the customer contract, and which entity ships? If those are three different answers, you have an intercompany design, not a warehouse design.
2. What is the transfer price, who decided it, and does the group tax position agree?
3. Are our due to/due from accounts sliceable by trading partner, at the volume cross-entity fulfilment will generate?
4. Are products released, and intercompany customer/vendor pairs built, in every entity we expect to fulfil from?
5. Which of our legal entities exist for a legal reason, and which exist because someone mirrored the org chart?