What Breaks Project Management & Accounting in Dynamics 365 Finance Faster Than Any Configuration Error

Here’s what breaks Project Management & Accounting (PMA) in Microsoft Dynamics 365 Finance faster than any configuration mistake:

Treating projects like cost centers that never die.

When finance treats PMA projects as permanent cost centers, budgets lose their teeth, accountability dissolves, and reconciliation turns into archaeology. Worse, it quietly creates compliance exposure around capitalization that most finance leaders don’t see until audit.

This pattern is everywhere.
And it’s not a technology problem — it’s a reflex.

The Cost Center Reflex (and Why It’s Understandable)

In many organizations, PMA projects are created as:

• one project per department,
• one project mirroring an existing cost center,
• or a single “administrative” project reused indefinitely.

The original justification is usually reasonable:

• standardizing processes,
• reporting from a single, consistent source,
• avoiding structure proliferation.

From a finance perspective, this feels clean and controlled.

The issue is that projects and cost centers solve fundamentally different problems.

Projects and Cost Centers Are Not Interchangeable

A cost center is:

• permanent,
• organizational,
• designed for allocation and reporting,
• rarely closed.

A project is:

• temporary or phased,
• goal-driven,
• governed by a specific set of rules and milestones,
• expected to evolve through distinct stages with different financial treatment.

When projects are designed like cost centers, PMA stops being a lifecycle tool and becomes a secondary reporting layer — with all the overhead of project accounting and none of its benefits.

👉 Related reading:
https://www.fitgapfinance.com/ledger-vs-subledger-d365-finance/

What Actually Goes Wrong

The consequences don’t show up immediately.
They accumulate quietly — then hit hard.

1. Capitalization Becomes a Compliance Risk

When projects are treated as cost centers, you lose the ability to distinguish between capital and expense at the transaction level.

In a properly designed PMA model:

• cost projects capture expense,
• investment projects capture capital,
• project categories determine accounting treatment as transactions occur.

In the cost-center model:

• everything hits the same “department project”,
• finance reclassifies manually at month-end or quarter-end,
• auditors lose the transaction-level audit trail,
• capitalization becomes a reconciliation exercise — not a control.

Real-world example:
A manufacturing client created a single “IT Department” project in PMA. Over three years, it accumulated $52M across infrastructure upgrades, support, and an ERP implementation.
At audit, they could not separate capital from expense without reconstructing history manually.
The resulting capitalization adjustment was $9M, flagged by external auditors as a material weakness in internal controls.

This isn’t inefficiency.
It’s an audit finding waiting to happen.

2. Heavy Maintenance and Rigid Processes

“Permanent” projects require:

• constant adjustments,
• ongoing clean-up,
• manual discipline just to remain usable.

What was meant to simplify ends up increasing operational burden.
You carry historical baggage forward indefinitely, and every close requires digging through years of legacy activity.

3. Reporting That Looks Centralized but Loses Meaning

Yes, costs flow through the same projects.
But over time:

• historical data becomes polluted,
• comparisons lose relevance (is this variance real, or noise from 2022?),
• reporting stops reflecting real initiatives.

You get consistency — at the expense of insight.

👉 See also:
https://www.fitgapfinance.com/d365-finance-reporting-gaps/

4. Governance Becomes Blurred

When a project never ends, a simple question becomes uncomfortable:

Who is accountable?

• The department?
• The project manager?
• Finance?

Cost centers are owned structurally.
Projects are owned by governance design — someone is accountable for scope, budget, and outcomes within a defined timeframe.

Mixing the two weakens accountability and decision rights. Budgets become envelopes. Variance explanations become vague. Responsibility dissolves.

👉 Governance deep dives:
https://www.fitgapfinance.com/erp-governance-model-roles-decision-rights/
https://www.fitgapfinance.com/raci-template/

5. WIP and Estimates Become Fictional

In properly designed PMA:

• WIP calculations,
• estimate-at-completion logic,
• variance-to-complete tracking

drive financial reporting and learning.

When projects never close and lack defined phases:

• WIP becomes meaningless or manually overridden,
• estimates are never validated against actuals,
• feedback loops disappear.

You’re left with a system that records costs — but doesn’t manage projects.

The “Administrative Project” Trap

Some finance teams push back:

“We need long-lived projects for salary allocation, shared services, or internal charging.”

Here’s the uncomfortable truth:

If your PMA design requires administrative allocation projects, your financial dimensions structure is probably broken.

Salary allocation, shared services, and internal charging should flow through:

• allocation journals with proper dimension logic,
• intercompany or inter-department allocation rules,
• cost accounting (when driver-based allocation is required),
• overhead pools with indirect rate structures.

Projects that exist only to move money are a symptom of failed financial structure design.

There is a narrow exception: projects explicitly designed as mechanisms, with strict scope, rules, and review periods.
But once this logic is generalized, you’ve recreated the cost center problem under a different name.

When PMA Is Not the Right Tool

If the objective is only:

• standardized reporting,
• consistent cost tracking,
• cross-department visibility,

then PMA is overkill.

Financial dimensions and reporting structures achieve the same result:

• with less governance overhead,
• less maintenance,
• fewer reconciliation risks.

👉 See:
https://www.fitgapfinance.com/the-strategic-role-of-financial-dimensions-better-insight-without-a-bloated-chart-of-accounts/

Using PMA should be a deliberate design choice, not a default.

When Cost Center Logic Does Make Sense

Use cost centers and dimensions when:

• reporting is organizational and permanent,
• costs don’t require phase-based treatment,
• capitalization vs expense is not determined at transaction level,
• accountability is structural.

Use allocation mechanisms when:

• redistribution is driver-based,
• rules are repeatable and transparent,
• overhead application must be explainable.

Use PMA projects when:

• financial treatment changes by lifecycle stage,
• capitalization applies to specific activities,
• revenue recognition depends on milestones or completion,
• estimates and WIP matter,
• accountability is governance-based, not structural.

The system will let you build anything.
The real question is whether you’re solving the right problem.

A Decision Framework Before Creating Any Project

Before creating a PMA project, finance should be able to answer “yes” to most of the following:

• Does financial treatment change across stages?
• Is there a specific objective to be achieved or abandoned?
• Are there defined phases, milestones, or review points?
• Will accounting differ meaningfully from corporate defaults?
• Is ownership defined by governance, not org chart?

If most answers are “no”, what you need is better reporting — not project accounting.

The Core Principle

A project exists to achieve a specific goal within a specific timeframe — and its accounting must reflect project governance, not the org chart.

That’s the line PMA enforces.

Cross it, and PMA becomes heavy, political, and fragile.
Respect it, and PMA becomes one of the most powerful financial control tools in Dynamics 365 Finance.

What This Means for Design

PMA configuration is straightforward.
The hard part is convincing finance leaders that discipline is a feature, not overhead.

This sets up what comes next:

• why project types are accounting decisions,
• how capitalization logic exposes weak design,
• why some PMA budgets create the illusion of control.

Related resources

• https://www.fitgapfinance.com/ledger-vs-subledger-d365-finance/
• https://www.fitgapfinance.com/d365-finance-reporting-gaps/
• https://www.fitgapfinance.com/erp-governance-model-roles-decision-rights/
• https://www.fitgapfinance.com/raci-template/
• https://www.fitgapfinance.com/d365-finance-month-end-close-tips/
• https://www.fitgapfinance.com/the-strategic-role-of-financial-dimensions-better-insight-without-a-bloated-chart-of-accounts/

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

🇫🇷 Version française: https://www.fitgapfinance.com/pourquoi-projets-centres-couts-cassent-pma-dynamics-365/