Quick question before you keep scrolling: if someone asked you right now to pull a profit and loss statement by region, by project, and by cost center, all at once, could your system do it cleanly? Or would you be exporting three reports into Excel and stitching them together by hand?
I’ve watched this exact scramble play out more than once during a Dynamics 365 Finance and Operations (D365 F&O) implementation. It usually traces back to the same root cause: decisions made in the first few weeks of design, about the chart of accounts and financial dimensions, that nobody revisited until it was too late to change cheaply.
I’ve worked with a variety of clients, some like to have a more simple chart of accounts and dimension sets, using tags and other means to gather reporting. With PowerBI and other reporting tools, this is really the way of the future. The need to have seven dimensions for every single item that is coded (simply for a reporting requirement) isn’t necessary. And those clients who still insist this is needed, can really back themselves into a corner with those continued requirements and extra work.
Welcome to the first post in a new series, “Things I Wish I’d Known: D365 Finance & Operations.” Over the next five posts I’m walking through the lessons that tend to show up only after you’ve lived through a few implementations. We’re starting here because this is the one that’s hardest, and most expensive, to fix after the fact.
The idea in one minute
Your chart of accounts and financial dimensions are the skeleton your entire general ledger hangs on. Every transaction from day one of go-live gets tied to that structure. Once you have real transaction history sitting on top of it, restructuring means either living with a permanent mess or undertaking a painful, costly rebuild. Get the design conversation right before go-live, with your actual reporting needs on the table, not just what’s fastest to configure, and you’ll save yourself years of pain. ✅
What is a chart of accounts, really?
Your chart of accounts is simply the full list of main accounts your organization uses to record financial transactions: your revenue accounts, your expense accounts, assets, liabilities, all of it. Nothing exotic there. It’s the same concept you learned in your first accounting class, just now living inside D365.
Where it gets more interesting is deciding how many main accounts you actually need, and how granular they should be. It’s tempting to create a separate main account for every possible breakdown you might want to report on someday. Resist that urge. That’s exactly what financial dimensions are for.
Where financial dimensions come in
Financial dimensions let you tag a transaction with extra context, department, cost center, project, region, whatever matters to your business, without multiplying your main account list into an unmanageable pile. Dimensions come in a couple of flavors: custom dimensions you build and maintain yourself, and entity-backed dimensions that pull their values from something already in the system, like your customer or project list.
Your main account and your dimensions come together through an account structure, which is the rule set that decides which dimension combinations are valid for a given account range. This is also where reporting flexibility actually gets built, or doesn’t.
Why this decision is so hard to walk back
Here’s the part that catches people off guard. Once you’re live and posting real transactions, that history is permanently linked to whatever main accounts and dimension values existed at the time. Dimension names have naming rules, values have a character limit, and once dimensions are activated they’re in active use across account structures and transactions. Unwinding any of that after go-live isn’t a quick settings change. It’s a project.
That’s why the design conversation matters so much before you ever open the system to build it. ⏳
Questions worth asking before you finalize the design
Bring these into the room early, ideally with finance leadership, not just the implementation team:
- What do we actually need to report on, by legal entity, by segment, by project, three years from now, not just at go-live?
- Which of these reporting needs belong on the main account, and which belong on a dimension? (Hint: if it changes often or applies across many accounts, it’s probably a dimension.)
- Are we planning for growth? New departments, new regions, new cost centers?
- Who owns adding new dimension values after go-live, and what’s the process?
- Have we mapped our current chart to the new one, or are we just recreating old habits in a new system?
None of these questions are complicated. But they get skipped constantly, usually because the team is focused on getting through configuration, not on the reporting the finance team will need eighteen months from now. 💡
Thank you for reading!
Next up in the series: “Number Sequences: Plan for Growth, Not Just Day One,” where we’ll look at another decision that feels harmless on day one and gets expensive the moment you run out of room to grow.
Sources
- Plan a local chart of accounts – Finance | Dynamics 365
- Financial dimensions – Finance | Dynamics 365
- Define financial dimensions – Finance | Dynamics 365
- Account structures overview – Finance | Dynamics 365
Interested in learning more? Below are some of my latest posts:
Leave a Reply