Quick answer
Use main ledger accounts to identify the financial category of a transaction. Use financial dimensions to classify that transaction by department, project, location, or another reporting perspective. Dimensions can become segments of the full ledger account, so this is a design distinction—not necessarily two separate technical structures. Microsoft’s documentation describes main accounts and dimensions working together through account structures and validation rules. (learn.microsoft.com)
Start here: List the reports you must produce, decide which classifications must be captured on transactions, and test valid combinations before migrating balances.
1. Separate financial categories from reporting perspectives
A useful starting question is: Does this information describe the financial category, or does it describe the business context?
For example, “travel expense” describes a financial category. “Consulting department,” “Boston office,” and “Project P101” describe perspectives through which management might analyze that expense. This follows the distinction in Microsoft’s chart-of-accounts guidance: accounts provide the financial framework, while dimensions add transaction classifications. (learn.microsoft.com)
Use the following as a proposed design worksheet, not a mandatory accounting template:
| Information | Starting design choice | Question to resolve |
|---|---|---|
| Travel, rent, service revenue | Main account | Does the category need a separate financial-report line or accounting treatment? |
| Department or cost center | Dimension | Who owns the revenue, cost, or budget? |
| Project | Project record and, where needed, dimension | Must project information appear in ledger-based reporting? |
| Location | Dimension or reporting hierarchy | Must location be captured independently, or can it be derived reliably? |
| Invoice or document number | Transaction reference or suitable tag | Is this a unique reference rather than a reusable classification? |
| Legal entity | Separate entity-design decision | Are separate operational, tax, or statutory processes required? |
Do not assume every classification belongs in a dimension. Microsoft advises against using dimensions for non-reusable document and reference numbers. In Dynamics 365 Finance, financial tags provide an alternative for some transaction-level information, but tags do not provide the same validation or trial-balance reporting as dimensions. (learn.microsoft.com)
Likewise, a dimension labeled “Company” is not automatically equivalent to a legal entity. Microsoft explicitly identifies operational and tax limitations when dimensions are used to represent entities. (learn.microsoft.com)
2. Design backward from required reports
Before assigning account numbers, create a reporting requirements register. For each report, record:
- Its owner and intended decision.
- Required rows, columns, and filters.
- Whether it needs transaction detail or balances.
- Whether the classification must also support budgeting.
- How it will reconcile to the general ledger.
For example:
| Required output | Proposed supporting structure |
|---|---|
| Company-wide income statement | Main accounts and report groupings |
| Department expense report | Main account plus department |
| Project direct-cost report | Project coding on relevant costs |
| Location comparison | Location coding or a tested hierarchy |
| Budget versus actual by department | Consistent department classification in both datasets |
Treat these as requirements to demonstrate in the target ERP—not assumed capabilities.
Microsoft’s account-structure guidance suggests considering a hierarchy instead of another entry segment when, for example, location can be determined from department or cost center. It also states that dimensions used for budgeting in Dynamics 365 Finance should be included in an account structure because budgeting does not currently use advanced rules. (learn.microsoft.com)
Before deriving location from department, ask what happens when a department moves or operates across several offices. Specify whether historical reports should show the original structure or a restated management view. Make that choice explicit rather than leaving it to report-builder interpretation.
3. Compare two designs for a services business
Synthetic example: Consider a services business with Consulting and Support departments, East and West locations, and client projects. The codes and amounts below are illustrative, not an actual implementation or a prescribed chart of accounts.
An account-heavy design might create separate main accounts such as:
- Travel—Consulting—East.
- Travel—Consulting—West.
- Travel—Support—East.
- Travel—Support—West.
A dimension-based alternative would use one main account, 6100 Travel, with separate Department, Location, and Project fields.
Assume the business receives a $1,200 travel invoice. For this example, ignore tax and currency complications. The invoice supports two client projects:
| Main account | Department | Location | Project | Debit |
|---|---|---|---|---|
| 6100 Travel | Consulting | East | P101 | $800 |
| 6100 Travel | Support | West | P202 | $400 |
| Accounts payable control | Per tested posting setup | Per tested posting setup | Per tested posting setup | $1,200 credit |
Enter the expense split through the appropriate purchasing or accounts-payable process. Let the configured posting setup generate the control-account entry; do not assume its dimensions must copy the expense lines.
The expected expense reports are:
- Travel total: $1,200.
- Consulting travel: $800.
- West-location travel: $400.
- P101 direct travel cost: $800.
These are alternative views of the same expense, not amounts to add together.
The account-heavy design embeds organizational detail in account selection. The dimension design separates those choices and makes each classification explicit. However, dimensions still need valid values, rules, and usable defaults; adding fields alone does not establish a controlled reporting structure. Dynamics 365 Finance uses account structures to determine required dimensions and valid combinations. (learn.microsoft.com)
Also distinguish project direct cost from project profitability. This example establishes only travel attribution. A profitability report would need an agreed treatment of revenue, labor, allocations, and other relevant costs.
4. Define valid combinations and test defaults
Document the intended rules before configuring the ERP.
For the synthetic business, a proposed rule matrix might be:
| Posting situation | Proposed rule |
|---|---|
| Operating expense | Department required |
| Project-specific travel | Department, location, and project required |
| Corporate overhead | Project blank permitted |
| Closed project | Block new ordinary postings, with a defined exception process |
| Control accounts | Apply the requirements established by the subledger design |
Then specify permitted relationships. If P101 belongs only to Consulting, decide whether selecting Support should be rejected or whether another business scenario legitimately requires that combination.
In Dynamics 365 Finance, account structures control permitted combinations and required values. Advanced rules can require additional dimensions when specified criteria apply. The documentation also requires a single valid path for a combination; overlapping criteria can prevent activation. (learn.microsoft.com)
A default is not the same as a restriction. Microsoft distinguishes overridable default dimensions from fixed dimensions, which override values supplied elsewhere. It also warns that dimension defaulting during imports can differ from application entry. (learn.microsoft.com)
Accordingly, test both a correct default and a conflicting value. Verify the posted result—not merely what appeared on the input screen.
Avoid requiring irrelevant dimensions simply to eliminate blanks. Define when blank means “not applicable” and when it means “missing information.”
5. Map legacy accounts without inventing history
Treat migration mapping as a controlled transformation, not just an account-number replacement.
For the synthetic business:
| Legacy account | Target main account | Department | Location | Project |
|---|---|---|---|---|
| Travel—Consulting—East | 6100 | Consulting | East | From supported source detail |
| Travel—Support—West | 6100 | Support | West | From supported source detail |
Keep the original account code, mapping rationale, approval, and effective date in the mapping register.
Recommended migration checks include:
- Account coverage: Every in-scope legacy account has an approved destination.
- Dimension support: Each assigned value is supported by account meaning or transaction evidence.
- Reconciliation: Transformed debits, credits, and balances agree to the approved source.
- Exception review: Ambiguous accounts are resolved or explicitly retained as unresolved.
- Comparative reporting: Users understand where historical detail differs from the new design.
If a legacy account combines several departments, the account balance alone does not establish the split. Use supporting transaction detail where available. Otherwise, document the limitation and obtain approval for the treatment rather than manufacturing precision.
Separate opening-balance requirements from historical reporting ambitions. Decide whether detailed history will be migrated, retained in an accessible archive, or transformed into a comparative reporting dataset.
Do not expect a new account structure to recode the past: Microsoft states that account-structure changes in Dynamics 365 Finance do not affect posted transactions. (learn.microsoft.com)
6. Assign ownership and preserve meaning
Create a short data dictionary for every account and dimension. Include:
- Business definition and reporting purpose.
- Owner and approver.
- Valid values and naming convention.
- Required, optional, and prohibited uses.
- Source system and defaulting rules.
- Effective dates and retirement procedure.
- Reports and integrations affected by changes.
A useful proposed ownership model is for the controller to approve main-account changes, department owners to approve organizational values, and project administration to maintain project records.
Distinguish manually maintained dimensions from dimensions backed by another record. In Dynamics 365 Finance, entity-backed dimension values are maintained through their source entity; a project-backed value, for example, comes from project setup. (learn.microsoft.com)
Require a change request when someone proposes a new value. Ask which report needs it, why existing values are insufficient, and which entry paths must support it.
Avoid reusing retired codes for unrelated meanings. Record organizational changes explicitly so that historical classifications remain understandable.
7. Validate the complete workflow in a sandbox
Give a finance process owner and ERP administrator access to a nonproduction environment with representative configuration and approved test data. Test the structure through actual posting paths, not only configuration screens.
Use this acceptance checklist:
- Positive tests: Valid invoices, journals, credit notes, and expense splits post.
- Negative tests: Missing required values and prohibited combinations are rejected.
- Default tests: Conflicting header, master-record, and line values produce the intended result.
- Integration tests: Each relevant import or interface preserves classifications.
- Report tests: Department, location, and project views reconcile to the same ledger totals.
- Lifecycle tests: New values, suspended values, reversals, and corrections behave as intended.
For the worked example, require the reports to reproduce the $1,200 total and its $800/$400 classifications. Investigate unexpected blanks, exclusions, or double counting before approval.
Plan configuration changes around unposted work. In Dynamics 365 Finance, activating an account structure synchronizes unposted transactions, while posted transactions remain unaffected. Test that impact before production activation. (learn.microsoft.com)
Finally, document a recovery procedure: pause affected interfaces, preserve configuration exports, identify impacted transactions, and rehearse the supported restoration or corrective process. Do not assume reactivating an old structure will undo posted entries.
The acceptance test is practical: Can users enter valid transactions, reject invalid ones, and produce agreed reports that reconcile? Approve the design only when all three work together.