What Project Margin Actually Is, for a Digital Agency

I have a standard question I ask the finance lead at any agency I meet for the first time: "What's your project margin number, on average?" The answers are almost always confident, and almost always wrong by a third.

They're wrong because the number being reported is labour margin, not project margin. Labour margin is what falls out of the timesheet system when you subtract costed hours from invoiced revenue. It is one input to project margin. It is not project margin.

This piece is for finance directors, COOs and agency owners who want a clean definition that survives audit, a worked example that uses real numbers, and a list of the four mistakes we see most often when we sit in on someone else's pricing review for the first time.

Project margin: the definition

Project margin, expressed as a percentage:

Project margin = (Revenue − True cost) / Revenue

Where True cost is the sum of three components, in this order:

1. Labour at real cost. The hours each person logged on the project, multiplied by that person's fully-loaded hourly cost — not by their role rate, not by their billable rate, not by their salary divided by 2,080.
2. Allocated overhead. The share of the agency's monthly fixed costs that the project should absorb during its lifetime, calculated pro-rata to the project's share of monthly revenue, with a minimum-revenue floor in slow months.
3. Unbilled scope. The cost of work delivered to the client without a corresponding line on an invoice — change orders that never got papered, post-launch support folded into delivery, internal management time costed at internal rates.

Each component has a standard mistake associated with it. We'll go through all three.

Component 1: labour at real cost (not at role rate)

The most common mistake we see is using role rate instead of real employee cost on the cost side of the calculation.

Role rate is what you sold the role at. £130/hour for a mid-level developer, £190/hour for a lead, £95/hour for QA. That's the price the client agreed to.

Real employee cost is what each named person on the project actually costs the agency per hour of their time. It is not their salary divided by working hours, although that is the starting point. The fully-loaded hourly cost includes:

• Base salary, before tax
• Employer's National Insurance contributions (UK) or equivalent payroll tax in your jurisdiction
• Pension contribution
• A pro-rata share of laptop, software licences, and per-head office costs
• Holiday and bank-holiday allowance (the salary is for 365 days; the working hours are roughly 220 days)

For a mid-level developer on a £55,000 base salary in the UK, the fully-loaded hourly cost typically lands somewhere between £43 and £52, depending on benefits, location and the share of overhead you bake in. (We bake in only the direct overhead — laptop, licences, payroll tax — and put the rest into the project-level overhead allocation, but agencies vary on this.)

The variance between role rate and real cost is where most of the margin variance lives. If you sold a 200-hour project at the lead role rate (£190/hour, so £38,000) and delivered it with two mids at £45/hour real cost (£18,000), your margin on labour is much wider than the role rate alone suggests. Conversely, if you sold the same project at the lead role rate but a single lead actually delivered it at £85/hour real cost (£17,000), the margin is also wide — but for a different reason.

The mistake agencies make: subtracting role-rate × hours from invoice and calling that labour cost. Role rate is what the client paid for the role. It is not what the role cost you to deliver. The right number is the named person × their real cost × their actual hours.

Component 2: allocated overhead (the line everyone forgets)

The second mistake is forgetting overhead entirely.

Most agencies have a settled monthly overhead figure. For a 50-person agency it's often in the £150–220k range; for a 100-person agency it's often in the £350–500k range. This number represents rent, salaries of non-billable staff (operations, finance, marketing, leadership), software licences not chargeable to a project, marketing spend, and a long tail of small but unavoidable costs.

This number does not allocate itself onto projects automatically. Many agencies simply ignore it at the project level: they look at labour margin per project, subtract overhead from total revenue at the end of the month, and call the residual "agency margin". That's a roll-up. It is not a project view.

The right way: allocate the monthly overhead onto each project pro-rata to that project's share of the agency's revenue that month. If the agency turned over £600k in a given month and a particular project produced £60k of that revenue, the project should absorb 10% of that month's overhead. If overhead ran at £200k that month, the project absorbs £20k of it.

The complication: in slow months, this formula will tell you that an unusually small revenue project absorbed a disproportionate share of overhead. To prevent that distorting things, agencies usually establish a minimum revenue floor — typically the agency's break-even monthly turnover — and use that as the denominator if the actual turnover dropped below it. The overhead each project absorbs in a slow month is therefore the project's share of minimum turnover, not actual.

The mistake agencies make: not allocating overhead at the project level at all, or allocating it at year-end against full-year revenue (which masks slow months entirely). Either approach gives you a project margin number that's roughly 30 percentage points too high at a healthy agency, and significantly worse than that during downturns.

Component 3: unbilled scope (the line nobody wants to look at)

The third mistake is the most uncomfortable one to confront, because it's a direct accounting of work the team gave away.

Three patterns produce unbilled scope:

• Change requests that never got papered. A client asks for a small extra. Someone on the team says "of course we'll do it" because shipping is the priority. The conversation about whether it warrants a change order gets postponed to the next call, and then to the next call, and so on. By the project's end the team has delivered fifteen or twenty days of unbilled work. We've seen this run as high as 12% of the original estimate value on builds where the relationship is friendly and the project lead is generous with their time.

• Post-launch support folded into delivery. The original scope said "two weeks of warranty support included". The actual support ran four to six weeks. The hours during weeks three through six lived inside the same Jira project as the build. They weren't billed; they showed up in your delivery cost.

• Internal management time at zero cost. Founders and account directors who join client calls without their hours being captured anywhere. Easily 20–40 hours per project for a hands-on agency owner. At an internal rate of £150–250 per hour, that's £3–10k per project never costed.

Add these up across forty projects in flight and you have a six-figure annual leak that doesn't appear on any margin report.

The mistake agencies make: treating these as "we just gave that one away" anomalies rather than a category to count and report on. They are a category. They are a recurring category. They are a pricing problem first and a tooling problem second.

A worked example, with real numbers

Take a project we ran (anonymised, scaled to round numbers).

• Estimate: £100k for a six-month build
• Final invoiced revenue: £148k after change orders
• Hours logged in Jira: 2,400 across the team
• Labour cost at role rates: £148k × 0.45 cost-of-revenue ratio ≈ £67k → labour margin = (£148k − £67k) / £148k = 54.7%

That's the number a labour-margin report would show. It's a fiction.

Real figures:

• Labour at real cost (named people × real hourly cost): £83k. Higher than the role-rate calculation because the lead developer's real hours ran higher than the role-rate plan assumed.
• Allocated overhead (project's share of revenue × monthly overhead × six months): £29k. The project produced about 8% of monthly turnover during its lifetime; 8% of £180k overhead × 6 months = £29k allocated.
• Unbilled scope: £8.7k. Two undocumented change requests (30 engineering days at £290/day blended) and four weeks of unbilled post-launch support (£3k of senior time).

True cost: £83k + £29k + £8.7k = £120.7k Real margin: (£148k − £120.7k) / £148k = 18.4%

That's about a third of the labour-margin number. It's not a story we wanted to tell ourselves. It is the truth.

Visualised on the margin-breakdown screen of the layer that became Saldo. Each cost component sits in its own row, each one is sourced from a different part of the data (worklogs at named-person cost, agency overhead pro-rata, scope register), and the labour-margin frame and real-margin frame are reported side-by-side so the gap is visible by inspection.

Two adjacent numbers worth tracking alongside

Project margin is the headline number. Two adjacent numbers, computed from the same data, are useful enough to track in parallel.

Margin contribution per role. For each role on the project (Lead, Senior, Mid, QA, etc.), compute the role's revenue line minus the named individuals' actual cost on that role's hours. The result tells you which roles are reliably profitable on the engagement and which are reliably loss-making. Across forty projects in flight, this number tends to be stable per role-and-project-type combination — useful for next-quarter pricing.

Margin contribution per client. Roll the project margin up by client over a rolling twelve months. The result is the real lifetime profitability of the relationship, not the invoiced revenue. Some clients who feel like the agency's biggest accounts (highest invoice value) come out as middle-tier on real margin; some smaller clients come out as the most profitable. The pricing review that follows this analysis is where most agencies first discover that one or two long-standing accounts are silently unprofitable.

Both of these numbers fall out of the project-margin calculation almost for free, once the project margin is being computed correctly. The work of computing them is roll-up work, not new measurement.

What the right number unlocks

Once project margin is computed correctly and continuously, three things change in how the agency is run:

• Capacity decisions get sharper. Hiring two more developers reads differently when the average project margin is 18% than when it's 55%. The decision to expand becomes a margin-protection decision, not a growth-protection decision.
• Sales incentives stop rewarding bad projects. Bonusing salespeople on invoice value rewards landing big estimates. Bonusing on real margin rewards landing projects that are actually profitable. The first agency we worked with that switched the bonus calculation reported (at the next quarter) that the projects salespeople were bringing in shifted noticeably towards smaller, healthier engagements.
• Pricing reviews stop being theoretical. A pricing review with a real margin number per project type becomes a quantitative exercise: which engagements consistently underperform, what shape they have, and what the price should be next time.

If you want to see the calculation done live on your real Jira data, Saldo is the layer we built to make this continuous. The glossary entry on the term itself explains why we chose the name. The reference customer page shows what the numbers look like at scale across a 120-person agency on this approach for two years.

The shorter version of all of this: invoice minus timesheet is not project margin. Project margin is what's left after every entry has been honestly recorded. Until then, you have a number; you don't have the saldo.