Change order management in Sage Intacct: How to close the loop

The hard part of change orders is not that they happen. It is processing them quickly and holding the process accountable. Between the day the field starts building a change and the day the owner signs it, that change has to live somewhere: priced, assigned a status, sitting on the schedule of values, and visible in the forecast. When it lives in a spreadsheet or an email thread instead, finance learns about the cost weeks after the field started the work.

That gap, between what the field has already set in motion and what finance can see, is what change order management has to close. Sage Intacct Construction is worth evaluating for contractors who need change orders to move through the full financial loop: job cost, budget revisions, billing review, and forecast reporting. It is the wrong shortcut for teams that have not defined who owns statuses, budget changes, and billing handoffs. The software will expose that confusion before it solves anything.

We implement and support construction ERP systems for a living, and this is one of the most common breakdowns we see in Sage Intacct Construction conversations. We also sat down with Troy Guevara, our Construction Technologist focused on Sage Intacct Construction and construction ERP implementation. His point was about culture, not carelessness. Contractors are wired to adapt and work around obstacles, and that is a strength: “Plans always have holes, change orders are expected, and you figure it out,” he told us. That instinct is exactly what keeps jobs moving. The cost is that the same instinct can let a broken financial handoff feel normal for years.

So follow one change order all the way through, from the field notice to the forecast. If the financial path breaks before leadership can see the exposure, the system will record plenty of activity while unapproved scope still runs through spreadsheets and catch-up meetings.

Change orders and scope creep are not the same problem

Change orders are normal in construction, but not every surprise is a change order. A drawing clarification usually starts life as an RFI and may never touch the contract value. Site conditions that differ from the plan may or may not justify a change order, depending on the contract. And work the contractor should have caught at bid time is not a change order at all; the contractor absorbs that cost. Scope creep is what happens when changed work gets built without being priced, submitted, and approved, so cost lands on the job with no revenue attached. The change order process is the instrument that prevents it, and the exposure that hurts is the extra cost, disputed scope, and unbilled approved work sitting outside the reports PMs, controllers, and CFOs use to run the job.

A tight change order process makes the financial exposure visible early enough for operations, finance, and leadership to work from the same facts. The same change carries a source, a status, a cost and revenue impact, a budget effect, a billing path, and a forecast consequence, and each of those needs a home in the system.

Usually one group knows something the next group does not yet. The field knows the work changed before finance hears about it. A pending change belongs on the schedule of values so billing can see it coming, and it stays there until owner approval moves it into the contract value and the actuals. Accounting knows the contract record is not ready while the project team is still wondering why the invoice is stuck. The miss almost always lands in the handoff between them.

Where change orders usually fall out of view

The drop happens between the people who see the work and the people who see the money. Field teams document the issue where it happens. PMs track pending changes in spreadsheets, project management tools, email threads, or job meeting notes. Accounting holds until it has a reliable contract record to post against. Billing waits on a clean handoff. Forecasts lag because the pending exposure never reached the financial view leadership uses to run the job.

Status definitions are usually the first thing to break. A PM may call a change “approved” because the owner agreed on the phone. Accounting reserves “approved” for the signed change order in hand. Billing may read “approved” as eligible for review but still short on final invoice support. One word, three different financial meanings, and nobody notices until the numbers disagree.

Troy sees the same pattern in ERP selection. He told us contractors sometimes buy “band-aid solutions” because they are chasing symptoms before they have named the real pain. Change order tracking turns into a band-aid when the deeper problem is unclear ownership for statuses, inconsistent cost coding, and a billing handoff accounting can actually trust. If you recognize your team here, fix the ownership question first and let it shape what you ask vendors to demo.

Where the software earns its keep: speed and accountability

Troy is specific about what the software is actually for. The challenge with change orders is the processing of them and the accountability for them, and that is where a system has power: it speeds the process up and it holds the process accountable. Each change moves through defined statuses — potential, submitted, approved, disputed, billed, closed — with one owner for every move. While a change is pending, it sits on the schedule of values so billing and forecasting can see it coming. Once the owner approves it, it moves into the contract value and hits the actuals. Nobody reconstructs that history from an email thread, and nobody quietly skips a step.

What should stay connected?

Before configuration, map one real change across these handoffs. The contractor type sets the approval thresholds, but the financial path still has to hold, and your team needs to agree how a change moves before the system carries it.

When Sage Intacct Construction is worth evaluating

Sage Intacct Construction belongs in the discussion when pending changes already affect labor, commitments, cash, and margin before anyone signs. Where pending changes shape daily job control, evaluate the construction version. Where change orders mostly live inside accounting after approval, you may be buying more system than the process needs.

Confirm you are evaluating Sage Intacct Construction, not standard Sage Intacct. The change order process has to touch job costing, cost codes, RFIs, project profitability, and billing handoffs, and the two products are not interchangeable for that work.

If the proposed workflow only records the approved owner change after the financial risk has already moved, it will leave scope creep right where it found it.

Pending changes need to show up before they are approved

Approved changes are only part of the risk. A job can look on budget while unpriced, unapproved, or disputed scope keeps building outside the financial view. Pending changes should be visible in management reporting so leaders can see likely cost, likely revenue, approval status, and forecast effect. On the billing side, the pending change belongs on the schedule of values, where it stays until approval moves it into the contract. Visibility gives leadership room to plan. Approval status, contract terms, and accounting policy still decide what gets billed or recognized. When projected profitability lives in a spreadsheet only one PM updates, the CFO and the field are looking at two different jobs, and the lag between them is exactly where margin exposure hides. Cloud access gives the field and the office browser access to the same change-order record from any location, so pending exposure shows up in one shared place.

Decide who can move a change forward before you configure the workflow

A system can route a change, keep its history, and make status visible. Leadership still has to define the rules the routing depends on, and back the process when someone works around it. For change orders, that means four decisions to settle before the workflow gets configured:

• Status definitions: Define what potential, submitted, approved, disputed, billed, and closed allow financially, including which documents are required to move status.
• Approval authority: Name who can submit, proceed internally, accept customer approval, or escalate delayed decisions by dollar threshold and risk.
• Budget authority: Name who can revise the job budget, which cost code carries the change, and whether estimated exposure appears before approval.
• Billing trigger: Define the exact status that sends a change to billing review and what accounting must verify first.

None of this has to make the process heavy. It just has to make the approved path easier to follow than the workaround.

This check heads off one of the most common implementation failures we run into: automating habits nobody agreed on, then trying to keep the old workarounds alive inside the new system. Change orders are where that failure shows up first.

What should you bring to a demo or workshop?

Bring one messy, recent, real change order into the conversation. Use the one that annoyed everyone, delayed billing, or forced the PM to rebuild a forecast.

Get the right people in the room: the PM, a project executive or operations lead, the controller, billing or contract administration, and whoever owns job reporting. If AP, payroll, or estimating touched the change, pull them in long enough to walk through their handoff.

Bring the real supporting material:

• The field note, RFI, photo, email, or meeting note that started the change.
• The pricing worksheet or estimate notes.
• The cost codes used for estimated cost, commitments, and actual cost.
• The approval trail, including any delay, dispute, or verbal approval.
• The budget revision history, if the budget moved.
• The billing status and any reason billing waited.
• The forecast or project report people trusted at the time.

Then walk it through the handoffs in the change order map above. If the team cannot agree on who owned each status and which report should have moved, the demo has already earned its keep: it has shown you where the workflow will stall once ownership stays vague.

This is also where the partner conversation should get practical. Troy often says the ERP decision comes down to “fit for the company.” For change order management, fit means the system, its configuration, the reporting model, and your internal rules can carry one real change through the financial path without manual reconciliation becoming your control process.

What should you fix before configuration?

Settle ownership for statuses, budget movement, billing review, and pending-change forecasting before you configure anything. Scope creep will still happen. Settle ownership first and you catch it as a financial signal while the job can still be managed, before it lands as an accounting surprise once the work is done.