Organisation hierarchies in Dynamics 365 Finance and SCM

The organisation hierarchy in Dynamics 365 Finance and Supply Chain Management is the structural backbone of how the system understands the customer's company structure. Security, financial dimensions, intercompany, reporting, workflow routing, and budgeting all hang off it. Getting it right at implementation pays back forever.

The building blocks.

• Legal entity — the unit of statutory accounting. One legal entity = one set of statutory books, one tax ID, one set of GL postings. A multinational with subsidiaries in five countries has at least five legal entities.

• Operating unit — a non-legal-entity organisation unit used for management and operational segmentation: cost centre, value stream, business unit, department, team. Operating units don't have their own GL; they're an analytical / operational layer.

• Department — a specific type of operating unit, commonly used as a default financial dimension.

• Cost centre — another operating unit type, used for cost accumulation.

• Worker — F&O's HR concept of an employee; workers map into operating units through positions.

Hierarchies. Organisations are connected through hierarchies — defined trees that express the relationship between organisation units. F&O supports multiple parallel hierarchies for different purposes:

• Legal hierarchy — legal-entity ownership structure (parent owns subsidiary). Used for consolidation and intercompany.
• Reporting hierarchy — management reporting structure (e.g. global → region → country → operating unit). May differ from the legal structure.
• Manager hierarchy — HR-style management reporting structure (people report to people). Used for workflow assignment.
• Cost centre hierarchy — budget and cost roll-up structure.

The same operating unit can appear in multiple hierarchies with different parents.

Why parallel hierarchies matter. Legal structure (who owns what) is rarely the same as management structure (who is responsible for what), which is rarely the same as cost centre structure (where spend is tracked). Forcing all three into one tree creates compromise; parallel hierarchies let each view be honest.

Effective dates. Hierarchies are time-aware: an org unit can move between parents on a specific date, and historical reporting respects the structure at the historical date. Reorgs don't destroy history.

Security through hierarchies. Security roles can be scoped to specific org units in a hierarchy — "Cost Centre Manager for Operating Unit X and its descendants". The hierarchy is what makes scope feasible without listing every entity manually.

Workflow assignment. Approval routing uses the manager hierarchy to walk up the chain until an approver with sufficient authority is found. Configure the hierarchy realistically; gaps create routing failures.

Financial dimensions and hierarchies. Most customers configure key org units (departments, cost centres) as entity-backed financial dimensions — so transactions automatically tag the relevant org unit, and the hierarchy can roll up reporting.

Consolidation. Consolidation companies in F&O reference the legal hierarchy to determine subsidiary inclusion, ownership percentages, and currency translation.

Common design pitfalls.

• Too few hierarchies. Forcing legal, reporting, and cost views into one tree compromises all three.
• Too many hierarchies. Beyond five or six, complexity overtakes value.
• Reorgs not handled with effective dates. Just renaming or re-parenting in place destroys historical comparability.
• Department dimension not aligned with hierarchy. Reporting roll-ups break when the dimension's parent doesn't match the hierarchy's structure.

Maintenance. Org hierarchies need maintenance as the business changes — quarterly review keeps them aligned.