Designing Dimensions in Business Central: Get It Right Before Go-Live

Dimensions are the most important finance design decision in a Business Central implementation, and the one most often rushed. They determine how every ledger entry can be analyzed: by department, location, project, product line, sales channel or anything else that matters to how you run the business. A good design gives management the reports they want without a sprawling chart of accounts. A poor one means re-coding history or living with reports that never quite work.

Here is how dimensions work and the decisions worth making before go-live.

Dimensions vs. the chart of accounts

Companies coming from QuickBooks or older systems often encode departments and locations into the account number: 6100-10 for sales salaries, 6100-20 for warehouse salaries, and so on. In Business Central that job belongs to dimensions. The chart of accounts answers what the money is (salaries, freight, rent). Dimensions answer where, who or for what.

Keeping them separate gives you a shorter, cleaner chart of accounts and the freedom to report any account by any dimension combination. As a rule of thumb, if you find yourself creating the same account several times with a suffix, that suffix is a dimension.

Global, shortcut and other dimensions

Business Central lets you create as many dimensions as you need, but they are not all equal:

Department and location (or business unit) are the most common global dimensions because finance filters by them every day. Project, customer group or product line often work well as shortcut dimensions. Global dimensions can be changed later with the Change Global Dimensions function, but it rewrites entries across large tables, so it is far better to choose well up front.

Default dimensions and value posting rules

Most dimension values should not be typed by users. They should flow from master data. You can attach default dimensions to G/L accounts, customers, vendors, items, resources, fixed assets, employees, projects and more. When a document or journal line uses that record, its dimension values are filled in automatically.

Each default dimension carries a Value Posting rule, which is how you enforce clean data:

• Code Mandatory: a value is required for this dimension, but any value is allowed. Use it on P&L accounts that must always carry a department.
• Same Code: the value must be exactly the default. Useful for a warehouse location that should only ever post to its own location code.
• No Code: the dimension must be blank. Typical on balance sheet accounts where a department makes no sense.

Setting these rules account by account takes an afternoon during design, and saves months of reclassification entries later.

Dimension combinations

Dimension combinations let you block or limit which values can be used together. For example, a project dimension value may only be valid with one department, or a sales channel may not combine with a manufacturing cost center. Use combinations sparingly. They are powerful, but every rule is another reason a posting can fail at month-end, so reserve them for combinations that would genuinely corrupt reporting.

How dimensions flow through documents

When a sales order is created, dimensions from the customer fill the header, and dimensions from each item or G/L account fill the lines. The header and line values are combined according to priorities you can set per source in Default Dimension Priorities. When the order is posted, the resulting customer, item, value and G/L entries all carry the same dimension set.

That is why the design work is worth doing: once defaults and priorities are right, most transactions arrive in the ledger fully coded without anyone thinking about it.

Reporting on dimensions

• Financial reports (formerly account schedules) can use dimension filters and dimension totaling in rows and columns, which covers most departmental P&Ls.
• Analysis views summarize G/L entries by up to four dimensions and are fast for slicing large ledgers.
• Excel and Power BI can pull dimension data through the standard APIs for anything more visual.

Design mistakes we see most often

1. Too many dimensions on day one. Every dimension is something a user must get right. Start with what management actually reviews, and add more once the basics are stable.
2. Using dimensions for things that are master data. Customer type or item category may already exist as fields; only make them dimensions if you need them on G/L entries.
3. Value lists that mirror the org chart of today. Use stable codes and descriptive names, and use totaling values for roll-ups, so a reorganization does not mean new codes everywhere.
4. No value posting rules. Without them, blanks creep in and the departmental P&L never ties to the total.
5. Migrating history without mapping. If old account suffixes become dimensions, map them during data migration so opening balances and history are coded consistently.

A short design checklist

• List the questions management asks of the numbers every month.
• Pick two global dimensions for the filters finance uses daily.
• Decide which other dimensions users enter on lines (shortcut) and which come from defaults only.
• Set default dimensions and value posting rules on accounts, customers, vendors and items.
• Agree a coding convention for dimension values, including totaling values.
• Test a full month of transactions in a sandbox and run the departmental reports before go-live.

Need a second opinion on your design?

Dimension design is part of every Business Central implementation we lead, and one of the first things we review in an implementation rescue. If your reports never quite tie out, talk to an architect.