Change Orders are the formal mechanism for modifying contracts, budgets, and subcontracts after their initial values are set. In BlueCollar the underlying record is called a Change Request, used interchangeably with "Change Order."
Why they exist: once a contract line has been invoiced, its Original Line Value and Original Units should never be edited directly on the Sales Order. Routing every later modification through the Change Order process is what preserves the audit trail, keeps reporting accurate, and keeps revenue recognition calculations correct. This is valuable because the original baseline stays intact — you can always see the original contract and estimate alongside the current values, rather than losing history to in-place edits.
For foundational concepts, see Contracts and Project Budget Overview.
| Type | What it changes |
|---|---|
| Contract Change Order (Billing-Side) | The Contract / Schedule of Values (Sales Order line items) |
| Contract Change Order (Cost-Side) | The Project Budget (BlueCollar Budget Items) |
| Subcontract Change Order | A subcontract (Purchase Order) |
A single Change Request can carry contract and budget changes together — the billing-side and cost-side are separate tabs on the same record. Subcontract change orders are linked child records. See Contract Change Orders and Subcontract Change Orders.
A key distinction: Change Orders update the Current Contract (Original Contract + Change Orders) and Current Estimate (Original Estimate + Change Orders). These are separate from the Projected Contract and Projected Estimate, which are your forecasts and drive revenue recognition.
Approving a change order does not automatically update your projections. After a change order, update projections separately on the project's Contract and Budget tabs if you want the forecast to reflect the change.
Every change order screen — the billing-side and cost-side grids, subcontract change requests, and the change order lists — is available in English and French. The screens display in whichever language a user has set as their NetSuite language preference, so a bilingual team can work side by side, each in their preferred language. Anything without a French translation falls back to English automatically.
Every change order line follows a three-state model:
| Status | Meaning |
|---|---|
| Pending Approval | Default; no proposed amount entered yet |
| Approved | Set automatically when a non-zero proposed change is entered (can also be set manually) |
| Rejected | Set manually to exclude a line from the approved change |
Entering a non-zero Proposed Change auto-approves the line. A line only returns to Pending when both its units change and its dollar change are back to zero — so zeroing one side of a change (say, a deliberate zero-quantity dollar adjustment) doesn't silently drop the line's approval status. When you approve the overall Change Request, any lines still Pending are auto-rejected.
The Approve button performs a systemic approval — it writes the values from the change order's subtabs into the project's Contract (Sales Order lines) and Budget (Budget Items). You'll be asked to confirm before it applies.
Approvals don't have to happen in the UI, either — external systems such as approval portals and workflow tools can drive the approve, reject, unapprove, and edit actions through the Integration APIs.
Change requests on the same contract can be approved in any order, so several change orders can be in flight on one Schedule of Values without anyone tracking which was created first. Only one approval of a given change request can run at a time: if a second approval starts while the first is still processing (two people clicking Approve, say, or a person and an integration), it is rejected with the message "Change request {0} is already being approved by another process. If this is stuck, roll it back first." ({0} is filled in with the change request's ID.)
Out of the box, a change request can be approved whatever accounting period its Date falls in. To keep change orders out of periods you have already closed, turn on the Global Preference Restrict Change Order Approval to Open Periods on the Global Preferences page (it is off by default).
With the preference on, a change request cannot be moved to Approved when its Date falls in a period that is closed, or locked for A/R, for the project's subsidiary. A period locked only for A/P does not block approval. The check applies on every approval path: the Approve button, re-approving after an edit, and approvals sent through the Integration APIs.
The approver sees the error Approval period is closed: "Cannot approve this change request: the accounting period for subsidiary '{sub}' containing the effective date {date} ({period}) is closed for A/R changes. Please select a date in an open period, such as '{next}', or ask an administrator to override the period restriction." If no open period exists for that subsidiary, the message ends with "...and no open period is currently available for this subsidiary. Please ask an administrator to open a period or override the period restriction." A change request with no Date at all fails with "Missing Change Request Date".
The system never re-dates a change request for you. To proceed, change the Date to one in an open period (the error suggests the next one) and approve again. Roles that hold NetSuite's Override Period Restrictions permission, and Administrators, can still approve into a closed period, and each override is recorded in the audit log. For the override to be recognized, the approving role must also be able to view role permissions (Setup > Manage Roles); without that access, the approval is blocked. The payoff comes at month-end: once a period is locked for receivables, a change order cannot land in it by accident, while a controller holding the override permission can still make a deliberate exception.
An approved Change Request can be unapproved. Once a Change Request is Approved, an Unapprove button appears; using it reverses the systemic approval — the contract lines and budget items roll back to their pre-approval values — and returns the Change Request to Pending Approval. This gives you a clean way to back out a change order that was approved prematurely or with the wrong values, without deleting it and losing its history.
Unapproval works even when invoices have already been billed against the change order's lines, or when related change requests exist: invoiced contract lines aren't removed — their approved values are zeroed instead — so your billing history stays intact. Unapproval is blocked only where reversing would orphan real activity, such as job costs already posted against budget items the change order created.
If you just need to correct an approved change order, you can also edit it in a single operation: the system unapproves, applies your updates, and re-approves in one atomic step, so the change order is never left half-applied.
Deleting an approved change request. If you delete an approved change request rather than unapproving it, the Sales Order lines it added are removed with it. Lump-sum lines are no longer left behind at zero quantity with a leftover amount, a line that other approved change orders also changed keeps the value those change orders contributed, and any line that has already been invoiced stays on the contract. While Approve, Reject, Unapprove, or Delete is running, a banner asks you not to close the tab; if you try to leave the page anyway, the browser's standard "Leave site?" prompt appears, so a half-finished update is not left behind by an accidental click.
Subcontract Change Requests can be unapproved as well, with the Purchase Order restored to its prior state — see Subcontract Change Orders.
| Metric | Calculation | Change Order Impact |
|---|---|---|
| Current Contract | Original Contract + Change Orders | Updated on approval |
| Current Estimate | Original Estimate + Change Orders | Updated on approval |
| Projected Contract | Your revenue forecast | Update separately |
| Projected Estimate | Your cost forecast | Update separately |
| Gross Profit | Contract − Estimate | Derived from the above |
Each project has a Change Request Log tab — a centralized list of all change orders with their Change Order number, status, date, dollar impact on the contract and estimate, gross profit and GP%, and committed-cost rollups (approved / pending / rejected). It supports status and date filtering, pagination, a grand-total summary row, and Export to Excel. This is useful for reviewing the cumulative change-order history on a job at a glance, and for handing an owner or auditor a clean log.
| Feature | Application | Action | Level |
|---|---|---|---|
| Create a Change Request from the project record | CHANGE_REQUEST | CHANGE_REQUEST_CREATE | FULL |
| View / edit the Contract tab | CHANGE_REQUEST | CHANGE_REQUEST_CONTRACT | EDIT |
| View / edit the Estimate tab | CHANGE_REQUEST | CHANGE_REQUEST_ESTIMATE | EDIT |
| View subcontract change requests | CHANGE_REQUEST | CHANGE_REQUEST_SUBCONTRACTS | VIEW |
| Approve a change request | CHANGE_REQUEST | CHANGE_REQUEST_APPROVE | FULL |
| Reject a change request | CHANGE_REQUEST | CHANGE_REQUEST_REJECT | FULL |
| View the Change Request Log | CHANGE_REQUEST_LIST | CHANGE_REQUEST_LIST_VIEW_LIST | VIEW |
| Create a Subcontract Change Request | SUBCONTRACT_CHANGE_REQUEST | SUBCONTRACT_CHANGE_REQUEST_CREATE | FULL |
| Approve a Subcontract Change Request | SUBCONTRACT_CHANGE_REQUEST | SUBCONTRACT_CHANGE_REQUEST_APPROVE | FULL |
A user whose role lacks the Create Change Request permission sees a clear missing-permission message when clicking Create Change Request, rather than a raw NetSuite error, which makes it obvious that a permission needs to be granted.