Dynamics 365 Project Management and Accounting: What It Is Actually For
TL;DR
The Project management and accounting (PMA) module in Dynamics 365 Finance is a project accounting engine, not a project management tool.
Most problems attributed to PMA are design and governance failures — not product limitations.
Why This Module Is So Often Misunderstood
The Project management and accounting (PMA) module in Microsoft Dynamics 365 Finance is one of the least well-documented areas from a business and governance perspective.
Microsoft documentation explains:
- Features
- Configuration options
- Functional capabilities
What it rarely explains is:
- When PMA should be used
- What business problem it actually solves
- What it should not be expected to do
After being involved in multiple mid-to-large Dynamics 365 Finance implementations across multiple sectors, one pattern repeats consistently:
Organizations approach PMA with a project management mindset and discover — often too late — that it enforces accounting logic instead.
This article resets that mental model.
PMA Is Not an Extension of the General Ledger
A common misunderstanding among business stakeholders is the belief that PMA is simply:
“A more detailed version of the general ledger.”
That assumption is wrong — and costly.
The general ledger exists to answer corporate questions:
- What was spent?
- Where does it hit the P&L or balance sheet?
- How does it roll up to financial statements?
PMA exists to answer project-specific financial questions:
- How do costs accumulate over a project’s lifecycle?
- Which costs are billable, capitalizable, or expensable — and under what rules?
- When do costs transition from operational tracking to financial reality?
- How do approvals, budgets, and controls differ from corporate finance?
PMA introduces project subledger accounting that posts to the general ledger based on explicit project accounting rules.
👉 Read more:
- https://www.fitgapfinance.com/ledger-vs-subledger-d365-finance/
- https://www.fitgapfinance.com/d365-finance-month-end-close-tips/
Treating PMA as a GL extension usually leads to:
- Late design decisions
- Weak governance
- Reconciliation issues that surface months after go-live
Why Organizations Say They Want PMA — And Why They Actually Need It
The stated reasons for implementing PMA are usually reasonable:
- Project cost visibility
- Billing (external or intercompany)
- Budget monitoring
The real reason is more fundamental:
Organizations want to manage projects end-to-end from a financial and accounting perspective, not just report costs after the fact.
PMA enables:
- Project-specific budgets and approvals
- Project subledger accounting governed by project rules (then posted to the GL)
- Lifecycle logic (start, execution, completion, settlement)
- Optional capitalization and billing flows
This is not reporting.
This is financial design applied at project level.
The Most Damaging Misuse: PMA as a Project Management Tool
PMA is frequently forced into roles it was never designed for:
- Milestone tracking
- Deliverable management
- Dependency and execution monitoring
This is where the most damage occurs.
PMA is very strong at project accounting:
- Cost control
- Cost classification
- Billing accuracy
- Capitalization logic
It is not a best-in-class project execution tool.
Yes, PMA includes planning constructs (WBS, activities, timesheets).
But these exist primarily to support financial control and postings, not to replace a full project management tool.
When organizations try to use PMA as a replacement for true project management tools, the result is usually:
- Over-engineered project structures
- Misuse of categories and activities
- Frustrated project managers
- Poor visibility on real progress
The irony is that this misuse often degrades both project execution and accounting clarity.
Governance Reality: PMA Reveals What Organizations Avoid Deciding
PMA does not create governance problems.
It exposes unresolved ones.
In most implementations:
- Finance owns PMA design decisions
- PMOs are partially involved
- IT executes configuration
The most common breakdown appears around approvals:
- Who approves purchase requisitions and purchase orders?
- Line manager?
- Project manager?
- Corporate finance?
If this is not explicitly defined, PMA becomes the arena where corporate control and project autonomy collide.
👉 Deep dives you may find useful:
- https://www.fitgapfinance.com/erp-governance-model-roles-decision-rights/
- https://www.fitgapfinance.com/raci-template/
Another recurring tension is project structure:
- Controllers want stability and reconciliation discipline
- Project managers want flexibility and operational alignment
PMA forces these conversations. Avoiding them guarantees friction later.
👉 Related reading:
Capitalization: Where PMA Quietly Becomes High-Risk
PMA is often selected specifically to support:
- R&D capitalization
- Capex projects flowing into fixed assets
The most dangerous assumption teams make is simple:
“We’ll define capitalization rules later.”
Capitalization logic directly impacts:
- Project structure
- Posting profiles
- Cost categories
- Integration with fixed assets
When these rules are unclear or incomplete, the consequences are predictable:
- Erroneous opening balances
- Weak reconciliation trails
- Manual corrections that do not scale
Even without immediate auditor pushback, these weaknesses tend to surface during financial reviews, close cycles, or internal audits.
👉 Related article:
When PMA Should — and Should Not — Be Used
PMA is not always the right tool.
If the objective is simply:
- More granular cost tracking
- Enhanced reporting
Then simpler mechanisms are often better:
- Financial dimensions
- Tags or attributes
- Reporting structures
👉 See:
PMA is the right tool when:
- The organization manages many projects with clear start and end dates
- Projects require dedicated budgets and approvals
- Project-level accounting differs from corporate accounting
- Billing (especially cost-based) is required
- Capitalization or intercompany charging is involved
Using PMA everywhere “just in case” is a design shortcut.
The One Design Decision Teams Always Regret Delaying
There is one decision that teams routinely postpone because it does not appear on financial statements:
Introducing a project dimension.
Even when not required for statutory reporting, it dramatically improves:
- Reconciliation
- Cross-module analysis
- Troubleshooting during close
Teams that skip it usually compensate later with manual analysis and opaque reporting.
The Mental Model That Changes Everything
After seeing PMA implemented well — and poorly — one conclusion stands out:
PMA is a project accounting tool, not a project management tool.
The worst implementations share a single root cause:
Unclear accountability between project managers, controllers, and corporate finance.
If every Dynamics 365 Finance project answered one question upfront, it should be this:
What do we consider a “project” in our organization — and how should PMA help us achieve our business goals?
Until that is clearly answered, configuration choices are guesses.
Who This Article Is For
This article is primarily for:
- Finance directors
- Controllers
- ERP sponsors
It should also resonate with:
- Senior consultants
- Project managers transitioning into ERP environments
If PMA feels heavier than expected, more political than planned, or harder to reconcile than promised — it is rarely a tool problem.
It is a design and governance problem.
What Comes Next in This Series
Next articles will cover:
- Why treating projects like cost centers breaks PMA
- Project types as accounting decisions
- Capitalization design mistakes
- Budgeting illusions vs real control
- When not to use PMA
This article is part of the FitGap Finance series — a business-first perspective on ERP governance, decision-making, and control beyond go-live.
🇫🇷 Version française: https://www.fitgapfinance.com/d365-pma-a-quoi-ca-sert-vraiment/
