Team Bonuses from Project Profit: How to Calculate Them

Team bonuses tied to project profit are a powerful tool: people start counting not just their own hours but the result, and they work like co-owners. But that same tool easily turns into a source of losses if you calculate the bonus the wrong way — from revenue instead of from real profit. Then the agency pays bonuses even on loss-making projects and wonders why there's plenty of motivation but no money.

Let's break down what to base bonuses on, how much to set aside and when to pay, so that motivation works for profit rather than against it.

Why revenue-based bonuses are a mistake

The most common mistake is calculating the bonus from the contract amount. A 300,000 project sounds impressive, and the team expects a bonus off that figure. But after contractors, the team's hours and overhead, those 300 might leave you 30,000 in profit — or nothing at all. If the bonus comes off revenue, you're paying it out of money you don't have, and a loss-making project becomes even more of a loss. A bonus should only come from what you actually earned.

What to base the bonus on: real project profit

The right base for a bonus is project profit: client payments minus all direct costs on it (the team's hours in money, contractors, services). This is exactly the figure that shows what the project truly brought in, and it's exactly what's fair to share with the team. How to calculate project profitability without the usual mistakes is covered in Project profitability: how to calculate it right. Without this accounting, a bonus system is built on sand.

How much to set aside: common schemes

A common benchmark is to allocate 10–20% of project profit to the team's bonus pool. That's enough to motivate and safe for the agency, because it's paid out of real earnings. The exact percentage depends on the bonus's role: if it tops up a good salary, it's closer to 10%; if part of the team's income is deliberately shifted into bonuses, it's higher. One rule matters above all: the bonus pool is never larger than the project's profit.

When to pay: after the project closes and is paid

A bonus is best paid not when the work is handed over, but after the project is closed and the client has paid. Otherwise you risk paying a bonus for a project that later "drifts" in revisions, or one the client never settled for. Tying the bonus to money actually received protects you both from a cash gap and from paying out on projects that are effectively loss-making.

Example: bonus from profit vs. bonus from revenue

A 300,000 project. Direct costs (team, contractors) — 250,000, profit — 50,000. A bonus pool of 15% of profit = 7,500 — the team is motivated, the agency is in the black.

Now the same project with a 5%-of-revenue bonus: 5% of 300 = 15,000. But the profit was only 50, so the bonus ate up 30% of everything earned, leaving 35 instead of 50. And if the profit had been 10,000 rather than 50, the revenue-based bonus (15) would have turned the project into a loss. The same generosity, the opposite result — the whole difference is in the calculation base.

Where to start

First learn to see the profit of each project, and only then build bonuses off it rather than off revenue. Start with a simple rule: bonus pool = a fixed percentage of the profit of a closed and paid project. You can check which projects are actually profitable in 15 minutes — as shown here, and Project margin will help you avoid going into the red on an order.

In Finmap, each project's profit is calculated from your transactions automatically, so the bonus pool is easy to compute from the real result rather than from revenue. Try it free for 7 days.