Dimensions in Business Central: Analytical Reporting Explained

Ask a finance team what they want from their system and the answer is almost always the same: they want to see the numbers cut the way the business actually runs. Profit by branch. Cost by project. Spend by department. Revenue by product line and by region at the same time. In many older systems the only way to deliver that was to bloat the chart of accounts with hundreds of near-duplicate accounts, one per department per cost type, until the account list became unusable. Business Central solves this problem cleanly with a feature called dimensions, and once a team understands dimensions properly, the chart of accounts can shrink back to what it was always meant to be: a list of what kind of money moved, not who spent it or why.

The message up front: dimensions let you tag every transaction with the analytical context you care about, department, project, region, customer group, funding source, and then report across those tags freely. The power is real and the setup is deceptively simple, which is exactly why so many implementations get it wrong. The choices you make on day one, especially which dimensions become global, are close to permanent. Design deliberately and dimensions become the reporting backbone of the whole system. Design carelessly and you spend the next two years working around your own decisions.

1. The problem dimensions solve

Start with the pain, because the pain explains the design. Every business needs to analyse its finances along more than one axis. The chart of accounts already gives you one axis: the nature of the transaction. Account 6100 is Salaries, account 6300 is Travel, account 4100 is Product Revenue. That is fine as far as it goes, but it only answers "what kind of money was this." It does not answer "which department incurred it," "which project consumed it," or "which region earned it."

The old way to answer those questions was to encode them into the account number itself. If you had four departments and needed to see travel spend per department, you created four travel accounts: Travel - Sales, Travel - Operations, Travel - Finance, Travel - IT. Multiply that across dozens of cost types and a handful of analysis axes and the chart of accounts explodes. I have opened charts of accounts with more than two thousand accounts, where ninety percent of them existed only to encode a department or a location into the account code. The account list becomes unreadable, posting becomes error-prone, and adding a new department means creating dozens of new accounts by hand. Worse, the moment the business wants a second axis, say department and project together, the combinatorial explosion makes the whole approach collapse.

Dimensions break the analysis axis away from the account entirely. Instead of building the department into the account code, you keep one clean Travel account and attach a Department tag to each transaction that hits it. Now you have two independent axes: the account tells you it was travel, the dimension tells you it was the Sales department. Want to add a Project axis as well? Attach a Project tag too. The chart of accounts stays small and stable while the analytical richness lives in the dimensions, where it belongs. This separation is the single most important idea in the whole feature, and everything else follows from it. For the broader picture of how the finance module fits together, see the Business Central financial management pillar.

2. What dimensions actually are

A dimension is a category you want to analyse by. A dimension value is a specific member of that category. That two-level structure is the whole model, and it is worth stating plainly because the words are easy to blur.

Take a concrete example that I will carry through the rest of this guide. Imagine a mid-sized engineering services company. It wants to see its profit and loss two ways: by department, and by project. So it sets up two dimensions.

• Dimension: DEPARTMENT. Its dimension values might be SALES, OPERATIONS, FINANCE, IT and ADMIN. Each is a code with a description. Every cost the business incurs belongs to one of these departments.
• Dimension: PROJECT. Its dimension values might be one code per active engagement, for example PRJ-1001, PRJ-1002, PRJ-1003, and so on. Revenue and direct cost that relate to a client engagement carry the relevant project code.

Now when a consultant books a flight for a client visit, the transaction hits the Travel account and carries DEPARTMENT = OPERATIONS and PROJECT = PRJ-1002. When you later ask "what did project 1002 cost us," Business Central sums every ledger entry tagged with PROJECT = PRJ-1002 across every account. When you ask "what did the Operations department spend on travel," it sums every Travel entry tagged DEPARTMENT = OPERATIONS. The same underlying entries answer both questions because each entry carries both tags. That is the entire magic: one posting, many analytical views.

Technically, every dimension value can also be assigned a dimension value type, such as Standard, Heading, Begin-Total or End-Total, which lets you group values and build subtotals in analysis just as you would with account categories. For most teams the values are simply Standard, but the grouping types are there when you want a reporting hierarchy inside a single dimension, for example grouping several project codes under a regional heading.

The crucial thing to hold onto is that dimensions are metadata attached to entries, not accounts. An account does not "have" a department. A posted entry has a department. This is why the chart of accounts stays clean: the account is generic, and the analytical detail rides along with each transaction that touches it.

3. Global, shortcut and budget dimensions

You can create as many dimensions as you like in Business Central, but they are not all equal. The system distinguishes a few special roles, and understanding these roles, particularly the global dimensions, is where good design and bad design part ways.

Global dimensions. Business Central lets you nominate exactly two dimensions as global. Global dimensions are special because their values are written directly onto every ledger entry as dedicated fields, and they are available everywhere: as columns on transaction pages, as filters on nearly every list and report, as fields in account schedules and financial reports, and as native filters in the general ledger. Because they are stored as first-class fields, global dimensions are the fastest to filter and the most widely supported across the standard reporting surface. In our example, the natural choice is DEPARTMENT and PROJECT as the two globals, because those are the axes the business reports on most.

The caution that matters most in this whole article: changing a global dimension after you have posted transactions is a heavy, disruptive operation. Business Central provides a "Change Global Dimensions" process, but on a live company with meaningful transaction volume it updates a large number of ledger entries and can run for a long time, and during much of that work the system is effectively locked for posting. In practice, once a company is live, the two global dimensions are treated as permanent. Choose them as if you cannot change them, because for all practical purposes you cannot. This is the decision teams most regret, so make it deliberately, not by whatever the implementation consultant happened to type in during setup.

Shortcut dimensions. Beyond the two globals, Business Central lets you promote up to six additional dimensions (positions three through eight, with the first two reserved for the globals) to appear as convenient inline columns on journal and document lines. Shortcut dimensions do not have the deep, first-class field storage that globals have, but they make frequently used non-global dimensions easy to enter directly on the line without opening the separate dimensions panel. If our engineering firm also tracks REGION but does not want it as a global, making REGION a shortcut dimension means clerks can key it straight onto journal lines. Shortcut dimensions are purely about data-entry convenience; they do not change how the dimension is stored or analysed.

Budget dimensions. When you create a general ledger budget, you can attach dimensions to it so that budget figures are also tagged by dimension and can be compared against actuals along the same axes. The global dimensions are always available on budgets, and you can nominate additional budget dimensions per budget so you can, for example, build a departmental budget or a project budget and then report actual-versus-budget cut by that dimension. Budget dimensions are what let variance reporting work along the same analytical lines as your actual reporting, which is the whole point of budgeting by dimension in the first place.

Everything else is an ordinary dimension. Ordinary dimensions are fully usable, you can post with them, filter on them and build analysis views over them, but they are not stored as first-class fields, so filtering large data sets on them is a little less direct than on a global. The practical hierarchy to remember: two globals for your most important axes, up to six shortcuts for convenient entry of the next tier, budget dimensions where you need variance analysis, and ordinary dimensions for everything else you want to tag and analyse.

4. Default dimensions on customers, vendors, items and accounts

Tagging every single transaction by hand would be exhausting and error-prone, so Business Central lets you attach default dimensions to master records. A default dimension says "whenever this record is used in a transaction, propose (or force) this dimension value automatically." You can set default dimensions on customers, vendors, items, general ledger accounts, fixed assets, resources, bank accounts, employees and more, on virtually any master record that participates in postings.

Continuing the example: if the FINANCE department has its own set of expense accounts and staff, you can set a default dimension of DEPARTMENT = FINANCE on the finance-specific general ledger accounts, so any posting to those accounts automatically carries the finance department tag. If a particular vendor only ever supplies the IT department, set DEPARTMENT = IT as a default on that vendor card, and every purchase invoice to that vendor is pre-tagged. If a customer belongs to a specific region, default the REGION dimension on the customer card so every sale to them inherits it. Defaults are what make dimensions practical at scale: the analytical tagging happens mostly automatically, driven by the master data, and clerks only override the exceptions.

The important refinement is the value posting rule attached to each default dimension. For each default you can specify how strictly it is enforced:

• No Code (blank rule): the default value is proposed but can be changed or removed at posting time. This is the gentle, suggestion-only behaviour.
• Code Mandatory: a value for this dimension must be present when the record is used, but it does not have to be the default one. This forces the clerk to always specify a department, for instance, without dictating which.
• Same Code: the transaction must use exactly the default value, no other value is permitted. Use this when a record genuinely only ever belongs to one dimension value and you want to prevent mistakes.
• No Code: no dimension value is allowed at all for this record, which is occasionally useful for accounts that must never carry a particular dimension.

You can also set default dimensions at the account-type level and even define dimension defaults for whole groups of accounts using default dimension priorities and dimension combinations, which brings us to the two features that most often cause confusion in practice: priorities and combinations.

5. Dimension priorities and how conflicts resolve

Here is a scenario that happens constantly. You post a sales invoice. The customer card has a default DEPARTMENT = SALES. The item on the line has a default DEPARTMENT = OPERATIONS. The general ledger account has a default DEPARTMENT = FINANCE. Three different master records, three different suggested department values, all feeding into the same posting line. Which one wins?

This is exactly what dimension priorities exist to resolve. Business Central lets you define, per source-code or posting context, a priority ranking of which record type's default dimension takes precedence when several records suggest a value for the same dimension. You might decide that for sales postings the customer's default should outrank the item's, which should outrank the account's. The system walks the priority list and takes the value from the highest-priority source that actually has a default for that dimension.

Without configured priorities, the behaviour when two sources propose different values for the same dimension can be a conflict that blocks posting until a human resolves it, which is safe but slow. With priorities configured, the resolution is automatic and predictable. My practical advice is to configure priorities early for your main posting flows, sales, purchases and general journals, so that the most authoritative master record for each flow wins cleanly. In a sales flow the customer is usually the most authoritative source of the region or business-unit dimension; in a purchase flow the vendor or the account often is. There is no universally correct ranking; it depends on which record in each flow best represents the analytical truth you want captured.

Practitioner insight: most "why is this dimension wrong on my entries" complaints trace back to unconfigured or misordered priorities, not to a system bug. When a posted entry carries a department nobody expected, do not start by blaming the clerk. Trace the chain: which master records were involved, what default each carried, and what the priority ranking told the system to prefer. Nine times out of ten the fix is a priority setting, not retraining the user.

6. Dimension combinations and rules

Sometimes certain dimension values should never appear together, or should only appear together in limited ways. Business Central handles this with dimension combination rules, which let you govern how two dimensions relate.

A blocked combination says two dimensions can never be used on the same entry at all. Suppose our firm has a dimension called FUNDING with a value GRANT, and a rule that grant-funded work can never be booked against internal overhead departments. You could block the combination so that any attempt to post FUNDING = GRANT together with DEPARTMENT = ADMIN is rejected outright. This is coarse but effective when two axes are genuinely mutually exclusive.

A limited combination is more nuanced: the two dimensions can be used together, but only specific value pairings are allowed. You define a matrix of which values of dimension A are permitted with which values of dimension B. In our example you might say that only certain projects are allowed for certain departments, so PROJECT = PRJ-1001 is valid with DEPARTMENT = OPERATIONS but invalid with DEPARTMENT = FINANCE. When a clerk tries to post an invalid pairing, Business Central refuses it. This is powerful for enforcing real organisational rules, for example that a given project can only be charged by the departments actually staffed on it.

Combination rules are one of those features that are easy to over-apply. They are genuinely useful for enforcing hard organisational constraints, but every rule you add is a way for a legitimate posting to get blocked, and every blocked posting is a support call. I use them sparingly and only for constraints that are truly invariant. If a combination is merely unusual rather than genuinely forbidden, a report exception is a better control than a hard block, because it flags the oddity without stopping the business. Reserve blocked and limited combinations for the rules that must never be broken, and let softer controls handle the rest.

7. Posting transactions with dimensions

With the structure in place, dimensions flow through everyday posting in a way that is mostly invisible once configured well. On a journal line, the two global dimensions appear as their own columns (in our case Department and Project), shortcut dimensions appear as additional inline columns if you promoted them, and the full set of every dimension on the line is always available through the Dimensions action, which opens a panel where you can see and set every dimension value for that line, global or not.

On documents, sales orders, purchase invoices, and the like, dimensions exist at two levels. There is a header level, holding the document-wide dimensions such as the customer's region, and a line level, where each line can carry its own dimension values. This matters: a single purchase invoice might hit two projects across two lines, so line-level dimensions let each line carry its own PROJECT value while the header carries the vendor-driven defaults. When you post, the line-level dimensions are what end up on the general ledger entries, so line dimensions are where the analytical truth is finally recorded.

The propagation logic is worth understanding because it explains most "where did this value come from" questions. When you enter a line, Business Central assembles the default dimensions from every relevant master record (account, item, customer or vendor, and so on), resolves any conflicts using the priorities you configured, respects the value posting rules (proposing, mandating or forcing values), checks the result against any combination rules, and lands on the final set of dimension values for the line. The clerk can override anything the value posting rules permit before posting. Once posted, those dimension values are stamped permanently onto the resulting ledger entries. You cannot casually edit dimensions on a posted general ledger entry; correcting them means a reversing and re-posting exercise, which is another reason to get the defaults and priorities right so that the values are correct at the moment of posting rather than fixed afterwards.

8. Analysis by dimensions and analysis views

Capturing dimensions is only half the value; the other half is analysing them. Business Central gives you several routes, and they suit different needs.

The most direct is to filter the general ledger entries and other ledgers by dimension. Because the global dimensions are first-class fields, you can filter the chart of accounts balances, the general ledger entries and most standard reports directly by Department or Project and see the numbers reshaped instantly. For quick questions, "what is the balance on this account for the Sales department this quarter," this native filtering is enough.

For richer, multi-dimensional analysis there are analysis views. An analysis view is a defined slice of the general ledger that you configure to track up to four dimensions together, over a chosen set of accounts and date ranges, and then update on demand or on a schedule. Once an analysis view is set up and updated, you can pivot the data by those dimensions, for example seeing a matrix of departments down the side and projects across the top, with account balances in the cells. Analysis views are the built-in answer to "I want to explore my postings across several dimensions at once without exporting to a spreadsheet." They pre-aggregate the dimension combinations so the analysis is fast, at the cost of needing to be refreshed to reflect the latest postings.

The trade-off to understand is that an analysis view is a materialised, periodically updated snapshot, not a live query. If you post new entries, the analysis view does not reflect them until it is updated. For most management reporting this is fine, you update at period close, but do not mistake an analysis view for real-time data. When you need the absolute latest figure, filter the ledger directly; when you need to explore many dimension combinations efficiently, use an analysis view. This distinction between dimension-based analysis and the fuller cost-allocation machinery is also where Business Central's separate Cost Accounting module comes in; for the contrast between using dimensions for analysis and using cost accounting for allocations, see the Business Central cost accounting pillar.

9. Dimensions in financial reports and Power BI

Dimensions reach their full potential in the reporting layer, and this is where the two-global choice pays off or bites you. Business Central's financial reporting, the account schedules and financial reports engine, lets you build row definitions and column definitions and then apply dimension filters to them. You can build a single profit and loss layout and then run it filtered by department, so the same report produces a Sales P and L, an Operations P and L and a consolidated view, all from one definition. You can also place dimensions on the columns, so a report shows each department as its own column across the page. Because the global dimensions are directly available in these definitions, reporting by your two globals is smooth; reporting by non-global dimensions is possible but generally needs analysis views underneath to make it efficient.

For anything beyond the built-in reports, Power BI is the natural destination, and dimensions are what make Business Central data genuinely useful in Power BI. When you connect Power BI to Business Central, the dimension values come through as attributes you can slice by, so you can build interactive dashboards that let a manager filter profit by department, drill into a project, or compare regions, all driven by the dimension tags captured at posting time. The quality of what you can do in Power BI is directly limited by the quality and consistency of your dimension data. Clean, consistently applied dimensions produce clean, trustworthy dashboards. Sparse or inconsistent dimensions produce dashboards full of blanks and "undefined" buckets that erode trust immediately.

This is the payoff argument for taking dimensions seriously from day one. The reports and dashboards everyone wants at year two are only as good as the tagging discipline you established at go-live. You cannot retrofit good dimension data onto years of untagged history without a painful cleanup, so the reporting future you want is decided by the posting discipline you enforce now.

10. Designing a dimension strategy

Everything so far leads to the practical question: how do you actually decide what your dimensions should be? Here is the framework I use when setting up or reviewing a Business Central dimension design.

• Start from the reports, not the system. List the management reports the business genuinely needs: profit by branch, cost by project, spend by cost center, revenue by product line. Each recurring analytical axis in those reports is a candidate dimension. Do not invent dimensions the business will never report on; every dimension is a tagging burden at posting time, so each one must earn its place by appearing in a report someone actually reads.
• Rank the axes by importance and pick the two globals carefully. Of all the candidate dimensions, which two does the business report on most and filter on most? Those are your global dimensions. Remember that this choice is effectively permanent, so bias toward the axes that are structural and enduring (department, cost center, business unit) rather than ones that churn. If projects come and go rapidly but departments are stable, that stability is an argument for department as a global even if projects feel more urgent day to day.
• Keep dimension values controlled and coded sensibly. Use short, meaningful codes with clear descriptions, and control who can create new values. Uncontrolled dimension value creation is how you end up with SALES, Sales, SLS and SALES-DEPT all meaning the same thing, which destroys the analysis. Treat the dimension value list as governed master data, not a free-text field.
• Lean on defaults to make tagging automatic. Set default dimensions on the master records that reliably imply a value, department on department-specific accounts, region on customers, and choose value posting rules that force what must be forced and merely suggest what can vary. The goal is that most entries are tagged correctly without the clerk thinking about it, so that dimension quality does not depend on daily human diligence.
• Configure priorities before go-live. Decide, for each posting flow, which master record is the authority for each dimension, and set the priorities accordingly. This prevents both silent wrong values and posting-blocking conflicts. It is a small amount of setup that removes a large amount of downstream confusion.
• Use combination rules only for hard constraints. Reserve blocked and limited combinations for rules that are genuinely inviolable. For everything softer, prefer a reporting exception over a posting block, so you keep control without adding friction to legitimate work.

The meta-principle behind all of this is restraint. The most common design failure is too many dimensions, not too few. A business that sets up eight dimensions because it can will find that most of them are inconsistently populated within a year, because the tagging discipline required to keep eight axes clean at every posting is more than any real operation sustains. Two well-chosen globals plus a small number of genuinely useful additional dimensions, all backed by strong defaults, beats a sprawling dimension design every single time. Start lean, prove each dimension earns its keep, and add only when a real reporting need justifies the ongoing tagging cost. For where dimensions sit within the full breadth of the product, the complete Business Central features guide puts them in context alongside the rest of the finance and operations modules.

11. Common dimension mistakes and how to avoid them

The patterns of failure in dimension implementations are remarkably consistent across the companies I have seen, and every one of them is avoidable with a little foresight.

• Choosing the two global dimensions carelessly. Because the choice is nearly permanent and the change process is heavy on a live company, a hasty global-dimension decision at setup haunts the business for years. Spend real time on this decision; it is the highest-stakes call in the whole configuration.
• Creating too many dimensions. Every extra dimension is another value someone has to get right on every relevant posting. Beyond a handful, consistency collapses and the analysis fills with blanks. Fewer, cleaner dimensions beat more, patchy ones.
• Not using defaults, so tagging depends on human memory. If clerks must remember to set every dimension by hand, some will forget, and your data develops holes exactly where you least expect. Defaults on master records are the mechanism that makes dimension data reliable at scale.
• Ignoring priorities until conflicts appear. Unconfigured priorities produce either wrong values or blocked postings. Configuring them proactively for the main flows removes a whole category of go-live pain.
• Letting dimension values proliferate uncontrolled. Duplicate and near-duplicate values (the SALES versus Sales problem) silently fracture every report. Govern the value list like the master data it is.
• Still bloating the chart of accounts. Teams migrating from an older system sometimes recreate their department-encoded accounts and add dimensions on top, getting the worst of both worlds. If you are adopting dimensions, commit to them and let the chart of accounts shrink to the nature of the transaction.
• Treating analysis views as live data. Forgetting that analysis views need updating leads to managers reporting stale figures. Know when you are looking at a snapshot versus a live ledger filter, and refresh views before you rely on them.

None of these is a technical limitation of Business Central. They are all design and discipline choices, which is encouraging, because it means the quality of your dimension analysis is entirely within your control. Get the globals right, keep the design lean, automate the tagging with defaults, configure priorities, and govern the value lists, and dimensions will do exactly what they promise: give you the analytical reporting the business always wanted without ever bloating the chart of accounts.

Final thoughts

Dimensions are the feature that separates a Business Central implementation that merely records transactions from one that genuinely informs decisions. The mechanics are not complicated: categories and their values, attached to entries as tags, propagated automatically from master data, resolved by priorities, governed by combination rules, and analysed through native filters, analysis views, financial reports and Power BI. What makes dimensions hard is not the mechanics but the design judgement, above all the near-permanent choice of the two global dimensions and the restraint to keep the overall design lean.

If you take one thing from this guide, let it be that the reporting you will want in two years is decided by the tagging discipline you establish now. You cannot retrofit clean dimension data onto years of careless posting. So design the dimensions from the reports the business actually needs, choose the two globals as if you can never change them, automate the tagging with strong defaults, and resist the urge to add every dimension you can imagine. Do that and dimensions become the quiet, powerful reporting backbone they were designed to be, delivering profit by department, cost by project, and any other analytical cut the business asks for, all from one clean chart of accounts.

Related reading: Business Central financial management, Business Central cost accounting, The complete Business Central features guide.