📋
D365 Project Operations
End-to-end professional services management — project sales, resource management, time and expenses, billing, and revenue recognition.
WBSResource ManagementT&M BillingRevenue RecognitionSubcontractingProject Forecasting75 Questions
Questions 1–10 of 75
D365 Project Operations is Microsoft's end-to-end professional services solution — connecting project sales, resource management, project delivery, and project financials in one platform.
Target users: Professional services firms (consulting, IT services, engineering), project-based businesses (construction, architecture), and internal PMOs.
Core capabilities: Project Sales (opportunity to contract), Project planning and scheduling (WBS), Resource management (capacity planning and allocation), Time and expense tracking, Project billing (T&M, Fixed Price, Retainer), Revenue recognition, Project analytics.
Deployment models: Lite (project scheduling and tracking only), Resource/Non-stocked (professional services with T&M billing), Stocked/Production order (project with inventory/materials).
Target users: Professional services firms (consulting, IT services, engineering), project-based businesses (construction, architecture), and internal PMOs.
Core capabilities: Project Sales (opportunity to contract), Project planning and scheduling (WBS), Resource management (capacity planning and allocation), Time and expense tracking, Project billing (T&M, Fixed Price, Retainer), Revenue recognition, Project analytics.
Deployment models: Lite (project scheduling and tracking only), Resource/Non-stocked (professional services with T&M billing), Stocked/Production order (project with inventory/materials).
💡 Pro Tip: Always establish the deployment model in the first requirements meeting — it determines the licence type and available features. Stocked/production-order clients need D365 Finance + Project Operations. Lite clients only need the core Project Operations licence.
The project lifecycle spans from opportunity to revenue recognition:
1. Opportunity (D365 Sales): Potential project identified. Project estimate attached to opportunity.
2. Project Quote: Detailed proposal created. Quote lines map to project tasks. Pricing: T&M, Fixed Price, or Retainer.
3. Project Contract: Quote accepted → Contract created. Project created and linked to contract.
4. Project Planning: Work Breakdown Structure (WBS) created. Tasks, dependencies, durations, and resources defined.
5. Resource Fulfilment: Named resources booked. Resource manager approves. Capacity checked.
6. Project Execution: Team members log time and expenses against project tasks. Approvals flow to project manager.
7. Billing: Invoice milestones triggered (fixed price) or time/expense entries billed (T&M).
8. Revenue Recognition: Revenue recognised per accounting rules (percentage completion, milestone).
1. Opportunity (D365 Sales): Potential project identified. Project estimate attached to opportunity.
2. Project Quote: Detailed proposal created. Quote lines map to project tasks. Pricing: T&M, Fixed Price, or Retainer.
3. Project Contract: Quote accepted → Contract created. Project created and linked to contract.
4. Project Planning: Work Breakdown Structure (WBS) created. Tasks, dependencies, durations, and resources defined.
5. Resource Fulfilment: Named resources booked. Resource manager approves. Capacity checked.
6. Project Execution: Team members log time and expenses against project tasks. Approvals flow to project manager.
7. Billing: Invoice milestones triggered (fixed price) or time/expense entries billed (T&M).
8. Revenue Recognition: Revenue recognised per accounting rules (percentage completion, milestone).
💡 Pro Tip: Drawing this lifecycle as a flow diagram during an interview — Opportunity → Quote → Contract → Project → Time Entry → Invoice — demonstrates deep platform understanding and shows you think in business process terms, not just features.
A Work Breakdown Structure (WBS) is the hierarchical decomposition of a project into tasks and deliverables — the blueprint of project work in D365 Project Operations.
WBS features: Task hierarchy (phases → deliverables → tasks → sub-tasks), task dependencies (Finish-to-Start, Start-to-Start), estimated effort and duration, assigned resources and roles, auto-scheduling based on dependencies and calendar.
WBS and costing: When a resource is assigned to a task, D365 calculates the estimated cost based on the resource's cost rate and hours. This drives the project cost estimate used in quotes and financial forecasting.
Project templates: Pre-built WBS structures for common project types (ERP Implementation Template, Digital Marketing Campaign Template). Creating a project from a template auto-populates the WBS.
WBS features: Task hierarchy (phases → deliverables → tasks → sub-tasks), task dependencies (Finish-to-Start, Start-to-Start), estimated effort and duration, assigned resources and roles, auto-scheduling based on dependencies and calendar.
WBS and costing: When a resource is assigned to a task, D365 calculates the estimated cost based on the resource's cost rate and hours. This drives the project cost estimate used in quotes and financial forecasting.
Project templates: Pre-built WBS structures for common project types (ERP Implementation Template, Digital Marketing Campaign Template). Creating a project from a template auto-populates the WBS.
💡 Pro Tip: Template management is one of the highest-ROI configuration items in Project Operations. A well-built project template means PMs create a fully costed, scheduled project in 15 minutes instead of 3 days. Proactively recommend templates in every Project Operations engagement.
Resource Management handles the allocation of the right people to the right projects — balancing demand (project requirements) with supply (resource availability).
Resource types: Named resource (a specific person). Generic resource (a role placeholder, e.g., "Senior Developer" — used during planning before specific people are identified). Account resource (an external resource/subcontractor).
Resource request flow: PM creates project with generic resource requirements (role, skills, hours, dates) → Resource requirement auto-created → Resource Manager sees requirement in Schedule Board → Resource Manager proposes a specific named resource → PM accepts or rejects the proposal → Named resource replaces generic placeholder.
Schedule Board: Visual Gantt-style view showing all resources, their current bookings, and available capacity. Resource Manager manages demand vs supply from this view.
Resource types: Named resource (a specific person). Generic resource (a role placeholder, e.g., "Senior Developer" — used during planning before specific people are identified). Account resource (an external resource/subcontractor).
Resource request flow: PM creates project with generic resource requirements (role, skills, hours, dates) → Resource requirement auto-created → Resource Manager sees requirement in Schedule Board → Resource Manager proposes a specific named resource → PM accepts or rejects the proposal → Named resource replaces generic placeholder.
Schedule Board: Visual Gantt-style view showing all resources, their current bookings, and available capacity. Resource Manager manages demand vs supply from this view.
💡 Pro Tip: The distinction between Soft Booking (tentative) and Hard Booking (confirmed) is frequently tested. Soft booking reserves capacity tentatively — used when a project is not yet sold. Hard booking commits the resource. This prevents over-committing resources to unconfirmed work.
Time and Expense entries are the operational record of project work performed — they drive project progress tracking, billing, and payroll.
Time Entry (Weekly timesheet): Team members submit weekly timesheets. Each row: Project, Task, Role, Hours per day, Comment. Submitted for approval at end of week.
Time approval workflow: Team member submits → Project Manager reviews → Approve or Reject with comments. If approved: Time entry converted to Actuals (cost actual + billable actual if T&M).
Expense entry: Category (travel, accommodation), Amount, Currency, Receipt upload, Project and Task allocation. Submitted for PM approval then Finance for reimbursement.
Mobile app: Time and expense capture available on the D365 mobile app — critical for field-based project teams.
Time Entry (Weekly timesheet): Team members submit weekly timesheets. Each row: Project, Task, Role, Hours per day, Comment. Submitted for approval at end of week.
Time approval workflow: Team member submits → Project Manager reviews → Approve or Reject with comments. If approved: Time entry converted to Actuals (cost actual + billable actual if T&M).
Expense entry: Category (travel, accommodation), Amount, Currency, Receipt upload, Project and Task allocation. Submitted for PM approval then Finance for reimbursement.
Mobile app: Time and expense capture available on the D365 mobile app — critical for field-based project teams.
⚠ Key Point: Time entry accuracy directly impacts billing accuracy. A common issue: team members submit time late, causing invoice delays. Requirements should define the time submission deadline (every Friday by 5pm) and the late submission escalation process.
Project Billing generates invoices for work delivered under a project contract — one of the most important financial functions in Project Operations.
Contract line types:
Time and Materials (T&M): Invoice all approved time and expenses at agreed rates. Billing frequency: weekly, monthly, or on-demand.
Fixed Price: Invoice at agreed milestones regardless of actual effort. Milestone date or completion trigger billing.
Retainer: Regular periodic invoice for ongoing availability (e.g., monthly support retainer).
Billing process (T&M): Time and expenses approved by PM → Billing manager runs "Invoice for Review" → Review journal (check billable transactions, adjust if needed) → Confirm invoice → Draft invoice created in D365 Finance → Invoice sent to customer.
Not-to-exceed (NTE) limits: T&M contracts can have billing caps. System warns or blocks when the NTE limit is approached.
Contract line types:
Time and Materials (T&M): Invoice all approved time and expenses at agreed rates. Billing frequency: weekly, monthly, or on-demand.
Fixed Price: Invoice at agreed milestones regardless of actual effort. Milestone date or completion trigger billing.
Retainer: Regular periodic invoice for ongoing availability (e.g., monthly support retainer).
Billing process (T&M): Time and expenses approved by PM → Billing manager runs "Invoice for Review" → Review journal (check billable transactions, adjust if needed) → Confirm invoice → Draft invoice created in D365 Finance → Invoice sent to customer.
Not-to-exceed (NTE) limits: T&M contracts can have billing caps. System warns or blocks when the NTE limit is approached.
💡 Pro Tip: Invoice review before posting is critical. Billing managers must catch: time entered against wrong task, expenses without receipts, and billable entries that should be non-billable. The "Invoice for Review" journal must be a defined process in the client's billing SOP.
Revenue Recognition ensures project revenue is recognised in financial statements according to accounting standards (IFRS 15 or ASC 606).
Revenue recognition methods: Completion percentage (% complete): Revenue = Contract Value x % Project Complete. Completed contract: Revenue recognised only on project completion. Cost-to-cost: % complete = Actual Cost / Total Estimated Cost. Effort-to-complete: % complete = Hours Worked / Total Estimated Hours.
D365 Project Operations process: Project runs in execution → Time and expenses posted as actuals → PM updates completion % → Revenue recognition (WIP) batch runs monthly at period close → Revenue estimate created → Accounting team reviews and posts to General Ledger in D365 Finance.
WIP (Work In Progress): Cost incurred before billing/recognition. WIP tracks unbilled cost. When billing occurs, WIP is cleared.
Revenue recognition methods: Completion percentage (% complete): Revenue = Contract Value x % Project Complete. Completed contract: Revenue recognised only on project completion. Cost-to-cost: % complete = Actual Cost / Total Estimated Cost. Effort-to-complete: % complete = Hours Worked / Total Estimated Hours.
D365 Project Operations process: Project runs in execution → Time and expenses posted as actuals → PM updates completion % → Revenue recognition (WIP) batch runs monthly at period close → Revenue estimate created → Accounting team reviews and posts to General Ledger in D365 Finance.
WIP (Work In Progress): Cost incurred before billing/recognition. WIP tracks unbilled cost. When billing occurs, WIP is cleared.
⚠ Key Point: Revenue recognition is an accounting function requiring close collaboration with the client's finance team and external auditors. Never design the revenue recognition setup without the client's CFO and auditor involvement.
Resource Reconciliation identifies gaps between resource hours booked (bookings) and resource hours assigned to tasks (assignments) — and resolves them.
Why reconciliation is needed: A resource can be booked for 40 hours on a project but only assigned to tasks for 30 hours (10 hours are floating — booked but unassigned). Conversely, a resource might be assigned more task hours than they are booked for.
Reconciliation view: The Reconciliation tab on the Project entity shows for each resource: Booked hours vs. Assigned hours per period. Green = balanced, Red = gap exists.
Resolving gaps: Extend bookings (if assignments > bookings, PM can request more hours from resource manager). Release unneeded bookings (if bookings > assignments, release excess capacity back to the resource pool).
Why reconciliation is needed: A resource can be booked for 40 hours on a project but only assigned to tasks for 30 hours (10 hours are floating — booked but unassigned). Conversely, a resource might be assigned more task hours than they are booked for.
Reconciliation view: The Reconciliation tab on the Project entity shows for each resource: Booked hours vs. Assigned hours per period. Green = balanced, Red = gap exists.
Resolving gaps: Extend bookings (if assignments > bookings, PM can request more hours from resource manager). Release unneeded bookings (if bookings > assignments, release excess capacity back to the resource pool).
💡 Pro Tip: Resource Reconciliation is one of the most distinctive features of D365 Project Operations — it does not exist in most project management tools. Knowing how to use it and when it is needed demonstrates deep product knowledge that separates experienced consultants from beginners.
Roles define the job function/category of a resource (Senior Consultant, Project Manager, Developer, Business Analyst). Roles are used in resource requirements, WBS task assignments, and price list rate entries.
Price Lists: Cost price list (rate to cost a role per hour — internal cost). Sales price list (rate to bill a role per hour to the client). Purchase price list (rate for subcontractor services).
Example: Project Manager, India OU: Cost rate ₹8,000/day, Bill rate ₹25,000/day. Senior Consultant, UK OU: Cost rate £400/day, Bill rate £1,200/day.
Currency and exchange rates: Contracts can be in any currency. If project team is in INR and client is billed in USD, D365 handles currency conversion using configured exchange rates.
Price Lists: Cost price list (rate to cost a role per hour — internal cost). Sales price list (rate to bill a role per hour to the client). Purchase price list (rate for subcontractor services).
Example: Project Manager, India OU: Cost rate ₹8,000/day, Bill rate ₹25,000/day. Senior Consultant, UK OU: Cost rate £400/day, Bill rate £1,200/day.
Currency and exchange rates: Contracts can be in any currency. If project team is in INR and client is billed in USD, D365 handles currency conversion using configured exchange rates.
💡 Pro Tip: Always workshop pricing dimensions early — they affect every financial calculation in the system. If a client bills different rates for the same role in different geographies, you need a custom pricing dimension. Missing this creates incorrect quote values and billing rates.
D365 Project Operations and D365 Finance are often deployed together — Project Operations handles project execution while Finance handles accounting.
Key integration points: Project contracts and price lists → Finance project contracts and billing rules. Time and expense actuals → Finance project transactions (cost journals). Invoice proposals → Finance customer invoices. Revenue recognition journals → Finance GL postings. Purchase orders for project materials → Finance AP.
Dual-write (real-time sync): Dual-write technology synchronises select entities between Dataverse (Project Operations) and D365 Finance in real time — eliminating batch delays.
Project accounting setup in Finance: Project groups, posting profiles, cost categories, revenue categories, project expense and revenue accounts in the Chart of Accounts.
Key integration points: Project contracts and price lists → Finance project contracts and billing rules. Time and expense actuals → Finance project transactions (cost journals). Invoice proposals → Finance customer invoices. Revenue recognition journals → Finance GL postings. Purchase orders for project materials → Finance AP.
Dual-write (real-time sync): Dual-write technology synchronises select entities between Dataverse (Project Operations) and D365 Finance in real time — eliminating batch delays.
Project accounting setup in Finance: Project groups, posting profiles, cost categories, revenue categories, project expense and revenue accounts in the Chart of Accounts.
⚠ Key Point: The Project Operations + Finance integration is the most technically complex part of most implementations. Always involve a D365 Finance consultant alongside the Project Operations consultant. Requirements that look simple in Project Operations may have complex Finance implications.
Questions 11–20 of 75
Subcontracting in D365 Project Operations manages the engagement of external resources (third-party vendors/contractors) on a project — with procurement, time tracking, and cost management.
Subcontracting flow: Generic resource requirement identified that cannot be filled internally → Subcontract created (vendor, SOW, rates, period) → Subcontract lines define services → Vendor resource assigned to project → Vendor submits time entries → Time approved → Vendor invoice matched to subcontract PO → Cost actuals posted to project.
Subcontractor margin tracking: If a consultant is subcontracted at $80/hour but billed to the client at $150/hour, D365 tracks the $70 margin per resource on the project. Critical for project profitability reporting.
Subcontracting flow: Generic resource requirement identified that cannot be filled internally → Subcontract created (vendor, SOW, rates, period) → Subcontract lines define services → Vendor resource assigned to project → Vendor submits time entries → Time approved → Vendor invoice matched to subcontract PO → Cost actuals posted to project.
Subcontractor margin tracking: If a consultant is subcontracted at $80/hour but billed to the client at $150/hour, D365 tracks the $70 margin per resource on the project. Critical for project profitability reporting.
💡 Pro Tip: Subcontracting requirements are often missed in the initial scoping. Always ask: "Do you use external contractors on projects? How do you currently track their time and costs?" The answer determines whether subcontracting features are in scope.
A Project Contract is the financial agreement between the client and the service provider — defining scope, billing arrangement, and financial terms.
Project Contract components: Contracting unit, Funding source (customer or internal department paying), Currency, Payment terms, Bill-to contact and address, Contract lines defining scope and billing type.
Contract Lines: Each line represents a billing arrangement for a portion of the project. Description, Transaction class (Time, Expense, Item, Fee), Billing method (T&M or Fixed Price), Budget amount.
Multiple contract lines example: Line 1: Implementation services — Fixed Price $500K. Line 2: Travel and expenses — T&M (actuals). Line 3: Post-go-live support — Monthly Retainer $10K.
Project Contract components: Contracting unit, Funding source (customer or internal department paying), Currency, Payment terms, Bill-to contact and address, Contract lines defining scope and billing type.
Contract Lines: Each line represents a billing arrangement for a portion of the project. Description, Transaction class (Time, Expense, Item, Fee), Billing method (T&M or Fixed Price), Budget amount.
Multiple contract lines example: Line 1: Implementation services — Fixed Price $500K. Line 2: Travel and expenses — T&M (actuals). Line 3: Post-go-live support — Monthly Retainer $10K.
💡 Pro Tip: The contract line design is where implementation consultants add significant value — ensuring the billing structure in D365 exactly matches the client's contractual terms with their customers. Mismatches here create invoice disputes. Get it right in requirements.
D365 Project Operations has three deployment scenarios matching different business needs:
IT consulting firm billing T&M? → Resource/Non-stocked. Construction company with materials? → Stocked/Production. Internal IT tracking projects? → Lite.
| Aspect | Lite | Resource/Non-stocked | Stocked/Production |
|---|---|---|---|
| Target | Internal PMO, basic tracking | Professional services (T&M/Fixed) | Project with materials/inventory |
| Finance integration | No | Yes (full) | Yes (full + inventory) |
| Billing | Basic | T&M + Fixed + Retainer | Full + materials |
| Revenue recognition | No | Yes (IFRS 15) | Yes |
💡 Pro Tip: Getting the deployment scenario right at the start of an engagement is critical — it determines the licence cost, integration requirements, and implementation complexity. The scenario cannot easily be changed later without significant rework.
Project Estimates provide a view of expected cost, revenue, and margins across the project lifecycle — updated as the project progresses.
Estimate components: Remaining cost (estimated cost to complete remaining work). Actual cost (cost incurred to date). Total cost (Actual + Remaining). Revenue budget (contracted revenue). Recognised revenue (earned to date). Estimated margin.
Estimate at Completion (EAC): EAC = Actual Cost + Estimated Cost to Complete. This is the real-time projected final cost. Compared against the original budget to show cost variance.
Earned Value Management (EVM): D365 Project Operations supports EVM metrics: Schedule Performance Index (SPI), Cost Performance Index (CPI), Schedule Variance (SV), Cost Variance (CV).
Estimate components: Remaining cost (estimated cost to complete remaining work). Actual cost (cost incurred to date). Total cost (Actual + Remaining). Revenue budget (contracted revenue). Recognised revenue (earned to date). Estimated margin.
Estimate at Completion (EAC): EAC = Actual Cost + Estimated Cost to Complete. This is the real-time projected final cost. Compared against the original budget to show cost variance.
Earned Value Management (EVM): D365 Project Operations supports EVM metrics: Schedule Performance Index (SPI), Cost Performance Index (CPI), Schedule Variance (SV), Cost Variance (CV).
💡 Pro Tip: Project financial health reporting is the #1 requirement in most Project Operations implementations. Define the "project health dashboard" requirements first — then work backward to ensure the data model supports them.
Approval workflows control who must review and approve time entries, expense reports, and other project transactions before they create financial actuals.
Standard approval flow: Team member submits timesheet → Project Manager receives approval request → Reviews entries (checks correct project, task, billable classification) → Approves or returns with comments → If approved: financial actuals created.
Approval set: Multiple time entries grouped and approved together as a batch. PM can approve or reject an entire week in one click.
Multi-level approval: Some organisations require both PM approval and Finance approval for expenses above a threshold. Power Automate can implement this.
Recall: Submitted but unapproved entries can be recalled by the submitter for correction.
Standard approval flow: Team member submits timesheet → Project Manager receives approval request → Reviews entries (checks correct project, task, billable classification) → Approves or returns with comments → If approved: financial actuals created.
Approval set: Multiple time entries grouped and approved together as a batch. PM can approve or reject an entire week in one click.
Multi-level approval: Some organisations require both PM approval and Finance approval for expenses above a threshold. Power Automate can implement this.
Recall: Submitted but unapproved entries can be recalled by the submitter for correction.
💡 Pro Tip: Approval timeline requirements directly impact billing cycle length. If time is submitted Friday, approved Monday, and invoiced Tuesday — that is your fastest possible billing cycle. Requirements must explicitly state the acceptable billing lag.
Project analytics provides visibility into project health, resource utilisation, and financial performance:
Built-in dashboards: My projects view (PM) — all active projects with health indicators, schedule variance, cost variance. Resource utilisation — hours booked vs. available per resource per week. Project financial summary — budget vs actual vs EAC per project.
Power BI integration: D365 Project Operations ships with Power BI template apps: Project Manager Report (task and resource view), Finance Manager Report (revenue, cost, WIP), Resource Manager Report (utilisation, demand vs supply).
Key metrics to define in requirements: Resource utilisation % = Billable hours / Available hours (target: 75-80% for consultant firms). Project gross margin %. Revenue leakage = Billable time not invoiced.
Built-in dashboards: My projects view (PM) — all active projects with health indicators, schedule variance, cost variance. Resource utilisation — hours booked vs. available per resource per week. Project financial summary — budget vs actual vs EAC per project.
Power BI integration: D365 Project Operations ships with Power BI template apps: Project Manager Report (task and resource view), Finance Manager Report (revenue, cost, WIP), Resource Manager Report (utilisation, demand vs supply).
Key metrics to define in requirements: Resource utilisation % = Billable hours / Available hours (target: 75-80% for consultant firms). Project gross margin %. Revenue leakage = Billable time not invoiced.
💡 Pro Tip: Revenue leakage (billable time approved but never invoiced) is the most business-critical metric for professional services firms. Ask: "Do you know today if any billable time has not been invoiced this month?" to quantify the pain point and justify the investment.
| Aspect | Microsoft Project (MSP) | D365 Project Operations |
|---|---|---|
| Purpose | Project scheduling and tracking | End-to-end project business management |
| Billing | None | Full T&M, Fixed Price, Retainer |
| Financial integration | None | Full D365 Finance integration |
| Revenue recognition | None | IFRS 15 / ASC 606 compliant |
| CRM integration | None | Native D365 Sales integration |
| Target | Project managers | Professional services organisations |
💡 Pro Tip: When clients ask "can't we just use Microsoft Project?", the answer is: MSP is a scheduling tool; Project Operations is a business management platform. If the client needs billing, resource management, and financial reporting on projects — Project Operations is the answer.
Project Parameters is the central configuration entity controlling system-wide behaviour — touching everything from scheduling to billing.
Key parameters to configure: Scheduling engine (Project for the Web — recommended). Work hours template (default working hours). Time entry mode (weekly grid or daily entry). Approval workflow (who approves time and expenses). Invoice frequency (default billing cycle). Resource availability type (hard booking required, or soft booking allowed). Billing cut-off date (date after which transactions are included in the next invoice run). Intercompany (allow resource sharing across legal entities).
Organisation unit: Represents internal divisions of the consulting organisation. Each resource belongs to an organisation unit. Cost rates are set per organisation unit.
Key parameters to configure: Scheduling engine (Project for the Web — recommended). Work hours template (default working hours). Time entry mode (weekly grid or daily entry). Approval workflow (who approves time and expenses). Invoice frequency (default billing cycle). Resource availability type (hard booking required, or soft booking allowed). Billing cut-off date (date after which transactions are included in the next invoice run). Intercompany (allow resource sharing across legal entities).
Organisation unit: Represents internal divisions of the consulting organisation. Each resource belongs to an organisation unit. Cost rates are set per organisation unit.
💡 Pro Tip: Getting Project Parameters right at the start avoids painful rework later. Hold a dedicated "Parameters Workshop" early in the project where all parameter decisions are documented and signed off BEFORE any configuration begins.
Organisation units in D365 Project Operations represent the internal divisions of the professional services organisation — each with its own cost rates and billing rates.
Organisation unit use cases: Regional practices (India OU, UK OU, US OU) with different cost rates reflecting local salary levels. Service lines (Management Consulting OU, Technology OU, Analytics OU) with different billing rates. The organisation unit assigned to a resource determines their cost rate on projects.
Transfer pricing: When a resource from one organisation unit works on a project owned by a different organisation unit, transfer pricing rules define the internal charge between OUs.
Project contracts linked to OUs: The contracting unit on a Project Contract determines which organisation unit is responsible for delivery and which cost rates and billing rates apply.
Organisation unit use cases: Regional practices (India OU, UK OU, US OU) with different cost rates reflecting local salary levels. Service lines (Management Consulting OU, Technology OU, Analytics OU) with different billing rates. The organisation unit assigned to a resource determines their cost rate on projects.
Transfer pricing: When a resource from one organisation unit works on a project owned by a different organisation unit, transfer pricing rules define the internal charge between OUs.
Project contracts linked to OUs: The contracting unit on a Project Contract determines which organisation unit is responsible for delivery and which cost rates and billing rates apply.
💡 Pro Tip: Organisation unit design directly affects every financial calculation. Ask clients early: "Do different parts of your business have different billing rates for the same role?" The answer determines whether you need multiple OUs or a single OU with pricing dimension overrides.
A structured set of discovery questions for scoping a Project Operations implementation:
Business model: What types of projects do you run — T&M, Fixed Price, Retainer, Mixed? Do you use subcontractors? Do you have multiple legal entities? Inter-company billing needed?
Resource management: How many resources do you manage? Do you have a Resource Manager role? How do you handle resource requests and allocations today?
Time and expenses: Do all team members submit timesheets? What is the submission frequency? Are all project hours billable or is there a non-billable split?
Billing: What billing methods do you use? How frequently do you invoice? Do you have complex billing rules (% complete, milestone, T&M caps)?
Finance and accounting: What ERP/accounting system are you on today? Do you need revenue recognition? What are the financial reporting requirements?
Business model: What types of projects do you run — T&M, Fixed Price, Retainer, Mixed? Do you use subcontractors? Do you have multiple legal entities? Inter-company billing needed?
Resource management: How many resources do you manage? Do you have a Resource Manager role? How do you handle resource requests and allocations today?
Time and expenses: Do all team members submit timesheets? What is the submission frequency? Are all project hours billable or is there a non-billable split?
Billing: What billing methods do you use? How frequently do you invoice? Do you have complex billing rules (% complete, milestone, T&M caps)?
Finance and accounting: What ERP/accounting system are you on today? Do you need revenue recognition? What are the financial reporting requirements?
💡 Pro Tip: Always ask "What is the single biggest problem you are trying to solve?" at the start of the scoping. The answer reveals the highest-priority requirement and helps you design the implementation phasing — fix the most painful problem first.
Questions 21–30 of 75
A Project Template in D365 Project Operations is a pre-built Work Breakdown Structure (WBS) with predefined tasks, durations, dependencies, and role assignments — allowing project managers to create a fully structured project in minutes rather than days.
What a project template contains: Task hierarchy (phases, deliverables, tasks), Task durations (effort hours), Task dependencies (Finish-to-Start, Start-to-Start), Generic resource assignments (roles, not named people), Estimated cost and revenue (if price lists are attached to the template).
Creating a template: Open a completed project → Save as Template. Or: Project Operations → Settings → Project Templates → New (build from scratch).
Using a template: When creating a new project, select "Copy from Template." All tasks, durations, and role assignments are pre-populated. The PM then adjusts dates, assigns named resources, and customises scope as needed.
Template governance: Templates should be owned by the PMO (Project Management Office) and reviewed quarterly. Common template types: ERP Implementation, D365 CRM Deployment, Digital Marketing Campaign, Infrastructure Migration.
What a project template contains: Task hierarchy (phases, deliverables, tasks), Task durations (effort hours), Task dependencies (Finish-to-Start, Start-to-Start), Generic resource assignments (roles, not named people), Estimated cost and revenue (if price lists are attached to the template).
Creating a template: Open a completed project → Save as Template. Or: Project Operations → Settings → Project Templates → New (build from scratch).
Using a template: When creating a new project, select "Copy from Template." All tasks, durations, and role assignments are pre-populated. The PM then adjusts dates, assigns named resources, and customises scope as needed.
Template governance: Templates should be owned by the PMO (Project Management Office) and reviewed quarterly. Common template types: ERP Implementation, D365 CRM Deployment, Digital Marketing Campaign, Infrastructure Migration.
💡 Pro Tip: Project templates are the highest-ROI configuration item in Project Operations. A well-built ERP implementation template with 80 tasks, role assignments, and effort estimates means a PM creates a fully costed, £500K project plan in 15 minutes. Include template design as a dedicated workshop in your implementation project plan — it typically takes 2-3 days but saves months across all future projects.
The Schedule Board in D365 Project Operations is the visual resource management interface — a Gantt-style board showing all resources, their current bookings, and available capacity across the organisation.
Schedule Board views: Horizontal (timeline view): Resources as rows, time as columns. Shows booked hours per resource per day/week. Color-coded: Green = available, Red = over-capacity, Yellow = partially booked. Vertical view: Time slots as rows, resources as columns. Map view: Shows resource locations geographically (relevant for field service).
Who uses the Schedule Board: Resource Managers: Review open resource requirements from projects. Drag and drop a resource to a requirement slot to create a booking. Project Managers: View their project's resource allocations alongside other projects to spot conflicts.
Booking from the Schedule Board: Resource requirement appears as an unfilled bar. Resource Manager selects an available resource and drags to fulfill the requirement. Booking type: Hard booking (confirmed commitment) or Soft booking (tentative reservation). Resource receives a notification of the new booking.
Schedule Board views: Horizontal (timeline view): Resources as rows, time as columns. Shows booked hours per resource per day/week. Color-coded: Green = available, Red = over-capacity, Yellow = partially booked. Vertical view: Time slots as rows, resources as columns. Map view: Shows resource locations geographically (relevant for field service).
Who uses the Schedule Board: Resource Managers: Review open resource requirements from projects. Drag and drop a resource to a requirement slot to create a booking. Project Managers: View their project's resource allocations alongside other projects to spot conflicts.
Booking from the Schedule Board: Resource requirement appears as an unfilled bar. Resource Manager selects an available resource and drags to fulfill the requirement. Booking type: Hard booking (confirmed commitment) or Soft booking (tentative reservation). Resource receives a notification of the new booking.
💡 Pro Tip: The Schedule Board requires Universal Resource Scheduling (URS) to be installed. URS is shared with D365 Field Service — if the client has both Project Operations and Field Service, all resources and bookings are managed on a single, shared Schedule Board. Identify this overlap in scoping to avoid configuring two separate resource management systems.
The distinction between Bookings and Assignments is one of the most important — and most misunderstood — concepts in D365 Project Operations. Many consultants confuse them.
Booking: A capacity reservation against a specific resource for a specified period. Created by the Resource Manager via the Schedule Board. Represents a commitment of the resource's time to the project. Bookings affect the resource's availability — reducing their capacity available to other projects. A resource can be booked to a project without being assigned to any specific tasks.
Assignment: An association of a resource to a specific task in the project WBS. Created by the Project Manager in the project task grid. Represents the PM's plan for who will do which work. Assignments do NOT automatically create bookings — they generate a resource requirement that the Resource Manager must then fulfill via a booking.
The gap they create: Booked hours ≠ Assigned hours is the core of the Resource Reconciliation view. If a resource is booked for 40 hours but assigned to tasks totaling 30 hours — 10 hours are "floating" capacity. If assigned 50 hours but only booked 40 hours — 10 hours are unfulfilled assignments.
Booking: A capacity reservation against a specific resource for a specified period. Created by the Resource Manager via the Schedule Board. Represents a commitment of the resource's time to the project. Bookings affect the resource's availability — reducing their capacity available to other projects. A resource can be booked to a project without being assigned to any specific tasks.
Assignment: An association of a resource to a specific task in the project WBS. Created by the Project Manager in the project task grid. Represents the PM's plan for who will do which work. Assignments do NOT automatically create bookings — they generate a resource requirement that the Resource Manager must then fulfill via a booking.
The gap they create: Booked hours ≠ Assigned hours is the core of the Resource Reconciliation view. If a resource is booked for 40 hours but assigned to tasks totaling 30 hours — 10 hours are "floating" capacity. If assigned 50 hours but only booked 40 hours — 10 hours are unfulfilled assignments.
💡 Pro Tip: In interviews, draw this distinction clearly: "Bookings are about resource capacity management — they answer the question 'Is this person available?' Assignments are about project planning — they answer 'Who will do this task?' They are related but separate. The Reconciliation view closes the gap between them."
Intercompany resource sharing in D365 Project Operations enables resources (employees) from one legal entity to work on projects owned by a different legal entity within the same group — with automated financial transactions between the entities.
Business scenario: Legal Entity A (UK) wins a project and is the contracting entity. Legal Entity B (India) has the specialist resources needed. Resources from India work on the UK project. UK entity bills the end client. India entity invoices the UK entity for the resource time (intercompany transaction).
How it works in D365: When a resource from Legal Entity B is booked on a project owned by Legal Entity A: Time entries from the resource post to Legal Entity A's project (billable to the end client). D365 simultaneously creates an intercompany cost transaction for Legal Entity A (cost of borrowing the resource from B) and an intercompany revenue transaction for Legal Entity B (revenue for lending the resource).
Configuration required: Intercompany must be enabled in Project Operations parameters. Transfer prices (the internal rate at which resources are "sold" between entities) must be defined in an Intercompany Price List. Each legal entity pairing must be configured (Entity A can borrow from Entity B, Entity A can borrow from Entity C).
Business scenario: Legal Entity A (UK) wins a project and is the contracting entity. Legal Entity B (India) has the specialist resources needed. Resources from India work on the UK project. UK entity bills the end client. India entity invoices the UK entity for the resource time (intercompany transaction).
How it works in D365: When a resource from Legal Entity B is booked on a project owned by Legal Entity A: Time entries from the resource post to Legal Entity A's project (billable to the end client). D365 simultaneously creates an intercompany cost transaction for Legal Entity A (cost of borrowing the resource from B) and an intercompany revenue transaction for Legal Entity B (revenue for lending the resource).
Configuration required: Intercompany must be enabled in Project Operations parameters. Transfer prices (the internal rate at which resources are "sold" between entities) must be defined in an Intercompany Price List. Each legal entity pairing must be configured (Entity A can borrow from Entity B, Entity A can borrow from Entity C).
💡 Pro Tip: Intercompany resource sharing is one of the most complex and frequently misunderstood features in Project Operations. Always conduct a dedicated intercompany requirements workshop with the finance director. Map every intercompany flow: "Which entities will lend resources? To which entities? At what transfer price?" Missing even one entity pairing causes financial posting errors on projects that use those resources.
When a project requires purchasing materials, subcontractor services, or equipment, D365 Project Operations integrates with the procurement process in D365 Finance to manage project-related purchase orders.
Project PO process:
1. PM identifies a need for a purchased service or material on the project (e.g., cloud hosting, specialist software, subcontractor services).
2. PM or procurement team creates a Purchase Order in D365 Finance, linked to the Project Contract and Project.
3. PO line specifies: Item/service, Quantity, Price, Project (costs post to this project), Project Category (determines which cost category the expense hits).
4. PO approved and sent to vendor.
5. Vendor delivers goods/services → PO receipt posted in D365.
6. Vendor invoice matched to PO and posted → Cost actual created on the project.
7. Cost actual appears in project cost reporting and may be billable to the client (depending on contract type).
Billable vs non-billable purchases: Stocked items (materials that go into the project deliverable) may be billed to the client at cost or marked up. Non-stocked service purchases (subcontractor time, software licences) are typically billable at actual cost or with a markup defined in the contract.
Project PO process:
1. PM identifies a need for a purchased service or material on the project (e.g., cloud hosting, specialist software, subcontractor services).
2. PM or procurement team creates a Purchase Order in D365 Finance, linked to the Project Contract and Project.
3. PO line specifies: Item/service, Quantity, Price, Project (costs post to this project), Project Category (determines which cost category the expense hits).
4. PO approved and sent to vendor.
5. Vendor delivers goods/services → PO receipt posted in D365.
6. Vendor invoice matched to PO and posted → Cost actual created on the project.
7. Cost actual appears in project cost reporting and may be billable to the client (depending on contract type).
Billable vs non-billable purchases: Stocked items (materials that go into the project deliverable) may be billed to the client at cost or marked up. Non-stocked service purchases (subcontractor time, software licences) are typically billable at actual cost or with a markup defined in the contract.
💡 Pro Tip: Project PO requirements are often missed during Project Operations scoping because the procurement team is not typically in the initial project workshops. Always ask: "Do your projects require purchasing goods or services from external vendors? Who manages that process?" If yes, the procurement team needs to be included in requirements gathering and the D365 Finance AP integration must be explicitly scoped.
Expense Categories in D365 Project Operations classify expense transactions — determining how costs are categorised in project financial reporting, which G/L accounts they post to, and whether they are billable to the client.
Standard expense categories (configurable): Travel (flights, trains, taxis), Accommodation (hotel, serviced apartments), Meals and Entertainment (client dinners, team lunches), Communication (mobile, internet), Software and Licences, Hardware and Equipment, Subcontractor fees, Training and Certification.
Expense category configuration: Project Operations → Settings → Expense Categories → New. Fields: Category name, Expense type (determines which form fields appear), Transaction type (Expense, Fee, Material, Time), Default billing type (Chargeable, Non-chargeable, Complimentary), G/L posting account (connects to D365 Finance Chart of Accounts), Per diem rate (if category uses daily allowance rather than actual receipts).
Category-specific rules: "Meals" category: capped at Rs.2,000 per day (warning if exceeded). "Travel" category: requires receipt attachment (mandatory field). "Entertainment" category: requires client name and business purpose fields.
Standard expense categories (configurable): Travel (flights, trains, taxis), Accommodation (hotel, serviced apartments), Meals and Entertainment (client dinners, team lunches), Communication (mobile, internet), Software and Licences, Hardware and Equipment, Subcontractor fees, Training and Certification.
Expense category configuration: Project Operations → Settings → Expense Categories → New. Fields: Category name, Expense type (determines which form fields appear), Transaction type (Expense, Fee, Material, Time), Default billing type (Chargeable, Non-chargeable, Complimentary), G/L posting account (connects to D365 Finance Chart of Accounts), Per diem rate (if category uses daily allowance rather than actual receipts).
Category-specific rules: "Meals" category: capped at Rs.2,000 per day (warning if exceeded). "Travel" category: requires receipt attachment (mandatory field). "Entertainment" category: requires client name and business purpose fields.
💡 Pro Tip: Expense category configuration directly affects financial reporting accuracy. Define expense categories in a joint workshop with both the PMO and Finance team — the PMO needs categories that mirror their project cost tracking habits, while Finance needs categories that map correctly to their Chart of Accounts. A category that satisfies one team but not the other will be used inconsistently, polluting cost data.
The Estimate at Completion (EAC) is a forward-looking financial forecast of the total project cost when complete — combining actual costs already incurred with the estimated cost to complete the remaining work. It is the most critical financial metric for a project manager.
EAC formula: EAC = Actual Cost to Date + Estimate to Complete (ETC). Where ETC = estimated cost of all remaining work.
How D365 Project Operations calculates EAC: Actual Cost = sum of all approved time, expense, and material actuals posted to the project to date. ETC = PM's current forecast of remaining work (updated in the project WBS by modifying the remaining hours and costs on tasks). D365 automatically recalculates EAC whenever actuals are posted or remaining estimates are updated.
EAC vs Original Budget: Cost Variance (CV) = Original Budget - EAC. Positive CV = project under budget (good). Negative CV = project over budget (action needed).
Project health indicator: D365 Project Operations shows EAC on the project dashboard with a traffic-light health indicator: Green = EAC within 5% of budget. Amber = EAC 5-15% over budget. Red = EAC 15%+ over budget.
EAC formula: EAC = Actual Cost to Date + Estimate to Complete (ETC). Where ETC = estimated cost of all remaining work.
How D365 Project Operations calculates EAC: Actual Cost = sum of all approved time, expense, and material actuals posted to the project to date. ETC = PM's current forecast of remaining work (updated in the project WBS by modifying the remaining hours and costs on tasks). D365 automatically recalculates EAC whenever actuals are posted or remaining estimates are updated.
EAC vs Original Budget: Cost Variance (CV) = Original Budget - EAC. Positive CV = project under budget (good). Negative CV = project over budget (action needed).
Project health indicator: D365 Project Operations shows EAC on the project dashboard with a traffic-light health indicator: Green = EAC within 5% of budget. Amber = EAC 5-15% over budget. Red = EAC 15%+ over budget.
💡 Pro Tip: The quality of EAC depends entirely on the PM keeping remaining estimates up to date. Many PMs update task progress (% complete) but forget to update remaining hours — causing EAC to be systematically understated. Train PMs that the EAC is only useful if remaining estimates are reviewed weekly. This data discipline is more important than any system feature.
For Fixed Price contracts, billing is not based on actual time and expenses but on predefined milestones or scheduled invoice dates. The Invoice Schedule defines when invoices are raised and for how much.
Invoice Schedule types in D365 Project Operations:
Milestone-based: Invoice triggered when a specific project deliverable is completed. E.g., Invoice 1 (Rs.5,00,000): Requirements Sign-off completed. Invoice 2 (Rs.10,00,000): UAT Completed. Invoice 3 (Rs.5,00,000): Go-live Achieved. PM marks the milestone as completed → Invoice is auto-created and ready for review.
Date-based: Invoice raised on specific calendar dates regardless of project progress. E.g., Invoice monthly on the 1st for one-third of the contract value. Useful for retainer-style engagements.
Progress-based: Invoice based on percentage completion. E.g., Invoice at 25%, 50%, 75%, and 100% completion. D365 calculates the invoice amount as: Contract Value × Progress %.
Invoice Schedule configuration: Project Contract → Contract Lines → Invoice Schedule tab. Add invoice schedule lines with: Invoice Date, Description (milestone name), Invoice Amount or % of contract value.
Invoice Schedule types in D365 Project Operations:
Milestone-based: Invoice triggered when a specific project deliverable is completed. E.g., Invoice 1 (Rs.5,00,000): Requirements Sign-off completed. Invoice 2 (Rs.10,00,000): UAT Completed. Invoice 3 (Rs.5,00,000): Go-live Achieved. PM marks the milestone as completed → Invoice is auto-created and ready for review.
Date-based: Invoice raised on specific calendar dates regardless of project progress. E.g., Invoice monthly on the 1st for one-third of the contract value. Useful for retainer-style engagements.
Progress-based: Invoice based on percentage completion. E.g., Invoice at 25%, 50%, 75%, and 100% completion. D365 calculates the invoice amount as: Contract Value × Progress %.
Invoice Schedule configuration: Project Contract → Contract Lines → Invoice Schedule tab. Add invoice schedule lines with: Invoice Date, Description (milestone name), Invoice Amount or % of contract value.
💡 Pro Tip: Milestone invoicing is the most contentious billing type in Fixed Price contracts because clients often dispute whether a milestone has truly been met. Document milestone completion criteria (acceptance criteria) explicitly in the contract and in the Invoice Schedule description field in D365 — not just "Requirements Sign-off" but "Signed BRD document received from client's project sponsor." Clear criteria prevent billing disputes post-delivery.
Project Actuals in D365 Project Operations are the financial records of real costs and revenues created as project work is performed — they are the backbone of project financial reporting, billing, and revenue recognition.
What creates Actuals: Approved Time Entry → Creates: Cost Actual (resource cost rate × hours), Billable Sales Actual (bill rate × hours — if the time is chargeable). Approved Expense Entry → Creates: Cost Actual (expense amount), Billable Sales Actual (if the expense is chargeable). Posted Vendor Invoice (for project POs) → Creates: Cost Actual. Invoice Confirmation → Creates: Billed Sales Actual (converts the Billable Sales Actual to Billed status).
Actual transaction types: Cost (internal cost of performing work), Unbilled Sales (work performed, billable, not yet invoiced), Billed Sales (work that has been invoiced and billed to the client), Inter-organizational (for intercompany resource sharing).
Correcting Actuals: Actuals cannot be edited directly — all corrections are made through reversal and re-entry. If a time entry was posted incorrectly, it is recalled, corrected, and re-approved — the system creates an offsetting reversal actual and a new correct actual.
What creates Actuals: Approved Time Entry → Creates: Cost Actual (resource cost rate × hours), Billable Sales Actual (bill rate × hours — if the time is chargeable). Approved Expense Entry → Creates: Cost Actual (expense amount), Billable Sales Actual (if the expense is chargeable). Posted Vendor Invoice (for project POs) → Creates: Cost Actual. Invoice Confirmation → Creates: Billed Sales Actual (converts the Billable Sales Actual to Billed status).
Actual transaction types: Cost (internal cost of performing work), Unbilled Sales (work performed, billable, not yet invoiced), Billed Sales (work that has been invoiced and billed to the client), Inter-organizational (for intercompany resource sharing).
Correcting Actuals: Actuals cannot be edited directly — all corrections are made through reversal and re-entry. If a time entry was posted incorrectly, it is recalled, corrected, and re-approved — the system creates an offsetting reversal actual and a new correct actual.
💡 Pro Tip: The Actuals entity is the most important table in Project Operations for financial reporting. If actuals are incomplete or incorrect, every project financial report (P&L, WIP, EAC) will be wrong. In UAT, always test the full end-to-end flow: "Submit time → Approve time → Verify cost actual and billable sales actual are created correctly with the right amounts." Do this for every combination of resource type and contract line before go-live.
A Not-to-Exceed (NTE) limit on a T&M project contract line sets a maximum billable amount — capping the client's financial exposure even though billing is otherwise based on actual time and expenses.
Example scenario: A consultant engagement is priced as T&M (actual hours billed) but the client wants a cap. Contract states: "T&M billing, not to exceed Rs.25,00,000 total." D365 enforces this cap — once cumulative billings reach Rs.25,00,000, no further billable sales actuals are created even if additional work is performed.
How D365 enforces NTE: The NTE amount is set on the Project Contract Line. As billable sales actuals accumulate, D365 tracks the running total against the NTE limit. When the NTE is approached (configurable warning threshold — e.g., 80% consumed), a warning appears on the project. When the NTE is reached, new time and expenses still post as Cost Actuals (internal cost) but NOT as Billable Sales Actuals — so the PM sees the cost but billing stops.
NTE adjustment: If the client agrees to increase the cap (contract amendment), the PM or billing manager updates the NTE amount on the Contract Line. Billing resumes automatically up to the new cap.
Example scenario: A consultant engagement is priced as T&M (actual hours billed) but the client wants a cap. Contract states: "T&M billing, not to exceed Rs.25,00,000 total." D365 enforces this cap — once cumulative billings reach Rs.25,00,000, no further billable sales actuals are created even if additional work is performed.
How D365 enforces NTE: The NTE amount is set on the Project Contract Line. As billable sales actuals accumulate, D365 tracks the running total against the NTE limit. When the NTE is approached (configurable warning threshold — e.g., 80% consumed), a warning appears on the project. When the NTE is reached, new time and expenses still post as Cost Actuals (internal cost) but NOT as Billable Sales Actuals — so the PM sees the cost but billing stops.
NTE adjustment: If the client agrees to increase the cap (contract amendment), the PM or billing manager updates the NTE amount on the Contract Line. Billing resumes automatically up to the new cap.
💡 Pro Tip: NTE limits are critical risk management parameters for professional services firms. A missing NTE configuration means the system will allow unlimited billing beyond the client's agreed cap — causing invoice disputes. Always confirm: "Does this contract have a not-to-exceed clause?" during contract setup. If yes, the NTE must be configured before the first time entries are posted.
Questions 31–40 of 75
The complete project invoicing process in D365 Project Operations connects time/expense actuals to a client-facing invoice through several structured steps:
Step 1 — Invoice Proposal creation: Billing Manager → Project Contract → Create Invoice. D365 gathers all unbilled sales actuals within the billing period. An Invoice for Review (Pro Forma Invoice) is created — a staging document that is NOT yet a formal invoice.
Step 2 — Invoice Review: Billing Manager reviews the pro forma: correct resource names, correct hours, correct rates, correct expense descriptions. Any adjustments: mark individual lines as Non-billable, change quantities, or apply credits. Attach supporting documents (timesheets, receipts) as required by the contract.
Step 3 — Invoice Confirmation: Billing Manager confirms the pro forma → A confirmed Invoice is created. This triggers: The unbilled sales actuals change status to Billed. The invoice posts to D365 Finance Accounts Receivable as a customer invoice. Revenue recognition records are updated.
Step 4 — Invoice to Customer: Confirmed invoice is printed or emailed to the client (from D365 Finance or directly from Project Operations). Client payment is recorded in D365 Finance AP when received.
Step 1 — Invoice Proposal creation: Billing Manager → Project Contract → Create Invoice. D365 gathers all unbilled sales actuals within the billing period. An Invoice for Review (Pro Forma Invoice) is created — a staging document that is NOT yet a formal invoice.
Step 2 — Invoice Review: Billing Manager reviews the pro forma: correct resource names, correct hours, correct rates, correct expense descriptions. Any adjustments: mark individual lines as Non-billable, change quantities, or apply credits. Attach supporting documents (timesheets, receipts) as required by the contract.
Step 3 — Invoice Confirmation: Billing Manager confirms the pro forma → A confirmed Invoice is created. This triggers: The unbilled sales actuals change status to Billed. The invoice posts to D365 Finance Accounts Receivable as a customer invoice. Revenue recognition records are updated.
Step 4 — Invoice to Customer: Confirmed invoice is printed or emailed to the client (from D365 Finance or directly from Project Operations). Client payment is recorded in D365 Finance AP when received.
💡 Pro Tip: Many clients require invoice attachments — detailed timesheet reports or expense receipts. Configure the invoice format in D365 Finance to include project, task, resource, and date detail on the invoice lines. Also create a standard "Invoice Backup Report" (Power BI or SSRS) that billing managers attach to every invoice. Clients who receive invoices without detail frequently dispute and delay payment.
A Retainer in D365 Project Operations is a fixed periodic payment arrangement — the client pays a regular amount (monthly, quarterly) for ongoing availability of services, regardless of the exact hours consumed.
Retainer use cases: Managed services engagements (Rs.5,00,000/month for up to 40 hours of support). Post-implementation support (Rs.2,00,000/month for bug fixes and minor enhancements). Strategic advisory (Rs.1,50,000/month for up to 8 hours of consulting access).
How retainers work in D365: The Project Contract Line is set to billing type "Retainer." The Retainer Schedule defines: periodic amount and frequency (monthly, quarterly). Each period, D365 creates a Retainer Advance (a pre-payment record). When time and expenses are logged, they consume the retainer balance. The invoice for the period bills the retainer amount — not the actual hours.
Retainer reconciliation: At period end, D365 reconciles actual consumption against the retainer amount. If actual work exceeds the retainer (overage), the excess may be: Carried forward to next period, Billed as additional T&M charges, Written off (depending on contract terms). If actual work is less than the retainer (unused capacity), the unused amount: Expires (non-refundable retainer), Carries forward (rollover retainer), Is partially refunded.
Retainer use cases: Managed services engagements (Rs.5,00,000/month for up to 40 hours of support). Post-implementation support (Rs.2,00,000/month for bug fixes and minor enhancements). Strategic advisory (Rs.1,50,000/month for up to 8 hours of consulting access).
How retainers work in D365: The Project Contract Line is set to billing type "Retainer." The Retainer Schedule defines: periodic amount and frequency (monthly, quarterly). Each period, D365 creates a Retainer Advance (a pre-payment record). When time and expenses are logged, they consume the retainer balance. The invoice for the period bills the retainer amount — not the actual hours.
Retainer reconciliation: At period end, D365 reconciles actual consumption against the retainer amount. If actual work exceeds the retainer (overage), the excess may be: Carried forward to next period, Billed as additional T&M charges, Written off (depending on contract terms). If actual work is less than the retainer (unused capacity), the unused amount: Expires (non-refundable retainer), Carries forward (rollover retainer), Is partially refunded.
💡 Pro Tip: Retainer overage and rollover policies vary widely between clients and contracts. Document the exact retainer policy in the contract notes field in D365 — and configure the appropriate treatment (expire vs. carry-forward) in the retainer settings. Discovering mid-engagement that 3 months of unused retainer hours have accumulated is both a billing dispute and a client relationship risk.
Multi-currency billing in D365 Project Operations handles engagements where the client contract is in one currency while project costs are incurred in another — a common scenario for global professional services firms.
Example: A UK consulting firm (GBP base currency) wins a project with an Indian client (invoiced in INR). UK consultants' costs are in GBP. The client invoice is in INR. The contract value is INR 2,00,00,000.
Currency configuration: Project Contract: Currency = INR (the invoicing currency). The Sales Price List linked to the contract is in INR (bill rates in INR). Resource Cost Price Lists are in GBP (cost rates in GBP). D365 uses the configured exchange rates to: Convert INR billable amounts to GBP for cost tracking. Track project margin in both INR and GBP.
Invoice generation: The client invoice is always produced in the Contract Currency (INR). Cost reporting for the PM and Finance team is in the Accounting Currency (GBP). Project Operations maintains both views simultaneously.
Exchange rate timing: The exchange rate used for revenue recognition is the rate on the transaction date (when actuals are posted). This means project margin can fluctuate with exchange rate movements during a long engagement.
Example: A UK consulting firm (GBP base currency) wins a project with an Indian client (invoiced in INR). UK consultants' costs are in GBP. The client invoice is in INR. The contract value is INR 2,00,00,000.
Currency configuration: Project Contract: Currency = INR (the invoicing currency). The Sales Price List linked to the contract is in INR (bill rates in INR). Resource Cost Price Lists are in GBP (cost rates in GBP). D365 uses the configured exchange rates to: Convert INR billable amounts to GBP for cost tracking. Track project margin in both INR and GBP.
Invoice generation: The client invoice is always produced in the Contract Currency (INR). Cost reporting for the PM and Finance team is in the Accounting Currency (GBP). Project Operations maintains both views simultaneously.
Exchange rate timing: The exchange rate used for revenue recognition is the rate on the transaction date (when actuals are posted). This means project margin can fluctuate with exchange rate movements during a long engagement.
💡 Pro Tip: Multi-currency projects require a clear policy on exchange rate treatment — does the firm use a fixed rate for the contract duration (simpler, more predictable), or the daily spot rate (accurate but creates variance)? Document this policy in the Project Parameters and in the contract terms. Unexpected currency variance is a common source of project profitability surprises at close-out.
Resource Utilisation is the measure of how productively a consultant's available time is being used on billable client work — the most critical operational KPI for professional services firms.
Utilisation formula: Billable Utilisation % = (Billable Hours / Available Hours) × 100. Available Hours = total working hours in the period (standard work hours minus approved leave). Billable Hours = approved time entries on chargeable contract lines.
Utilisation types in D365: Target utilisation: The firm's expected minimum billable utilisation per role (e.g., Senior Consultant = 75%, Junior Consultant = 85%, Partner = 50%). Actual utilisation: Calculated from approved time actuals in D365. Scheduled utilisation: Forward-looking — based on confirmed bookings on projects. Booked utilisation: Based on both hard and soft bookings.
Resource Utilisation report in D365 Project Operations: Available in the Resource Manager workspace. Shows actual vs. target utilisation per resource per period. Red = below target (underutilised — risk of revenue loss). Green = at or above target (healthy).
Utilisation formula: Billable Utilisation % = (Billable Hours / Available Hours) × 100. Available Hours = total working hours in the period (standard work hours minus approved leave). Billable Hours = approved time entries on chargeable contract lines.
Utilisation types in D365: Target utilisation: The firm's expected minimum billable utilisation per role (e.g., Senior Consultant = 75%, Junior Consultant = 85%, Partner = 50%). Actual utilisation: Calculated from approved time actuals in D365. Scheduled utilisation: Forward-looking — based on confirmed bookings on projects. Booked utilisation: Based on both hard and soft bookings.
Resource Utilisation report in D365 Project Operations: Available in the Resource Manager workspace. Shows actual vs. target utilisation per resource per period. Red = below target (underutilised — risk of revenue loss). Green = at or above target (healthy).
💡 Pro Tip: Target utilisation rates should be set based on firm economics: "A senior consultant at Rs.1,50,000/day billing rate and Rs.80,000/day cost rate needs 65% billable utilisation to break even. 75% target gives 10% headroom for admin, training, and proposals." Calculate the break-even utilisation for each role and make that the minimum target — not an arbitrary 80% for everyone.
D365 Project Operations provides a mobile time entry experience through the D365 mobile app — allowing consultants to log time and expenses from their smartphones, particularly valuable for field-based or frequently traveling team members.
Mobile time entry features: Weekly timesheet grid (same as desktop — project, task, role, hours per day). Quick entry mode: swipe to add time against recent projects. Voice entry: dictate time entries (limited availability). Timer: start/stop a timer to track time on an active task in real time. Offline mode: enter time without connectivity — syncs when network is available. Push notification reminders: "Your timesheet is due — Friday 5pm."
Mobile expense capture: Camera receipt scanning (AI extracts merchant, amount, date, currency from receipt photo). GPS location stamping for mileage claims. Per diem calculator (automatically suggests daily allowance based on location and travel policy). Submit expense with photo receipt — no paper required.
Project Operations app (dedicated): Separate from the generic D365 app. Optimised for time and expense entry workflows. Available for iOS and Android.
Mobile time entry features: Weekly timesheet grid (same as desktop — project, task, role, hours per day). Quick entry mode: swipe to add time against recent projects. Voice entry: dictate time entries (limited availability). Timer: start/stop a timer to track time on an active task in real time. Offline mode: enter time without connectivity — syncs when network is available. Push notification reminders: "Your timesheet is due — Friday 5pm."
Mobile expense capture: Camera receipt scanning (AI extracts merchant, amount, date, currency from receipt photo). GPS location stamping for mileage claims. Per diem calculator (automatically suggests daily allowance based on location and travel policy). Submit expense with photo receipt — no paper required.
Project Operations app (dedicated): Separate from the generic D365 app. Optimised for time and expense entry workflows. Available for iOS and Android.
💡 Pro Tip: Mobile time submission adoption is consistently higher than desktop in consulting firms — consultants who travel frequently prefer submitting time on their phone during travel rather than at their desk on Friday afternoon. If mobile adoption is a goal, ensure the mobile app is included in go-live training (not just the desktop). A 30-minute hands-on mobile training session increases adoption significantly.
The Opportunity-to-Contract flow connects D365 Sales CRM with D365 Project Operations — bridging the sales pipeline with project delivery once a deal is won.
Flow stages:
Opportunity (D365 Sales): Sales team identifies a potential project engagement. A Project Estimate (rough cost and revenue) is attached to the Opportunity to support the sales proposal.
Project Quote (D365 Project Operations): When the Opportunity progresses to proposal stage, a Quote is created. The Quote contains: Quote Lines (scope items), Pricing (T&M rates, fixed price amounts), Project Estimate details (role breakdown, hours). Multiple quote versions can be created (original proposal, revised after negotiation, final).
Quote Win / Quote Activation: Client accepts the proposal → Quote is marked Won → A Project Contract is automatically created from the Quote. The Quote Lines become Contract Lines. All pricing and scope is locked into the Contract.
Project Creation: Project is created and linked to the Contract (either manually by PM or auto-created from a template linked to the contract type). Delivery begins.
Flow stages:
Opportunity (D365 Sales): Sales team identifies a potential project engagement. A Project Estimate (rough cost and revenue) is attached to the Opportunity to support the sales proposal.
Project Quote (D365 Project Operations): When the Opportunity progresses to proposal stage, a Quote is created. The Quote contains: Quote Lines (scope items), Pricing (T&M rates, fixed price amounts), Project Estimate details (role breakdown, hours). Multiple quote versions can be created (original proposal, revised after negotiation, final).
Quote Win / Quote Activation: Client accepts the proposal → Quote is marked Won → A Project Contract is automatically created from the Quote. The Quote Lines become Contract Lines. All pricing and scope is locked into the Contract.
Project Creation: Project is created and linked to the Contract (either manually by PM or auto-created from a template linked to the contract type). Delivery begins.
💡 Pro Tip: The most common implementation gap: sales teams not attaching project estimates to Opportunities before project delivery begins. Without an estimate, the project has no budget baseline — the PM cannot track cost variance from day 1. Make "Project Estimate Required before Opportunity Stage = Propose" a mandatory business rule in both D365 Sales BPF requirements and project governance policy.
The Project Team in D365 Project Operations is the collection of resources (named or generic) who are allocated to deliver the project — managed via the Project Team Members subgrid on the Project record.
Project Team Members grid fields: Resource (named person or generic role placeholder). Booking method (Full capacity, Percentage of capacity, Hours per day, By hours — total hours for the project). From/To dates (the period during which the resource is allocated). Hard/Soft booking status. Role (what role this resource plays on the project). Task assignments (which WBS tasks this resource is assigned to).
Adding team members: Option 1: Add a named resource directly (bypasses the Resource Manager request process — PM self-books). Option 2: Add a generic resource (creates a resource requirement that the Resource Manager fulfills). Option 3: Resource Manager books a named resource via the Schedule Board (resource appears in the team automatically).
Team member notifications: When a resource is added to a project team, they receive a notification. They can then see the project in their My Projects view and submit time against it.
Project Team Members grid fields: Resource (named person or generic role placeholder). Booking method (Full capacity, Percentage of capacity, Hours per day, By hours — total hours for the project). From/To dates (the period during which the resource is allocated). Hard/Soft booking status. Role (what role this resource plays on the project). Task assignments (which WBS tasks this resource is assigned to).
Adding team members: Option 1: Add a named resource directly (bypasses the Resource Manager request process — PM self-books). Option 2: Add a generic resource (creates a resource requirement that the Resource Manager fulfills). Option 3: Resource Manager books a named resource via the Schedule Board (resource appears in the team automatically).
Team member notifications: When a resource is added to a project team, they receive a notification. They can then see the project in their My Projects view and submit time against it.
💡 Pro Tip: Define a clear policy in requirements for who can directly book named resources vs. who must go through the Resource Manager. If PMs can self-book any resource, the Resource Manager loses visibility of capacity commitments. Most mature organisations require Resource Manager approval for all bookings above a threshold (e.g., > 40 hours). This policy must be enforced through process, not just system configuration — Project Operations allows both routes.
D365 Project Operations ships with a pre-built Power BI analytics suite — a set of interactive reports that provide project financial, resource, and operational insights without requiring custom report development.
Included Power BI reports:
Project Manager Report: Project-level view — WBS progress, budget vs actual cost, EAC, milestone status, resource utilisation by project. Audience: Individual Project Managers.
Finance Manager Report: Revenue, cost, WIP (Work in Progress), billed vs unbilled revenue, project margin by project and client. Audience: Finance team and Billing Managers.
Resource Manager Report: Resource utilisation (actual vs. target), capacity vs. demand heatmap, resource bookings vs. availability, skill supply vs. project demand. Audience: Resource Managers and Practice Leaders.
Executive Dashboard: Portfolio-level view — overall revenue, pipeline, active projects count, at-risk projects, top clients by revenue.
Deployment: Power BI reports are available as a template app from Microsoft AppSource. Connect to the D365 Project Operations Dataverse environment. Reports update automatically as project data changes.
Included Power BI reports:
Project Manager Report: Project-level view — WBS progress, budget vs actual cost, EAC, milestone status, resource utilisation by project. Audience: Individual Project Managers.
Finance Manager Report: Revenue, cost, WIP (Work in Progress), billed vs unbilled revenue, project margin by project and client. Audience: Finance team and Billing Managers.
Resource Manager Report: Resource utilisation (actual vs. target), capacity vs. demand heatmap, resource bookings vs. availability, skill supply vs. project demand. Audience: Resource Managers and Practice Leaders.
Executive Dashboard: Portfolio-level view — overall revenue, pipeline, active projects count, at-risk projects, top clients by revenue.
Deployment: Power BI reports are available as a template app from Microsoft AppSource. Connect to the D365 Project Operations Dataverse environment. Reports update automatically as project data changes.
💡 Pro Tip: The Power BI template app is a "deploy and configure" step that is frequently missed in implementations — it is not automatically enabled. Add "Deploy and configure Project Operations Power BI reports" to the go-live checklist. These reports replace weeks of custom report development and are available on day 1 of go-live. Walking stakeholders through these reports in the UAT phase builds confidence and reduces post-go-live support requests.
The security model in D365 Project Operations controls who can see which projects, what financial data they can access, and what actions they can perform — balancing transparency with confidentiality in professional services organisations.
Standard security roles: Project Manager: Can create and manage projects they own. Can see all tasks, resources, and financial data on their projects. Cannot see financial data on other PMs' projects. Resource Manager: Can see all resource bookings and requirements across all projects. Can book resources to projects. No access to project financial data (rates, margins). Team Member: Can submit time and expenses against projects they are assigned to. Cannot see cost rates or billing rates — only hours. Project Approver: Can approve time and expense entries for projects they are assigned to approve. Billing Manager: Can create and manage invoices. Can see billable amounts. Cannot modify project plans or resources. Finance Manager: Can see all project financial data including cost rates and margins. Cannot modify project plans.
Standard security roles: Project Manager: Can create and manage projects they own. Can see all tasks, resources, and financial data on their projects. Cannot see financial data on other PMs' projects. Resource Manager: Can see all resource bookings and requirements across all projects. Can book resources to projects. No access to project financial data (rates, margins). Team Member: Can submit time and expenses against projects they are assigned to. Cannot see cost rates or billing rates — only hours. Project Approver: Can approve time and expense entries for projects they are assigned to approve. Billing Manager: Can create and manage invoices. Can see billable amounts. Cannot modify project plans or resources. Finance Manager: Can see all project financial data including cost rates and margins. Cannot modify project plans.
💡 Pro Tip: Rate confidentiality is almost always a requirement in professional services firms. Team members must NOT see each other's billing rates or the project margin. This is controlled by Field Level Security on the Rate fields and by restricting access to the Price List entity. Always include a "Rate Confidentiality" requirement in the security model design — it is easily forgotten and embarrassing to discover post-go-live that junior consultants can see the partner's billing rate.
D365 Project Operations can integrate with Microsoft Project Desktop (MSP) for organisations where project managers prefer the traditional Gantt chart and scheduling features of the desktop application over the Project for the Web interface.
Integration capabilities: Export a D365 Project Operations project plan to Microsoft Project Desktop (MPP file format). Make scheduling changes in MSP (dependency changes, resource levelling, critical path analysis). Re-import the updated plan back to D365 Project Operations.
When to use MSP integration: PMs with deep MSP expertise who are resistant to changing tools. Very complex project schedules requiring advanced scheduling features (resource levelling, critical path). Projects with 500+ tasks where the browser-based Project for the Web interface may be less performant.
Limitations: Two-way sync is not real-time — changes in MSP must be manually re-imported. Financial actuals (cost, revenue) remain in D365 and are not visible in MSP. Resource bookings in D365 and resource assignments in MSP must be kept manually in sync.
Integration capabilities: Export a D365 Project Operations project plan to Microsoft Project Desktop (MPP file format). Make scheduling changes in MSP (dependency changes, resource levelling, critical path analysis). Re-import the updated plan back to D365 Project Operations.
When to use MSP integration: PMs with deep MSP expertise who are resistant to changing tools. Very complex project schedules requiring advanced scheduling features (resource levelling, critical path). Projects with 500+ tasks where the browser-based Project for the Web interface may be less performant.
Limitations: Two-way sync is not real-time — changes in MSP must be manually re-imported. Financial actuals (cost, revenue) remain in D365 and are not visible in MSP. Resource bookings in D365 and resource assignments in MSP must be kept manually in sync.
💡 Pro Tip: The MSP integration was more important in earlier versions of Project Operations (when it was PSA). The Project for the Web scheduling engine has significantly improved and now handles most scheduling needs natively. Before recommending MSP integration, ask: "Why do you need MSP? What does it do that Project for the Web does not?" Most PMs who say they need MSP actually only need features that Project for the Web provides — they just haven't seen it yet.
Questions 41–50 of 75
D365 Project Operations tracks multiple project health indicators that give PMs and practice leaders an at-a-glance view of whether a project is on track:
Standard health indicators:
Schedule health (On Time): Calculated from Schedule Performance Index (SPI = Earned Value / Planned Value). SPI ≥ 1.0 = On Time. SPI 0.9-1.0 = Minor delay. SPI < 0.9 = Significant delay.
Cost health (On Budget): Calculated from Cost Performance Index (CPI = Earned Value / Actual Cost). CPI ≥ 1.0 = On Budget. CPI < 1.0 = Over budget.
Effort health: Comparison of remaining effort (hours) vs. available time to complete. Flags if the remaining work cannot be done in the remaining time at current pace.
Overall project status (manual): PM sets an overall RAG (Red/Amber/Green) status with a commentary note. This manual override allows context that the system metrics cannot capture (e.g., project is technically "Red" on schedule but client has agreed to an extension).
Standard health indicators:
Schedule health (On Time): Calculated from Schedule Performance Index (SPI = Earned Value / Planned Value). SPI ≥ 1.0 = On Time. SPI 0.9-1.0 = Minor delay. SPI < 0.9 = Significant delay.
Cost health (On Budget): Calculated from Cost Performance Index (CPI = Earned Value / Actual Cost). CPI ≥ 1.0 = On Budget. CPI < 1.0 = Over budget.
Effort health: Comparison of remaining effort (hours) vs. available time to complete. Flags if the remaining work cannot be done in the remaining time at current pace.
Overall project status (manual): PM sets an overall RAG (Red/Amber/Green) status with a commentary note. This manual override allows context that the system metrics cannot capture (e.g., project is technically "Red" on schedule but client has agreed to an extension).
💡 Pro Tip: Automated health indicators are only reliable if PMs keep their remaining estimates updated. A PM who sets all tasks to 50% complete on week 4 without updating remaining hours will show a misleadingly Green schedule health. Establish a "weekly forecast update" discipline: PMs review and update remaining hours every Friday before submitting time. This discipline is more valuable than any system feature.
Revenue leakage is billable work that is performed but never invoiced — one of the most significant financial problems in professional services firms. Industry estimates suggest 5-10% of professional services revenue is lost to leakage annually.
Common causes of revenue leakage: Time not submitted: Consultant forgets to submit time at the end of the week — hours are lost and never billed. Time submitted but not approved: Time sits in the approval queue past the invoice cut-off date — missing the billing cycle. Time approved but marked non-billable incorrectly: Admin error — work done for client marked as internal. Invoice cut-off not enforced: Time submitted after the billing manager has already run the invoice — delayed and forgotten. Contract limits reached: Work continues after NTE limit — cost incurred but not billed.
How D365 Project Operations reduces leakage: Mandatory time submission reminders (Power Automate notifications every Friday at 3pm). Approval deadline alerts (Approver notified — "You have 12 unapproved time entries past the cut-off"). Unbilled transaction report: Shows all approved, billable actuals NOT yet invoiced. Invoice for Review automation: Regular billing run ensures all billable actuals are captured in each billing cycle.
Common causes of revenue leakage: Time not submitted: Consultant forgets to submit time at the end of the week — hours are lost and never billed. Time submitted but not approved: Time sits in the approval queue past the invoice cut-off date — missing the billing cycle. Time approved but marked non-billable incorrectly: Admin error — work done for client marked as internal. Invoice cut-off not enforced: Time submitted after the billing manager has already run the invoice — delayed and forgotten. Contract limits reached: Work continues after NTE limit — cost incurred but not billed.
How D365 Project Operations reduces leakage: Mandatory time submission reminders (Power Automate notifications every Friday at 3pm). Approval deadline alerts (Approver notified — "You have 12 unapproved time entries past the cut-off"). Unbilled transaction report: Shows all approved, billable actuals NOT yet invoiced. Invoice for Review automation: Regular billing run ensures all billable actuals are captured in each billing cycle.
💡 Pro Tip: Build a "Revenue Leakage" KPI dashboard as a requirement for every Project Operations implementation. This dashboard shows: Unbilled billable actuals by project and by resource. Time entries not submitted past the cut-off date. Unapproved time entries per manager. Showing this dashboard in the first go-live review typically reveals Rs.5-20 lakh of previously uncaptured revenue — instantly justifying the system investment.
Understanding the core data model in D365 Project Operations is essential for building integrations, custom reports, and troubleshooting financial discrepancies.
Core entities and their relationships:
Account (client organisation) → Project Contract (1:N). Project Contract → Contract Lines (1:N — one per scope/billing method). Contract Line → Project (1:1 or 1:N — project linked to contract line). Project → Project Tasks (1:N — the WBS). Project Tasks → Resource Assignments (1:N — which resources are assigned). Project → Project Team Members (1:N — resource bookings). Time Entry → Actuals (1:N — approval creates actuals). Expense Entry → Actuals (1:N). Actuals → Invoice Lines (N:N — actuals are added to invoice proposals). Invoice → Customer Invoice in D365 Finance (1:1 — confirmed invoices post to Finance).
Key junction entities: msdyn_projecttask, msdyn_resourceassignment, msdyn_bookableresourcebooking, msdyn_timeentry, msdyn_actual, msdyn_invoice (Project Operations uses the "msdyn_" prefix for all Project Operations entities in Dataverse).
Core entities and their relationships:
Account (client organisation) → Project Contract (1:N). Project Contract → Contract Lines (1:N — one per scope/billing method). Contract Line → Project (1:1 or 1:N — project linked to contract line). Project → Project Tasks (1:N — the WBS). Project Tasks → Resource Assignments (1:N — which resources are assigned). Project → Project Team Members (1:N — resource bookings). Time Entry → Actuals (1:N — approval creates actuals). Expense Entry → Actuals (1:N). Actuals → Invoice Lines (N:N — actuals are added to invoice proposals). Invoice → Customer Invoice in D365 Finance (1:1 — confirmed invoices post to Finance).
Key junction entities: msdyn_projecttask, msdyn_resourceassignment, msdyn_bookableresourcebooking, msdyn_timeentry, msdyn_actual, msdyn_invoice (Project Operations uses the "msdyn_" prefix for all Project Operations entities in Dataverse).
💡 Pro Tip: When building custom Power BI reports or integrations for Project Operations, always start with the Actuals entity (msdyn_actual) — it is the single most comprehensive source of truth for all financial data. Cost, unbilled sales, billed sales, and intercompany transactions are all Actuals records. If the Actuals entity is healthy, all financial reporting will be accurate.
The choice between Lite and Resource/Non-Stocked deployment is one of the first and most important decisions in a Project Operations implementation — it determines the licence requirements, integration scope, and financial capabilities.
Project Operations Lite: Target: Internal project management, PMOs tracking projects without external billing. Financial scope: No integration with D365 Finance. No project accounting, no revenue recognition, no external invoicing. Time and expenses tracked but purely for project progress — no financial posting. Licence: Team Member licence only (lowest cost). Use case: IT department tracking internal projects, NGO managing grant-funded programmes.
Resource/Non-Stocked: Target: Professional services firms billing clients for time and expenses. Financial scope: Full D365 Finance integration — cost actuals, billable actuals, customer invoices, revenue recognition, WIP reporting. Time and expenses create financial actuals that drive billing and P&L reporting. Licence: Project Operations licence + D365 Finance licence. Use case: Consulting firms, system integrators, engineering firms, IT services companies.
The critical question: "Do you bill clients for time and expenses?" If yes → Resource/Non-Stocked. If no → Lite.
Project Operations Lite: Target: Internal project management, PMOs tracking projects without external billing. Financial scope: No integration with D365 Finance. No project accounting, no revenue recognition, no external invoicing. Time and expenses tracked but purely for project progress — no financial posting. Licence: Team Member licence only (lowest cost). Use case: IT department tracking internal projects, NGO managing grant-funded programmes.
Resource/Non-Stocked: Target: Professional services firms billing clients for time and expenses. Financial scope: Full D365 Finance integration — cost actuals, billable actuals, customer invoices, revenue recognition, WIP reporting. Time and expenses create financial actuals that drive billing and P&L reporting. Licence: Project Operations licence + D365 Finance licence. Use case: Consulting firms, system integrators, engineering firms, IT services companies.
The critical question: "Do you bill clients for time and expenses?" If yes → Resource/Non-Stocked. If no → Lite.
💡 Pro Tip: Starting with Lite and migrating to Resource/Non-Stocked later is very disruptive — historical actuals do not migrate cleanly to the Financial integration model. Always invest time upfront to confirm the correct deployment scenario. A 30-minute conversation with the CFO about whether project billing is required will prevent a costly rework 6 months into the implementation.
A comprehensive Project Operations go-live checklist ensures all critical configuration is in place before real projects go live:
Foundation setup: Organisation Units created and hierarchy defined. Price Lists (Cost and Sales) created for all currencies. Expense categories configured with G/L posting accounts. Project parameters set (scheduling engine, time entry mode, approval workflow). Business hours and holiday calendars configured. Security roles assigned to all users.
Resource management: All resources created with correct Organisation Units. Resource skills defined and assigned. Resource calendars set (working hours, availability). Schedule Board configured and tested.
Project financial setup: D365 Finance project posting profiles configured. Revenue categories mapped to G/L accounts. Intercompany configuration (if applicable). Invoice format and layout configured.
Test scenarios to complete before go-live: End-to-end T&M project: Create project → Book resource → Submit and approve time → Create invoice → Confirm invoice → Verify posting in Finance. End-to-end Fixed Price project: Create project with milestone schedule → Mark milestone complete → Create and confirm invoice. Expense submission and approval → expense appears on invoice.
Foundation setup: Organisation Units created and hierarchy defined. Price Lists (Cost and Sales) created for all currencies. Expense categories configured with G/L posting accounts. Project parameters set (scheduling engine, time entry mode, approval workflow). Business hours and holiday calendars configured. Security roles assigned to all users.
Resource management: All resources created with correct Organisation Units. Resource skills defined and assigned. Resource calendars set (working hours, availability). Schedule Board configured and tested.
Project financial setup: D365 Finance project posting profiles configured. Revenue categories mapped to G/L accounts. Intercompany configuration (if applicable). Invoice format and layout configured.
Test scenarios to complete before go-live: End-to-end T&M project: Create project → Book resource → Submit and approve time → Create invoice → Confirm invoice → Verify posting in Finance. End-to-end Fixed Price project: Create project with milestone schedule → Mark milestone complete → Create and confirm invoice. Expense submission and approval → expense appears on invoice.
💡 Pro Tip: The most critical go-live test is the end-to-end financial test. Many Project Operations go-lives discover on day 1 that invoices cannot be confirmed because a G/L posting account is missing or a tax configuration is wrong in D365 Finance. Run 10 complete test invoices in the UAT environment and verify every one posts correctly to Finance before signing off go-live readiness.
Project Milestones in D365 Project Operations are significant project events or deliverable completion points — used for tracking project progress, triggering milestone-based billing, and communicating project status to stakeholders.
Types of milestones in D365 Project Operations:
WBS Milestones (Task-level): A task with zero duration and zero effort — represents a checkpoint or deliverable completion in the project plan. Used for: Sprint completion dates, Phase gate reviews, Deliverable sign-offs. Displayed on the project Gantt chart as a diamond marker.
Contract Milestones (Invoice Schedule): Billing-specific milestones on Fixed Price contract lines. When marked as completed, they trigger invoice proposal creation. Fields: Description, Due Date, Amount (the invoice value for this milestone), Status (Incomplete / Ready to Invoice / Invoice Created).
Milestone tracking and reporting: Project Milestone report: All milestones across all active projects with their planned vs actual completion dates. Overdue milestone report: Milestones past their planned date — not yet marked complete. At-risk milestone report: Milestones due in next 14 days with incomplete predecessor tasks.
Types of milestones in D365 Project Operations:
WBS Milestones (Task-level): A task with zero duration and zero effort — represents a checkpoint or deliverable completion in the project plan. Used for: Sprint completion dates, Phase gate reviews, Deliverable sign-offs. Displayed on the project Gantt chart as a diamond marker.
Contract Milestones (Invoice Schedule): Billing-specific milestones on Fixed Price contract lines. When marked as completed, they trigger invoice proposal creation. Fields: Description, Due Date, Amount (the invoice value for this milestone), Status (Incomplete / Ready to Invoice / Invoice Created).
Milestone tracking and reporting: Project Milestone report: All milestones across all active projects with their planned vs actual completion dates. Overdue milestone report: Milestones past their planned date — not yet marked complete. At-risk milestone report: Milestones due in next 14 days with incomplete predecessor tasks.
💡 Pro Tip: Contract milestones are only created when the PM explicitly marks them as "Ready to Invoice" in D365. A common revenue delay: PMs don't know they need to do this — they mark a task complete but don't update the invoice schedule milestone. Train PMs specifically on the milestone billing trigger and include "Mark milestone as Ready to Invoice within 2 business days of deliverable sign-off" in the project management SOP.
D365 Project Operations includes basic Risk and Issue tracking — allowing project managers to log, monitor, and manage project risks and issues within the same platform as project planning and financials.
Risk record fields: Title and description, Risk type (Schedule, Cost, Scope, Resource, Technical, External), Probability (High/Medium/Low or percentage), Impact (High/Medium/Low), Risk score (Probability × Impact — auto-calculated), Status (Active, Mitigated, Closed), Mitigation plan (text description of the mitigation action), Owner (who is responsible for managing this risk), Due date (when the mitigation is due).
Issue record fields: Title, description, priority, assigned to, due date, status (Active, Resolved, Closed), resolution description.
Risk and Issue on Project: Both are accessible from the Project record via the Risks and Issues subgrids. Project Managers can log risks and issues directly from the project context.
Limitation: D365 Project Operations Risk and Issue management is basic — it covers logging and tracking but lacks advanced RAID log features (Risk register with heat maps, Issue escalation workflows, Action log). For advanced risk management, some clients use a separate tool (SharePoint RAID log, Jira, etc.).
Risk record fields: Title and description, Risk type (Schedule, Cost, Scope, Resource, Technical, External), Probability (High/Medium/Low or percentage), Impact (High/Medium/Low), Risk score (Probability × Impact — auto-calculated), Status (Active, Mitigated, Closed), Mitigation plan (text description of the mitigation action), Owner (who is responsible for managing this risk), Due date (when the mitigation is due).
Issue record fields: Title, description, priority, assigned to, due date, status (Active, Resolved, Closed), resolution description.
Risk and Issue on Project: Both are accessible from the Project record via the Risks and Issues subgrids. Project Managers can log risks and issues directly from the project context.
Limitation: D365 Project Operations Risk and Issue management is basic — it covers logging and tracking but lacks advanced RAID log features (Risk register with heat maps, Issue escalation workflows, Action log). For advanced risk management, some clients use a separate tool (SharePoint RAID log, Jira, etc.).
💡 Pro Tip: Ask clients in requirements: "How do you currently manage project risks? Do you use a formal RAID log?" If they have a mature risk management process, D365 Project Operations' basic Risk and Issue feature may not be sufficient — and that is fine. Acknowledge the limitation and recommend a simple SharePoint-based RAID log that links back to the D365 Project record. Trying to build complex risk management in D365 is the wrong investment.
Many organisations run Microsoft's legacy Project Service Automation (PSA) and are evaluating or planning an upgrade to D365 Project Operations. Understanding this migration path is important for consultants encountering existing PSA clients.
Key differences requiring migration effort: Scheduling engine: PSA used the legacy PSA Scheduling Engine. Project Operations uses Project for the Web (or legacy engine in backward compatibility mode). Data model changes: Several entity names and relationships changed between PSA and Project Operations. Price dimension framework: More flexible in Project Operations. Subcontracting: New in Project Operations — not in PSA. Finance integration: Deeper in Project Operations with dual-write real-time sync.
Migration path: Microsoft provides upgrade scripts and tooling via Lifecycle Services (LCS) for PSA to Project Operations upgrade. The upgrade is in-place — existing data migrates to the new schema. Key steps: Run PSA to Project Operations upgrade readiness checker. Resolve all pre-upgrade issues. Execute the upgrade in Sandbox first. Validate all projects, actuals, and invoices. Promote to Production.
Common migration risks: Open invoice proposals in PSA may need to be cleared before upgrade. Customisations built on PSA entities need re-testing. Custom reports need updating if they referenced PSA entity names.
Key differences requiring migration effort: Scheduling engine: PSA used the legacy PSA Scheduling Engine. Project Operations uses Project for the Web (or legacy engine in backward compatibility mode). Data model changes: Several entity names and relationships changed between PSA and Project Operations. Price dimension framework: More flexible in Project Operations. Subcontracting: New in Project Operations — not in PSA. Finance integration: Deeper in Project Operations with dual-write real-time sync.
Migration path: Microsoft provides upgrade scripts and tooling via Lifecycle Services (LCS) for PSA to Project Operations upgrade. The upgrade is in-place — existing data migrates to the new schema. Key steps: Run PSA to Project Operations upgrade readiness checker. Resolve all pre-upgrade issues. Execute the upgrade in Sandbox first. Validate all projects, actuals, and invoices. Promote to Production.
Common migration risks: Open invoice proposals in PSA may need to be cleared before upgrade. Customisations built on PSA entities need re-testing. Custom reports need updating if they referenced PSA entity names.
💡 Pro Tip: Always run the upgrade in Sandbox first and complete a full financial reconciliation: compare total actuals, WIP, and unbilled revenue pre- and post-upgrade. Any discrepancy must be investigated and resolved before upgrading production. A PSA-to-PO upgrade that introduces financial discrepancies is extremely difficult to untangle after the fact.
D365 Project Operations exposes its data and business logic through the Dataverse Web API — enabling external systems to create, read, update, and delete Project Operations records programmatically.
Key integration use cases: HR system → Project Operations: When a new employee joins, the HR system calls the API to create a Resource record in Project Operations with the correct organisation unit, skills, and calendar. Time tracking tool → Project Operations: A third-party time tracker (Harvest, Toggl, Clockify) posts time entries to Project Operations via API at the end of each day. Project Operations → CRM: When a Project Contract is created, the API triggers a notification to the Sales team in D365 Sales with the project details. Project Operations → Finance system: For clients not using D365 Finance, actuals are exported via API to a third-party ERP (SAP, Oracle) for financial posting.
Project Operations-specific API actions: Beyond standard CRUD operations, Project Operations provides specific "Project schedule" APIs for creating and updating tasks (the WBS has specific API endpoints that handle scheduling recalculation). Using the generic Dataverse API to update task durations will not trigger schedule recalculation — the dedicated Project Schedule API must be used.
Key integration use cases: HR system → Project Operations: When a new employee joins, the HR system calls the API to create a Resource record in Project Operations with the correct organisation unit, skills, and calendar. Time tracking tool → Project Operations: A third-party time tracker (Harvest, Toggl, Clockify) posts time entries to Project Operations via API at the end of each day. Project Operations → CRM: When a Project Contract is created, the API triggers a notification to the Sales team in D365 Sales with the project details. Project Operations → Finance system: For clients not using D365 Finance, actuals are exported via API to a third-party ERP (SAP, Oracle) for financial posting.
Project Operations-specific API actions: Beyond standard CRUD operations, Project Operations provides specific "Project schedule" APIs for creating and updating tasks (the WBS has specific API endpoints that handle scheduling recalculation). Using the generic Dataverse API to update task durations will not trigger schedule recalculation — the dedicated Project Schedule API must be used.
💡 Pro Tip: The Project Schedule API (for creating and modifying WBS tasks programmatically) is different from the standard Dataverse API and requires specific transaction batching. Developers unfamiliar with this distinction will create tasks that appear in the database but show wrong dates. Always direct developers to the Microsoft documentation on "Use Project schedule APIs to perform operations with Scheduling entities" before they begin development.
The first discovery workshop for a Project Operations implementation must cover all dimensions of the project business — from sales through delivery to billing.
Business model questions: What types of projects do you deliver? (IT implementations, management consulting, engineering, managed services). How do you price your work? (T&M, Fixed Price, Retainer, Hybrid). What is your average project duration and value? (1 month to 18 months, £50K to £5M).
Resource management questions: How many billable resources do you have? Do you use subcontractors? Do resources work across multiple projects simultaneously? How do you currently decide who goes on which project?
Financial questions: What is your current invoicing process and how often do you invoice? How do you track project profitability today? Do you need revenue recognition per accounting standards (IFRS 15)?
Current system questions: What do you use today for project planning, time tracking, and billing? (Excel, Jira, Harvest, Mavenlink). What does your current system do well that must be preserved?
Integration questions: What HR or payroll system do you use? What accounting/ERP system do you use? Do you have D365 Sales for opportunity management?
Business model questions: What types of projects do you deliver? (IT implementations, management consulting, engineering, managed services). How do you price your work? (T&M, Fixed Price, Retainer, Hybrid). What is your average project duration and value? (1 month to 18 months, £50K to £5M).
Resource management questions: How many billable resources do you have? Do you use subcontractors? Do resources work across multiple projects simultaneously? How do you currently decide who goes on which project?
Financial questions: What is your current invoicing process and how often do you invoice? How do you track project profitability today? Do you need revenue recognition per accounting standards (IFRS 15)?
Current system questions: What do you use today for project planning, time tracking, and billing? (Excel, Jira, Harvest, Mavenlink). What does your current system do well that must be preserved?
Integration questions: What HR or payroll system do you use? What accounting/ERP system do you use? Do you have D365 Sales for opportunity management?
💡 Pro Tip: The most revealing question in a Project Operations discovery is: "Walk me through what happens from the moment you win a project to the moment you receive the final payment from the client." This single narrative typically takes 30-45 minutes and surfaces all the key process steps, pain points, and system integrations — giving you everything you need to design the Project Operations solution scope.
Questions 51–60 of 75
The Subcontract Management module in D365 Project Operations (introduced in the 2021 release) provides native management of external subcontractor engagements — connecting procurement, project delivery, and financial accounting for subcontracted work.
Subcontract lifecycle:
1. PM identifies a skill gap — no internal resource available. Decides to engage a subcontractor.
2. Subcontract created: Vendor, SOW description, Contract period, Subcontract lines (roles, hours, rates in Purchase Price List).
3. Subcontract Lines linked to Project: Specific tasks in the project WBS are fulfilled by the subcontract lines.
4. Subcontractor resource added to Project Team as a "Vendor" resource type.
5. Subcontractor submits time (via guest access to the Project Operations time entry form or via API from their own system).
6. Time approved by PM → Cost actuals created using the subcontract purchase rates.
7. Vendor invoice received → Matched to the subcontract PO in D365 Finance → Vendor invoice posted.
Margin tracking: If a subcontractor is purchased at £500/day and billed to the client at £900/day, D365 tracks the £400 margin on every subcontractor unit — enabling subcontract-level profitability reporting.
Subcontract lifecycle:
1. PM identifies a skill gap — no internal resource available. Decides to engage a subcontractor.
2. Subcontract created: Vendor, SOW description, Contract period, Subcontract lines (roles, hours, rates in Purchase Price List).
3. Subcontract Lines linked to Project: Specific tasks in the project WBS are fulfilled by the subcontract lines.
4. Subcontractor resource added to Project Team as a "Vendor" resource type.
5. Subcontractor submits time (via guest access to the Project Operations time entry form or via API from their own system).
6. Time approved by PM → Cost actuals created using the subcontract purchase rates.
7. Vendor invoice received → Matched to the subcontract PO in D365 Finance → Vendor invoice posted.
Margin tracking: If a subcontractor is purchased at £500/day and billed to the client at £900/day, D365 tracks the £400 margin on every subcontractor unit — enabling subcontract-level profitability reporting.
💡 Pro Tip: Subcontract margin erosion is a common problem when subcontractor costs are not tracked against the billing rate for that resource slot. Always configure a Purchase Price List for each vendor with their contracted rates before they log any time. If a subcontractor logs time before the purchase price list is configured, the cost actuals will use the wrong rate — and the resulting financial corrections are time-consuming and create audit issues.
Leave and Absence management intersects with Project Operations because approved leave reduces a resource's available capacity — affecting resource planning, utilisation reporting, and project scheduling.
Integration options:
D365 Human Resources integration: If the organisation uses D365 Human Resources, approved leave is automatically blocked in the resource's calendar in Project Operations. The Schedule Board shows the resource as unavailable during approved leave periods. Utilisation calculations exclude approved leave from available hours.
Manual leave management (without D365 HR): HR or the Resource Manager creates a non-working period on the resource's calendar in Project Operations. The Project Operations calendar for each resource (accessible from Resource → Work Hours) can have specific dates marked as non-working. This must be maintained manually — a burden for larger teams.
Impact on project scheduling: If a resource on a critical path task goes on leave, the task's scheduled completion date shifts — potentially delaying the project. PMs can see this in the project Gantt and take action (reassign tasks, adjust dependencies).
Integration options:
D365 Human Resources integration: If the organisation uses D365 Human Resources, approved leave is automatically blocked in the resource's calendar in Project Operations. The Schedule Board shows the resource as unavailable during approved leave periods. Utilisation calculations exclude approved leave from available hours.
Manual leave management (without D365 HR): HR or the Resource Manager creates a non-working period on the resource's calendar in Project Operations. The Project Operations calendar for each resource (accessible from Resource → Work Hours) can have specific dates marked as non-working. This must be maintained manually — a burden for larger teams.
Impact on project scheduling: If a resource on a critical path task goes on leave, the task's scheduled completion date shifts — potentially delaying the project. PMs can see this in the project Gantt and take action (reassign tasks, adjust dependencies).
💡 Pro Tip: In requirements, always ask: "Which HR system do you use for leave management?" If not D365 HR, plan for a Power Automate integration or manual process to block leave in Project Operations calendars. Ignoring this leads to utilisation reports that overstate availability and project plans that do not account for resource absences — two significant accuracy problems.
Project Operations implementations almost always require some level of customisation beyond the standard configuration to meet client-specific needs:
Common custom fields: On Project: Client Industry, Engagement Type (New Business / Extension / Support), Strategic Importance (High/Medium/Low), Profit Centre, Practice Area, Delivery Manager (second PM field). On Contract: Contract Value (original, for tracking amendments), Client PO Number, Internal Reference Number, Payment Terms. On Time Entry: Activity Type (Development / Testing / Project Management / Travel), Billable (custom override field).
Common custom views: "My Projects — Profitability Summary" (PM view showing EAC and margin for all active projects). "At-Risk Projects" (projects where CPI or SPI is below threshold). "Unbilled Revenue by Client" (billing manager view). "Resource Availability Next 4 Weeks" (resource manager view).
Common Power Automate flows: Project created notification to practice lead. Contract value above £1M requires Practice Director approval. Weekly utilisation report emailed to Resource Manager every Monday. Invoice confirmed notification to project finance team. Milestone completion reminder 7 days before due date.
Common custom fields: On Project: Client Industry, Engagement Type (New Business / Extension / Support), Strategic Importance (High/Medium/Low), Profit Centre, Practice Area, Delivery Manager (second PM field). On Contract: Contract Value (original, for tracking amendments), Client PO Number, Internal Reference Number, Payment Terms. On Time Entry: Activity Type (Development / Testing / Project Management / Travel), Billable (custom override field).
Common custom views: "My Projects — Profitability Summary" (PM view showing EAC and margin for all active projects). "At-Risk Projects" (projects where CPI or SPI is below threshold). "Unbilled Revenue by Client" (billing manager view). "Resource Availability Next 4 Weeks" (resource manager view).
Common Power Automate flows: Project created notification to practice lead. Contract value above £1M requires Practice Director approval. Weekly utilisation report emailed to Resource Manager every Monday. Invoice confirmed notification to project finance team. Milestone completion reminder 7 days before due date.
💡 Pro Tip: Keep a "Configuration Decision Log" throughout the project that records: what was requested, what out-of-box capability was evaluated, what the decision was, and the rationale. This log prevents the same configuration question being raised multiple times and provides audit evidence if scope disputes arise. It also becomes valuable institutional knowledge for future system enhancements.
Understanding common implementation challenges in Project Operations helps consultants proactively manage risks:
Challenge 1 — Resistance from Project Managers: PMs who use MS Project or Excel for planning resist moving to D365. Root cause: Unfamiliar interface, perceived loss of control. Mitigation: Early PM involvement in design. Show templates — "Your ERP implementation plan in D365 in 15 minutes." Dedicated PM super-user group.
Challenge 2 — Time submission compliance: Consultants who travel frequently or work on multiple projects submit time late or inaccurately. Root cause: No mobile-first experience, no reminders, no consequence for late submission. Mitigation: Configure mobile time entry. Set up weekly Friday reminder notifications. Implement a "lock late submissions" rule after 5 business days.
Challenge 3 — D365 Finance configuration complexity: The finance integration (posting profiles, project accounting categories, revenue recognition) requires senior D365 Finance expertise that is sometimes underscoped. Mitigation: Always have a D365 Finance consultant paired with the Project Operations consultant.
Challenge 4 — Price List maintenance: Billing rates change annually but Price Lists are not updated. Old rates used on new projects. Mitigation: Price List versioning and expiry dates. Annual rate review process built into Project Parameters.
Challenge 1 — Resistance from Project Managers: PMs who use MS Project or Excel for planning resist moving to D365. Root cause: Unfamiliar interface, perceived loss of control. Mitigation: Early PM involvement in design. Show templates — "Your ERP implementation plan in D365 in 15 minutes." Dedicated PM super-user group.
Challenge 2 — Time submission compliance: Consultants who travel frequently or work on multiple projects submit time late or inaccurately. Root cause: No mobile-first experience, no reminders, no consequence for late submission. Mitigation: Configure mobile time entry. Set up weekly Friday reminder notifications. Implement a "lock late submissions" rule after 5 business days.
Challenge 3 — D365 Finance configuration complexity: The finance integration (posting profiles, project accounting categories, revenue recognition) requires senior D365 Finance expertise that is sometimes underscoped. Mitigation: Always have a D365 Finance consultant paired with the Project Operations consultant.
Challenge 4 — Price List maintenance: Billing rates change annually but Price Lists are not updated. Old rates used on new projects. Mitigation: Price List versioning and expiry dates. Annual rate review process built into Project Parameters.
💡 Pro Tip: The single biggest Project Operations implementation risk is separating the Project Operations consultant from the D365 Finance consultant. Project Operations is half CRM and half ERP — it requires expertise in both. Proposals that include Project Operations configuration but no D365 Finance resource should be challenged: "Who will configure the posting profiles and revenue recognition?" The answer is often "nobody" — and that means the financial integration will not work at go-live.
Capacity Planning in D365 Project Operations enables Resource Managers to plan future resource supply against anticipated project demand — ensuring the right people are available before projects begin.
Demand side (what projects need): Generic resource requirements on project WBS (roles, skills, hours, dates from future or pipeline projects). Soft bookings on projects with high win probability (pipeline projects that are 70%+ likely to proceed). Sales pipeline in D365 Opportunities with estimated resource requirements attached.
Supply side (what people are available): Current resource headcount and skills in Project Operations. Planned hires (can be added as "future resources" with planned start dates). Confirmed leave periods reducing availability. Existing hard bookings on active projects (committed capacity).
Capacity analysis views in D365: Resource utilisation heat map: Shows available vs. booked hours per resource per week. Red = over-booked. Green = available. Capacity vs. demand chart: At practice or team level — does the team have enough hours to deliver all active + pipeline projects? Gap analysis: Which skills are in shortage? Which roles are over-committed?
Demand side (what projects need): Generic resource requirements on project WBS (roles, skills, hours, dates from future or pipeline projects). Soft bookings on projects with high win probability (pipeline projects that are 70%+ likely to proceed). Sales pipeline in D365 Opportunities with estimated resource requirements attached.
Supply side (what people are available): Current resource headcount and skills in Project Operations. Planned hires (can be added as "future resources" with planned start dates). Confirmed leave periods reducing availability. Existing hard bookings on active projects (committed capacity).
Capacity analysis views in D365: Resource utilisation heat map: Shows available vs. booked hours per resource per week. Red = over-booked. Green = available. Capacity vs. demand chart: At practice or team level — does the team have enough hours to deliver all active + pipeline projects? Gap analysis: Which skills are in shortage? Which roles are over-committed?
💡 Pro Tip: Capacity planning is most powerful when connected to the sales pipeline. Configure the requirement in Project Operations for all Opportunities above a threshold deal size to have resource estimates attached. Resource Managers can then see the capacity pressure of the pipeline before deals are won — enabling proactive hiring decisions rather than reactive scrambling after a deal is signed.
D365 Project Operations provides a dedicated Time and Expense mobile application for iOS and Android — purpose-built for consultants who need to capture time and expenses on the go rather than at a desktop.
Time entry on mobile: Weekly grid view (same structure as desktop — project, task, role, hours per day). Copy previous week (quick-fill for consultants with recurring project allocations). Quick create (tap a project, enter hours — minimal steps). Offline mode (enter time without WiFi — syncs automatically when connectivity restored).
Expense entry on mobile: Camera receipt capture (point camera at receipt — AI extracts amount, merchant, date, currency). GPS mileage tracking (automatic distance calculation for car travel). Per diem entry (daily allowance claim — no receipt required). Multiple currency support (expenses in foreign currency auto-converted at today's rate).
Approval notifications: Managers receive push notifications for pending time and expense approvals. Can approve directly from the notification or within the app — without opening a browser.
App features by platform: iOS and Android parity for core features. Biometric login (Face ID / fingerprint) for quick and secure access. Dark mode supported.
Time entry on mobile: Weekly grid view (same structure as desktop — project, task, role, hours per day). Copy previous week (quick-fill for consultants with recurring project allocations). Quick create (tap a project, enter hours — minimal steps). Offline mode (enter time without WiFi — syncs automatically when connectivity restored).
Expense entry on mobile: Camera receipt capture (point camera at receipt — AI extracts amount, merchant, date, currency). GPS mileage tracking (automatic distance calculation for car travel). Per diem entry (daily allowance claim — no receipt required). Multiple currency support (expenses in foreign currency auto-converted at today's rate).
Approval notifications: Managers receive push notifications for pending time and expense approvals. Can approve directly from the notification or within the app — without opening a browser.
App features by platform: iOS and Android parity for core features. Biometric login (Face ID / fingerprint) for quick and secure access. Dark mode supported.
💡 Pro Tip: Receipt scanning is one of the most appreciated features for traveling consultants — it eliminates the paper receipt collection and manual entry process. Demo it live in training: scan a receipt in front of the audience and show the auto-populated expense fields. The collective reaction is usually "we needed this 5 years ago." This demo moment significantly accelerates mobile app adoption.
Transaction Categories (also called Project Categories) in D365 Project Operations classify project transactions — determining how they appear on invoices, which G/L accounts they post to, and how they are reported.
Transaction category types: Hour (labour): e.g., Consulting, Project Management, Development, Testing, Training. Expense: e.g., Travel, Accommodation, Software, Hardware. Fee: e.g., Licence Fee, Professional Fee (a non-time, non-expense charge). Item (for stocked/production-order deployments): physical goods consumed on the project.
Transaction categories on invoices: Each invoice line shows the transaction category — giving the client visibility into what they are paying for. A detailed invoice might show: 40 hours Consulting at £800/day = £32,000. 20 hours Project Management at £600/day = £12,000. Travel expenses = £3,500. Total: £47,500.
G/L mapping: Each transaction category maps to a Revenue G/L account (for billable sales) and a Cost G/L account (for cost actuals) in D365 Finance. This enables P&L reporting by service line — consulting revenue vs. project management revenue vs. expense recovery.
Transaction category types: Hour (labour): e.g., Consulting, Project Management, Development, Testing, Training. Expense: e.g., Travel, Accommodation, Software, Hardware. Fee: e.g., Licence Fee, Professional Fee (a non-time, non-expense charge). Item (for stocked/production-order deployments): physical goods consumed on the project.
Transaction categories on invoices: Each invoice line shows the transaction category — giving the client visibility into what they are paying for. A detailed invoice might show: 40 hours Consulting at £800/day = £32,000. 20 hours Project Management at £600/day = £12,000. Travel expenses = £3,500. Total: £47,500.
G/L mapping: Each transaction category maps to a Revenue G/L account (for billable sales) and a Cost G/L account (for cost actuals) in D365 Finance. This enables P&L reporting by service line — consulting revenue vs. project management revenue vs. expense recovery.
💡 Pro Tip: Transaction category design requires Finance team input. The categories must align with both: the client's invoicing preferences (what level of detail do they want on invoices?) and the Finance team's reporting structure (which revenue and cost accounts in the CoA are needed for the P&L?). Run a joint Finance + Operations workshop to agree categories before any configuration.
D365 Finance has its own project accounting module, and D365 Project Operations is a separate but integrated application. Understanding the distinction prevents scoping confusion:
D365 Finance Project Accounting (legacy / standalone): Used by organisations that manage projects through the Finance module directly — project creation, hour journals, invoice proposals — all within D365 Finance. Suitable for: manufacturing companies tracking project costs, government-funded projects, internal capital projects. User interface: Finance forms — less user-friendly for PMs and consultants. Project planning: Very basic — no WBS, no scheduling, no resource management.
D365 Project Operations (modern): Purpose-built for professional services project management. Modern UI with WBS scheduler, resource management, Sales integration. Integrates WITH D365 Finance for accounting posting — but the project management activities happen in Project Operations (Dataverse), not Finance. Recommended for: consulting firms, IT services, engineering, managed services.
Co-existence: Some organisations use both — Finance Project Accounting for internal capital projects (building a factory, developing internal software) and Project Operations for client-facing service delivery. They coexist in the same environment but are configured separately.
D365 Finance Project Accounting (legacy / standalone): Used by organisations that manage projects through the Finance module directly — project creation, hour journals, invoice proposals — all within D365 Finance. Suitable for: manufacturing companies tracking project costs, government-funded projects, internal capital projects. User interface: Finance forms — less user-friendly for PMs and consultants. Project planning: Very basic — no WBS, no scheduling, no resource management.
D365 Project Operations (modern): Purpose-built for professional services project management. Modern UI with WBS scheduler, resource management, Sales integration. Integrates WITH D365 Finance for accounting posting — but the project management activities happen in Project Operations (Dataverse), not Finance. Recommended for: consulting firms, IT services, engineering, managed services.
Co-existence: Some organisations use both — Finance Project Accounting for internal capital projects (building a factory, developing internal software) and Project Operations for client-facing service delivery. They coexist in the same environment but are configured separately.
💡 Pro Tip: When a client says "we already use D365 Finance project accounting," investigate carefully before assuming they mean Project Operations. Many Finance implementations include the basic Finance Project module for internal cost tracking — but that is very different from Project Operations' full professional services capability. A quick question: "Can your PMs create WBS tasks and book resources in D365 today?" will clarify which system they actually have.
Microsoft is progressively embedding Copilot and AI capabilities into D365 Project Operations — reducing administrative overhead for project managers and improving decision-making quality.
Current Copilot capabilities in Project Operations:
Task planning assistant: PM describes the project type and deliverables in natural language. Copilot suggests a WBS structure with typical tasks, durations, and dependencies. PM reviews, modifies, and publishes. Reduces WBS creation time from hours to minutes for standard project types.
Project status report generation: Copilot reads the current project state (actuals vs budget, milestone status, risk log, team updates) and generates a draft project status report. PM reviews and sends to stakeholders — avoiding manual report writing.
Resource recommendation: When a generic resource requirement is created (e.g., "Senior D365 Consultant for 3 months"), Copilot scans the available resources and recommends the best matches based on: skill match score, current availability, past project performance ratings, location preference.
Risk identification (early access): Copilot analyses project progress patterns and highlights emerging risks: "This project's cost performance index has dropped 3 weeks in a row — there may be a scope creep issue."
Current Copilot capabilities in Project Operations:
Task planning assistant: PM describes the project type and deliverables in natural language. Copilot suggests a WBS structure with typical tasks, durations, and dependencies. PM reviews, modifies, and publishes. Reduces WBS creation time from hours to minutes for standard project types.
Project status report generation: Copilot reads the current project state (actuals vs budget, milestone status, risk log, team updates) and generates a draft project status report. PM reviews and sends to stakeholders — avoiding manual report writing.
Resource recommendation: When a generic resource requirement is created (e.g., "Senior D365 Consultant for 3 months"), Copilot scans the available resources and recommends the best matches based on: skill match score, current availability, past project performance ratings, location preference.
Risk identification (early access): Copilot analyses project progress patterns and highlights emerging risks: "This project's cost performance index has dropped 3 weeks in a row — there may be a scope creep issue."
💡 Pro Tip: The WBS generation from Copilot is the most immediately useful AI feature for Project Operations users. Position it as a "first draft" generator — the PM still owns the plan and must review it, but starting from a 60% complete WBS is far faster than starting from scratch. In UAT, have PMs test Copilot WBS generation on a real project type they deliver regularly — the quality of the output will immediately show the current state of the AI capability.
A phased implementation approach for D365 Project Operations reduces risk by delivering value incrementally — avoiding the complexity of going live with all features simultaneously:
Phase 1 — Core Delivery (Weeks 1-12): Project creation from template. WBS task management. Time and expense entry and approval. Resource booking and assignment. Basic project financial reporting (actuals vs budget). Go-live outcome: Consultants log time in D365 instead of spreadsheets. PMs track project progress digitally.
Phase 2 — Billing and Finance (Weeks 10-20, overlapping): Project contract and billing setup. Invoice proposal, review, and confirmation. D365 Finance integration (posting, revenue recognition). Go-live outcome: Project invoices generated from D365 and posted to Finance. Revenue leakage reduced.
Phase 3 — Resource Management (Weeks 18-26): Resource Requirements and Schedule Board. Capacity planning. Utilisation reporting. Go-live outcome: Resource Manager can manage demand vs supply in D365.
Phase 4 — Advanced Analytics and AI (Months 7+): Power BI advanced reports. Copilot WBS generation. Predictive resource demand. Go-live outcome: Data-driven decision making across the practice.
Phase 1 — Core Delivery (Weeks 1-12): Project creation from template. WBS task management. Time and expense entry and approval. Resource booking and assignment. Basic project financial reporting (actuals vs budget). Go-live outcome: Consultants log time in D365 instead of spreadsheets. PMs track project progress digitally.
Phase 2 — Billing and Finance (Weeks 10-20, overlapping): Project contract and billing setup. Invoice proposal, review, and confirmation. D365 Finance integration (posting, revenue recognition). Go-live outcome: Project invoices generated from D365 and posted to Finance. Revenue leakage reduced.
Phase 3 — Resource Management (Weeks 18-26): Resource Requirements and Schedule Board. Capacity planning. Utilisation reporting. Go-live outcome: Resource Manager can manage demand vs supply in D365.
Phase 4 — Advanced Analytics and AI (Months 7+): Power BI advanced reports. Copilot WBS generation. Predictive resource demand. Go-live outcome: Data-driven decision making across the practice.
💡 Pro Tip: Phase 1 (time submission) and Phase 2 (billing) should always be deployed together or in tight sequence (within 4-6 weeks). Deploying time submission without billing means consultants log time but finance cannot invoice it — creating a backlog of unreviewed actuals. The value of Phase 1 is only realised when Phase 2 billing follows quickly. Avoid a 6-month gap between phases.
Questions 61–70 of 75
The Project Budget in D365 Project Operations establishes the approved spending limits for a project — providing the baseline against which actual costs are tracked and variance is measured.
Project Budget components: Cost budget: Total approved internal cost for project delivery. Revenue budget: Contracted revenue from the client (the invoice value). Margin: Revenue budget minus Cost budget.
Budget lines: Each budget can be broken down by: Transaction category (Labour, Travel, Software), Role (Senior Consultant, PM, Developer), Time period (month, quarter), Project phase or task.
Budget creation: Option 1: Auto-generated from the project WBS (estimated hours × cost rates + estimated expenses). Option 2: Manual entry by the Finance team. Option 3: Imported from the Project Quote lines (the quote becomes the budget on contract win).
Budget control: D365 can be configured to warn or block transactions that would exceed the project budget. Warning only: PM sees an alert when actuals approach budget but can continue. Hard stop: Transactions cannot be posted once budget is exceeded — requires Finance Manager override.
Project Budget components: Cost budget: Total approved internal cost for project delivery. Revenue budget: Contracted revenue from the client (the invoice value). Margin: Revenue budget minus Cost budget.
Budget lines: Each budget can be broken down by: Transaction category (Labour, Travel, Software), Role (Senior Consultant, PM, Developer), Time period (month, quarter), Project phase or task.
Budget creation: Option 1: Auto-generated from the project WBS (estimated hours × cost rates + estimated expenses). Option 2: Manual entry by the Finance team. Option 3: Imported from the Project Quote lines (the quote becomes the budget on contract win).
Budget control: D365 can be configured to warn or block transactions that would exceed the project budget. Warning only: PM sees an alert when actuals approach budget but can continue. Hard stop: Transactions cannot be posted once budget is exceeded — requires Finance Manager override.
💡 Pro Tip: The most common budget management question: "Should we set a hard stop when the budget is exceeded?" The answer depends on culture: Fixed-price firms with tight margin control prefer hard stops. T&M firms often prefer warnings only (since costs above the NTE are still legitimate internal costs, just unbillable). Define the budget control policy in requirements — it is a financial governance decision that requires CFO sign-off.
Pricing Dimensions in D365 Project Operations are the attributes used to look up the correct billing rate and cost rate for a transaction — determining price based on combinations of resource attributes.
Default pricing dimensions: Role (e.g., Senior Consultant — determines the base rate). Organisation Unit (e.g., India OU vs UK OU — same role, different rates in different locations). These two dimensions are the standard default: a Senior Consultant from the UK OU has a different rate from a Senior Consultant from the India OU.
Custom pricing dimensions: Additional dimensions can be added to create more granular pricing. Examples: Resource Category (Partner, Director, Manager, Consultant — within each Role). Delivery Location (on-site vs. remote — on-site rates may be higher). Seniority Level (years of experience). Certification level (CPA, PMP certified commands a premium).
Configuration: Project Operations Settings → Pricing Dimensions. Add new dimension. Define whether it applies to Cost, Sales, or both. Map it to an entity field (Role is the msdyn_bookableresourcecategory field; custom dimensions require custom fields).
Default pricing dimensions: Role (e.g., Senior Consultant — determines the base rate). Organisation Unit (e.g., India OU vs UK OU — same role, different rates in different locations). These two dimensions are the standard default: a Senior Consultant from the UK OU has a different rate from a Senior Consultant from the India OU.
Custom pricing dimensions: Additional dimensions can be added to create more granular pricing. Examples: Resource Category (Partner, Director, Manager, Consultant — within each Role). Delivery Location (on-site vs. remote — on-site rates may be higher). Seniority Level (years of experience). Certification level (CPA, PMP certified commands a premium).
Configuration: Project Operations Settings → Pricing Dimensions. Add new dimension. Define whether it applies to Cost, Sales, or both. Map it to an entity field (Role is the msdyn_bookableresourcecategory field; custom dimensions require custom fields).
💡 Pro Tip: Custom pricing dimensions should be added before any price lists are created — adding a new dimension after price lists exist requires updating every price list entry. As a rule of thumb: if 5 or fewer pricing dimensions cover 95% of your billing scenarios, stick with the defaults. Every additional dimension multiplies the price list maintenance effort — a 3-dimensional price list with 10 values each requires 1,000 price list entries to be complete.
Time entry validation rules in D365 Project Operations enforce business policies on time submission — ensuring time entries are accurate, complete, and compliant with company policy before they reach the approval workflow.
Built-in validations: Cannot submit time for a project you are not a team member of. Cannot enter more than 24 hours on a single day (system limit). Cannot submit time for dates outside the project start and end date. Cannot retroactively submit time for locked periods (once Finance has closed a period).
Custom validations (via Business Rules or Power Automate): Cannot submit time with blank External Description on billable entries (invoice-ready description required). Cannot submit more than 10 hours on a single day without an overtime reason code. Cannot submit time against a task that is marked as Completed (100% done). Mileage expense requires a start and end location. Entertainment expense requires a Business Purpose and client name.
Approval-level validation: Approvers can add custom checks: Time entries on Fixed Price contracts flagged if total hours exceed the original estimate by >10%. Expense entries above £500 require receipt attachment (validated before approval is allowed).
Built-in validations: Cannot submit time for a project you are not a team member of. Cannot enter more than 24 hours on a single day (system limit). Cannot submit time for dates outside the project start and end date. Cannot retroactively submit time for locked periods (once Finance has closed a period).
Custom validations (via Business Rules or Power Automate): Cannot submit time with blank External Description on billable entries (invoice-ready description required). Cannot submit more than 10 hours on a single day without an overtime reason code. Cannot submit time against a task that is marked as Completed (100% done). Mileage expense requires a start and end location. Entertainment expense requires a Business Purpose and client name.
Approval-level validation: Approvers can add custom checks: Time entries on Fixed Price contracts flagged if total hours exceed the original estimate by >10%. Expense entries above £500 require receipt attachment (validated before approval is allowed).
💡 Pro Tip: Do not over-engineer validation rules. Every validation adds friction for consultants submitting time. Each validation rule must be justified: "What incorrect time entry problem does this rule prevent? How often does that problem occur? Is the cost of the friction worth the reduction in errors?" The answer often reveals that 2-3 validations solve 80% of the data quality problems — and that 20 validations cause so much friction that adoption suffers.
D365 Project Operations reporting is served from multiple layers — choosing the right layer for each report requirement is important for performance and accuracy:
Layer 1 — In-app views and dashboards (real-time, basic): Project record views (WBS, team, actuals). System dashboards (Project Manager, Resource Manager). Quick filters and personal views. Best for: day-to-day operational monitoring. Limitations: cannot cross-join multiple entities, limited chart types.
Layer 2 — Power BI template apps (near real-time, pre-built): Project Operations Power BI template app (Finance, Resource, PM reports). Reads from Dataverse via DirectQuery or scheduled import. Best for: management dashboards, pre-built KPI views. Refresh: up to 15 minutes behind real-time.
Layer 3 — Custom Power BI (most flexible, highest effort): Custom reports reading from Dataverse directly. Can combine Project Operations data with HR data, Finance data, CRM data. Best for: portfolio P&L, multi-entity reports, advanced analytics. Requires: Dataverse connector setup, data modelling, DAX expertise.
Layer 4 — Azure Synapse / Fabric (enterprise analytics): Export Dataverse data to Azure Synapse or Fabric for large-scale analytics. Best for: organisations with a data warehouse. Enables cross-system analytics at volume.
Layer 1 — In-app views and dashboards (real-time, basic): Project record views (WBS, team, actuals). System dashboards (Project Manager, Resource Manager). Quick filters and personal views. Best for: day-to-day operational monitoring. Limitations: cannot cross-join multiple entities, limited chart types.
Layer 2 — Power BI template apps (near real-time, pre-built): Project Operations Power BI template app (Finance, Resource, PM reports). Reads from Dataverse via DirectQuery or scheduled import. Best for: management dashboards, pre-built KPI views. Refresh: up to 15 minutes behind real-time.
Layer 3 — Custom Power BI (most flexible, highest effort): Custom reports reading from Dataverse directly. Can combine Project Operations data with HR data, Finance data, CRM data. Best for: portfolio P&L, multi-entity reports, advanced analytics. Requires: Dataverse connector setup, data modelling, DAX expertise.
Layer 4 — Azure Synapse / Fabric (enterprise analytics): Export Dataverse data to Azure Synapse or Fabric for large-scale analytics. Best for: organisations with a data warehouse. Enables cross-system analytics at volume.
💡 Pro Tip: Always match the reporting layer to the reporting requirement. "What is the EAC of my project today?" → Layer 1 (in-app). "What is our firm's billable utilisation this month?" → Layer 2 (Power BI template). "What is our 3-year revenue forecast by practice?" → Layer 3 (custom Power BI). Attempting to build strategic analytics in Layer 1 or operational lookups in Layer 4 wastes effort and underdelivers.
Many professional services firms use project management tools like Jira, Azure DevOps, or Monday.com alongside D365 Project Operations — creating integration requirements to avoid double-entry and maintain a single source of truth.
Common integration scenarios:
Jira ↔ Project Operations: IT consulting firms track delivery tasks in Jira (developer-friendly) but financial management (billing, invoicing) in Project Operations. The integration syncs: Jira issues as Project Operations tasks (WBS items). Jira time logs as Project Operations time entries (eliminating double-entry for developers). Project status from Jira back to Project Operations project health.
Azure DevOps ↔ Project Operations: Similar to Jira — development work items in Azure DevOps, financial management in Project Operations. Microsoft provides native connectors via Power Automate for Azure DevOps.
Monday.com / Smartsheet ↔ Project Operations: Operational teams prefer these tools for task management. Time entries from Monday are pushed to Project Operations for billing. Project budgets are pulled from Project Operations into Monday for PM visibility.
Integration architecture options: Power Automate (low-code, suitable for simple bi-directional sync). Azure Logic Apps (enterprise integration, more complex flows). Middleware platforms (MuleSoft, Boomi — for complex, high-volume integration).
Common integration scenarios:
Jira ↔ Project Operations: IT consulting firms track delivery tasks in Jira (developer-friendly) but financial management (billing, invoicing) in Project Operations. The integration syncs: Jira issues as Project Operations tasks (WBS items). Jira time logs as Project Operations time entries (eliminating double-entry for developers). Project status from Jira back to Project Operations project health.
Azure DevOps ↔ Project Operations: Similar to Jira — development work items in Azure DevOps, financial management in Project Operations. Microsoft provides native connectors via Power Automate for Azure DevOps.
Monday.com / Smartsheet ↔ Project Operations: Operational teams prefer these tools for task management. Time entries from Monday are pushed to Project Operations for billing. Project budgets are pulled from Project Operations into Monday for PM visibility.
Integration architecture options: Power Automate (low-code, suitable for simple bi-directional sync). Azure Logic Apps (enterprise integration, more complex flows). Middleware platforms (MuleSoft, Boomi — for complex, high-volume integration).
💡 Pro Tip: The Jira integration for time entry elimination is the highest-ROI Project Operations integration for IT consulting firms. Developers who already log time in Jira will not log it again in D365 — so billing relies on manual timesheet entry that is inevitably incomplete. Connecting Jira time logs to Project Operations via Power Automate eliminates the double-entry problem and improves time submission compliance from 70% to nearly 100%.
A Credit Note (also called a corrective invoice) in D365 Project Operations reverses all or part of a previously confirmed invoice — used when billing errors are discovered, when work was disputed by the client, or when a credit was agreed.
Scenarios requiring a credit note: Wrong billing rate used on an invoice. Duplicate invoice sent for the same period. Client disputes a specific time entry or expense. Goodwill credit given to a dissatisfied client. Contract amendment reduces the invoice value retroactively.
Credit note process in D365 Project Operations:
1. Billing Manager opens the confirmed invoice that needs correction.
2. Select "Create Corrective Invoice" — this creates a new Credit Note document linked to the original invoice.
3. The Credit Note shows the original billed lines as negative amounts (reversals).
4. If a partial credit is needed, adjust the quantity or amount on specific lines.
5. Confirm the Credit Note → It posts to D365 Finance as a negative customer invoice (reducing the outstanding AR balance).
6. The original invoice's actuals are reversed and the credit note actuals are created — maintaining accurate WIP and billed revenue records.
Scenarios requiring a credit note: Wrong billing rate used on an invoice. Duplicate invoice sent for the same period. Client disputes a specific time entry or expense. Goodwill credit given to a dissatisfied client. Contract amendment reduces the invoice value retroactively.
Credit note process in D365 Project Operations:
1. Billing Manager opens the confirmed invoice that needs correction.
2. Select "Create Corrective Invoice" — this creates a new Credit Note document linked to the original invoice.
3. The Credit Note shows the original billed lines as negative amounts (reversals).
4. If a partial credit is needed, adjust the quantity or amount on specific lines.
5. Confirm the Credit Note → It posts to D365 Finance as a negative customer invoice (reducing the outstanding AR balance).
6. The original invoice's actuals are reversed and the credit note actuals are created — maintaining accurate WIP and billed revenue records.
💡 Pro Tip: Credit notes are often processed hastily to satisfy angry clients — and frequently result in incorrect financial postings if not done carefully. Always verify that the Credit Note has correctly reversed the specific billed actuals before confirming. A confirmed credit note that does not reverse the correct actuals will leave the WIP and revenue recognition records in an incorrect state that is difficult to remediate.
Key configuration best practices that prevent common go-live failures in Project Operations implementations:
1. Configure Project Parameters first: All billing, scheduling, and approval settings are governed by Project Parameters. Wrong parameter settings affect every project created after go-live. Review and sign off Project Parameters in a dedicated workshop before any projects are created in production.
2. Create Price Lists before Projects: Projects must have a Cost and Sales price list assigned at creation. If price lists are not ready, projects are created without rates — all actuals post at zero cost and zero revenue. Build price lists first.
3. Test the complete financial flow before go-live: Run 5 end-to-end test scenarios covering all contract types (T&M, Fixed Price, Retainer). Each test: create project, book resource, submit time, approve time, create invoice, confirm invoice, verify Finance posting. Do not go live until all 5 scenarios pass without error.
4. Set up approval workflows before users go live: If approvers are not configured before time submission begins, time entries queue up without being processed — creating a billing backlog on day 1.
5. Archive or remove inactive resources: Test environments have resources from testing that should not exist in production. Clean up the resource list before go-live — old resources get accidentally added to projects and cause confusion.
1. Configure Project Parameters first: All billing, scheduling, and approval settings are governed by Project Parameters. Wrong parameter settings affect every project created after go-live. Review and sign off Project Parameters in a dedicated workshop before any projects are created in production.
2. Create Price Lists before Projects: Projects must have a Cost and Sales price list assigned at creation. If price lists are not ready, projects are created without rates — all actuals post at zero cost and zero revenue. Build price lists first.
3. Test the complete financial flow before go-live: Run 5 end-to-end test scenarios covering all contract types (T&M, Fixed Price, Retainer). Each test: create project, book resource, submit time, approve time, create invoice, confirm invoice, verify Finance posting. Do not go live until all 5 scenarios pass without error.
4. Set up approval workflows before users go live: If approvers are not configured before time submission begins, time entries queue up without being processed — creating a billing backlog on day 1.
5. Archive or remove inactive resources: Test environments have resources from testing that should not exist in production. Clean up the resource list before go-live — old resources get accidentally added to projects and cause confusion.
💡 Pro Tip: The most common go-live blocker in Project Operations: the first real invoice cannot be confirmed because a required G/L posting account is missing in D365 Finance. This is always discovered on the day the first invoice is due — not in UAT. Add "Invoice confirmation to Finance posting" as a mandatory UAT test case. Run it at least 3 times with different contract types. It's the most important test in the entire UAT cycle.
Work in Progress (WIP) accounting in D365 Project Operations tracks the financial value of work that has been performed but not yet invoiced or revenue-recognised — a critical balance sheet item for professional services firms under accrual accounting.
WIP arises when: Time and expenses are approved (work performed) but the invoice has not yet been issued to the client. Under Fixed Price contracts, work is done but the milestone invoice has not been triggered. Under T&M contracts, work is done in the current period but the monthly invoice cut-off has not occurred yet.
WIP on the Balance Sheet: WIP is an asset (Unbilled Revenue / Accrued Revenue). It represents future cash that will be received when the invoice is issued. At period close, WIP is calculated and posted to the Balance Sheet. When the invoice is issued, WIP is reversed and Accounts Receivable is debited.
D365 Project Operations WIP calculation: WIP = Billable Cost (cost of work performed, billable, not yet invoiced). The WIP amount appears in the Project Financial Summary and in D365 Finance period-end reports. WIP reports are critical for: Finance team period-close, auditors verifying revenue, management tracking unbilled revenue pipeline.
WIP arises when: Time and expenses are approved (work performed) but the invoice has not yet been issued to the client. Under Fixed Price contracts, work is done but the milestone invoice has not been triggered. Under T&M contracts, work is done in the current period but the monthly invoice cut-off has not occurred yet.
WIP on the Balance Sheet: WIP is an asset (Unbilled Revenue / Accrued Revenue). It represents future cash that will be received when the invoice is issued. At period close, WIP is calculated and posted to the Balance Sheet. When the invoice is issued, WIP is reversed and Accounts Receivable is debited.
D365 Project Operations WIP calculation: WIP = Billable Cost (cost of work performed, billable, not yet invoiced). The WIP amount appears in the Project Financial Summary and in D365 Finance period-end reports. WIP reports are critical for: Finance team period-close, auditors verifying revenue, management tracking unbilled revenue pipeline.
💡 Pro Tip: WIP accuracy depends on two things: timely time submission (work performed must be logged promptly) and correct billability classification (non-billable work incorrectly marked as billable inflates WIP). Run a WIP accuracy check at the end of the first month post-go-live: compare the D365 WIP report with what the finance team estimates the WIP should be. Any material difference must be investigated before the second month-end.
The Expense Policy in D365 Project Operations defines the rules and limits governing how project expenses should be submitted and approved — enforcing company travel and expense policies systematically.
Expense policy components: Per diem rates: Daily allowance amounts for meals, accommodation, and incidentals by country and city tier. Category limits: Maximum amount per expense category (e.g., Hotel maximum Rs.8,000/night; Business meal maximum Rs.3,000/person). Receipt requirements: Threshold above which a receipt is mandatory (e.g., all expenses above Rs.500 require receipt). Prohibited categories: Expenses that are never reimbursable (mini-bar charges, personal entertainment). Justification requirements: Business purpose required for client entertainment and travel above certain amounts.
Approval workflow for expenses: Standard expenses: PM approves (same as time). Above a threshold (e.g., Rs.25,000 for a single expense): PM + Finance Manager approval. International travel expenses: Requires pre-approval before travel (separate workflow).
Policy violation handling: D365 can flag expense entries that violate policy (hotel above daily limit) with a warning. The approver sees the violation and must explicitly acknowledge it. Finance can run a "Policy Violations Report" monthly to identify systematic policy breaches.
Expense policy components: Per diem rates: Daily allowance amounts for meals, accommodation, and incidentals by country and city tier. Category limits: Maximum amount per expense category (e.g., Hotel maximum Rs.8,000/night; Business meal maximum Rs.3,000/person). Receipt requirements: Threshold above which a receipt is mandatory (e.g., all expenses above Rs.500 require receipt). Prohibited categories: Expenses that are never reimbursable (mini-bar charges, personal entertainment). Justification requirements: Business purpose required for client entertainment and travel above certain amounts.
Approval workflow for expenses: Standard expenses: PM approves (same as time). Above a threshold (e.g., Rs.25,000 for a single expense): PM + Finance Manager approval. International travel expenses: Requires pre-approval before travel (separate workflow).
Policy violation handling: D365 can flag expense entries that violate policy (hotel above daily limit) with a warning. The approver sees the violation and must explicitly acknowledge it. Finance can run a "Policy Violations Report" monthly to identify systematic policy breaches.
💡 Pro Tip: Expense policy configuration is most effective when it mirrors the actual company expense policy document precisely. Obtain the current expense policy before configuration and map each policy rule to a D365 configuration setting. Any rule in the policy document that cannot be enforced in D365 must be documented as a manual control — and the Finance team must acknowledge they will check it manually.
The Project Status Report in D365 Project Operations is a structured summary of project health that PMs use to communicate progress to clients and internal stakeholders — generated directly from live project data.
Status Report components: Overall RAG status (Red/Amber/Green). Schedule performance (SPI, milestone status). Cost performance (CPI, budget vs actual, EAC). Key accomplishments since last report (milestones completed, deliverables signed off). Issues and risks (current open items with status). Next steps and planned activities (upcoming milestones and key activities). Decisions required from the client (escalations needing client action).
D365 Project Operations Status Report generation: PM opens the project → Reports tab → Create Status Report. The form pre-populates with the current project metrics (SPI, CPI, EAC from live data). PM adds the narrative sections (accomplishments, issues, next steps). Status Report is saved as a record linked to the project (full history of all status reports). Report can be exported to Word or PDF for client sharing.
Copilot assistance: Copilot can draft the narrative sections of the Status Report based on project data — recent task completions, current risks, recent actuals. PM reviews and finalises the draft.
Status Report components: Overall RAG status (Red/Amber/Green). Schedule performance (SPI, milestone status). Cost performance (CPI, budget vs actual, EAC). Key accomplishments since last report (milestones completed, deliverables signed off). Issues and risks (current open items with status). Next steps and planned activities (upcoming milestones and key activities). Decisions required from the client (escalations needing client action).
D365 Project Operations Status Report generation: PM opens the project → Reports tab → Create Status Report. The form pre-populates with the current project metrics (SPI, CPI, EAC from live data). PM adds the narrative sections (accomplishments, issues, next steps). Status Report is saved as a record linked to the project (full history of all status reports). Report can be exported to Word or PDF for client sharing.
Copilot assistance: Copilot can draft the narrative sections of the Status Report based on project data — recent task completions, current risks, recent actuals. PM reviews and finalises the draft.
💡 Pro Tip: Status report frequency should be agreed in the contract and then enforced in D365 with a Power Automate reminder: "Project Status Report not submitted in 14 days — reminder sent to PM." Many project overruns are first visible in status reports that PMs delay submitting. Consistent, timely status reports are the earliest warning system for at-risk projects.
Questions 71–75 of 75
Skills Management in D365 Project Operations enables organisations to define, track, and search the capability profile of each resource — supporting skills-based resource matching to project requirements.
Skill management components: Skills: A defined library of technical and functional capabilities. Examples: D365 Sales Configuration, Power Automate, SAP FI, PRINCE2, PMP, Python, Agile Scrum Master. Proficiency Models: Define proficiency levels for skills. Example: 1 = Aware (basic knowledge), 2 = Familiar (has used in training), 3 = Proficient (delivered a project with this skill), 4 = Expert (trained others in this skill). Resource skill assignments: Each resource gets skills with proficiency levels — maintained by the Resource Manager or HR team. Certification tracking: Certificates with expiry dates (e.g., PMP certification expires every 3 years) can be attached to resource profiles.
Skill-based resource matching: When creating a generic resource requirement on a project, the PM specifies required skills and minimum proficiency levels. The Schedule Board filters resources to show only those who meet the skill criteria. Resources are ranked by skill match score — the closest match appears at the top.
Skill management components: Skills: A defined library of technical and functional capabilities. Examples: D365 Sales Configuration, Power Automate, SAP FI, PRINCE2, PMP, Python, Agile Scrum Master. Proficiency Models: Define proficiency levels for skills. Example: 1 = Aware (basic knowledge), 2 = Familiar (has used in training), 3 = Proficient (delivered a project with this skill), 4 = Expert (trained others in this skill). Resource skill assignments: Each resource gets skills with proficiency levels — maintained by the Resource Manager or HR team. Certification tracking: Certificates with expiry dates (e.g., PMP certification expires every 3 years) can be attached to resource profiles.
Skill-based resource matching: When creating a generic resource requirement on a project, the PM specifies required skills and minimum proficiency levels. The Schedule Board filters resources to show only those who meet the skill criteria. Resources are ranked by skill match score — the closest match appears at the top.
💡 Pro Tip: Skills data quality determines the value of skills-based matching. If resource profiles are not kept current, the system recommends resources based on outdated skills. Establish a quarterly "Skill Profile Review" process: each resource reviews their own skill profile, updates it, and a manager confirms the accuracy. Embed this in the performance review cycle — it only takes 15 minutes per person and dramatically improves resource recommendation quality.
Defining the right KPIs for a professional services firm using D365 Project Operations transforms the system from a time-tracking tool into a strategic management platform:
Financial KPIs: Gross Margin % per project: (Billed Revenue - Cost) / Billed Revenue. Target: typically 30-50% for consulting. Revenue per head: Total billed revenue / number of billable headcount. Billable utilisation %: Billable hours / available hours. Target: 70-80%. Days Sales Outstanding (DSO): Average days from invoice issue to payment receipt. Revenue leakage: Value of unbilled actuals at month-end as % of total billable actuals.
Operational KPIs: On-time delivery rate: % of projects delivered on or before planned completion date. On-budget delivery rate: % of projects where final cost did not exceed budget by more than 10%. Time submission compliance: % of time submitted by the weekly deadline. Project health distribution: % of projects Red / Amber / Green across the portfolio.
Client KPIs: Project CSAT: Post-project satisfaction score. Net Revenue Retention: Revenue from existing clients vs. prior year. Repeat client rate: % of revenue from clients who have used the firm before.
Financial KPIs: Gross Margin % per project: (Billed Revenue - Cost) / Billed Revenue. Target: typically 30-50% for consulting. Revenue per head: Total billed revenue / number of billable headcount. Billable utilisation %: Billable hours / available hours. Target: 70-80%. Days Sales Outstanding (DSO): Average days from invoice issue to payment receipt. Revenue leakage: Value of unbilled actuals at month-end as % of total billable actuals.
Operational KPIs: On-time delivery rate: % of projects delivered on or before planned completion date. On-budget delivery rate: % of projects where final cost did not exceed budget by more than 10%. Time submission compliance: % of time submitted by the weekly deadline. Project health distribution: % of projects Red / Amber / Green across the portfolio.
Client KPIs: Project CSAT: Post-project satisfaction score. Net Revenue Retention: Revenue from existing clients vs. prior year. Repeat client rate: % of revenue from clients who have used the firm before.
💡 Pro Tip: Billable utilisation is the most important operational KPI for any professional services firm — it is the primary driver of revenue and profitability. However, it must be paired with Gross Margin % — 85% utilisation at negative margin is worse than 70% utilisation at 40% margin. Build both KPIs into the management dashboard and train practice leaders to monitor both together, not in isolation.
A realistic implementation timeline and team structure for D365 Project Operations, based on a mid-sized professional services firm (50-200 billable staff):
Typical implementation timeline (Resource/Non-Stocked deployment): Weeks 1-3: Discovery and solution design (workshops, requirements documentation). Weeks 4-7: Foundation configuration (Org Units, Price Lists, Project Parameters, Expense Categories, Security Roles). Weeks 5-10: Project management features (WBS, Templates, Resource Management, Schedule Board). Weeks 8-14: Financial integration (D365 Finance posting setup, Invoice process, Revenue Recognition). Weeks 12-16: Reporting (Power BI deployment, custom views, dashboards). Weeks 14-18: UAT and training. Week 18: Go-live. Total: 18-22 weeks for a standard mid-complexity implementation.
Required team composition: D365 Project Operations Functional Consultant (1-2). D365 Finance Functional Consultant (1 — mandatory for billing integration). Power Platform Developer (0.5 — for custom flows and Power BI). Project Manager (0.5 from the implementation partner). Client-side: Executive Sponsor, PMO Lead, Finance Controller, Resource Manager, Super User representatives (2-3 PMs).
Typical implementation timeline (Resource/Non-Stocked deployment): Weeks 1-3: Discovery and solution design (workshops, requirements documentation). Weeks 4-7: Foundation configuration (Org Units, Price Lists, Project Parameters, Expense Categories, Security Roles). Weeks 5-10: Project management features (WBS, Templates, Resource Management, Schedule Board). Weeks 8-14: Financial integration (D365 Finance posting setup, Invoice process, Revenue Recognition). Weeks 12-16: Reporting (Power BI deployment, custom views, dashboards). Weeks 14-18: UAT and training. Week 18: Go-live. Total: 18-22 weeks for a standard mid-complexity implementation.
Required team composition: D365 Project Operations Functional Consultant (1-2). D365 Finance Functional Consultant (1 — mandatory for billing integration). Power Platform Developer (0.5 — for custom flows and Power BI). Project Manager (0.5 from the implementation partner). Client-side: Executive Sponsor, PMO Lead, Finance Controller, Resource Manager, Super User representatives (2-3 PMs).
💡 Pro Tip: The D365 Finance consultant is non-negotiable for Resource/Non-Stocked implementations. Many firms try to resource the Project Operations implementation without a Finance consultant to save cost — and pay 3x the cost when the Finance integration fails at go-live and needs emergency remediation. The Finance configuration (posting profiles, revenue recognition, period close process) is a specialised skill that the Project Operations consultant typically does not have.
A Client Project Portal built on Microsoft Power Pages extends D365 Project Operations with an external-facing web portal — giving clients real-time visibility into their projects without requiring a D365 licence.
Client Portal capabilities: Project status dashboard: Client logs in and sees overall project health (RAG status, schedule, budget). Milestone tracker: Current milestone status and upcoming delivery dates. Invoice and payment history: Client can download approved invoices and see payment status. Document library: Access to project deliverables, meeting minutes, signed approvals (linked from SharePoint). Risk and issue log: Client visibility into open risks and issues with mitigation actions. Resource roster: Who is working on their project, in which roles.
Authentication: Client contacts are invited via Azure AD B2C. Clients log in with their email — no Microsoft licence required. Role-based access ensures clients only see their own projects.
Configuration: Power Pages site connected to Dataverse (Project Operations entities). Table permissions define which tables and records clients can read. Custom forms and views designed for client consumption — not the internal PM view.
Client Portal capabilities: Project status dashboard: Client logs in and sees overall project health (RAG status, schedule, budget). Milestone tracker: Current milestone status and upcoming delivery dates. Invoice and payment history: Client can download approved invoices and see payment status. Document library: Access to project deliverables, meeting minutes, signed approvals (linked from SharePoint). Risk and issue log: Client visibility into open risks and issues with mitigation actions. Resource roster: Who is working on their project, in which roles.
Authentication: Client contacts are invited via Azure AD B2C. Clients log in with their email — no Microsoft licence required. Role-based access ensures clients only see their own projects.
Configuration: Power Pages site connected to Dataverse (Project Operations entities). Table permissions define which tables and records clients can read. Custom forms and views designed for client consumption — not the internal PM view.
💡 Pro Tip: A client portal transforms the transparency of a consulting engagement and is a strong differentiator against competitors who share project status via email spreadsheets. When proposing the client portal, frame it as a premium service offering: "Our clients always have real-time visibility into their project health, not just weekly status calls." This resonates with procurement and governance-focused clients and can be a competitive differentiator that wins deals.
Preparing for a D365 Project Operations functional consultant interview requires demonstrating both platform knowledge and professional services domain expertise:
Platform knowledge questions you will likely face: "Walk me through the Lead to Invoice flow in D365 Project Operations." "What is the difference between a Booking and an Assignment? How does Reconciliation work?" "How does D365 Project Operations integrate with D365 Finance?" "Explain the difference between T&M, Fixed Price, and Retainer billing — and when would you recommend each." "What is revenue recognition and how does D365 support IFRS 15?" "What is the role of Organisation Units in pricing?"
Business and requirements questions: "A consulting firm has 200 consultants across 3 countries. How would you approach the resource management requirements?" "A client's invoice is disputed — what is the process in D365 Project Operations to issue a credit note?" "How would you design the Pricing Dimensions for a firm that bills different rates for on-site vs remote work?"
Process and methodology questions: "How long would a typical Project Operations implementation take and what team would you need?" "What are the most common go-live failures you have seen and how do you mitigate them?"
Platform knowledge questions you will likely face: "Walk me through the Lead to Invoice flow in D365 Project Operations." "What is the difference between a Booking and an Assignment? How does Reconciliation work?" "How does D365 Project Operations integrate with D365 Finance?" "Explain the difference between T&M, Fixed Price, and Retainer billing — and when would you recommend each." "What is revenue recognition and how does D365 support IFRS 15?" "What is the role of Organisation Units in pricing?"
Business and requirements questions: "A consulting firm has 200 consultants across 3 countries. How would you approach the resource management requirements?" "A client's invoice is disputed — what is the process in D365 Project Operations to issue a credit note?" "How would you design the Pricing Dimensions for a firm that bills different rates for on-site vs remote work?"
Process and methodology questions: "How long would a typical Project Operations implementation take and what team would you need?" "What are the most common go-live failures you have seen and how do you mitigate them?"
💡 Pro Tip: The most differentiating answer in a Project Operations interview is demonstrating understanding of BOTH the delivery side (WBS, resources, time tracking) AND the financial side (actuals, invoicing, revenue recognition, Finance integration). Most candidates know one side well. Interviewers are looking for someone who can run the full end-to-end workshop from Opportunity through to Invoice — that combination of skills is what drives the highest consulting day rates in the Project Operations market.
Page 1 of 8