Translate the EBS organisational stack — ledger, legal entity, operating unit, inventory organization, subinventory and locator — into D365 legal entities, ledgers, operating units, sites, warehouses, locations and financial dimensions, with an explicit disposition for every operating unit.
The organisational model is where an EBS migration is won or lost first, because every later design depends on it. The chart of accounts cannot be frozen until the legal-entity set is known. The posting crosswalk cannot be completed until the dimension set is known.
An R12 ledger binds four things: chart of accounts, calendar, currency and accounting method. Several legal entities may be associated with one ledger, which is why an EBS estate can present a tidy front — one ledger, one chart, one calendar — while carrying substantial internal variation underneath.
Start by listing every operating unit with four facts attached: which ledger and legal entity it sits under, which subledgers actually transact in it, what volume it carries, and — the difficult one — what module policy it applies that its neighbours do not.
MOAC deserves a specific warning because it blends three concerns that D365 keeps apart: which data a user may see, how transactions are partitioned, and which processing scope a responsibility operates in.
The operational stack translates more predictably, with one caveat at each level.
One decision straddles this module and the Inventory module: what happens to inter-organisation transfers.
The deliverable from this module is a single artefact: an organisational crosswalk that finance and supply chain have both signed. Its minimum columns are:
The EBS organisational stack — ledger, legal entity, operating unit, inventory organization, subinventory, locator — does not align level-for-level with the D365 stack. Ledger and legal entity translate cleanly. Everything below them is a design decision.