Change Orders Between HubSpot and a Construction Management System

A job closes at $840,000 and finishes at $1.15m. The difference is eleven change orders approved across nine months, every one of them recorded properly in the construction management system, and none of them anywhere near the CRM. The account shows $840,000, the year-end revenue report shows $840,000, and the largest client the business has is understated by a quarter of a million dollars in every commercial conversation anybody has about it.

This article describes how change orders should cross the boundary between a construction management system and HubSpot. It begins with why one job produces two records, then sets out what a change order actually does to a deal, then draws the boundary and names the fields that carry the value. It closes with the write-back mechanics, where this arrangement breaks, and what it deliberately does not attempt.

Three terms, used narrowly. A contract value is what the job was awarded at. A change order is an approved variation to scope and price after that award. Revised contract value is the sum of the two, and it is the figure almost every commercial question is actually asking about.

Two Records of One Job

A construction management system owns the job as a project: the schedule, the cost codes, the commitments to subcontractors, the daily logs and the change orders themselves. It owns them properly, it is audited against them, and nothing described here proposes moving any of it (Procore REST API overview).

HubSpot owns the relationship the job came from: who the client is, what else they have put out to bid, what was quoted and refused, and which general contractors send work worth having. That record is not a subset of the project record, because most of it concerns work that never became a project at all.

The overlap between them is small and specific. It is the commercial value of the job, which the project system revises continuously and the CRM captures once and then forgets.

The Deal Amount After Approval

A deal in HubSpot carries an amount, and that amount is set when the deal closes. Everything downstream — pipeline reporting, account value, the forecast, the largest-client list — reads that number (HubSpot deals).

The moment a change order is approved, that number is wrong, and it stays wrong for the life of the job. It is not slightly stale in the way a forecast is stale. It is a figure the business has superseded in another system and continues to report from this one.

The instinct is to edit the deal amount. That is the wrong move, and the reason is worth being precise about: the amount the deal closed at is a real fact with real uses. It is what the bid was won on, what the estimating process should be measured against, and what a bid-to-award analysis needs. Overwriting it destroys the evidence of whether the estimate was accurate, and it does so to report a number that could have lived in its own field.

The Boundary, and the Three Values

The project system stays authoritative for the change order itself: its number, its scope, its cost breakdown, its approval state and the date it was approved. None of that crosses (Procore change orders).

Three values cross, and they are three fields on the deal rather than one.

Original contract value, written once when the job is awarded and never edited afterwards. This is what the bid was won at and what estimating accuracy is measured against.

Approved change order value, a running total maintained by the integration, which is the sum of approved variations and nothing else.

Revised contract value, the sum of the two. This is the field reporting should read, and making it a separate stored value rather than a calculation keeps it available to HubSpot's reporting layer without a join (HubSpot properties).

The deal's native amount continues to hold the original figure, so pipeline history and win-rate analysis keep working on the thing they were always measuring.

The Write-Back

The trigger is approval rather than submission. A change order that has been requested is not a commercial fact yet, and writing it across means the CRM reports value the client has not agreed to — which is the same defect in the opposite direction.

The write is an idempotent update keyed on the project identifier, recalculating the running total from the project system's own list of approved changes rather than incrementing a counter. Incrementing is what produces a revised value that drifts by one change order after a retry, and the error is invisible until somebody reconciles by hand.

The reconciliation key is a field on the deal carrying the project identifier, set once when the project is created and never matched on job name. Two jobs for one client at the same address in consecutive years is the ordinary case in this industry, not an edge case.

Associations carry the relationship between the deal and any records modelling individual change orders, where a business wants them itemised rather than totalled (HubSpot associations).

Four Failure Points

Four failures, each of which follows from the mechanics above.

A deducted change order reduces the scope, and a running total implemented as a sum of positive values silently ignores it. The total has to be signed.

A change order approved against a job that closed in a prior period moves revenue between periods, and the CRM has no concept of a closed period at all. The finance system does, so this is a case where the CRM should follow rather than lead.

A job that is cancelled mid-execution leaves a revised contract value that will never be earned. Nothing automatic should reverse it, because the amount recoverable is a negotiation rather than a calculation.

And the common one: the project is created in the construction system before anybody links it to a deal, so the first change orders have nowhere to write. Provisioning the project from the awarded deal rather than by hand is what closes that gap.

The Business Case

What this buys is an account record whose value is the value of the work, so that client rankings, renewal conversations and the largest-customer list are computed from what the business actually did rather than from what it expected to do at award.

What it costs is an integration with a running total to maintain, plus the discipline that the original contract value is never edited by a person. That second part is a permissions question more than a technical one, and it is the one that erodes.

The case is strongest where change orders are large relative to the award, which is most commercial construction and nearly all renovation. It is weakest in fixed-price residential work with a change-order rate close to zero, where three fields are carrying a difference that does not occur.

Limits of This Approach

This describes moving an approved commercial value across a boundary. It determines nothing about when a change order should be approved, how it should be priced, or how the resulting revenue should be recognised, all of which belong to the business and its accountants.

It assumes one job maps to one deal. Contractors working under a master agreement with releases against it need the agreement modelled as the relationship and each release as a job, and the change orders then attach to the release rather than to the agreement.

Nothing here establishes that visible change orders improve margin. The narrower claim is that a business reporting the award value of a job is reporting a figure it has already superseded, and that the cost of correcting it is one integration and one field nobody is allowed to edit.

In Summary

One job produces two records, and only the commercial value overlaps between them. The project system revises that value continuously and the CRM captures it once.

Keep three fields rather than one: the original contract value the bid was won at, the approved change order total maintained by the integration, and the revised value that reporting reads. Never overwrite the first, because it is the only evidence of whether the estimate was any good.

Write on approval rather than on request, recalculate the total instead of incrementing it, and match on a project identifier rather than a job name.

A business that skips all of this is not missing a feature. It is telling its largest client's story using a number that stopped being true in month two.