Approving additional work: scope, price and the client's decision

How not to mix up the technical decision, scope approval and price approval. A register of additional work for industrial and engineering contractors.

By Artem Korsakov ·

Approving additional work starts with recording a specific change: what was found, which section is affected and what decision is required. For an industrial contractor, an email saying “yes, go ahead” leaves too many questions. What scope was discussed, who confirmed the technical part, has the price been agreed and how will the timeline change? A digital register helps preserve these distinctions and show the next step.

In short: manage each change as a separate card. Separate technical review, scope verification, the commercial decision and contractual formalisation. The history in the service helps manage the process but does not by itself guarantee payment.

Editorial illustration: Approving additional work: scope, price and the client's decision
Generated editorial illustration for the article topic. Not a photograph of a real project.

Why a single “approved” status is not enough

On an industrial site, the routing, the connection point, the equipment set or access conditions may change. One participant confirms technical feasibility, another assesses the scope, a third reviews the cost. Authority and the form of decisions depend on the contract and how the project is organised.

In the proposed model, the status is built from several independent states: technical decision, scope, price, schedule impact and formalisation. Then the manager sees what exactly has been accepted and what is still under discussion. The contractor's internal approval must not be displayed as the client's decision.

Separation of financial states is also found in off-the-shelf systems: the Autodesk help page on change order requests shows estimated, submitted and approved amounts separately. This is an example of a data model. It does not suggest copying another system’s approval procedure into your contract.

Which record to start a change with

The initial card should answer questions about the event and the required action. You do not have to wait for a full calculation to inform the manager of a potential change. But uncertainty should be marked explicitly: “preliminary estimate”, “scope being clarified”, “designer's decision required”.

A practical set of card fields:

  • The site, section, system and link to the original work package.
  • The basis: a question, a discovered circumstance, a request or a changed document.
  • A description of the difference from the original solution and the boundaries of the affected work.
  • Links to drawings, correspondence, photos and versions of calculations.
  • The proposed action, the responsible party and the required response date.
  • An estimate of scope, price and schedule impact, with the degree of confirmation stated.

The author of the record does not have to know the final cost straight away. It is better to record a question with incomplete data than to hide it until an estimate appears. The required fields for the first stage include only what is needed to assign a review.

What the process looks like in an industrial example

A hypothetical situation: during installation of a cable route, a clash with an adjacent system is discovered. The crew attaches the location and photos, and the technical department links the question to the current working documentation. The technical decision is requested from the party authorised by the project and the contract.

Once the decision has been determined, the contractor assesses the changed scope, materials, availability of the work front and equipment needs. Then the commercial terms and the schedule are reviewed on a separate route. If part of the work remains undefined, the card does not automatically turn it into a confirmed obligation.

Tracking additional work in construction this way shows the manager, next to the total amount, the questions that have not yet reached the calculation. This matters for managing the portfolio of changes and response times.

Calculation versions and the boundaries of a change

The card keeps the original estimate, the new revision and the reason for the revision. If the client has excluded part of the scope, the old file stays in the history, and the current proposal gets its own number. A document that a decision has already referenced must not be quietly replaced.

For the calculation, it is useful to separate materials, labour, equipment and other agreed cost categories. The cost estimate is done in a specialised tool. The register can store the file, the totals and the link to the change without trying to reproduce the estimating software.

You should also check whether the question relates to fixing a defect, the original contract scope or another category. The system must not automatically treat any additional action as additional paid work. The classification is confirmed by the responsible party after reviewing the circumstances.

Who makes decisions and where to record them

Automating approvals in construction requires a list of roles and authorities. For each step, the performer, a deputy and the expected result are defined. For example, the technical department confirms that the technical justification is complete, and the project manager makes the internal decision to send the proposal.

An external decision must be stored together with its source: a document, an email or a record in an agreed system. The author, date and limits of the decision are stated. If information was entered by an employee following a conversation, this must be distinguished from a received document.

The legally binding procedure for notification, approval, suspension and formalisation must be checked against the applicable contract and current requirements with a specialist. An internal portal cannot by itself establish the right to perform or be paid for work.

An urgent question must not lose its history

On site, there are situations that require a quick response. They need a separate urgency flag and clear escalation to authorised participants. Such a flag must not mean automatic permission to start work.

Record what happened, to whom the question was passed, what decision was received and what document is still expected. If work has been stopped or the order of actions changed, this is recorded in accordance with the accepted process. Safety questions and mandatory approvals are not delegated to AI.

The register of additional work must also keep rejected options. Otherwise, a month later the team will start discussing a solution that was already turned down, or mistakenly include it in the summary of expected amounts.

What to build in the first version of the product

A feasible version: change cards, roles, routes, attachments, an activity log and filters by site, person responsible and state. The manager sees pending decisions, the age of questions and amounts at different stages without mixing them into one total.

Add an export for meetings and reminders based on set deadlines. The link to the contract and the main work package can initially be stored as a link and an identifier. Integration with the budget, estimates and the client's external system is assessed after checking access and data structure.

A neural network for the change card and the list of questions

Input: an email about a change in the solution, the attached calculation and selected messages on one question. The model identifies the site, the basis, a description of the change, the stated scope, the amount and unresolved questions. The output is a draft card with links to source fragments. Technical consent and the commercial proposal remain separate fields.

The technical department and the project manager check the content, whether the attachments are current and the limits of the decision received. After confirmation, the card enters the register and is assigned to the person responsible. The assistant can compare two text versions of a proposal and prepare a list of differences. It does not determine the contractual right to payment and does not issue a technical decision.

If working documentation is managed in EXON (a Russian construction document management system), the technical review can stay in the accepted process: the EXON guide describes comments and returning a document set for revision. The commercial question is linked to it with a separate record. If changes are already tracked in an installed system, first check its routes and reports. The add-on chain: email/files → AI draft → verified card → existing register or agreed export. The Autodesk help page shows an example of financial states; it does not imply a ready connection to your data.

The pilot checks whether qualifiers such as “preliminary” and “technical part only” have been lost. Data from documents is material for extraction; it does not become commands for the assistant. External correspondence and sending proposals require separate human confirmation.

How to check the result of implementation

Before the pilot, count how many changes are currently at different stages and for which of them the next step is unknown. During the pilot, measure the time to assign a person responsible, the number of returns due to incomplete justification and the time spent at each stage.

The “approved” metric needs to be broken down. An approved technical scheme, an agreed amount and a signed document produce different results. Separately check whether you can find the original basis, the current calculation and the source of the decision without searching personal correspondence.

Do not promise growth in paid scope just from introducing a register. It helps build the history and manage expectations, but the financial result depends on the contract, the validity of the claims and the participants' decisions.

How to link a change to the cash forecast

A change can simultaneously have the contractor's cost estimate and the price requested from the client. These are different amounts. The first helps understand future cost; the second reflects the commercial proposal. The submitted amount must not be automatically included in the project's confirmed revenue.

In a hypothetical situation, the contractor estimated the necessary costs at RUB 300,000 and sent a proposal for RUB 420,000. The technical decision has been made; the price is still under review. The management forecast shows the expected costs under the chosen scenario and, separately, the unconfirmed commercial effect. If the manager has authorised a specific purchase, the commitment is linked to the same card so that when the invoice arrives it is not added again.

After the new price is agreed, the source and date are recorded. If part of the work is excluded, the corresponding quantities and the forecast of remaining costs change. The archived estimate remains available to explain why the total changed. The word “approved” by itself, without stating the subject of the decision, must not switch the entire financial forecast.

Both amounts are illustrative, in Russian roubles (RUB). The technical decision has been made, the commercial one has not, so the change does not yet have a confirmed margin. AI extracts amounts and qualifiers from correspondence and keeps the sources; the manager checks the limits of the approval and the calculation version. Training example: costs of RUB 300,000, a proposal to the client of RUB 420,000. There is no decision on the price yet, so the additional revenue is shown as unknown, not as zero.

What to check in correspondence about a change

For the pilot, take messages such as “accepted for review”, “we confirm the scope, the price will be clarified” and “no comments on the technical part”. For each, define the correct extraction result in advance. It is important that the model keeps the limitations, the addressee and the link to the specific attachment.

If a reply refers to an old version of the calculation, the assistant shows the version mismatch. The employee decides whether clarification from the counterparty is needed. A draft request can be prepared automatically, but sending it and any promises on price or timeline remain an action of the responsible person.

On a few anonymised changes, we will show a prototype register: technical decisions, amounts, versions and next actions will be visible separately.

Sources

Autodesk Help, summary of change order requests and financial states. EXON, working documentation approval process. Checked 18 October 2026. The article describes how to organise an internal process; it does not establish the legal procedure for a specific project.

Related reading: Construction cost forecasting: how much a project will earn by completion; A contractor's cash gap: how to link work, completion certificates and payments.

Частые вопросы ### Can a button in the portal count as the client's consent?

Only if this method, the authority and the consequences have been properly defined for the project. The interface does not establish this by itself. For internal records, keep the source and the limits of the decision.

What should be done with changes that have no price estimate?

Manage them separately with an uncertainty status and a person responsible for the calculation. A zero amount and the absence of an estimate are different states; they are not mixed in the summary.