More than any other configuration choice you’ll make, your financial dimension structure shapes what your system can tell you for years to come. Let’s get it right the first time.
“If I had a dollar for every time I’ve been called into a post-go-live conversation that starts with ‘our reports don’t look the way we expected’ — and traced it back to a financial dimension design decision that was made too quickly, too late, or without the right people in the room — I would have a very comfortable retirement fund.”
Let’s Start From the Beginning: What Is a Financial Dimension?
If you’re coming from a traditional accounting background, you already understand this concept — you just probably knew it by a different name. Cost centers. Departments. Profit centers. Business units. Projects. In D365 F&SCM, these are all financial dimensions.
Here’s the official definition, translated into plain English: a financial dimension is an attribute you attach to a financial transaction to give it context beyond just the account number. It answers the question your general ledger alone can’t: not just what was spent, but where, by whom, for what purpose, and against which project or product line.
Without financial dimensions, your P&L tells you that you spent $80,000 on salaries. With financial dimensions, it tells you that $23,000 of that went to the Northeast sales region, $41,000 went to the manufacturing cost center, and $16,000 was allocated to Project Greenfield. Same dollar amount. Completely different insight.
That’s the whole idea. And that’s why getting the structure right matters so much.
The Teacher in Me Has to Do This
Think of your chart of accounts as the what — what kind of transaction is this? Revenue? Expense? Asset? A financial dimension is the who, where, and why. Your chart of accounts is the noun. Your financial dimensions are the adjectives. The combination is what makes your financial statements actually tell a story instead of just listing numbers.
How Dimensions Actually Work: The Account String
In D365 F&SCM, every transaction is coded to an account structure that combines your main account with one or more financial dimension values. This is called your account string, and it looks something like this:
601000—NE—MKT—P-2024-007—PRD-A
Main Account-Region–Department-Project-Product Line
What you’re looking at is a single transaction coded to account 601000 (let’s say Salaries & Wages), in the Northeast region, in the Marketing department, against Project 2024-007, and attributed to Product Line A. That’s a remarkably specific slice of financial data — and it was captured automatically at the point of transaction entry, based on the dimension values assigned.
This is what makes financial reporting in F&SCM so powerful. And it’s also exactly why the design of this structure deserves a dedicated meeting — or several — before anyone touches a configuration screen.
The Types of Dimensions You Can Use
D365 F&SCM gives you a few different ways to define the values in your dimensions, and it’s worth understanding the difference before you design yours.
| Dimension Type | What It Means | Example Values | Best Used For |
|---|---|---|---|
| Custom Dimension | A freestanding list of values you define and maintain manually in F&SCM | NORTH, SOUTH, EAST, WEST | Geographic regions, cost centers, business units, product lines — anything that doesn’t already exist as a system entity |
| Entity-Backed Dimension | Pulls its values directly from an existing F&SCM entity — departments, workers, customers, vendors, projects, items | Dept: Finance, HR, Ops | Anything you want to stay in sync with master data you’re already maintaining in the system — fewer places to update when things change |
| Derived Dimension | Automatically fills in other dimension values based on the one you entered — set it up once, let the system do the work | Enter Cost Center → Region auto-fills | Reducing data entry errors when certain dimensions always go together — great for enforcing consistency without relying on users to remember |
| Default Dimensions | Pre-assigned values on master records — vendors, customers, departments — that auto-populate on transactions related to that record | Vendor ABC always defaults to Dept: Procurement | Minimizing manual entry and coding errors on high-volume transactions; your AP team will appreciate this one |
The magic — and the discipline — is in using these thoughtfully together. Entity-backed dimensions that feed derived dimensions that populate through defaults mean your team is spending almost no time manually coding transactions. That’s the goal. You design the intelligence into the system upfront so your users don’t have to carry it in their heads.
Real-World Scenarios: What This Looks Like in Practice
Abstract explanations only get you so far. Let me show you how different types of organizations typically structure their dimensions — and what reporting capabilities those structures unlock.
Multi-Site Manufacturer
Needs to track costs and revenue by production facility, by product family, and by cost center within each site. Leadership wants to compare plant-level profitability and identify where margin compression is happening.
Business Unit-Site-Cost Center-Product Family
Multi-Entity Professional Services Firm
Operating in multiple legal entities with shared services functions. Needs to track revenue and cost by service line, by client, and — critically — by the individual who performed the work for project billing and profitability analysis.
Department-Service Line-Project-Worker
Regional Distributor
Operating across geographic territories with multiple product lines. Sales leadership needs territory-level P&Ls. Finance needs to track warehouse operating costs separately from sales costs. Executive team wants a product-line view that cuts across territories.
Region-Channel-Product Line-Cost Center
Holding Company with Subsidiaries
Multiple legal entities with consolidated reporting requirements. Needs intercompany transaction visibility, entity-level financial statements, and a structure that supports eliminations cleanly at consolidation. Leadership also wants a segment view that cuts across legal entities.
Business Unit–Department-Segment-Intercompany
Notice what all of these have in common: the dimension structure was designed around what leadership needs to see in reports — not around what was easy to enter or what matched the old system’s structure. That’s the lens you need throughout this conversation.
The Conversation You Need to Have — and Who Needs to Be in the Room
Here’s where my controller background becomes genuinely useful, because I’ve been on both sides of this table. I’ve been the person who inherited a dimension structure I didn’t design and spent years working around it. And I’ve been the consultant helping organizations design one that actually serves them.
The difference between those two experiences almost always comes down to whether the right questions were asked at the right time, by the right people. So let’s talk about the questions.
01 Start With the Reports, Not the Dimensions
Ask your CFO and your controller this question: “If you could run any financial report you wanted — any cut of the data, any view of profitability, any cost allocation — what would it show?” Write down every answer. Every single one. Those answers are your dimension requirements. You’re building the structure that makes those reports possible, so you need to know exactly what you’re building toward before you start.
02 Then Ask: What Does Operations Need to See?
Financial reporting is half the story. Your operations leadership — plant managers, regional VPs, project managers — also have visibility requirements. What do they need to monitor performance in their area? If the dimension structure serves Finance but not Operations, you’re going to have users finding workarounds, which defeats the entire purpose. Both sides of the house need to be part of this conversation.
03 Be Honest About How Transactions Actually Get Coded Today
Whatever dimension structure you design is only as good as the data that flows into it. So ask: how do your transactions get coded today? Who does it? How often do they make mistakes? How much manual entry is involved? A beautifully designed dimension structure that requires your AP team to manually select four dimension values on every invoice is a structure that will have inconsistent data within six months. Design for how the work actually happens, and use defaults and derived dimensions to automate as much of the coding as possible.
04 Challenge Every “We’ve Always Had This” Dimension
When someone says “we need a dimension for X because we’ve always tracked X,” that’s the moment to pause and ask why. Sometimes the answer is a genuinely good business reason. Sometimes the answer is “honestly, nobody has looked at that report in three years.” Migrating unnecessary complexity into a new system doesn’t clean it up — it just makes the new system messier. This is your chance to rationalize.
05 Map Your Account Structures Before You Configure
F&SCM uses account structures to define which dimensions are valid (and required) for which main accounts. You don’t necessarily need every dimension on every account. Your revenue accounts might require Region and Product Line. Your expense accounts might require Department and Cost Center. Your capital accounts might require only Business Unit. Designing these structures thoughtfully — on paper, before you touch the system — prevents configuration rework and ensures your data is consistently populated where it matters.
The Things That Go Wrong — And How to Avoid Them
I promised you practical, and practical includes the cautionary tales. Here are the dimension design mistakes I’ve seen derail reporting and cause genuine organizational pain.
Too Many Dimensions
More dimensions feel like more flexibility — until they become more maintenance, more data entry, more inconsistency, and more confusion about which dimension captures what. I’ve seen implementations where nobody could agree on the difference between “Division” and “Business Unit” and “Segment” because all three existed and nobody had defined them clearly. Every dimension you add is a commitment to maintaining its values, training users on its purpose, and auditing its data quality going forward. Add only what you will genuinely use.
→ A rule of thumb worth stealing: if you can’t immediately name two reports that use a dimension, challenge whether it needs to exist.
Copying the Old System’s Structure Without Questioning It
This one happens all the time. The old system had six cost centers, so the new system gets six cost centers — same names, same codes, same structure. Nobody asked whether those six cost centers still reflect how the business is organized, or whether leadership actually uses the reports they produce. Migrations are a natural point to redesign. Don’t miss the opportunity because it feels safer to replicate.
→ For every dimension value you plan to migrate, ask: “Do we have active transactions against this? Do we run reports on it? Does anyone outside of accounting know what it means?” If the answer to all three is no, consider retiring it.
Designing Dimensions That Should Be Separate Accounts
Sometimes organizations try to use dimensions where they really need distinct main accounts. If you’re using a “Transaction Type” dimension to distinguish between different types of revenue or expense, ask yourself whether those actually belong as separate lines in the chart of accounts instead. Dimensions are for slicing a single account across business attributes — not for compensating for an under-developed chart of accounts.
→ A clean chart of accounts and a clean dimension structure work together. If your dimensions are doing work your chart of accounts should be doing, revisit both.
Forgetting That Dimensions Live on Master Records
Default dimensions on vendors, customers, departments, and workers are one of the most powerful tools you have for ensuring clean data — and one of the most commonly overlooked during implementation. If your vendor master isn’t set up with appropriate default dimensions, your AP team will be manually coding those values on every invoice. Multiply that by invoice volume and you have a significant data quality risk and a significant efficiency problem. Master record defaults are not an optional cleanup item — they’re a core configuration requirement.
→ Include default dimension assignment as part of your data migration checklist. Every vendor, every customer, every department should arrive in the new system with default dimensions already assigned.
Not Locking Down the Design Before Build Starts
Dimension changes after configuration begins — and especially after data migration — are painful. Changing the name of a dimension, adding a new dimension to an existing account structure, or retiring a dimension that already has transactions against it creates cascading configuration rework and potential data integrity issues. Decisions about financial dimensions need to be final before build starts. “We’ll figure out the details later” is not an acceptable status for this particular conversation.
→ Get sign-off. Formal, documented, named-individual sign-off from your CFO, Controller, and any business unit leaders whose reporting is impacted. If they’re not willing to commit to the structure, you’re not ready to build it.
The Do’s and Don’ts — Quick Reference Version
For those of you who like a tidy summary — you’re welcome.
✓ Do This
- Start with report requirements, work backward to dimension design
- Involve CFO, Controller, and operations leaders in the design conversation
- Use entity-backed dimensions wherever the data already lives in the system
- Set up derived dimensions to reduce manual entry errors
- Assign default dimensions to all vendor, customer, and department master records
- Document the purpose of each dimension in plain language
- Define account structures that require only the dimensions relevant to each account type
- Get formal sign-off before build begins
- Test your dimension structure with real report scenarios, not just data entry scenarios
✗ Don’t Do This
- Copy your old system’s structure without questioning it
- Add dimensions you “might want someday” without a specific use case
- Let dimension design happen in a vacuum between IT and the implementation consultant
- Treat dimension values as a data migration item rather than a design decision
- Use dimensions to compensate for a poorly structured chart of accounts
- Make dimension changes after build has started without a formal change control process
- Require users to manually code more than two or three dimensions on routine transactions
- Forget that dimension data is only as good as the people entering it — design for human behavior
A Word on Changing Your Mind Later
I want to be honest with you about something, because I think it matters: financial dimension changes after go-live are possible, but they are never fun. Adding a new dimension to an account structure that already has transactions means all of those existing transactions don’t have a value for the new dimension — which creates gaps in your historical reporting. Renaming a dimension can have downstream impacts on financial reports and any integrations that reference dimension values. Retiring a dimension that’s been in use requires careful data archiving and communication.
None of this means you’re locked in forever. Businesses change, and your system should be able to accommodate that. But it does mean that getting the design right the first time saves an enormous amount of pain, cost, and disruption later. The time you invest in this conversation upfront — even if it feels slow, even if it requires multiple meetings and some uncomfortable debates — pays dividends for as long as the system is live.
The controller in me needs to say this plainly: I’ve seen organizations spend years generating financial reports they don’t fully trust because their dimension structure didn’t capture the data they actually needed. I’ve also seen organizations where leadership can pull a meaningful, decision-quality P&L cut in minutes because the dimension design was thoughtful and disciplined. The difference between those two outcomes is almost entirely a design decision made before go-live. You have the chance to be the second kind of organization. Take it seriously.
Up Next:
We’ll be diving into Chart of Accounts Design in D365 F&SCM — because financial dimensions and the chart of accounts are two sides of the same coin, and if one isn’t designed well, the other can’t compensate. We’ll talk about segment design, account numbering strategy, the accounts you always need and the ones people always forget, and what “less is more” actually looks like in practice.
If you’ve ever inherited a chart of accounts that looked like it was designed by committee over fifteen years with no shared vision — I see you, and that post is for you.
As always — take notes, ask the uncomfortable questions, and do not let this design conversation happen without the people who actually read the financial statements.
— Bobbi
D365 Functional Architect · Recovering Controller
Leave a Reply