A discovery framework for project accounting where public evidence is thin

How to establish whether project accounting is in scope at all for a QAD estate, and how to design the D365 target when the source behaviour must come from a tenant rather than from documentation.

What you will be able to do

Introduction

This module is shorter than most on this path, and the reason is worth stating rather than disguising.

Establishing scope honestly

Does the estate run a project module today? If yes, the scope question is answered and the discovery package below applies. If no, continue.

Recognising project-shaped work

Automotive and regulated manufacturing estates carry several patterns that look like projects without being called projects.

The discovery package, if scope is confirmed

Where project accounting is genuinely in scope, the evidence required mirrors the finance and posting discovery packages, because project accounting is a subledger with its own account determination.

Choosing the target capability

Project accounting within the ERP provides projects, work breakdown structures, project types, cost and revenue categories, budgets with control, work in progress, billing and revenue recognition.

Migrating open projects

Where projects exist and are in flight at cutover, the migration follows the same discipline as production work in progress.

Where this leaves the domain

If project accounting is in scope, the target design is well documented and the constraint is source evidence — which puts this domain in exactly the same position as finance and posting, and it should be discovered alongside them rather than separately.

Knowledge check

Summary

The source material for this path contains no project-accounting entries, so this module gives target-side design knowledge and a discovery framework rather than a source mapping that would have to be invented.