Xero Project Profitability Reports: Why You Can't Get a P&L by Project (And What To Do Instead)

8 Jul 2026

6 mins read

Xero Project Profitability Reports: Why You Can't Get a P&L by Project (And What To Do Instead)

So much data and yet nobody can say which client is quietly losing money.

Jarvin Ong

Ask an agency owner which of their twelve current projects is losing money and you'll usually get a confident answer. Ask them to prove it from Xero, and the room goes quiet.

The Xero project profitability report — a proper P&L per project, with real staff costs, allocated overheads, and revenue recognised against work delivered — is one of the most-searched, most-assumed features in the product. Everyone expects it to be in there somewhere. It isn't. What's in there is a collection of partial answers, and the gaps between them are where project margins go to hide.

This post walks through what Xero actually gives you, where each option stops, and what a project profitability setup that holds up actually looks like.

What Xero gives you natively

There are two native routes, and they don't talk to each other properly.

Xero Projects is the add-on module: time tracking, task estimates, expenses assigned to projects, and a Project Details report with a Profitability dashboard. For a freelancer or a small studio billing time and materials, it's genuinely usable.

But its version of "profitability" is narrow. Staff costs come from a manually entered cost rate per person — not from payroll, so the moment salaries change or someone forgets to update a rate, every margin figure is fiction. Overheads don't exist: rent, software, insurance, and the ops manager's salary sit in the P&L, unallocated, making every project look more profitable than it is. And Projects data lives in its own reporting silo — it doesn't flow into the main P&L, so you can't reconcile "profit per the Projects dashboard" with "profit per the accounts". At month-end, those two numbers will disagree and you'll be the one explaining why.

Tracking categories are the other route: dedicate one of your two tracking slots to "Project" and tag every invoice line, bill, and journal. Now the real P&L can be filtered by project, which is a genuine improvement — the numbers tie to the ledger by construction.

Then the limits arrive. You've burned one of two tracking slots on projects (we've written about the two-limit problem before — this is its most common casualty). Xero caps tracking options, so if you run dozens of jobs a year, closed projects have to be archived to make room, taking historical comparability with them. Payroll still doesn't split by project unless someone journals hours across jobs by hand every month. And a P&L filtered by project is still just revenue minus tagged costs — no percent-complete, no WIP, no view of whether a fixed-fee job is burning hours faster than it's earning fee.

The three numbers that never make it into the report

Whichever route you take, the same three ingredients are missing, and they're precisely the ones that decide whether a project made money.

True labour cost. The biggest cost line in any services business is people, and it's the least likely to be correct per project. Timesheets live in Projects (or Harvest, or Float), salaries live in payroll, and the mapping between them — loaded cost rates, employer taxes, leave, non-billable time — lives nowhere. Most firms either use stale cost rates or blended guesses.

Overhead allocation. A project that "makes" 40% margin before overheads may be underwater after them. Allocating shared costs — by headcount hours, by revenue share, by whatever policy you choose — is a derived calculation Xero has no mechanism for, in either module.

Revenue that matches the work. On fixed-fee and milestone projects, invoicing schedules and delivery schedules diverge constantly. Invoice 50% upfront and the project P&L looks wildly profitable in month one and terrible in month three. Meaningful project profitability needs revenue recognised on percent-complete or milestones — with the unbilled portion sitting in WIP — and that's a spreadsheet exercise in every Xero shop we've met. It's the same class of problem as SaaS deferred revenue: the ledger records billing events, not the underlying delivery.

The workarounds, and where they crack

Most firms land in one of three places. The Projects-module camp accepts the silo and keeps a mental adjustment for "the dashboard says 35% but really it's more like 20%". The tracking-category camp gets ledger-true numbers but spends month-end journaling payroll splits and rebuilding WIP in Excel. And the biggest camp of all exports everything and maintains The Spreadsheet — timesheet data joined to payroll joined to the general ledger, one tab per project, held together by VLOOKUPs and the one person who understands it.

All three work, in the sense that a number comes out. None of them survive contact with growth: more projects, more staff, a second entity, or the departure of the spreadsheet's author.

What good looks like

A project profitability report worth trusting is built outside Xero's native reports, from joined sources:

  • Revenue from the ledger, tagged by project (tracking category or invoice metadata), recognised on percent-complete where fees are fixed — with WIP and deferred income falling out of the same logic
  • Labour costs from timesheets × loaded cost rates that reconcile back to actual payroll, not manually keyed estimates
  • Overheads allocated on a stated policy, consistently, every month
  • The whole thing tied back to the P&L, so project profits sum to firm profit and nobody has to explain a mystery gap

None of this is exotic accounting. It's joining data Xero already holds (or that sits one system away) and encoding the logic once — the same shape as building proper management accounts from Xero, just sliced by job instead of by month. The Xero API exposes everything needed — invoices, bills, journals, tracking, contacts — though there are pitfalls worth knowing before you build on it directly.

Where Cheetah fits

Project profitability is one of the most common reports we're asked to build — usually by an agency, consultancy, or project-based firm that has outgrown the Projects dashboard but isn't about to migrate to a heavyweight professional services automation tool. We pull the ledger, timesheets, and payroll together, encode your recognition and allocation policy, and produce a per-project P&L that ties to the accounts and refreshes without anyone touching a spreadsheet.

If your month-end includes reverse-engineering which jobs actually made money, Cheetah is worth a look.

The short version

Xero can tell you what you invoiced a project and what you tagged to it. It cannot tell you what the project cost in people, what share of overheads it carried, or whether the fee was earned yet — and those are the three things "profitability" means. The data exists. The report doesn't. Building the layer between them is a solvable problem, and far cheaper than pricing next year's work off margins nobody actually measured.

Jarvin
Written by
Jarvin Ong

A finance professional turned product builder, Jarvin has built hundreds of reports by hand and knows what financial and operational reporting demands: customisability, auditability, scalability, and security. Having automated that work reliably, he's now helping advisory firms and finance teams do the same.

Ready to Hunt at Cheetah Speed?

Stop prowling through generic solutions.
Let us show you a better way to hunt.