A retail operations director looks at a stalled online order and sees the maddening part immediately: the product is in stock, just not in the legal entity that took the sale. This happens constantly inside multi-entity retail and distribution organizations, the kind that grew by acquisition, by regional incorporation, or simply because tax and banking realities forced separate companies to hold separate inventory. To the customer, it looks like one brand. To Dynamics 365, it looks like several unrelated companies, each with its own stock ledger, unable to see past its own four walls without someone picking up a phone and negotiating a manual intercompany purchase order. Microsoft’s new cross-legal-entity fulfillment capability, built on top of Distributed Order Management (DOM), is aimed squarely at that gap. It reached private preview in version 10.0.48 this past August, with a public preview following in 10.0.49, and it is worth a serious look from any finance or operations leader running Dynamics 365 across more than one legal entity.
What Cross-Legal-Entity Fulfillment Actually Changes
DOM itself is not new. Dynamics 365 Commerce has used it for years to solve a narrower version of this problem: given an order and a set of warehouses inside a single legal entity, which location should fulfill it, based on inventory availability, distance to the customer, and cost. The new capability extends that same logic across company boundaries. DOM can now evaluate inventory sitting in a different legal entity entirely, and when it decides that location is the right one to fulfill from, it does not just flag the mismatch for someone to sort out manually. It automatically builds the full intercompany transaction chain: an intercompany purchase order in the entity that took the original sale, and a matching intercompany sales order in the entity actually holding the stock, synchronized so that when the fulfilling entity ships, both records update and the customer’s original order closes out correctly. For an organization that has been handling these situations with a spreadsheet and a Teams message between two warehouse managers, that is a real reduction in manual work, not just a marginal one.
The business case writes itself on the inventory side. Stock that would otherwise sit idle in one entity while a nearly identical order goes unfulfilled, or gets backordered, in another becomes usable. Organizations running regional legal entities for tax or regulatory reasons, but operating as one brand commercially, finally get a fulfillment engine that reflects how customers actually experience the business rather than how the org chart is drawn.
The mechanics matter just as much when things do not go according to plan. If a fulfilling entity cannot complete an order, whether because inventory shifted after DOM made its decision or a warehouse simply declines the assignment, DOM does not leave the order stranded. It marks the line rejected and attempts reassignment on its next scheduled run, first to another location within the same entity, then to a warehouse in a different one entirely. Partial fulfillment works the same way: if a location can only ship part of an order, the shortfall carries through the intercompany chain, and DOM can reassign the remainder on a later pass. For an operations leader weighing this against the status quo, that built-in retry logic is arguably as valuable as the initial sourcing decision, since it replaces exception handling that used to depend on someone noticing the problem before anyone could fix it.
The Setup Cost Nobody Puts in the Feature Announcement
None of this activates by flipping a single switch, and the gap between the headline and the configuration work is exactly where evaluation projects go wrong. The prerequisite that will consume the most calendar time is intercompany trading relationships. For every pair of legal entities that should be able to fulfill for each other, someone has to create and link a customer record in the selling entity and a vendor record in the fulfilling entity, then configure both for automatic intercompany order creation. With two entities that is a manageable afternoon of setup. With eight or ten, which is not an unusual footprint for a company that has grown through acquisition, the number of pairs that need configuring grows fast, and each one typically touches both an accounts payable and an accounts receivable process owner who may not have been in the room when this project got approved.
Beyond that, three technical dependencies are easy to miss until a pilot stalls on them. First, the DOM solver has to be set to Production Solver rather than Simplified Solver, because the simplified option cannot create intercompany orders at all, a detail that only surfaces after someone has already built out fulfillment groups and rules under the wrong configuration. Second, Azure Maps has to be enabled and licensed, because DOM uses it to calculate real distances between warehouses and delivery addresses when deciding which entity should fulfill an order, and that is a dependency an IT team evaluating this purely as an ERP feature might not budget for. Third, and most consequential for a phased rollout, every legal entity that should participate has to be explicitly added to the DOM fulfillment profile. Miss one, and DOM will not simply deprioritize its locations, it will not see them at all, which makes partial or staged rollouts across a large entity footprint riskier to get right the first time than the documentation implies.
What’s Actually in Scope Today
It is worth being precise about where this feature currently draws the line, because a preview capability evaluated against the wrong assumptions leads to a rollout plan that has to be rewritten in six months. As of this preview, cross-legal-entity fulfillment covers retail order channels only: point of sale, e-commerce, call center, and headless Commerce Scale Unit orders. Sales orders originated directly in Supply Chain Management sit outside this scope for now. Microsoft has said SCM order support is on the roadmap, but roadmap language in a preview announcement is explicitly not a delivery commitment, and organizations that need cross-entity logic for B2B or wholesale sales orders processed natively in SCM should not build a 2027 plan around a capability that has not shipped yet.
The preview status itself carries the same caveat every Dynamics 365 preview does, and it is worth repeating because it gets skipped over in internal pitch decks more often than it should: preview features are for evaluation, are subject to change, and Microsoft’s own documentation is explicit that timing and functionality should not factor into purchasing decisions. Private preview in 10.0.48 moving to public preview in 10.0.49 is a normal, healthy cadence, not a signal that general availability is imminent.
How to Evaluate This Before You Pilot It
For a finance or operations leader deciding whether this belongs on next year’s roadmap, the useful first step is not a technical proof of concept. It is an honest audit of how complete the organization’s existing intercompany trading setup already is. Companies that have already done the work of linking customer and vendor records across their legal entities for other intercompany scenarios will find the DOM-specific configuration, the vendor mapping, fulfillment groups, and rules, relatively fast to layer on top. Companies where intercompany trade has been handled ad hoc, entity by entity, as problems came up, should expect the trading relationship setup itself to be the majority of the project timeline, not the DOM configuration.
It is also worth involving accounts payable and accounts receivable process owners earlier than a typical fulfillment feature would require, since this changes the volume and pattern of intercompany transactions those teams reconcile every period. A pilot scoped to a single, well-understood pair of legal entities, run alongside the existing manual process rather than replacing it immediately, gives a much clearer read on actual fulfillment savings and reconciliation impact than a broad rollout attempted on day one of public preview.
Cross-legal-entity fulfillment addresses a real and common operational gap, and the underlying DOM engine it builds on is mature technology, not an experimental one. The preview label applies to the cross-entity orchestration layer, not to order fulfillment optimization itself. Routeget Technologies has walked a number of multi-entity clients through intercompany trade configuration for other reasons, and the pattern holds here too: the technology adoption timeline is rarely the bottleneck. The completeness of the underlying intercompany setup is.
#DistributedOrderManagement #Dynamics365SCM #IntercompanyFulfillment #OmnichannelFulfillment #SupplyChainAutomation