Project Accounting Cost Structure in Dynamics 365 Finance

What Each Layer Is Really For — and Where Most Designs Go Wrong

Most project accounting problems in Microsoft Dynamics 365 Finance don’t come from missing features or poor configuration.

They come from decisions that feel small at the time — how to structure projects, how much detail to capture, where to enforce control — but end up shaping everything that follows. Accounting behavior. Data quality. Day-to-day friction. Even how often finance and project teams end up arguing.

Cost structure isn’t a reporting preference.
It’s a design choice.

And once a system is live and transactions are flowing, that design choice becomes hard to revisit without real cost.

This article isn’t a configuration guide.
It’s a way to think clearly about what each structural layer in Project Management and Accounting is actually meant to do — and what happens when it’s asked to do something else.

Why cost structure is where PMA either holds together or starts drifting

In many implementations, project accounting structure ends up trying to satisfy everyone at once.

Leadership wants visibility.
Project managers want room to maneuver.
Finance wants control and traceability.
Procurement wants something that doesn’t slow purchasing down.

When those priorities aren’t explicitly reconciled, structure becomes the place where tensions are absorbed. Extra layers get added. Categories multiply. Hierarchies grow deeper than anyone originally intended.

Nothing breaks immediately.
But over time, the system becomes harder to explain, harder to govern, and harder to trust.

(If this sounds familiar, it connects closely to the ideas in Dynamics 365 Project Management & Accounting: What It’s Really For
https://www.fitgapfinance.com/d365-pma-what-its-really-for/)

The layers exist for a reason — but not all at once

Dynamics 365 Finance offers a rich set of building blocks:

• project groups
• projects and sub-projects
• WBS / activities
• project categories and category groups
• transaction types (hour, expense, item)
• financial dimensions

Each one solves a specific problem.
Trouble starts when they’re treated as interchangeable — or worse, when one layer is stretched to compensate for a governance decision that was never really made.

Project groups: where accounting behavior is anchored

Project groups sit closer to accounting than most people realize. They define how costs behave financially — whether they land in P&L, flow through WIP, or support capitalization.

Because of that, they’re often more stable than the rest of the structure. You typically don’t want dozens of them. You want a small set that finance understands, owns, and can defend.

Where things start to slip is when project groups are created to satisfy reporting requests or delivery preferences. That may solve a short-term need, but it makes the accounting layer harder to reason about later — especially during close or audit.

A good rule of thumb: if changing a project group would surprise finance, you probably have too many of them.

Projects and sub-projects: about responsibility, not flexibility

At their core, projects answer a simple question: who owns this?
They’re about accountability and lifecycle, not about fine-grained cost analysis.

Sub-projects add a useful degree of separation. They let you isolate scopes, responsibilities, or even accounting behavior within a larger initiative. Used intentionally, they can be very effective.

One capability that’s often overlooked is that different project types can coexist within the same structure — for example, an investment sub-project alongside a cost sub-project. That can reflect reality well, but it only works if finance is actively involved in the design.

Where sub-projects tend to cause trouble is when they’re introduced mainly to regain flexibility — to move costs around, soften overruns, or avoid uncomfortable conversations. At that point, structure stops reflecting reality and starts obscuring it.

WBS and activities: powerful for planning, fragile for accounting

Work breakdown structures are excellent planning tools. They help teams forecast, track progress, and understand where effort is being spent.

They also offer flexibility that can be very useful: budgets can live at a higher level, while actual costs are captured lower down. That separation is not a flaw — it’s a feature.

Problems arise when WBS is treated as a financial reporting structure. The deeper it goes, the more fragile the analysis becomes. Small changes ripple upward. Reporting logic gets duplicated elsewhere. Finance ends up rebuilding views outside the system.

WBS works best when it stays focused on planning and control, and leaves accounting logic to other layers.

Project categories: where accounting decisions really happen

If there’s one object that deserves more respect in Project Accounting, it’s the project category.

Project categories determine how costs and revenue post to the general ledger. They influence capitalization eligibility and are the primary driver of accounting consistency across projects.

They’re also where many designs quietly start to drift. Because categories feel abstract, they’re often overloaded — used for reporting convenience, tagging, or compensating for missing financial dimensions. Over time, this leads to duplication, inconsistent posting logic, and unnecessary complexity.

This is where project category groups play an important supporting role. A category group can contain multiple project categories, while each category belongs to a single group. Category groups are frequently referenced in posting profiles and controls, making them a useful way to organize and govern the accounting model without endlessly multiplying categories.

The distinction matters:
project categories define accounting behavior; project category groups help structure and govern that behavior.

Transaction types: the constraint that trips people up

One of the most common sources of frustration in Project Accounting comes down to a simple rule:

A project category can only be associated with one transaction type — hour, expense, or item.

That means you can’t track multiple transaction types under the same category, even if the business conceptually sees them as the “same cost.” The usual response is to duplicate categories per transaction type, which works — but comes at a price.

More categories mean more maintenance, more naming conventions, and more room for inconsistency. This isn’t a system quirk to hack around; it’s a constraint that needs to be acknowledged early and designed for deliberately.

Ignoring it doesn’t make it go away. It just pushes complexity downstream.

Budgeting and actuals don’t have to live at the same level — but the rules must be clear

Another frequent source of confusion is the relationship between budgets and actuals.

In Dynamics 365 Finance, project budgets are primarily category-driven. Actuals, on the other hand, can post at different structural levels — project, sub-project, or activity.

That mismatch is not inherently wrong. It becomes a problem only when ownership and expectations aren’t aligned. When budget responsibility and cost entry drift apart, finance ends up reconciling after the fact instead of guiding decisions upfront.

Clarity matters more than symmetry.

Financial dimensions: adding context without adding structure

Beyond posting profiles that link the project subledger to the general ledger, financial dimensions play an important supporting role.

Projects can carry default financial dimensions that flow naturally to the GL, enriching reporting without forcing additional hierarchy into the project structure. Automatic dimensions — such as Project itself — can also provide traceability with relatively little effort.

There is a practical caution here. Character limits still apply, and in multi-level structures, dimension values can quickly become unwieldy if naming conventions aren’t disciplined.

Dimensions work best when they reinforce a clean structure — not when they’re asked to compensate for one that’s already too complex.

Why structures get heavier than anyone intended

Very few teams set out to over-engineer their project structures. It usually happens gradually, driven by unresolved trade-offs.

Leadership asks for more visibility.
Project teams ask for more flexibility.
Finance adds controls to protect outcomes.

Without clear prioritization, structure absorbs the tension. Layers accumulate. Users adapt. Workarounds appear.

This dynamic is closely tied to governance and decision rights — who gets to decide what the system should optimize for, and when those decisions are revisited.
(See also: ERP Governance, Roles, and Decision Rights
https://www.fitgapfinance.com/erp-governance-model-roles-decision-rights/)

A way to think about structure that actually holds up

A simple mental model helps cut through the noise:

• Use project groups and categories to define accounting behavior
• Use projects to establish ownership
• Use sub-projects to isolate scope when needed
• Use WBS for planning and control
• Use dimensions to support reporting before adding structure

When each layer does the job it was designed for, the overall system becomes easier to govern — and easier to explain.

What more disciplined organizations do differently

Organizations that handle project accounting well don’t rely on clever configuration. They rely on restraint.

They use fewer layers.
They make trade-offs explicit.
They involve finance early.
They review structures periodically instead of letting them evolve silently.

It’s not glamorous work. But it’s what keeps project accounting from slowly drifting out of reach.

(Closely related: Data Quality and Structural Discipline in Dynamics 365
https://www.fitgapfinance.com/data-migration-in-dynamics-365-how-to-avoid-the-most-costly-mistakes/)

Final thought

Project accounting cost structures don’t fail because the system is too complex.
They fail because too many decisions are made implicitly, and then left untouched for too long.

Designing fewer layers — and being clear about why each one exists — is often the most effective improvement an organization can make.

This article is part of the FitGap Finance – Project Management & Accounting series, focused on finance-led ERP design, governance, and decision-making beyond go-live.

🇫🇷 Version française: https://www.fitgapfinance.com/structure-couts-comptabilite-projets-dynamics-365-finance/