How to Calculate Net Multiplier for an Engineering or Architecture Firm

Net multiplier is your net revenue divided by your direct labor cost. Most healthy architecture and engineering firms land between 2.75 and 3.25, with 3.0 as the conventional target. If you're below 2.75, you are either underpricing your work or over-servicing it — and the fix is different depending on which.

That's the whole answer. The rest of this post is about the two things that make firms get it wrong: what counts as "net revenue," and why 3.0 is a target at all.

I've been an MEP engineer for fifteen years, most of it at firms in the 10-to-100-person range, and I now run one. I've watched otherwise sharp principals track this number wrong for years and make hiring decisions on the strength of it. So it's worth being precise.

The formula

Net Multiplier = Net Revenue ÷ Direct Labor

Two terms, both of which get fumbled.

Net revenue (sometimes "net service revenue" or NSR) is your total revenue minus consultant and subconsultant pass-throughs, and minus reimbursable expenses. It's the money you earn for your own people's work.

Direct labor is the raw salary cost of hours charged directly to projects. Raw, not burdened. No overhead, no fringe, no multiplier baked in. If an engineer's salary works out to $58/hour and she charges 20 hours to a project, that project absorbed $1,160 of direct labor.

A worked example

A mechanical scope on a mid-size institutional project:

$150,000 ÷ $52,200 = 2.87

The pass-through problem

Run that same project with the subconsultant left in.

$180,000 ÷ $52,200 = 3.45

That's the trap. A 3.45 looks like a firm operating comfortably above target. The real number is 2.87 — likely below break-even depending on the firm's overhead. Same project, same performance, and the difference between "we're doing great" and "we lost money on this" is entirely whether you netted out a pass-through.

Sometimes this is a chart-of-accounts problem: consultant fees get booked to a revenue account rather than a pass-through account and nobody has revisited the setup since the day it was built. But in my experience that's the less common cause.

To be fair to the principals I've watched get this wrong — and to myself — it usually isn't self-deception. It's that the data isn't there.

At my own firm we weren't fooling ourselves about pass-throughs. We simply had no clean way to see how much our consultants were spending against each project in anything close to real time. Without that, you can't reliably net it out, and net revenue becomes an estimate you true up at some indefinite later date. Add hand-calculated multipliers on top of that, and "later" means closeout. We learned that our multipliers were bad on several projects well after the point where we could do anything about it.

That last part is the real cost, and it's not the one people talk about.

Measure it in-flight, not at closeout

A bad multiplier at closeout is a post-mortem. A bad multiplier at 40% design completion is evidence.

If you can see that a project is consuming materially more of your team than the fee assumed — and you can see it while the project is still open — you have a documented basis for an additional services request. That's a different conversation than the one you have after the fact. You're not asking a client to cover a budget you already blew; you're showing them that scope grew past what was priced, with the hours to prove it.

That was the shift for us. We stopped treating net multiplier as an accounting output and started treating it as an early-warning signal that tells us when to go ask for more money. The metric didn't change. The timing did, and the timing is where the money is.

Why 3.0? Because of your overhead rate

Here's the thing most explainers skip: 3.0 isn't a magic number handed down by the AIA. It's a derived one.

Break-even Multiplier = 1.0 + Overhead Rate

Your overhead rate is total indirect expenses divided by direct labor. Rent, admin salaries, software, insurance, business development, non-billable time — everything that isn't direct project labor. For A/E firms this typically runs somewhere in the 1.4 to 1.8 range.

So if your overhead rate is 1.65:

• Break-even multiplier = 2.65
• At 2.87, your profit on net revenue is (2.87 − 2.65) ÷ 2.87 = 7.7%
• To hit a 15% profit margin, you'd need a multiplier of about 3.12

That's where 3.0 comes from. It's roughly "typical overhead rate plus a defensible profit margin." Which means the target is firm-specific. A lean firm with a 1.35 overhead rate is genuinely profitable at 2.7. A firm carrying 1.85 is bleeding at 2.9 and doesn't know it.

If you take one thing from this post: calculate your own break-even multiplier before you benchmark yourself against anyone else's target.

Target multiplier vs. what you actually realize

There's a second gap worth naming. The multiplier built into your published billing rates — call it the target multiplier — is usually 3.0 to 3.2. The multiplier you realize is always lower, because of:

• Hours written off as unbillable
• Fixed-fee scopes that ran long
• Discounted rates for a favored client
• Unbilled time nobody logged in the first place

A firm billing at a 3.1 target and realizing 2.6 has a 16% leak. That leak is not a pricing problem. It's a scope and process problem, and raising your rates won't fix it.

What to do if your multiplier is low

Three levers, in the order most firms should pull them:

1. Scope discipline. The cheapest fix. Most low multipliers are unpriced scope creep — extra design iterations, RFI volume from incomplete documents, "quick" client requests that consume a week. This is a change-order and documentation problem before it's anything else.

2. Staffing mix. If senior staff are doing work a mid-level engineer could do, your direct labor cost per deliverable is inflated and your multiplier compresses. Look at who is actually charging hours to your largest projects.

3. Rates. Real, but slowest and most constrained by your market. And worth noting: raising rates on a firm with a leaky realization problem just raises the size of the leak.