What is a construction schedule of values? A guide for specialty contractors

What is a construction schedule of values?

A construction schedule of values, often shortened to SOV, is a table that divides the signed price of a contract or subcontract among portions of work. Each row is an SOV line. The line has a description, a value, and a method for measuring progress.

The specialty contractor usually prepares the SOV from the signed price and scope, meaning the work included in the contract and the work excluded from it. Depending on the contract, the customer may be a general contractor, an owner, or another named party. The customer checks whether the lines describe the work and whether the total matches the agreed price.

In this guide, the approved price is the signed price adjusted only by changes that the project process allows the team to add. A price estimate that is still under discussion does not change the total.

The SOV therefore answers one practical question: how much of the approved price belongs to each measurable portion of the work? It helps the project manager prepare proposed progress values and helps the reviewer understand the amount.

A project may instead call this table a cost breakdown, contract-price breakdown, or schedule of values and work performed. Use the term and form named in the contract and current customer instructions. In Quebec French, teams may call it a ventilation des coûts de construction or ventilation du prix du contrat. The Grand dictionnaire terminologique lists ventilation des coûts as a French term for a cost breakdown.

Similar records with different jobs

Swipe horizontally to view all columns.

Which actors, records, and states should stay separate?

This section separates the records that follow one another. A version is an identified, dated copy of the table. A stable ID is a short code that does not change when someone later clarifies a line description.

A reliable SOV includes at least:

• a contract or subcontract with one approved value at a point in time;
• an SOV version, such as SOV-v1;
• many SOV lines with stable IDs, scope, scheduled value, and measurement method;
• progress records connected to one line and one cut-off date;
• a payment-application version that uses one identified SOV version;
• a review or decision tied to the version that was submitted;
• an invoice and a payment tracked separately under the contract and accounting process.

One line can have many monthly progress records. One contract can also have many SOV versions. Keep those relationships visible. If SOV-v2 replaces SOV-v1, retain the first version and its submission proof. Do not silently edit the earlier file.

A simple state sequence

1. Draft: the estimator or project manager builds the lines.
2. Ready for internal approval: scope and total checks pass.
3. Approved for submission: an authorized person approves this exact version.
4. Submitted: the file, date, recipient, and proof are retained.
5. Accepted: the project-designated actor accepts that version under the applicable process.
6. Superseded: a later accepted version becomes active while the older history remains intact.

The person who prepares the SOV should not be its only reviewer. The project manager confirms that each line describes the work and can be measured. The billing coordinator or controller checks the values. An authorized person then approves the exact copy that will be sent to the customer.

How do you build the SOV before the first application?

1. Start with the project instructions

Read the subcontract, purchase order, technical description of the work, payment terms, and customer template. Capture:

• the required format and level of detail;
• the categories or codes the customer requires for organizing the work;
• how the project treats site set-up, technical documents, materials, testing, and end-of-project documents;
• the expected measurement method for each type of work;
• who reviews and who accepts the SOV;
• when the project requires it.

This guide does not set a deadline. Use the signed contract and current written instructions.

2. Cover the signed scope exactly once

Start with the approved scope. Identify the systems, areas, phases, and deliverables that make up the work. Every item should appear once, without double counting.

Mark exclusions and work by others. One line called “electrical work” hides too much. A line for every support and connection becomes impossible to maintain. Choose enough detail for the field team to measure and the customer to review.

3. Create lines with observable completion

A strong line describes an outcome, not only an expense. Examples include:

• distribution panels and feeders;
• branch circuits and devices;
• lighting and controls;
• testing, commissioning, and closeout records.

Do not combine equipment procurement, installation, and commissioning in one line when the project will measure those events separately. If the customer treats them as one result, keep one line and define clear milestones within it.

4. Give every line an ID, value, and rule

An ID such as EL-200 remains stable when the wording is refined. Add:

• the scheduled value before tax;
• the measurement basis, such as installed quantity, cumulative percentage, or completed milestone;
• the expected supporting documents;
• the person who confirms progress;
• the drawing, specification, or scope reference.

A line can be measured by a completed quantity, a defined step, or a reviewed percentage. For example, the team may count installed metres of pipe, confirm that a test is complete, or verify that two of four agreed steps are finished. The guide on how to measure construction progress provides more detail, but this explanation is enough to prepare the SOV lines.

5. Tie out the total in both directions

First, add the scheduled values. The result must equal the current approved contract value. Then start with the contract total and subtract every line. The remaining balance must be zero.

Keep pending changes in a separate log. A pending change is a possible alteration whose work, price, or approval is not yet settled. Only a change approved under the project process can alter the active SOV. The construction change tracker explains that process in more detail.

6. Review the allocation, not only the arithmetic

An exact total can still hide a weak breakdown. Ask:

• Is a large amount placed early in the project without a clear connection to delivered work?
• Does closeout retain enough value to be measured honestly?
• Do two lines include the same equipment or labour?
• Does a broad line absorb work that reviewers need to see separately?
• Do the values express the agreed price allocation without implying that internal cost is a contractual rule?

Do not move value artificially into early periods. Use an allocation the team can explain, measure, and support under the contract.

7. Approve and freeze the version

A second person reviews the scope, values, measurement methods, and references. An authorized person then approves the exact file. Assign a version number and preserve its file name, date, and submission proof.

When the customer accepts the SOV, mark that version active. Do not open the first payment application from an old draft.

What does a complete, reconciled example look like?

Consider a fictional CAD 480,000 electrical subcontract before tax. The values only demonstrate the model. They are not a recommended allocation for a real project.

Swipe horizontally to view all columns.

Now assume the team confirms progress for a new payment application. Prior cumulative is the value of work shown in the previous application. Current period is the value added since that application. New cumulative is the sum of the two.

Consider line EL-100, which is worth CAD 96,000. The previous application showed 50%, or CAD 48,000. The new measurement shows 60%, or CAD 57,600. The proposed current-period value is CAD 9,600. This is a proposed value before tax. It is not yet an amount accepted by the customer, an invoice, or a payment.

The new cumulative percentages are 100% on EL-001 and EL-010, 60% on EL-100, 35% on EL-200, 10% on EL-300 and EL-400, and zero on the final two lines.

Swipe horizontally to view all columns.

The CAD 156,000 cumulative value equals 32.5% of CAD 480,000. The current-period amount is the difference between the two cumulative values. This example excludes taxes and holdback, which is a portion the contract or applicable rules may temporarily withhold from payment. It also excludes pending changes, invoicing, and payment. Those items depend on the project. The complete construction progress billing cycle explains how they fit into an application.

Which table can you copy?

To start simply, use five columns:

Line ID | Work included | Value before tax | How progress is measured | Supporting document

Then add the columns needed to carry the SOV through later applications:

Keep assumptions, exclusions, and drawing references in separate fields. Do not bury them in one long description that cannot be filtered.

Should you split a line?

Swipe horizontally to view all columns.

The right number of lines depends on the contract, trade, project size, and customer review process. A generic template cannot decide that level for you.

Which checks should pass before approval?

Calculation checks

• The lines total the current approved contract value.
• No line has a negative value unless an approved rule and revision clearly require it.
• Every cumulative line value remains between zero and its approved scheduled value.
• Prior cumulative, current period, and new cumulative values reconcile exactly.
• The total balance to finish equals the approved price less the cumulative value.
• Pending changes do not alter the active total.

Scope checks

• Every portion of the work appears once.
• Exclusions and work by others are visible.
• Every line has observable completion and a measurement method.
• Mobilization, materials, testing, and closeout follow project instructions.
• A large early-project value connects to real, verifiable work or a deliverable.

Governance checks

• The file has a version number and date.
• The preparer, reviewer, and approver are named.
• Internal approval identifies the exact file.
• Submission proof and customer acceptance remain separate records.
• The first payment application uses the accepted version, not the latest file found on someone's desktop.

How do approved changes and later cycles work?

For the first application, start from the SOV accepted by the person named in the project instructions. For later applications, start from the last submitted application and the same SOV. The new application begins with the previous cumulative values and adds only the work from the new period. Do not start from a blank table.

When a change is approved under the project process:

1. retain the current accepted SOV;
2. create a new version, such as SOV-v2;
3. add a stable line for the change, or alter an existing line only when the accepted instruction requires it;
4. reconcile the new SOV total to the revised approved contract value;
5. review, approve, submit, and obtain acceptance for the new version;
6. mark the older version superseded without deleting it.

Each payment-application version should reference exactly one SOV version. The same active SOV may support several applications. If an application already submitted used SOV-v1, preserve that link after SOV-v2 becomes accepted. A later application can use the new version when the project process allows it.

After submission, keep four amounts or events separate: the amount requested by the contractor, the amount accepted by the person designated under the contract, the invoice created under company procedures, and the payment received from the customer. The payment application tracker provides a table for this follow-up. The SOV continues to explain the work lines, while the accounting system remains the official source for invoices and payments.

What do current Canadian official sources show?

Requirements vary by contract. The following sources are concrete examples, not universal rules.

A March 2025 National Research Council mechanical specification requires a cost breakdown for approval at the first site meeting. It connects that breakdown to current-period and cumulative amounts and percentages by discipline. That requirement belongs to the specific project.

Public Services and Procurement Canada's current form 1792 separates item number, description, unit, current and cumulative quantities, unit price or value, and current and cumulative values. It illustrates why the line table should preserve cumulative facts without mixing tax, holdback, and prior payments into the scheduled value.

For private-sector projects only, the National Master Specification document descriptions place schedule-of-values procedures within payment procedures alongside progress payments, unit-price items, holdback, and final payment. This supports an important boundary: the SOV is one controlled input to payment. It is not the entire billing cycle.

Use the signed contract, current form, and written instructions to build your own SOV. Obtain qualified advice when a question involves rights, deadlines, holdback, tax, invoices, or remedies.

Pre-first-application checklist

Frequently asked questions

What is the difference between a schedule of values and a construction schedule?

The SOV allocates contract value. The construction schedule organizes activities over time. They may use the same systems or phases as references, but the records are not interchangeable.

Must a contractor disclose internal costs and margin?

Not automatically. The SOV allocates price according to the project form and requirements. Your estimate may contain different internal data. Confirm what the contract requires before disclosing cost, margin, or unit-price detail.

How many SOV lines should you create?

Use enough lines to measure and explain the work without making the table impossible to maintain. Split portions that have different measurement methods, evidence, review timing, or blocking conditions.

Can the SOV change after the first application?

Create a new version when the project process allows it. Retain the version already submitted and every application that used it. Reconcile the new version to the approved value, then obtain the required approvals.

Can a pending change increase the SOV total?

Not in this operating model. Keep the change and its estimate in the change log. Add it to a new SOV version only after the approval required by the project.

Does an accepted SOV prove an amount is payable?

No. It organizes contract value and helps review progress. The contract, work completed, supporting documents, payment decision, and applicable rules determine what follows.

Official sources and scope

• Office québécois de la langue française: ventilation des coûts
• National Research Council: mechanical specification, cost breakdown and payment application, March 2025
• Public Services and Procurement Canada: request for progress payment, form 1792
• National Research Council Canada: National Master Specification document descriptions

This content is for general information. It is not legal, tax, accounting, or contract advice. Verify the contract, current form, and project-specific advice.

Sources verified on September 1, 2026. To report a correction, contact Aplon.

Free Excel workbook

A workbook for your next payment application

Track progress, holdback, GST, and QST in one Excel file.

Email

Website

Get the workbook

Keep the workbook. Automate the cycle when you are ready.

Use the workbook now. When the manual handoffs become the bottleneck, Aplon connects field progress, review, approval, submission proof, and collection follow-up.

A person still approves every external commitment.See how Aplon controls the cycle