Tracking recurring revenue in a project-based firm

You track recurring revenue in a project-based firm by separating income into two streams — recurring (retainers, support plans, licences) and one-off project work — and reporting each with its own metric. Blending them into a single revenue line hides the one number that determines whether next quarter starts at zero. The mechanism is a tag at the point a deal is won, plus a monthly movements report.

Why does a project firm need an MRR number at all?

Because project revenue resets. Every month a pure project firm starts from nothing and sells its way back to payroll, and that treadmill is why so many capable firms feel permanently fragile. Recurring revenue is the floor under the month — the portion of income that arrives without a new sale being made.

The number worth watching is coverage: recurring revenue as a share of fixed monthly costs. When coverage is low, every quiet sales month is a cash problem. When recurring income covers most of the overhead, project wins become upside rather than survival. That coverage figure belongs on the management dashboard — it is one of the handful of numbers The MD Dashboard Blueprint argues an MD should see without anyone compiling anything.

What counts as recurring, and what doesn't?

The honest rule: revenue counts as recurring when it is contracted, or on a rolling agreement, and expected to repeat without a new sales conversation. Everything else is project revenue, however reliable it feels.

The common self-deception is promoting a friendly repeat client into the recurring column. Repeat business is valuable, but it still requires a sale each time; counting it as recurring flatters the floor and hides the fragility the metric exists to expose.

How do you build the tracking mechanism?

When a deal is marked won, it is tagged either recurring or project — one required field, no exceptions. When the tag is recurring, three more fields are captured: monthly value, start date, and review or end date. When a retainer later changes, the change is logged as an event — expansion, contraction, or churn — with a date and a value, rather than silently overwriting the record. When the month closes, MRR is the sum of active monthly values, and the movements report writes itself from the events.

This only works if deal records reflect reality, which is a data-entry problem before it is a reporting problem — the same problem solved by getting meeting notes into the CRM without typing. A recurring tag applied weeks late, or never, produces an MRR figure that drifts from the truth in both directions.

What do you report each month?

Five lines, the same shape SaaS companies use, because the shape is right:

• Opening MRR
• New (retainers won)
• Expansion (existing retainers increased)
• Contraction (retainers reduced)
• Churn (retainers ended)
• Closing MRR, and coverage against fixed costs

That is the whole report. The movements matter more than the total: a flat MRR line built from strong new business and equally strong churn is a very different firm from one holding steady with no movement. Resist the urge to add a dozen supporting metrics around it — too many KPIs is the same as none.

Where do firms get this wrong?

Four recurring mistakes, in rough order of damage. Counting project deposits or phased invoicing as recurring — instalments on a one-off build are still one-off revenue. Dividing annual contracts by twelve without recording the renewal date, so a third of the "floor" quietly expires in the same quarter. Failing to log churn the month it happens, which overstates MRR until someone notices the invoices stopped. And letting the recurring work itself be priced by the hour, which caps the very margin the retainer exists to protect — the argument I make in why hourly automation billing is a trap applies to most recurring service work.

Fix the tag, log the movements, watch coverage. A project-based firm that grows its recurring floor is buying itself the one thing project work never provides: a month that does not start at zero.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.