Quick answer: Use the main account to identify the financial nature of a transaction, and dimensions to identify the department, location, project or other reporting context. Avoid creating a separate expense account for every organizational combination. Start with reporting requirements, define valid combinations, and test the design in your ERP before approving it. Microsoft’s documentation describes dimensions as a way to categorize transactions without building an unnecessarily complicated chart of accounts. (learn.microsoft.com)
This guide is for finance teams designing or reviewing an ERP reporting structure. The decision framework is a recommended approach; product-specific capabilities are identified separately for Microsoft Dynamics 365 Finance and Dynamics 365 Business Central. It is not a production configuration procedure.
1. Separate financial meaning from reporting context
A chart of accounts is the structured collection of general ledger accounts used to organize financial information. In Dynamics 365 Finance, financial dimensions add segments that further classify transactions—for example, department, cost center or purpose. (learn.microsoft.com)
Use the following design test:
| Question | Recommended starting point | Example |
|---|---|---|
| What financial item is this? | Main account | Rent expense |
| Who is responsible for it? | Department or cost center | Operations |
| Where does it belong? | Location dimension | North branch |
| Which initiative does it support? | Project dimension, if needed | Branch refurbishment |
| Which broader reporting group contains it? | Reporting hierarchy or mapping, where suitable | Northern region |
These are starting points, not universal accounting rules. Consider local reporting requirements, ledger configuration and posting needs before deciding whether two items can share an account.
For each proposed new account, ask:
“If we removed the department, location and project from its name, would this still be a distinct financial category?”
If “Rent—North—Operations” becomes simply “Rent,” consider keeping rent as the account and storing the other attributes separately. If the distinction remains financially meaningful, document why a separate account is necessary.
2. Start with reports and decisions, not account codes
Before choosing code lengths or segment order, list the outputs the structure must support.
For each report, record:
- The decision it supports and its owner.
- Required rows, columns and filters.
- Whether it needs actuals, budgets or both.
- Whether users need transaction-level investigation.
- Whether historical organizational structures must remain visible.
- Which transactions provide the required attributes.
For example, “monthly operating expenses by branch and department” implies three separate classifications: expense category, branch and department. It does not automatically justify branch-specific expense accounts.
Distinguish data that must be captured on a transaction from data that can be derived reliably. Microsoft’s account-structure guidance suggests considering a hierarchy instead of another input segment when, for example, location can be determined from department or cost center. Treat that as conditional: if departments operate across locations, the relationship is not sufficient. (learn.microsoft.com)
A useful workshop deliverable is a report-to-data matrix. Do not approve a dimension merely because someone might want it someday. Require a defined use, an owner and a dependable source.
3. Compare two designs for a fictional multi-location business
Consider a fictional business with one legal entity, three branches and two departments: Sales and Operations. For this example, it tracks four expense categories: rent, utilities, repairs and travel.
An overloaded design creates a separate main account for every expense–branch–department combination:
| Illustrative account | Description |
|---|---|
| 610101 | Rent—North—Sales |
| 610102 | Rent—North—Operations |
| 610201 | Rent—Central—Sales |
| 610202 | Rent—Central—Operations |
Repeating this pattern across all four expense categories produces 4 × 3 × 2 = 24 main accounts, assuming every combination is used.
A dimension-based alternative keeps the classifications separate:
| Component | Illustrative values |
|---|---|
| Main account | 6100 Rent; 6200 Utilities; 6300 Repairs; 6400 Travel |
| Branch | NORTH; CENTRAL; SOUTH |
| Department | SALES; OPS |
This alternative has four main accounts for the example, plus the dimension values and validation rules. It does not eliminate the underlying reporting combinations; it separates their components.
Worked reporting check
Assume these illustrative rent expense lines, in USD, excluding tax considerations:
| Main account | Branch | Department | Debit |
|---|---|---|---|
| 6100 Rent | NORTH | SALES | $1,200 |
| 6100 Rent | NORTH | OPS | $800 |
| 6100 Rent | SOUTH | OPS | $1,000 |
| Total | $3,000 |
The offsetting payable or cash lines are outside this reporting example.
Expected results are:
- Total rent: $3,000
- North branch rent: $2,000
- South branch rent: $1,000
- Operations rent: $1,800
For acceptance testing, reproduce these totals from posted transactions—not only an entry screen or spreadsheet. Confirm that branch totals and department totals independently reconcile to the same $3,000.
For a proposed fourth branch, the design decision would be whether to add a branch value and its permitted combinations, rather than automatically duplicating the expense accounts.
4. Define valid combinations and deliberate exceptions
A dimension list is only part of the design. Write down which values may appear together and when a value is mandatory.
For the fictional business, a proposed rule matrix could be:
| Transaction category | Proposed requirement | Test |
|---|---|---|
| Routine operating expense | Branch and department required | Missing department is rejected |
| Refurbishment expense | Project required under the approved policy | Missing project is rejected |
| Central-only function | Only approved branch–department pairs | Invalid pair is rejected |
| System-generated posting | Explicitly reviewed treatment | Automated process completes correctly |
These are example business rules, not prescribed accounting treatment.
Dynamics 365 Finance account structures define permitted combinations and required dimensions. Advanced rules can add dimensions when specified conditions are met. A default value is not the same as enforcement: Microsoft distinguishes an overwriteable default from a fixed value applied during posting. (learn.microsoft.com)
Business Central can block an entire pair of dimensions or limit particular value combinations. Use that distinction carefully: prohibiting Department and Project together is different from prohibiting one particular department–project pairing. (learn.microsoft.com)
Avoid making every dimension mandatory on every account. Instead, define legitimate “not applicable” cases and assign someone to review unexplained blanks. If an “Unassigned” value is permitted temporarily, specify who resolves it and when.
5. Check the restrictions of the actual ERP
Do not assume that products with similar terminology use identical rules. Verify the following against your deployed version, enabled features and extensions.
Dynamics 365 Finance
- Account-structure capacity: A structure supports a main account plus up to ten financial dimensions. Microsoft documents advanced rules for additional segments, but recommends evaluating whether that complexity is necessary.
- Budgeting: Dimensions used for budgeting should be in an account structure; budgeting does not currently use advanced rules.
- Legal entities: Dimensions can represent organizational distinctions, but are not a general substitute for legal-entity functionality. Microsoft identifies limitations, including sales-tax functionality being associated with legal entities rather than financial dimensions. (learn.microsoft.com)
Dynamics 365 Business Central
- Global and shortcut dimensions: There are two global dimensions and up to eight shortcut dimensions—not a total limit of eight defined dimensions.
- Automated postings: Microsoft warns against setting Code Mandatory or Same Code on accounts used by the Adjust Exchange Rates or Post Inventory Cost to G/L batch jobs.
- Later changes: Changing global dimensions can require substantial processing and affect performance. (learn.microsoft.com)
Before approval, test purchasing, sales, journals, imports, automated postings and budget reporting. A successful manual journal is not sufficient evidence that all posting routes work.
6. Assign ownership, naming standards and change governance
Use a small data dictionary for each account and dimension:
| Field | What to document |
|---|---|
| Definition | What the classification means—and excludes |
| Owner | Who approves values and resolves ambiguity |
| Source | Manual maintenance, source entity or integration |
| Code standard | Length, characters, leading zeros and examples |
| Posting rules | Required, optional, fixed or conditional |
| Lifecycle | Creation, effective date, suspension and retirement |
| Reporting impact | Reports, budgets and mappings affected |
Prefer stable identifiers with clear descriptions. Avoid embedding a manager’s name or a changing organizational hierarchy into a permanent code. Do not reuse a retired code for an unrelated purpose.
Product constraints matter here. Dynamics 365 Finance custom dimensions are maintained manually, while entity-backed dimensions obtain values from another system entity. Changes to entity-backed values belong at that source. Microsoft also warns against using the chart-of-accounts delimiter inside account numbers, dimension names or dimension values. (learn.microsoft.com)
For each change request, require the business reason, owner approval, affected integrations, test evidence and an agreed deployment plan. Record whether comparative reports should preserve the old structure or apply a separately approved management-reporting mapping.
7. Run a design review before migration or go-live
Use this checklist as an acceptance gate:
- Account purpose: Each proposed main account has a distinct, documented financial purpose.
- Reporting coverage: Every required report has a confirmed data source and owner.
- Dimension independence: Separate dimensions capture genuinely separate classifications.
- Combination controls: Valid, invalid and missing-value cases have been tested.
- Default behavior: Tests include conflicting header, master-record and line values.
- Posting coverage: Manual, imported and automated transactions have been checked.
- Budget compatibility: Budget and actual reports use compatible classifications.
- Historical treatment: Old codes, reorganizations and comparative reporting are addressed.
- Reconciliation: Dimension reports reconcile to the same ledger totals, including blank or unassigned values.
- Governance: Named owners approve additions, restrictions and retirements.
Pay particular attention to defaults. Microsoft notes that Dynamics 365 Finance import behavior differs from application defaulting. Therefore, test the imported result rather than assuming it will match manual entry. (learn.microsoft.com)
The most useful design is not simply the one with the fewest accounts. Approve a structure only when the team can explain what each component means, demonstrate the required reports, reject inappropriate combinations and maintain the classifications through future changes.