Designing dimensions in Business Central

Dimensions are the analytical lens of Business Central. Designed well, they let you run any management report from the GL without ever multiplying the chart of accounts. Designed badly, they turn into an unenforced mess that everyone reports around. The design is one of the most consequential decisions in an implementation.

Global vs shortcut

Business Central has up to eight global dimensions — every transaction can carry a value for each of them, and they're filterable everywhere. Of those, two are shortcut dimensions that appear as columns on every transactional document (sales order line, purchase invoice line, journal line), making them easy to set. The other six global dimensions are still attached to every transaction but require an extra click to set; pick the two that are most operationally relevant as the shortcuts.

Choosing dimensions

Start from the management reports you want. Common dimensions: Department / Cost Centre (the unit owning the spend), Project (for project-billable businesses), Customer Group or Region (for sales analysis), Salesperson (for commissions), Brand or Product Line (for marketing roll-ups). Don't reach for dimensions that simply replicate data already on the transaction — date, customer number, item number all flow naturally; reporting them needs no dimension.

Default values

Master records — customers, vendors, items, GL accounts, employees, locations — can default dimension values onto the transactions they appear on. Configure defaults so that the right values get set automatically; manual setting should be the exception.

Default rules

Mandatory rules force a dimension value to be present before posting (typical for Department). Same Code rules force a dimension to match another dimension's value (rare; typical use is two related dimensions that should never disagree). No Code rules block a dimension on certain accounts (e.g. balance sheet accounts shouldn't carry a Project dimension).

Dimension combinations

A separate matrix defines which combinations of dimension values are valid (e.g. Project X is only valid with Department A). Combinations are powerful but get heavy to maintain — use sparingly.

Renaming and deleting

Dimension values can be merged or renamed; once they've been used on posted transactions, they cannot be deleted. So plan the initial coding scheme to leave space (e.g. number gaps) for future expansion.

Don't reach eight

Companies that use all eight global dimensions are usually under-using their chart of accounts. Aim for four to six clean dimensions and a tidy CoA.

Global vs dimensions without limit

Beyond the eight global dimensions, Business Central allows an unlimited number of ordinary dimensions with no cap — they just don't get the shortcut columns or the same filter performance on every page. Use global dimensions for the two or three values every single report needs (Department, Cost Centre are the classic pair); push anything more specialised — a dimension only Sales cares about, or one used on 5% of transactions — into an unlimited dimension instead. This is the single most common design mistake: teams burn a global dimension slot on something niche because "global" sounds like it should be used for anything important, then run out of shortcut slots for the two things that actually needed them.

A worked example

A mid-size distributor with three warehouses, project-billable services, and regional sales reps might land on:

Location often looks tempting as a dimension, but if it maps one-to-one with the existing Location Code field, a dimension adds nothing — filter and report on Location Code directly and save the dimension slot for something that doesn't already have a field.

Dimension sets and performance

Every unique combination of dimension values used on a posted entry becomes a dimension set entry — an internal, deduplicated record BC creates automatically so it doesn't store every dimension value redundantly on every ledger entry. This is transparent in normal use, but it means a design with dozens of near-unique combinations (e.g. a "Batch ID" dimension that's different on every transaction) generates a dimension set entry per transaction with almost no reuse, bloating the table and slowing dimension-filtered reports. Dimensions are for categories you'll filter and total by, not for unique transaction identifiers — those belong in a text field or a custom table, not a dimension.

Retrofitting a bad design

Adding a dimension after go-live is easy; changing the shortcut dimensions is not — shortcut dimension 1 and 2 are set at company creation and changing them later requires Microsoft's dimension-swap tooling (or a partner-run data conversion) because they're baked into the posted-entry table structure, not just a setup choice. If a design mistake is discovered after go-live — the wrong two dimensions were made shortcuts, or a global dimension is barely used while an ordinary one is queried constantly — budget for a proper dimension-swap project rather than trying to patch around it with saved views and workarounds.

Where to go next

Dimensions feed everything downstream: the finance module, financial reports and account schedules, and multi-company setup all assume the structure is right. The companion decision is posting groups, and the errors a bad dimension setup produces at posting time are decoded in journal and document posting errors.