Financial dimensions in Dynamics 365 Finance

Where Business Central has up to eight global dimensions, Dynamics 365 Finance allows up to ten financial dimensions, with a richer account-structure model on top. Designing the dimension framework is one of the most consequential decisions of any F&O implementation — it sets the reporting flexibility for the next decade.

Financial dimensions. Each dimension represents an analytical axis — Department, Cost Centre, Project, Region, Brand, Activity, etc. Dimensions have values (the codes within the dimension) and metadata (descriptions, defaults, validations).

Two flavours of dimensions.

• Custom dimensions — codes maintained in the dimension table. Used for axes that don't naturally exist as Dataverse-like entities (Cost Centre, Activity, Project Code if not using full Project Operations).
• Entity-backed dimensions — the dimension is sourced from an existing F&O entity (Customer, Vendor, Item, Worker, Project). The dimension value is the entity's ID. Powerful: a Customer dimension means transactions automatically tag the customer without manual entry. Common entity-backed dimensions: Customer, Vendor, Site, Warehouse, Worker, Project.

Account structures. This is where F&O surpasses BC. An account structure defines, for a given GL posting, which dimensions are required and in what combination. The structure is a set of segments where each segment lists allowed values and the relationships between segments.

Example: an account structure might specify that for revenue accounts (411xxx), the Department segment must come from a list of operational departments, and the Project segment must be non-empty. For balance-sheet accounts (1xxx), no Project is allowed. The system enforces the structure at posting time — wrong combinations are blocked.

Advanced rules. Beyond the basic account structure, advanced rules add conditional logic: when a specific account is used, require additional dimensions or constrain values. Used for compliance and statutory regimes that require dimension scrutiny on specific account types.

Default financial dimensions. Each master record (Customer, Vendor, Item, GL Account, Worker, Project, Site) carries default financial dimensions that flow onto transactions where the master is used. Defaults can be fixed (cannot be overridden) or flexible (the user can override at the transaction line).

Default priority. When multiple masters appear on the same transaction (a sales line involves customer, item, salesperson), the default priority rules decide which master's defaults win for each dimension. Configure these carefully — wrong priority assigns the wrong cost centre on every transaction.

Derived dimensions. F&O can derive a dimension value from a formula or lookup — e.g. derive Region from the Customer's address. Reduces manual entry; introduces dependencies.

Reporting dimensions. When reporting, dimensions can be:

• Flat-rolled — view spending across all dimensions on a single account, summed.
• Sliced — view spending broken down across one or more dimensions side by side.
• Combined — multiple dimensions intersect in pivot-style reports.

Both Financial Reporting and Power BI consume the dimension structure.

Design discipline.

• Start from the management reports the business needs. Work backwards to the dimensions required.
• Don't reach for ten dimensions when six will do. More dimensions slow performance and increase data-entry burden.
• Document the dimension semantics — what each value means, what counts as a valid combination — so the design survives staff turnover.
• Revisit annually — dimension values that haven't been used in 12 months are usually candidates for deactivation.