Project Profitability Dashboards: What Is Included in the Number?

Before commissioning a project profitability dashboard, define what its result includes. A report that compares sales with only some recorded costs can look reassuring while leaving important work outside the calculation. Ask for an explainable management view, not a green number without a basis.

This guide is about software requirements for internal project reporting. It does not define statutory profit, accounting recognition, payroll cost or tax treatment. Have the responsible financial adviser approve the calculation policy and labels.

Write the report's promise first

State what question the report should answer. Are you comparing the current plan with its expected costs, reviewing recorded performance to date, or looking only at invoiced transactions? These can all be useful views, but they are not interchangeable.

Write a short definition beside the proposed result: included revenue, included cost categories, reporting period, currency basis and update time. If your first version excludes overhead or outstanding supplier commitments, say so visibly. Do not call a limited contribution view the business's final profit without an approved definition.

Odoo 19's project profitability documentation describes comparing project revenue with resource costs, including employee costs, materials, purchases and expenses. It distinguishes expected amounts, amounts awaiting invoicing or billing, and invoiced or billed amounts. This is a product-specific example of reporting stages, not a universal accounting policy.

Map every contributing record to the project

For each included category, identify the source system and the event that makes a record eligible. A project selected on a time entry may provide a clear link. A supplier invoice covering several projects needs an explicit allocation rule instead of being counted in full against each one.

Odoo says records must be linked to the project and its analytic account to appear on its profitability dashboard. The general commissioning lesson is to test missing relationships: a record can exist elsewhere in the business and still be absent from a project report.

Ask for a review list of eligible but unassigned records where the system can identify them. Define who resolves that list. A blank association should not quietly mean “no cost,” and records whose project cannot be determined should not be assigned by guesswork.

Keep billing rates separate from internal cost

For staff time, specify the approved internal costing basis separately from the customer charge. A fixed-price project may have no relationship between the selling price and each hour's billing rate. Do not use a customer rate as an employee cost merely because both fields are labelled “hourly.”

Agree which version of a rate applies and what a later change does to earlier work. Keep sensitive cost inputs restricted to the people permitted to see them. The project manager may need a reviewed total without receiving every person's underlying employment details.

These are requirements for your project, not legal definitions or claims that the cited platform implements every privacy and historical-rate control described here.

Do not add stages as though they were separate income

A transaction may move from expected to delivered to invoiced. Define whether columns show separate balances or successive views of the same activity. Do not sum a sale and its resulting invoice into two independent revenues unless the approved model genuinely calls for separate items.

The same issue arises when a purchase order later becomes a supplier bill, or when a reimbursed expense has both a cost side and a customer-charge side. Specify record identity and allocation so the report can explain why each amount appears. Showing an entry on both the revenue and cost sides can be legitimate; counting the same cost twice is a different problem.

Keep cash collection outside the promise unless payment data is actually included and reconciled. An invoiced amount does not establish that money has arrived.

Demonstrate an incomplete project, not only a tidy one

Use fictional records in your acceptance criteria. Include an unassigned supplier cost, a shared cost split between projects, staff work with an internal cost basis and a transaction that advances to invoiced status.

The report should expose its included records, explain stage movement without unintended duplication and show the agreed treatment of missing allocations. Test a late cost and a corrected historical rate under the approved policy. Confirm that restricted users cannot retrieve sensitive detail through exports or drill-down views.

For a project-reporting app discussion, bring a blank example of the management report and define what decision follows a disappointing result. Start with a report the team can reconcile before requesting automatic forecasts.

Questions before development

Is this a cash-flow report?

Not unless payment timing and actual receipts or payments are explicitly included. A project revenue-and-cost view answers a different question.

Should every cost be included in the first version?

Include what the agreed decision requires and make exclusions visible. A narrower honest report is more useful than a supposedly complete one with unknown coverage.

Does a positive result prove the project is finished profitably?

No. It describes the chosen records and policy at a particular time. Missing or later costs and unresolved work remain relevant.