Mapping the fifteen-field organisational stack

How SAP's explicit hierarchy of company codes, controlling areas, plants, storage locations, and CO reporting objects is projected onto D365 legal entities, sites, warehouses, and financial dimensions — and which concepts dissolve entirely in the transition.

What you will be able to do

Introduction

SAP models the enterprise with roughly fifteen distinct organisational fields. Each has its own master data table, its own assignment rules, and its own reporting semantics. Company code BUKRS governs statutory reporting; plant WERKS governs inventory and production; controlling area KOKRS governs cost accounting;

SAP's fifteen-field stack

The SAP organisational model is layered. At the outermost boundary sits the Client (MANDT), which provides data isolation at the database level. Below it, the fields most relevant to a migration fall into three functional groups.

What collapses cleanly: the logistical tier

Company Code → Legal Entity. BUKRS maps directly to D365's DataAreaId. Both are the statutory boundary for financial accounting, and the four-character code convention aligns naturally. This is built first; every subsequent object references it.

What dissolves: the controlling area problem

The controlling area is the concept that consumes the most programme effort to resolve. The common mistake is to spend weeks searching for its D365 equivalent. There is none.

What becomes a dimension: CO objects and reporting segments

Every object below the controlling area in the CO stack becomes a financial dimension value in D365. A financial dimension is a named attribute backed either by a system entity (such as OMOperatingUnit for cost centres and business units) or by a custom value list.

The Sales Area and Purchasing Org challenge

The SAP Sales Area and Purchasing Organisation are the two most ambiguous mappings in the programme, because D365 has no dedicated entities for either.

Knowledge check

Summary

The SAP organisational model uses fifteen fields to express boundaries that D365 handles with four concepts: legal entities, sites, warehouses, and financial dimensions. The migration is a collapse, not a rename — and each collapse is a decision.