Microsoft’s August 19 Dynamics 365 blog places the feature in private preview for version 10.0.48 and public preview for version 10.0.49. For multinational retailers running separate companies for countries, brands, franchises, or tax jurisdictions, the feature is meant to eliminate a familiar operational dead end: stock exists somewhere in the group, but the selling entity cannot use it without people manually arranging an intercompany transfer and rekeying orders.
The important qualification is that this remains a Commerce order capability in preview. It is not a general solution for every Dynamics 365 Supply Chain Management sales order, and it is not a license to treat legally separate companies as one undifferentiated inventory pool. The intercompany relationships, accounting structures, product releases, delivery settings, and vendor mappings still have to be configured correctly before DOM can make the automated decision.
DOM now carries the order across company boundaries
Before this release, Dynamics 365 Commerce customers could use DOM to decide which eligible fulfillment node should serve an order, applying rules such as inventory availability, priority, maximum distance, and order limits. But the normal operating boundary was the legal entity that owned the sale. A warehouse in another company might have stock, yet using it required a separate intercompany process outside the optimizer’s automated fulfillment flow.
The new preview expands the optimizer’s candidate locations to warehouses and stores belonging to participating legal entities. Microsoft Learn’s configuration documentation says DOM can choose a fulfillment location in a legal entity other than the one where the sales order originated, then create the intercompany purchase order in the source entity and the intercompany sales order in the fulfilling entity.
That means a German Commerce order, for example, can be assigned to a French warehouse if the French entity is eligible and represents the better configured choice. The original sales order remains the customer-facing document, while the associated intercompany purchase and sales orders provide the commercial and accounting chain between the entities.
Microsoft describes this as an automated chain involving the original sales order, intercompany purchase order, and intercompany sales order. The operational team still uses standard processes—pick, pack, ship, invoice, and rejection handling—but the orders are intended to remain synchronized as fulfillment progresses.
This is a more consequential change than the cross-company inventory lookup Microsoft added to Point of Sale in Commerce 10.0.47. That earlier feature allowed store associates to see inventory held by other legal entities. Cross-legal-entity fulfillment is the missing execution step: it lets the system act on that inventory through intercompany order creation rather than leaving an associate or back-office team to coordinate the result manually.
The optimizer is only as good as the commercial setup behind it
The preview does not create intercompany trading relationships automatically. Microsoft’s own implementation guidance makes clear that each participating company pair needs linked intercompany customer and vendor records, with policies that permit automatic sales-order and purchase-order creation. Administrators must also map the source legal entity to the intercompany vendor used when DOM creates the purchase order.
This detail deserves more attention than the product announcement gives it. A fulfillment engine can identify an ideal warehouse, but it cannot compensate for an incomplete intercompany model. If a legal-entity pair is absent from the mappings, its warehouses cannot be used successfully for the automated cross-entity flow. If products have not been released and made available in every participating entity, the optimizer may find stock that the downstream order chain cannot legally or operationally process.
The system also does not decide in a vacuum. Administrators define cross-legal-entity fulfillment groups containing the warehouses and stores DOM may consider, then attach those groups to fulfillment profiles. The profiles determine which legal entities, delivery modes, sales order origins, and rules are eligible for a DOM run.
In other words, this is a controlled network, not enterprise-wide “inventory sharing” switched on by a Feature Management toggle. A company can deliberately exclude a warehouse, restrict a delivery method, preserve a local fulfillment priority, reserve minimum stock, or impose a maximum shipping distance. Those controls are particularly important where an organization wants to avoid draining store inventory for e-commerce orders, protect regional allocation, or keep cross-border fulfillment from becoming the low-friction default merely because another entity has stock.
Cost modelling becomes more important once company boundaries enter the decision. Microsoft’s DOM documentation already supports shipping, handling, packaging, and location-specific costs. The cross-legal-entity preview adds the need to model intercompany transfer costs and policy constraints accurately. If those costs are omitted or understated, an optimizer designed to minimize distance can produce a result that is operationally close to the customer but commercially inferior after transfer pricing, customs exposure, packaging, or internal handling are considered.
The preview requires the Production Solver and scheduled processing
The technical deployment has a few non-obvious requirements. Microsoft Learn states that cross-legal-entity fulfillment needs DOM’s Production Solver; the Simplified Solver cannot create the necessary intercompany orders. That distinction matters for teams that have used the simplified option for evaluation or low-scale DOM trials and assume the new feature is simply another rules configuration.
DOM processing also runs through a scheduled batch job. It evaluates qualifying sales-order lines according to the fulfillment profile and applies its rules, inventory constraints, and optimization process to generate a fulfillment plan. The batch model is appropriate for many high-volume retail fulfillment scenarios, but administrators should plan around its cadence rather than promise an instant cross-company sourcing decision at every point in the customer journey.
Microsoft’s documentation says eligible orders must be Commerce-channel orders, among other criteria, and it excludes pickup and electronic-delivery lines from the standard DOM processing criteria. The submitted announcement describes support for POS, e-commerce, call-center, and headless Commerce Scale Unit orders, but organizations should validate their specific order origins and fulfillment modes in a sandbox before changing customer delivery promises.
Address quality is another dependency. DOM uses Azure Maps to calculate distances between fulfillment locations and delivery addresses. Microsoft requires valid warehouse addresses with latitude and longitude data, or Azure Maps address resolution. In a single-country implementation, that may be routine. In a multi-entity, multi-market rollout, incomplete addresses or inconsistent store data can quietly distort the distance calculations that influence sourcing decisions.
Microsoft’s availability record is not fully aligned
There is a notable mismatch in Microsoft’s own published timeline. The 2026 release-wave plan says cross-legal-entity order fulfillment for Dynamics 365 Commerce was scheduled for public preview by May 31, 2026 and general availability in June 2026. Microsoft’s Commerce 10.0.48 release notes also list cross-legal-entity order fulfillment as a feature in that release.
Yet the August 19 blog calls the feature private preview in 10.0.48 and public preview in 10.0.49, while the current Microsoft Learn configuration article is explicitly marked preview. The public record therefore does not support treating the capability as generally available today.
That may reflect a change in rollout scope, a feature flight that arrived later than the original release-plan target, or a documentation lag between the Commerce release notes and the product team’s availability messaging. Microsoft has not publicly explained the difference in the material reviewed here. What customers should take from it is simpler: use the Feature Management availability stated for the environment and version actually in use, and do not use the release-plan GA date as evidence that the feature is production-supported for a broad rollout.
Microsoft says 10.0.48 customers in the private preview need to request enablement with their environment details, while 10.0.49 customers can self-enable through Feature Management. The company’s published Commerce release index still prominently lists 10.0.48, while Finance and Operations version 10.0.49 is on the current preview-to-general-availability schedule. Administrators should confirm the exact application build, Commerce components, and feature-flight status with Microsoft before scheduling a pilot.
What a responsible pilot should test
A first implementation should be treated as an intercompany process test, not merely an inventory-routing test. The technical success condition is more than seeing a foreign-entity location selected in a fulfillment plan; it is seeing the original sale and the linked intercompany documents remain correct through shipment, rejection, reassignment, invoicing, and exceptions.
A useful pilot should include the following checks:
- Verify that products, warehouses, store locations, delivery modes, and sales-order origins are configured consistently across every legal entity participating in the trial.
- Test the full original sales order, intercompany purchase order, and intercompany sales order chain, including partial availability, fulfillment-location rejection, inventory changes after optimization, and cancellation paths.
- Compare DOM’s selected source against a cost model that includes internal transfer and handling costs, rather than assuming the nearest warehouse is the cheapest fulfillment choice.
- Confirm that the Production Solver, Azure Maps configuration, batch recurrence, and relevant number sequences are in place before judging the feature’s reliability.
- Reconcile the resulting financial and inventory transactions with the teams that own intercompany accounting, tax, warehouse operations, and customer service.
Microsoft is also positioning the preview as a first step rather than a finished cross-company order-management platform. Supply Chain Management sales orders are outside the initial scope, according to the company’s blog, and Microsoft says broader SCM support is only under consideration. Cross-legal-entity inventory visibility for customer-facing e-commerce is likewise described as an evaluated roadmap direction, not a delivered function.
For Commerce retailers with fragmented stock across national or brand entities, the preview can remove a genuinely expensive manual handoff. But the first production consequence will be a stricter demand for clean intercompany master data and tested exception handling: once DOM starts creating cross-company orders automatically, configuration mistakes move from an operational inconvenience into the financial transaction chain.