Decide whether project accounting in the Acumatica estate is operational or analytical, map projects, tasks and account groups onto the D365 project hierarchy and categories, and choose deliberately between the project module, dimensions and Project Operations.
Projects is the module where the most important question is architectural rather than functional: should there be a project subledger at all?
The last row is the diagnostic. If the honest answer is that projects exist because the subaccount could not carry a capital scheme, a grant, a cost initiative or a client engagement code, then the requirement is analytical and the target answer is a financial dimension.
Where the module is in scope, the structural mapping has three source objects and more than three target homes.
The target classifies project cost by transaction type, and each type has its own journal, its own posting setup and its own reporting:
Where projects are billed, the target introduces structure the source may not have needed.
Where project delivery is a genuine business capability, a further choice arises: the finance-side project module alone, or a Project Operations deployment that adds opportunity-to-cash, resourcing, scheduling and project management on Dataverse with integration back to the finance and operations side.
The validation set for this path names project balances if in scope as a reconciliation item. What that means in practice depends on the project types.
Project scope is a discovery finding. The concept mapping rates the project translation medium confidence and scopes it to project-enabled tenants. Whether project accounting is used at all, and how, is a tenant fact.
The first project decision is whether to have a project subledger. Acumatica project accounting is sometimes an operational capability with delivery, billing and revenue recognition attached, and sometimes a way of slicing the ledger that grew because the subaccount could not carry it.