The profitability number for a construction project is usually the last thing to arrive and the first thing leadership questions. By the time it reaches the monthly review, the person who built it has already spent two days reconciling the budget against actuals, chasing procurement for what is committed, and asking the project manager what changed on site this month.

Finance holds the actuals. The project team holds the field context. Procurement knows what has been bought. The change register holds part of the exposure, and the rest is sitting in someone's inbox. Billing and cash live in a different system again. So the margin story gets rebuilt from scratch every cycle, and by the time it is explainable, it is already old.

This guide is for developers, contractors, and finance leads who want project profitability to be a review they run, not a rescue they perform at month-end. It stays useful whether or not you ever bring in outside help. The point is to make one project's margin forecast honest and quick to question.

What the forecast is really trying to answer

The point of this workflow is not a cleaner report. It is being able to say, in the meeting, why the margin moved and where that came from. A forecast earns its place when it can answer four things without a scramble: what changed since the last one and which line backs it up, how committed cost and approved changes and cash timing add up to the margin on the page, which movements need a decision from procurement or the project director or finance, and which numbers are real versus still a judgment call.

A quick test

Open last month's project review and ask whether someone new could see, in five minutes, what moved the margin, which line supports each move, and who owns the next decision. If the answer lives in the head of the person who built the pack, the forecast is hiding the work rather than showing it.

How a project margin forecast is built

Every project margin forecast is the same short equation dressed up in different software. Forecast revenue is the contract value plus approved change orders, sometimes plus claims the client has accepted. Forecast final cost is what you have already spent, plus what you have committed but not yet been invoiced for, plus the cost still to come to finish the job. Subtract one from the other and you have the forecast final margin.

The trouble is that each term in that equation comes from a different place and moves at a different speed. Actual cost is solid but slow, because invoices arrive weeks after the work. Committed cost is knowable the day a subcontract or purchase order is signed, but it often lives in procurement's files rather than the cost report. Cost to complete is not a fact; it is the project manager's and estimator's read of what the rest of the job will take. Revenue looks fixed until you remember that half the change orders driving it are still being argued about.

So the forecast is only as honest as the weakest term in it, and the weakest term is almost always cost to complete or unapproved change exposure. Most of the work in this guide is about keeping those two honest.

Walk the month-end forecast, step by step

Most teams are not short of data. They have budgets, cost codes, accounting actuals, a change register, payment applications, the schedule, and site notes. The time goes into stitching them together by hand, in the same order, every month, and the handoffs are where the number gets soft.

StepWho owns itWhere it breaks
Close actuals for the periodFinance or project accountantInvoices lag the field, so cost looks lower than the work already done.
Pull committed costProcurement or commercial managerSubcontract and order commitments sit outside the cost report; some get missed.
Update cost to completeProject manager and estimatorDone from memory under time pressure, so optimism creeps in.
Reconcile change ordersCommercial manager or QSApproved and unapproved get blended, or an optimistic one gets booked as revenue.
Reconcile billing and retentionFinanceOver-billing and under-billing get missed, so margin reads better or worse than it is.
Compare margin to last monthWhoever built the packThe bridge is rebuilt from memory the night before the meeting.

By the time the number is defensible, the meeting is tomorrow and nobody quite remembers which change moved the forecast. The fix is not to work faster through the same steps. It is to stop rebuilding the explanation from scratch each month.

Keep committed cost and cost to complete in separate columns

The single most common way a project forecast goes wrong is collapsing everything on the cost side into one number called forecast cost. Committed cost and cost to complete are different kinds of thing, and blending them hides the risk. Committed cost is money you have already promised: a signed subcontract, a placed order, a letter of intent the other side is working to. Cost to complete is money you expect to spend but have not tied down yet, so it still carries judgment and can still move.

When they sit in separate columns, a reviewer can see at a glance how much of the remaining cost is locked and how much is still an estimate. A project that is ninety percent committed is a very different risk from one where most of the remaining cost is still a guess, even if the two show the same forecast margin.

Cost categoryCommitted against budgetSpent to dateCost to completeWhat the row tells you
StructureFully committed, above budgetMost of it invoicedSmall and firmA real overrun, but locked in; no more surprises here.
Fit-outPartly committedEarlyLarge and still an estimateThe biggest source of forecast risk on the job.
PreliminariesCommitted but time-basedTracking to dateGrows if the schedule slipsTied to the schedule, so watch the end date.
ContingencyNot committedUntouchedPure judgmentThe buffer, and whether it is real or already spent in your head.

The last row matters more than it looks. A contingency that everyone has quietly earmarked for the fit-out overrun is not a buffer anymore, and a forecast that still shows it as untouched is telling the meeting a comfortable lie.

Cost to complete is the number everyone leans on

Cost to complete carries the whole forecast, and it is the number under the most pressure to look good. A project manager who is behind on schedule has every reason, conscious or not, to keep it optimistic: it protects this month's margin and buys time to recover. The estimate is also genuinely hard, because it depends on productivity that has not happened yet, on subcontractor performance, and on weather.

You cannot automate judgment out of cost to complete, and you should not try. What you can do is make the estimate reviewable. Ask for it by cost category rather than as one project number, so a jump shows up where it happens. Ask what changed since last month and why, in a sentence. Flag any cost code where spend has moved but cost to complete has not, because that usually means the estimate is stale. And keep the estimator's assumptions next to the number, so the review can question the assumption instead of arguing about the total.

The point is not accuracy for its own sake. When the forecast misses, you want to see which assumption missed, and fix that one thing next month.

Keep approved money separate from possible money

The fastest way to lose leadership's trust in a forecast is to mix money that is confirmed with money that is only likely. On a live job, change exposure sits in several states at once, and each one belongs in a different place.

State of the changeWhat it isWhere it belongsWho decides
Approved change orderThe client has signed; it is revenue.In the base margin.Already done; just book it.
Submitted, not approvedPriced and sent, still being negotiated.A separate exposure view, not the headline number.Commercial manager tracks it; keep it out of the base.
Instructed, not pricedWork told to proceed, cost not yet agreed.Flagged as risk, with a labeled cost estimate.Commercial manager and project director.
Likely, not submittedThe project manager expects it, but nothing is raised.Commentary only, stated as a judgment.Project manager's call, said out loud as such.

When these sit side by side, the review can talk about risk honestly instead of arguing about whether one optimistic change belongs in the number. That separation is usually worth more than any single system connection. Getting changes approved quickly is its own piece of work, and if the change register itself is the bottleneck, the change order approval workflow is the thing to fix first, because an unapproved backlog turns every forecast into a guess.

Build one margin picture the team can question

Once the cost side is honest and the change states are separated, the forecast becomes worth building once and updating, rather than reassembling from scratch each month. The useful version is a single margin picture per project that carries the number and its explanation together.

That picture should hold a few things: budget, committed, spent, and cost to complete by category; approved changes, and separately the submitted, instructed, and likely ones; billing to date, retention held, and cash against progress; the project manager's cost-to-complete adjustments with a one-line reason; and a bridge that shows the movement from last month, line by line.

The bridge is the part that turns a number into a conversation. Instead of a single margin figure, leadership sees the two or three moves that changed it and the line behind each one. A reviewer who missed last month can still follow the story, because the movement is on the page, not in the head of whoever built it.

A worked example

The project and figures here are invented to show the shape, not a real client. Say a developer-builder with nine active projects, everything from townhome rows to a couple of mid-rise blocks, runs its margin forecasts in a shared spreadsheet that one commercial manager keeps alive. Take one project, a mid-rise block a few months into construction.

Last month it forecast a healthy margin. This month the number dropped, and the board wants to know why. Rebuilt from the spreadsheet, the answer came out as "costs are up," which satisfied nobody. Built as a bridge, it looked like this.

Project sliceWhat moved since last reviewBacked byEffect on marginDecision owner
Structural steelSubcontract let above the budget allowanceSigned subcontract and cost-code detailRoughly a point of margin, real and lockedProcurement variance review
Fit-out cost to completeEstimate raised after a slow first floorProject manager's revised estimate and productivity to dateAround half a point, still a judgmentProject director to confirm
Two submitted change ordersPriced and sent, not yet approvedChange register and client emailsPossible upside, kept out of the baseCommercial manager to chase approval
PreliminariesSchedule slipped two weeks, so prelims run longerSchedule update and site reportsSmall drag that grows if the slip holdsProject director call on recovery

The two or three real moves are now visible, each tied to a line and each with an owner for the next step. The steel overrun is locked and honest. The fit-out estimate is flagged as judgment, so nobody pretends it is precise. The submitted changes show as upside without being booked, so next month's margin does not quietly fall when they are approved late or for less. That is the difference between a forecast the board questions and one the board can use.

Where AI helps, and where it does not

Once the margin picture and the categories are clear, most of what is left is assembly, and that is where a well-scoped tool earns its place. It can draft the margin narrative from the movements, so the commentary is a first pass to edit rather than a blank page. It can flag cost codes where spend jumped without a matching commitment, or where spend moved but cost to complete did not. It can group change-register items by reason and check this month's commentary against the underlying lines to catch a claim that no longer holds.

What it must not do is invent an explanation for a variance it cannot trace, or set the forecast itself. The judgment on cost to complete, on whether a change belongs in the number, and on what gets reported up stays with the commercial and finance team. Used this way, the tool shortens the write-up, not the review. The boundary is simple: software assembles and reconciles and drafts, and people decide what the margin is.

The data and systems this touches

A working version usually connects the accounting or ERP system for actuals, the job-cost or project-management tool for commitments and cost to complete, the change register, procurement and subcontract records, and the payment-application or billing layer where valuations and retention live. Most of that data already exists. It is just scattered.

The first design decision is not which tool to buy. It is which system owns each number: where actuals are the truth, where commitments are the truth, and where cost-to-complete judgment is allowed to override them. Until that ownership is agreed, connecting systems just moves the argument about which number is right into a nicer screen. Once it is agreed for one real estate and construction project, the monthly hunt turns into a review.

Give the forecast a monthly cadence people trust

A forecast that lands whenever it happens to be ready trains everyone to distrust it, because nobody knows how much checking is behind this month's version. A predictable monthly cadence does more for trust than any single feature.

The shape most teams settle on is straightforward. Finance closes actuals and confirms commitments in the first few days after month-end. The project manager and commercial manager update cost to complete and the change states against those actuals. The forecast and its bridge get built and self-checked. Then the project review works the exceptions, the two or three moves that need a decision, rather than reading every line aloud. The exact days matter less than running the same sequence every month, so the meeting spends its time on judgment instead of on assembling the number.

What tells you it is working

You do not need a scorecard to know whether this is landing. A few signals do the job. Watch the time from month-end close to a margin you would actually defend, and whether it is shrinking. Watch how much of the margin movement you can trace to a line without a phone call. Watch the gap between forecast margin and final margin when a project closes, and whether that gap is narrowing across projects. Watch how often approved and unapproved change money still get mixed up in a review.

The real test is whether the same variance keeps surprising leadership two months running. When it does, the estimate is the problem, not the project. A forecast is working when the surprises get smaller, not when the margin looks good.

Where it usually breaks

A few failure modes show up again and again. The first is treating this as a finance project when the field holds half the story, because a forecast built without the project manager's read of cost to complete is just tidy accounting. The second is booking optimistic change exposure into the base, which makes every good month look worse later when the change is approved for less or not at all. The third is chasing a perfect systems integration before the categories and ownership are agreed, which mostly produces a fast way to generate a number nobody trusts. The fourth is letting the forecast become a black box, where a single margin figure arrives with no bridge behind it and leadership has no way to question it.

The fifth is quieter and more dangerous. It is letting cost to complete drift into a plug, the number someone nudges at the end to make the margin land where it needs to. Once that happens, the forecast stops describing the project and starts performing for the meeting, and every downstream decision inherits the fiction.

How to roll this out on one project first

You do not need to fix nine projects at once, and you should not try. Pick one live project, ideally one a few months in with real cost history and at least one live change order, so the forecast has something to chew on. Rebuild its last two or three months as a bridge, by hand if you have to, so you can see exactly where the margin story had to be reconstructed and which numbers were soft.

From that, agree the categories, the change states, and who owns each number. Build the single margin picture for that one project and run one real review from it. If the review is sharper and the forecast holds up better against actuals next month, widen it to a second project and connect the data that is worth automating. If the review is still an argument about which number is right, the blocker is ownership, not tooling, and more software will not help until that is settled.

How Ubisar would build this with you

In week one, we would take one project and pull its last two or three forecasts to see exactly where the margin story had to be rebuilt by hand and which numbers were soft. From that we would shape a single margin picture: budget, spent, committed, and cost to complete by category, the states of change exposure, billing and cash, and the movement since the last review, each line tied to what backs it.

In weeks two and three, we would connect only the accounting, job-cost, change-register, procurement, and billing data needed to keep that picture current, and let software draft the commentary and flag the anomalies while the commercial and finance team keep the forecast call. By week four, one real project review should separate what actually happened, what is still judgment, and what needs a decision.

At month-end we keep going if the margin is easier to explain and forecasts hold up better against final numbers, and we narrow or stop if cost ownership is not yet settled. If you want this built on one of your live projects, that is what the AI, Data & Tech Implementation retainer does, starting from $4,000/month, on the workflow you pick first. If you would rather just talk it through, get in touch and we will reply within one business day.