We Thought We Made 55% Margin. The Real Saldo Was 18%.

There’s a project I think about more than I’d like to admit. It was 2023, I was CTO of an agency of about 50 people at the time, and we’d just wrapped up a six-month engagement for a mid-cap retailer. The brief was a digital-products platform. We’d estimated it at £100k. We invoiced £148k after change orders. On the Friday we closed it out, the project lead sent the kind of email you remember:

Lovely client, healthy invoice, 55% labour margin. Filing it under “wins”.

It bothered me. Not because I doubted his maths — he’d done what every PM does, which is take the invoice, subtract the costed hours from the timesheet system at role rate, and divide. The number came out clean. It bothered me because I had a quiet, persistent feeling that we’d worked harder on that project than 55% should feel like.

So I asked our finance lead to redo the calculation. Not roughly. Not on the back of an envelope. Honestly, with everything in.

A week later she came back with the answer. The real saldo, she wrote, was eighteen percent.

How a 55% labour margin became 18% real saldo in five days of recomputation

Let me lay out what changed, because each line of it has surfaced in every agency I’ve worked with since. None of it was unique. None of it was malicious. None of it was the kind of thing a single tool catches.

The starting point was the labour-margin number on the spreadsheet: revenue £148k, labour costed at role rate £67k, so labour margin (£148k − £67k) ÷ £148k = 54.7%. That is the figure the project lead was emailing about. It is the figure agency post-mortems start with — and the figure they should never end at.

Senior covering junior — £16k of invisible cost. We’d estimated the project at one Lead Dev day a week and four mid-developer days a week. What actually happened — a thing every PM has watched happen — is that the Lead Dev quietly took on tickets the mids couldn’t crack quickly enough. He didn’t escalate. He didn’t re-quote. He just did the work because shipping mattered. By the end, his time on the project was double what we’d costed for, and four mid-developers’ time was correspondingly under. Same hours billed at the role rate. Different cost on the cost side, because the lead’s real hourly cost is materially higher than a mid’s. Costed against named individuals at real cost, the labour total moved from £67k to £83k. £16,000 of margin we’d never had.

Unbilled scope and support folded into delivery — £8.7k given away. Two undocumented change requests, a nightly reconciliation job that “wasn’t in the original spec but obviously you need it”, and four weeks of post-launch support that ran past the two weeks of warranty we’d quoted. Each one was the kind of thing where the answer is, of course, yes we’ll do it, and the question of whether to re-paper the SOW gets pushed to the next call. From the project’s spreadsheet view it looked like part of delivery cost. From the agency’s P&L view it was a separate, longer engagement we hadn’t priced. Roughly thirty engineering days plus forty-five hours of senior post-launch time, all unbilled.

Overhead allocation — £29k we’d been pretending didn’t exist. This was the big one. Until that year I, like every founder I knew, had been thinking about margin in labour-only terms. Project revenue minus project hours times hourly cost equals “margin”. Done.

But of course nothing only costs labour. We had an office. We had account managers and ops staff and a finance lead and a junior we’d hired three months earlier who hadn’t billed an hour yet. We had software. We had a marketing budget. We had me, sitting in calls with the client, costed at zero in the project’s spreadsheet because I was technically a fixed cost.

The proper accounting move — and I learned this the hard way — is to take the agency’s monthly overhead and pro-rate it across projects according to the share of the month’s revenue each project represents. Our overhead at the time was around £180k a month against a target turnover of £600k. So overhead was running at roughly 30% of revenue. The “good” project — that £148k of invoice over six months — had to absorb its share. About £29k of it. Our 50-person agency had a 30% overhead drag we’d been hiding from ourselves on every project we celebrated.

When you add those three lines back in, labour at real cost (£83k) plus unbilled scope (£8.7k) plus allocated overhead (£29k) gave a true cost of £120.7k. The £148k revenue carried £27.3k of saldo. Eighteen percent. Not fifty-five.

Why it matters that the number is eighteen, not just “less than fifty-five”

A 30%+ real-saldo project, in our world, is one we lean into. We staff it with the senior team. We pitch a follow-on. We use it as a reference. We bonus the salesperson at the rate we bonus the wins.

An 18% real-saldo project — like this one — is something different. It’s a project we run carefully. We watch the scope like hawks. We don’t put the most expensive people on it unless we have to. We absolutely do not bonus the salesperson at the win rate, because at single-digit-pts above the long-run threshold where overhead growth catches up, the project is paying its way and not much more.

The point of the exercise wasn’t shame. The point was that we had been making capacity decisions, hiring decisions, sales-incentive decisions on the basis of a margin number that was off by a factor of three. And every other agency I have talked to since has been working with a gap of similar size.

What changed — and what didn’t

I’d love to say the answer was sophisticated. It wasn’t. We didn’t buy enterprise software. We didn’t roll out a balanced scorecard. We didn’t hire a CFO.

We did three things, and all three of them have run unchanged for two years now.

One: estimating moved from “hours” to “role × hours”. Every estimate now lists, by line, which role will do how many hours at which rate. Not a single line says “Engineering: 40 hours” any more. It says “Lead Dev: 6 hours at £190, Mid Dev: 28 hours at £130, QA: 8 hours at £95”. The client sees a single price; we see the composition.

Two: actual cost is calculated from worklogs against employee hourly cost — not against the role rate. Every developer in our system has a real, fully-loaded hourly cost number: salary plus employer’s NI plus pension plus a rough share of laptop and tooling, divided by working hours. When a worklog comes in from Jira, we cost it at the employee’s number, not the role’s. The variance between what we sold the role at and what the actual person cost us to do it is, exactly, where margin moves.

Three: every project carries an overhead allocation, every month. It’s a single number, computed automatically: take that month’s overhead, pro-rate by share of revenue, drop it onto the project’s cost side. The project’s “real saldo” is what survives. The number on the project page is no longer the labour margin. It’s the saldo. There’s no other number on the page to confuse it with.

The things that don’t help

A few things I’ve watched other agencies try, that I don’t think work:

• Pushing engineers to log “more accurately”. Engineers log fine. The problem isn’t logging. It’s that nobody costs the logs honestly afterwards.
• Buying a Jira plugin that adds a “cost” field. We had one of those. It only knew about labour. It didn’t know about overhead. It didn’t know that role rate ≠ employee cost. It produced numbers that were wrong in exactly the same direction as our spreadsheet had been wrong.
• Asking the team to “be more disciplined about scope”. The team is disciplined about scope. The problem is that the cost of saying yes to a small extra is invisible until someone makes it visible. Discipline arrives the day the number on the project page goes red.

The honest version of “we made margin”

Two years on, the agency is at 120 people. Every project runs through the internal layer that grew out of that 2023 post-mortem — I ended up calling it Saldo, because saldo is the bookkeeping word for the actual balance left after every entry has been recorded honestly, which felt like the right name for the only number we now look at. It is now a standalone product — but it started life as an internal CTO tool.

When someone tells me a project came in at 55% labour margin, the first thing I ask, half-joking, half-not, is: “Sure, but what’s the saldo?” Most weeks they know. Some weeks the answer is let me check, and that’s when we usually learn something.

If you’re reading this and thinking your own number might be off in the same direction — it almost certainly is. Not because anyone is doing anything wrong, but because the labour-margin frame is too narrow, and most agency tooling is still wired into it.

You don’t need our software to fix it. You need a finance person, a Friday afternoon, and a willingness to recompute one project honestly, line by line, the way our finance lead recomputed ours. Pick the project the team is proudest of. That’s where the gap will be biggest.

If you do want our software — well, we built it because Friday afternoons get expensive when you’re running forty active projects at once. That’s what Saldo is. The 15-minute demo is on your real Jira; we don’t ask for card details up front, and we don’t follow up if it doesn’t land.

Either way: stop looking at the invoice number and calling it the margin. The invoice is what the client paid. The saldo is what’s left.

Those are not the same number, and the gap between them is where every agency I know lives.