Where project money quietly leaks — and why you notice too late
Project budgets rarely blow up. They drift. A supplier charges a bit more than quoted. A subcontractor's scope expands by a few hours. A materials order gets topped up on site because the first count was wrong. A variation gets agreed verbally and recorded three weeks later. None of these feel like an overrun at the moment they happen. Each one is defensible, small, obviously necessary. Then month-end runs and the project is 12% over budget, and nobody can quite reconstruct how.
This is the shape of most project overruns: not a single bad decision, but hundreds of small ones that aggregated silently because the budget wasn't visible at the moment each one was made.
The reflex is to tighten reporting. More frequent dashboards, better forecasting, tougher conversations at month-end. All of this is useful. None of it addresses the actual problem, which is that by the time any report shows the drift, the decisions that caused it have already been made.
What drift actually looks like
Before thinking about fixes, it helps to see the leaks clearly. Here are five patterns that show up on nearly every project-based business — regardless of sector — and that collectively account for most of the margin that goes missing.
Leak 1 · Scope-creep by email
The client asks for a small addition. The project lead agrees in a reply thread. The hours get logged. The budget never gets updated to reflect the expanded scope. Three months in, the project has consumed 1,400 hours against a 1,200-hour budget, and nobody flagged it along the way because each individual expansion felt too small to raise.
Leak 2 · Supplier price drift between quote and PO
A supplier quoted £180 per unit six weeks ago. By the time the PO is raised, their price list has moved to £195. The PM approves the PO because they need the materials and the price feels close enough. Across 40 suppliers and 200 POs a year, that drift compounds into a six-figure variance that no one line item would ever surface.
Leak 3 · Verbal variations that don't make it to the budget
Something changes on site. The subcontractor confirms the change in person. Work proceeds. Three weeks later, the variation gets written up and submitted. The commercial manager approves it because the work's already done. The budget line it draws from was decided during tender; nobody updated the budget to reflect the new scope.
Leak 4 · "Top-up" POs that never get rolled into the main one
The original PO was for 500 units of material. On site, 540 are needed. A supplementary PO goes out for 40 more. The main PO still shows 500 on reports. Three months later, a reconciliation surfaces the extra 40 units in a different budget line because the second PO got coded to a general-materials bucket rather than the project itself.
Leak 5 · Approval thresholds that treat drift as "within tolerance"
A policy says any PO under £10,000 doesn't need commercial sign-off. On a £1.2m project, 20 POs below that threshold can add up to £180,000 — a 15% drift — without any one of them triggering a review. The threshold was set to speed up small purchases. It also set up a blind spot.
Each pattern is small on its own. The problem isn't any single one. It's that all five run in parallel, none of them trip a warning at the moment they happen, and the aggregate only becomes visible in retrospect.
Budget overruns don't arrive. They accumulate. By the time one is visible on a report, dozens of small commitments have already made it inevitable.
The same PO lands with the same approver on the same day. The only difference is whether committed-vs-budget is on the screen at the moment of decision.
Why reporting doesn't fix drift
Most companies respond to drift the same way: better reports, more often. If the drift was visible monthly, make it visible weekly. If weekly, daily. If daily, real-time.
This treats drift as an information problem — if finance just knew sooner, they could act. The problem is that by the time finance "knows," the commitment has been made. A dashboard that shows "this project is drifting" on Thursday doesn't walk back the three subcontractor hours agreed on Tuesday. It just lets finance see the drift faster. The commitment is already irreversible.
| Approach | What it changes | What it doesn't change |
|---|---|---|
More frequent reports | Finance sees drift sooner | Commitments are already made before the report runs |
Tighter month-end reviews | Conversation gets more aggressive after the fact | No upstream behaviour change — PMs defend decisions already made |
Mandatory variation logs | Documentation improves | Logging is after the commitment, not before |
PM training on budget discipline | Awareness improves temporarily | Erodes under deadline pressure within one quarter |
The thing all four of these have in common: they operate after the commitment is made. Reporting is retrospective by definition. Even "real-time" reporting is retrospective — it just shortens the delay. The commitment still comes first; the visibility second.
The structural shift — visibility before commitment, not after
What actually stops drift is a different sequence: the person approving a cost sees the current budget state before they commit the business to it.
This sounds obvious. In practice, almost no project business operates this way. The purchase order approval happens in one system (email, procurement tool, shared drive). The budget lives in another system (accounting, project tracker, Excel). The two don't talk to each other at the moment of approval. The PM approving a £15,000 subcontractor engagement doesn't see "this will push the subcontractor budget line from 68% to 94%." They just see the PO, decide it's reasonable, and approve.
If the budget state were visible on the same screen as the approval, that approval conversation changes. The PM sees that the subcontractor line is near its cap. They either approve knowingly (and flag it), reduce the scope, or push back on the supplier. The point isn't that the approval gets blocked — it's that the person approving has the information needed to make a conscious decision, not an unconscious one.
Drift is the result of unconscious approvals. Each one, individually, would have been questioned if the person approving could see what it did to the budget.
What a budget-control system actually does
A purchase order control system that handles this properly has three structural properties — all three must be present for drift prevention to work:
- The budget and the PO live in the same system. Not two systems with a nightly sync. The same system, so the budget state is current at the moment of approval.
- Approval shows committed-vs-budget before sign-off. The approver sees how much of the budget line is already committed, how much this PO adds, and what's left afterward. Not as a prediction. As the current state.
- Over-budget approvals are blocked by default. If a PO would push a budget line over its cap, the approval doesn't go through on the normal path. It routes to a higher authority, or requires an explicit over-budget acknowledgment with a reason. The block is the point.
That third property is where most tools fall short. Many procurement systems show budget data at approval but let the approval through anyway, with no enforcement. That's visibility without control — useful, but it doesn't change behaviour. Drift continues because the system is informational, not consequential.
A proper budget-control system makes the budget cap mean something at the moment of approval. Not a soft warning. A hard block that forces either a scope reduction, a supplier renegotiation, or an explicit senior-level acknowledgment that the project is now officially over budget on this line. That friction is the fix. It's uncomfortable by design, because the alternative — silent drift — is more expensive.
What this looks like in practice
Take the five leaks above, one by one, and see what changes when budget-at-approval is enforced.
| Leak | What changes with budget-at-approval |
|---|---|
Scope-creep by email | No hours get logged against a budget line that doesn't have capacity. The expansion either gets formally added to the budget (with a client conversation) or the hours stop. |
Supplier price drift | The PO approval screen shows the current committed-vs-budget on the materials line. A 7% price drift that would push the line to 103% blocks the approval and forces a conversation. |
Verbal variations | Work can't proceed on a variation that hasn't been formally added to a budget line. The variation gets written up before the work starts, not three weeks after. |
Top-up POs | The top-up PO is forced into the same budget line as the original. It can't be coded away to a general-materials bucket to avoid the budget hit. |
Threshold blind spots | The aggregate of small POs against a budget line is visible, even if no single PO is above the review threshold. The threshold stops being a blind spot because the line-level view surfaces the pattern. |
Note what isn't on this table. There's no "the system automatically catches X." The system makes the data visible. The human — PM, commercial lead, approver — sees it and makes the decision. The behaviour change comes from the information being available at the right moment, not from the system taking the decision away.
Why this is a tool change and a process change
If you implement a budget-control system without changing the approval process, the system doesn't help. If you change the approval process without a tool that makes the budget state visible, the process fails under pressure. Both have to change together.
The process change is the harder of the two. It requires:
- Project budgets structured at a level POs can map to. If the budget has three lines ("materials", "labour", "overhead") and POs touch dozens of specific items, the committed-vs-budget view is too blunt to be useful. The PO needs to land against a specific line in a structured budget.
- PO approval happens inside the system that holds the budget. Not email, not Slack, not verbal. The approval event has to happen in a place where the budget state is current and visible.
- Over-budget approvals require explicit senior sign-off. If anyone can override the block without consequence, the block is theatre. It needs real authority behind it.
- Variations modify the budget, not just the PO. When scope changes, the budget line changes to reflect it — ideally with the client conversation that justifies the change. Otherwise the budget stays wrong and every subsequent PO fights it.
None of these are tool features. They're agreements the business has to make about how it will run. The tool makes those agreements enforceable.
Where this connects to committed-cost thinking
Everything above is a specific application of a broader shift: treating cost as something that commits at approval, not at invoicing. If your systems only recognize cost when the invoice arrives, drift is invisible by design — the budget line still looks healthy at the moment a drift-generating PO gets approved, because none of the earlier POs on the line have invoiced yet either. Everything looks fine until the invoices start landing in month three, and by then it's too late.
If your systems recognize cost at commitment — the moment the PO is approved — the budget line reflects reality in real time. The next approver sees the actual committed state, not the historical invoiced state. Drift becomes self-correcting because each approver inherits an accurate picture from everyone upstream.
This is the whole mechanism. It isn't an alert system. It isn't a prediction engine. It's a change to when cost gets recognised in the system, which cascades into what each approver sees, which changes how each commitment decision gets made.
Who this works for (and where it doesn't)
The structural fix lands hardest for businesses where project margin depends on dozens of commitment decisions made across the project lifecycle by multiple people. That's most of construction, engineering consultancy, marine, events, energy infrastructure, specialist contracting — any business where the cost base is being decided in real time by the people doing the work.
It lands less hard for businesses where the cost base is largely fixed at project start — some product-based consulting, some service businesses — because there are fewer commitment decisions downstream to drift. The problem exists but at smaller magnitude. The fix is still useful; it just moves less revenue.
It doesn't work at all if the business genuinely can't commit to budget lines upfront. Early-stage R&D, pure time-and-materials consulting with no scope boundary, exploratory work — these aren't drift problems, they're structure problems. No budget-control system fixes an undefined budget.
For everyone else — which is most project businesses — the quiet drift of 10-15% off margin, year after year, isn't inevitable. It's the specific result of commitment decisions being made without the budget being visible at the moment of decision. Fix that sequence and the drift stops.
Where to start
If this pattern feels familiar, three concrete starting points, in order of leverage:
- Audit a recent overrun. Pick one project that went 10-20% over. Reconstruct the commitment decisions chronologically. Count how many were under the review threshold at the time. The exercise usually surfaces the drift pattern in your business specifically — not these generic five, but your own.
- Find out where PO approvals currently happen. If the answer is "email and various systems," you've located the drift mechanism. The budget cannot be visible at approval if the approval doesn't happen in a budget-aware system.
- Decide the authority level that can override a hard-block. This is a management decision, not a tooling decision. If anyone can override, the block means nothing. If only the CFO can, every small over-budget decision becomes a bottleneck. The right answer sits in the middle and depends on the business.
The underlying shift — from reporting on cost after the fact, to showing budget state at the moment of commitment — is the whole fix. The tooling makes it enforceable. The process makes it stick. Neither works alone.
Project money stops leaking when the budget stops being invisible at the moment it's being spent.
See the budget state before you commit, not after
CostTracker shows committed-vs-budget on every PO approval screen, and blocks approvals that would push a line over its cap. The budget cap means something — not as a warning, as a hard block that forces a conscious decision. Drift stops being invisible because every approver inherits the current state.
Frequently asked questions
No. Audits catch drift after it happened, by design — they look backward. The problem is drift that's visible only in aggregate, which audits only surface after the fact. Prevention requires visibility at the moment each commitment is made, not after a quarter of commitments have accumulated.
Lowering the threshold means more approvals routed up, which creates a bottleneck without changing what the approver sees. The threshold isn't the problem; the information at the approval moment is. A £5,000 threshold with no budget context is just as blind as a £10,000 one.
That's actually the first problem to fix. If POs can't be mapped to specific budget lines, you can't measure drift at all — just overall spend. Breaking project budgets down to the level POs touch (subcontractor labour, materials by category, equipment hire) is prerequisite work before any tooling helps.
Warnings get ignored under deadline pressure within a quarter. Hard blocks force the conversation to happen before the commitment, which is the whole point. Soft warnings produce visibility without accountability.
The budget changes with the scope. When a client agrees to additional work, the budget line gets updated to reflect it before the PO is raised. That keeps the budget honest. If scope grows without budget updates, you're not controlling drift — you're documenting it.
