TL;DR: Revenue leakage in architecture is rarely one big problem. It’s several small ones compounding unnoticed: time that never gets logged, variations delivered before a fee conversation, proposal hours absorbed as overhead, and invoices raised after the fact. This post covers the root causes and explains how the right project management setup makes each gap visible before it becomes a write-off.
Pick a project from the last six months. One that ran roughly on time, the client was reasonably happy, and no invoices were disputed. Now run the actual hours against the budget.
For many practices, that exercise tells a different story. Not a disaster. Just a project that delivered more than it billed: a handful of site visits logged to the wrong stage, a round of revisions absorbed without a conversation, a feasibility call that never hit anyone’s timesheet. Nothing that looks like a mistake. Just a gap between what was done and what was invoiced.
That gap is revenue leakage in architecture. The RIBA Business Benchmarking 2024 report found that profits as a percentage of revenue fell by 2% despite total sector income growing by 13%. Revenue went up; margin did not. That’s a leakage problem as much as a cost problem.
This post covers the five specific points where revenue leaves a practice without an invoice, what makes each one structural rather than accidental, and how project management software addresses the root cause rather than the symptom.
What is revenue leakage in an architecture practice?
Revenue leakage is the gap between work delivered and work billed. In architecture, it accumulates across five points: unlogged time, scope changes absorbed without a fee adjustment, business development hours that never touch a timesheet, delayed invoicing after project milestones, and fee proposals priced on incomplete cost data from previous projects.
Each is small on its own. Together, they can erode margin significantly. Industry research suggests professional services firms bill around 90–95% of the hours they actually deliver, with the remainder absorbed, rounded down, or written off. For a practice billing £600,000 a year, that’s potentially £30,000-£60,000 in unrecovered work annually.
The 2025 RIBA Benchmarking data shows the squeeze is sharpest at the smaller end. Practices with 1–4 staff saw flat revenue and a slight fall in profits. At that scale, even modest leakage recovery has real impact on viability.
Why does time go unlogged in architecture practices?
Time goes unlogged when the friction of recording it exceeds the perceived cost of skipping it. In architecture, three patterns drive this: end-of-week timesheets filled from memory, time misallocated to the wrong RIBA stage, and short tasks like site calls or email clarifications that have no obvious place to land in the system.
The consequences compound. A study by Monograph of architecture and engineering firms found that practices typically lose 15–25% of potential billable time to unlogged hours. For a 10-person practice, that’s a significant volume of delivered work that never appears on an invoice.
The SPI Research 2025 Professional Services Maturity Benchmark puts average billable utilisation across professional services at 66.4%, well below the 75% threshold identified as optimal. Architecture practices aren’t unique here, but the RIBA stage structure creates natural misallocation points when the project code setup doesn’t reflect how work actually runs.
Good time tracking for architects addresses this at the system level. Jobs already open in the platform, stages pre-configured, timers accessible during the task rather than after it. And, critically, a running budget total by stage so project leads can see where they are before the stage is over rather than after.
Scope creep: the leak most practices absorb without a conversation
Scope creep is the most visible form of revenue leakage and, paradoxically, the one practices are most likely to accept without challenge. On a fixed-fee project, every round of client-driven revisions, every change prompted by planning feedback, every Stage 3 tweak after the package was supposedly signed off represents time the practice has agreed to absorb by delivering first and raising the fee question later.
It usually isn’t calculated. It happens because the team doesn’t have real-time visibility on how much of the stage budget is already spent when the new request arrives. The decision to absorb rather than charge gets made implicitly, because nobody pulls up the numbers in time to make the alternative case.
Project management for architects that surfaces budget position before additional work starts changes this dynamic. When a project lead can see that 83% of the Stage 4 fee is already spent before the tender package is issued, the conversation with the client has a factual basis. That’s a structural fix, not a behavioural one.
The business development hours that never hit a timesheet
Proposal writing, initial client meetings, feasibility scoping, internal briefings before a pitch: these have real costs. They take senior staff time, often hours per opportunity. In most practices, none of that time touches a timesheet.
The industry benchmark puts business development at around 5.3% of non-billable overhead hours. What that figure doesn’t capture is how rarely this time gets logged against anything.
We worked with a practice spending upwards of ten hours on a typical fee proposal: design research, site review, meeting time, the draft itself. None of it was recorded against the client or the opportunity. That created two problems. First, the practice had no visibility on the true cost of winning work. Second, every fee proposal was priced without data, because the cost of business development was invisible in the financials. Under-pricing the next project wasn’t a mistake; it was the structural outcome of not tracking the last one.
The fix isn’t necessarily to bill for proposals (though that’s worth considering for complex briefs). It’s to log the time so it’s visible. A connected software stack for architecture practices should allow BD time to be captured against a lead or opportunity record, separately from live projects, so it doesn’t distort project profitability reporting and does feed back into how future proposals are priced.
How does project management software reduce revenue leakage?
Project management software reduces revenue leakage by making each of the gaps above visible in real time rather than retrospectively. A well-configured platform doesn’t require the team to change how they work. It makes the right information available at the point of decision-making.
A properly set-up system does four things. Time is logged against pre-built RIBA stages as work happens. WIP (work in progress) is visible as a running total by stage, so project leads know their budget position at any point. Scope changes are captured as variation lines before delivery, and those lines flow directly to invoices, meaning additional work doesn’t disappear into absorbed overhead. BD time is logged against lead records, giving the practice a real cost-per-opportunity figure.
WorkflowMAX for architecture firms supports all of this natively. Real-time profitability reporting means a project lead can pull up a job and see budget vs. actual by phase before deciding whether to absorb a change or raise a variation. Connecting that to resource planning for architects through the same platform links utilisation data to project performance, so you can see not just where margin is going but who is delivering it.
The platform matters, but configuration matters more. The same software running on misaligned project codes still produces bad data. That’s the work.
SPI Research’s 2025 benchmark found a 739% difference in revenue growth between high-maturity and low-maturity professional services firms.
Fix the system, not the behaviour
Revenue leakage in architecture is a systems problem, not a discipline problem. Time goes unlogged because logging is inconvenient. The scope expands unnoticed because the budget position isn’t visible when a new request arrives. BD hours disappear because there’s nowhere connected to log them. Each of these is fixable, and none of the fixes requires architectural staff to behave differently. They require the right system to make the right behaviour the default.
If you want to find out which of these gaps are present in your practice, and what a configured setup would look like to close them, book a discovery call with us. We’ll go through your current workflow and be direct about what’s worth changing.
