Why I am a fan of a Single Company setup for Retailers in D365 F&O

Implementing D365 F&O requires some specific Design considerations when it comes to Retail organizations. A Retail company is not simply organized by Legal entities which transact with each other and 3rd parties. A Retailer has one or more brands to protect. Consumers expect the same brand experience anywhere anytime. This experience cannot have interference from legal entity boundaries or the way an ERP system is configured.

Too often, I see D365 F&O Solution Architects and Consultants automatically translate a Retailer’s subsidiaries to companies in D365 F&O. Even if this does not align with the way the Retailer is organized (central backoffices) and/or their logistics model is setup (hub and spoke). But first and foremost, it can shatter Supply Chain and Order fulfillment into pieces and significantly raise operational complexity and overhead with detrimental impact on the Customer Journey..

Is there an alternative???

The Retailer’s dilemma: Vertical walls vs Horizontal freedom

Retail organisations reduce financial risk by slicing their operation into legal entities organized by brand, specific activities and/or jurisdiction. In doing so, If any of the activities are underperforming potentially causing a bankruptcy, it can never bring down the complete enterprise.

At the same time, Retail companies require boundless operation to effectively manage their supply chain from Purchasing to Retail and to provide a consistent high-quality experience to their consumers, regardless of brand, country or specific store.

These 2 powers of ‘vertical structure’ vs ‘horizontal freedom’ brings a field of tension in typical cross-border Retail Businesses which is most prevalent in Retail Businesses with brick-and-mortar (stores) and/or service activities.

When defining the Financial setup in D365 F&O for these Retail companies, most Dynamics partners translate the company structure 1:1 based on classical in-operation intercompany postings (1# in the picture below) and then try to make the best out of the ‘horizontal freedom’ dimension (#2 in the picture below).

It is perfectly understandable to choose this path since any Solution must be legally and fiscally compliant. However, this comes with a price as it shatters the Supply chain and Order Fulfillment into pieces. Stitching these together to enable effective management of the Supply chain and seamless Customer journey is complex and costly.

Shattering Order Fulfillment into pieces?

Retail companies are often legally organised along the following lines:

Holding company: often stock holding company, so responsible for buying and stock (re)distribution - Sometimes e-commerce activities are also operated from this company
Brand holding: parent company for all brand specific activity
Selling company per brand/country: this company holds all sales activities like store sales, online sales
Service company per brand/country: this company holds all field service activities like on-site advisory, installations, repairs etc.

Often this legal entity structure (or similar structure) is translated into a ‘classic’ Intercompany structure in D365 F&O. In other words: each Legal Entity is reflected by a company in D365 F&O and every transaction between these companies is reflected by an additional Intercompany Sales Order/Purchase order pair (=IC PO/SO). Relatively straightforward Business processes can then suddenly become utterly complex to manage.

Example Retail Business Process.

In this example, a consumer places an in-store order for a Make-To-Order item (such as a bespoke closet or suit). The item is to be purchased from a supplier and then shipped to the consumer, in this case by cross docking via a main warehouse.

D365 F&O (including Commerce) is not too strong when it comes to managing more complex Fulfillment journeys. For these cases I would definitely recommend D365 Commerce/F&O to Team up with D365 Intelligent Order Management (=OMS). See for example my video on the combination of IOM and D365 Commerce. With a “classic” intercompany setup, the Fulfillment journey is even more complicated due to the additional ICO SO/PO pairs.

In this example, not 1 SO (Sales Order) with related PO (Purchase order) and TO (Transfer Order) is to be managed, but 3 SOs, 3 POs and 1 TO. And there are more complexities like the fact that stock is only available in Legal Entity 2 (the main holding) where we’d like to reserve stock from the main Sales order in Legal Entity 1. Even if D365 Intelligent Order Management (IOM) would be used here, IOM would have to manage and monitor multiple ‘overhead’ intercompany documents. This compromises “Keeping the Promise” which raises complexity in OMS implementation and OMS operation.

Beyond all this impact on the Fulfillment journey, there are more considerations which urge to look for an alternative set up. For example:

Rapid D365 F&O DB growth by ICO transactions. Customers now pay for this DB footprint!
Impact on Customer journey: Only Legal Entity 1 in the example is aware of the Consumer - The consumer does not exist and is not known in Legal Entity 2 or 3.
Customisations for IC processes. Some fundamental requirements for effective Order Fulfillment and Order Management are not compatible in a D365 F&O intercompany context. These will require (heavy) customisations in D365 F&O increasing implementation risk and Project implementation cost.
Organizational alignment: Retail organizations often have a central Backoffice per group of countries (=Region). These backoffices have to manage pieces of the Fulfillment chain across multiple D365F&O companies which is not ideal.
Margin: in an Intercompany Setup, margin components (like landed cost, shipping cost and fulfillment cost in general) are not sitting in 1 D365 F&O company. Of course, this can be stitched together in (for example) the BI domain, but some stakeholders prefer to see all cost components in their financial records.
You can probably come up with more downsides yourself!

Finding an Alternative Setup in D365 F&O

First let’s set a goal.. In the ideal world, we’d keep things as SIMPLE as possible. For a Retailer this would mean an all-in-one company setup in D365 F&O which hosts their Full Operation, from buying to order fulfillment. It would also mean to have no in-operation intercompany transactions, but post-operation intercompany postings, aggregated as per desired level (i.e. transactions condensed daily, monthly or quarterly).

But how is this possible while still addressing all specific Financial Requirements the enterprise may have AND being fully compliant with legal and fiscal regulations…?

Lets keep some typical Financial, Legal and Fiscal requirements in mind when trying to find an alternative for the “classic” intercompany setup:

Typical Financial, Legal and Fiscal requirements.

The D365 F&O Single “OPCO” (Operating Company)

My best shot to realise the Single company goal and being compliant with Financial, Legal and Financial requirements is the so called “OPCO” (Operating Company) concept.

In this company all ‘normal’ legal entities are reflected by D365 F&O companies, but they do not have direct intercompany relationships. Instead, the full Retail Operation is happening in the OPCO, a company in D365 F&O which does not represent a real-life Legal Entity.

Characteristics of the OPCO

Financial Dimension Values. All transactions in the OPCO are stamped with Financial dimension values which at least represent Brand, Cost center and Legal Entity. Non-D365 Commerce consultants may be surprised by the D365 Commerce out-of-box capability to allow inheritance of financial dimension values from Retail channel to Sales order/Sales order line. This auto-stamps the right Brand and Legal Entity for any Sale. Knowing these details on any Transaction will also allow to print a Brand and even Channel specific invoice and receipt if required. Since this information baseline provides full traceability and accountability, there is a solid fiscal and legal foundation for invoicing the consumer from the OPCO.
Statutory Reporting. Intrastat, VAT declaration, EU Sales list and other statutory reporting are directly created from the OPCO. The 2022 introduced functionality to report for multiple VAT registrations from 1 company is utilized for this - This is now supported for many European countries. See Microsoft Learning.
Intercompany transactions. IC Transactions are posted POST-Operation from OPCO to the actual Legal Entities. This is done by setting up Intercompany Accounting and Ledger allocations which automatically offset post OPCO financial transactions to the actual Legal Entity by main account/financial dimension rules. So for example, financial postings on OPCO revenue accounts can be broken out to various postings to the ledgers of the actual legal entity, so a P&L can be viewed from that Legal Entity.
OPCO = Stock holding company. Optionally the OPCO is the Stock holding company itself, so all companies in D365 F&O align with real-life Legal Entities.
Multi-currency. The OPCO can cover jurisdictions with different primary currencies. D365 F&O is dual-currency system since a few years now, so this should also not be a deal breaker if the number of primary currencies does not exceed 2.

Challenges

The Single Company/“OPCO” concept is often quickly wiped off the table by hardened D365 F&O Consultants and Solution Architects. This is often because they have done their intercompany transaction routine for so many years that they do not even consider other options. In other cases, it’s because they don’t know how to overcome the following 2 most-heard obstacles:

Localization. The DataAreaId (=company identifier) in D365 F&O is not only used in tables, to slice Data into Legal Entity specific buckets or shared buckets. The Legal Entity is also used to trigger locale (=jurisdiction) specific code. In most cases, this code is triggered for groups of countries which have similar legal context, such as the following regions: BeNeLux, DACH, Scandinavia, Ireland/GB and Eastern Europe. My rule of thumb is to have 1 OPCO for each of these regions. This also aligns with the Retailer’s organization and Logistics model in most cases: when a Retailer operates in BeNeLux (Belgium-Netherlands-Luxemburg) and expands brick-and-mortar (store operation) into DACH (Germany-Austria-Switzerland), often a new local (DACH) organization and logistics hub is set up for that region:

Subledger traceability. Especially financial auditors and controllers have the requirement to be able to click from the Legal Entity’s General ledger to the OPCO’s General ledger and Subledger. If the OPCO>Legal Entity intercompany accounting postings are condensed, this cannot be arranged on a 1:1 transactional basis. In that case, click-through capability is to be arranged by (minor) customization, for example by clicking from a single non-OPCO General ledger entry into multiple OPCO subledger transaction.

Final words

Every Solution Design choice should always be made in the specific context of an Enterprise. On top of that, a Project stakeholder will always be able to find a weak point in any Design Decision. But in our profession as an IT Architect it should not be the aim to pick the best option in a specific domain. The aim is to pick the best option Cross-Domain, where the overall score/value of the Solution as a whole is the highest possible.

I hope this post inspired you to look beyond ‘proven Design paths’ which may not represent the best Overall score.

In case of Retail organizations, the decision for a Single company setup or small group of OPCOs instead of 20+ or even 100+ companies in D365 F&O is more than fundamental: it can be the difference between a highly successful Transformation Program and a Program which technically succeeds but is considered a pain in the a** by the Retail Operation!