A project status report is usually the first thing a PM opens on a Monday morning, and the thing that makes it useful or useless is the same thing every time: whether budget-to-actual comparison is done at the right level of the project's task/cost-code hierarchy, or flattened into one project-level number that hides exactly where the project is actually bleeding.
Project, task, and cost code — pick your rollup level deliberately
Acumatica's project cost structure nests cost transactions under project tasks, and tasks under the project, with a cost code dimension cutting across both (labor, materials, subcontractor, per task). A status report that only rolls up to the project level tells a PM "we're $40K over" without saying whether that's one task massively over and everything else fine, or a even spread suggesting a systemic estimating problem. Build the report at task level by default, with project-level totals as a group footer, not the other way around — you can always suppress task detail with a parameter for an executive-summary variant, but you can't recover it after the fact if the schema never fetched it.
Base: PMTran (actual cost transactions) JOIN PMTask
Group: ProjectID (outer) -> TaskID (inner)
Sum per task: ActualCost = SUM(PMTran.Amount)
Compare against: PMBudget.Amount for the same ProjectID/TaskID/CostCodeCommitted cost — open POs and unbilled subcontractor work — belongs in the picture
A budget-vs-actual comparison using only posted actual cost understates real exposure the same way an AR aging without unbilled shipments understates credit risk: a task can look comfortably under budget purely because a large subcontractor PO hasn't been invoiced yet. Include committed cost (open purchase order balance tied to the project/task) as a separate column alongside actual, so "budget remaining" reads as budget minus actual minus committed, which is the number that actually predicts whether the task finishes on budget.
Percent-complete can come from a PM's manual estimate on the task, from a cost-based calculation (actual cost / budgeted cost), or from a units-based measure (milestones achieved / milestones planned) depending on the project's billing rule. Cost-based percent-complete looks identical to "we're spending money" even on a task that's genuinely behind schedule but under-spending. State which percent-complete source the report uses in a column header or footnote — this is the number PMs argue about most in status meetings, and half the arguments are actually about which definition each person assumed.
Wrapping up
Build project status at task level with project totals as a rollup, not the reverse, so the report can actually point at where a project is over. Add committed cost from open POs alongside posted actuals, since actuals alone understate exposure the same way an AR report without unbilled shipments does. Be explicit about which percent-complete method the report uses — it's the single most contested number on the page.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.