Bill of Quantities: From Specification to Estimate

The statement of work volumes (SWV) is a list of work items and materials for a construction project: name, unit of measure, quantity. It contains no prices, which is the main difference from an estimate: the statement answers what is being done and in what quantity, while the estimate converts those volumes into money through unit rates. The designer's specification is the third document in this chain: it lists products and materials by project section, but does not include work items, consumption coefficients, or non-modeled elements.

So a specification cannot be turned into a bill of quantities by renaming columns: between them sits reference and regulatory data with coefficients, maintained by the client, not the designer. Next, we explain where quantities come from in construction, what turns them into works and materials, how the bill reaches the estimate and the construction contract, what state review requires, who in a construction company owns this area, and how the bill is tied to construction cost.

Quantities come from two sources, and both are legitimate. The first source is the information model: geometry and element attributes are taken from the IFC export, and quantities are calculated by counting rules directly from the model. The second source is the designer's specification: when working drawings are issued in 2D and the model is kept for approvals, it remains the only carrier of design quantities.

The source is chosen not by ideology but by what the designer actually issues for a specific project. The mistake is to build the process only for the first route: on a significant number of projects there is no detailed model, and the estimate, contract, and procurement cannot wait. That is why the specification route is designed as an equal route with the same continuation: work and materials, unit rates, estimate, contract, actuals.

The specification has no coefficients, and that is the whole difference. The designer provides the design quantity: so many meters of cable, so many square meters of masonry, so many tons of reinforcement according to the design solution. Between that number and the quantity that must be procured, written off, and submitted for payment sits reference data with coefficients.

Coefficients can come from different sources: material consumption beyond the design quantity, cutting and waste allowances, reinforcement as a conversion from structural volume to steel mass, job complexity factors, and height. Each one turns a single specification line into several work and material lines, and the designer does not set any of them because that is outside their responsibility.

A separate category is non-modelled elements. Cable along the route, terminations, and small installation consumables are not in the model at all, but they exist in the estimate and on site. These items are added to the bill as a separate list, by standard or by calculation, and without that list the bill will always be incomplete.

For quantities to move from the specification into the bill, the designer does not need to switch to new software or retrain. What is needed is different: the specification must include attributes that identify each line unambiguously, such as element type, mark or classifier code, design solution, level, and project section.

The practical tool here is the reference form: an agreed specification output form with a catalog of allowed values for each attribute. The designer fills in the familiar document, but selects values from the catalog instead of typing free text. This removes the main cause of manual parsing: the same item no longer gets called five different ways by different designers.

As long as an attribute value is arbitrary, matching it to the work and rate catalog remains manual by definition. A reference form is not bureaucracy for its own sake, but a prerequisite for automated matching.

Automatic volume transfer is risky because it silently drops rows. An item for which no rule is found in the reference data simply does not make it into the statement, and this is usually discovered at month-end close or during an overspend review.

So completeness control is built not on trusting the mapping, but on explicit highlighting: the system shows specification lines that were turned into neither works nor materials. The list of uncovered lines is a working queue, not an error report: it is used to complete the master data, and on the next project the same items pass automatically. The same principle also applies to the model: not only the calculation result is checked, but also the set of elements between issued versions.

The statement turns into an estimate through unit rates, meaning the price per unit of work together with the resources that work includes. The key property of rates is that they are regional: the same work costs differently in different regions and with different contractors, so the rate directory is not one table for the whole country but a set of sets for each region, object type, and method of performing the work.

The practical conclusion to accept before starting is this: the unit rate catalog cannot be built 100 percent in advance. Trying to force it to completeness before the first project stops the project at the methodology stage. The workable approach is the opposite: the catalog starts with the scope already covered, and uncovered lines become a backlog for later completion. With each project, the share of automatically priced items grows, and manual analysis shrinks to truly new work.

Before the working documentation is issued, cost is still needed: without it, you cannot sign a contract or issue an advance payment. A pre-tender cost estimate based on high-level indicators and data from analogous projects closes this gap, and once the working documentation is issued, the high-level item is replaced by a full estimate, preserving the link from the early estimate to the contract and actuals.

Estimates and procurement start from the design documentation, while working documentation almost always differs from it in quantities. This is a normal project flow, not a designer error: the working docs refine the decisions, and quantities change accordingly.

The only question is whether the delta has been calculated or discovered. If the statement, estimate, and contract items are linked, the volume difference between the design documentation and the working documentation is visible for each item, and that difference becomes the basis for a revised estimate, an author sheet, or an addendum, with the reason for change, author, and date. Without that link, the only available tool is to recalculate the entire project from scratch.

Another case is closing a decrease and an increase in one act, when the removed and added quantities are processed in a single document. Without this, the contractor gets a month without closeout, and the client gets a gap in planned versus actual and in acceptance of work performed. To offset the decrease and increase, the estimate, contract, and actual items must again be linked: this is data discipline, not accounting cleverness.

The first question when setting up the process is not about software, but about people. A bill of quantities sits at the intersection of three functions: the PTO team is responsible for quantities and their confirmation on site, the estimating department handles rates and the estimate format, and the BIM team handles the model, attributes, and counting rules. None of the three roles can cover the bill on its own.

That is why the process needs an explicit owner: someone who maintains the master data with coefficients, the reference form for designers, and the queue of uncovered lines. Usually this is a production engineering specialist with an estimating background, or an estimator who understands the model structure, and less often a dedicated role in the BIM team.

Without such an owner, the predictable happens: every project rebuilds the statement from scratch, coefficients live in personal files, and the knowledge of why an item was calculated that way leaves with the employee. Software does not solve this problem; it only makes it visible.

The chain does not end with the estimate and the contract. Next, the estimate items must map to the financial codifier, the reference list of items in the project's financial model that management uses to track construction costs and project economics.

The gap here is just as manual as between a specification and a bill: one estimate with mixed works is assigned in full to a single cost item, and the economist later reconstructs after the fact who allocated the amount and where. The gap is closed by rules for mapping estimate items and cost elements to financial codebook items, splitting one estimate across multiple items, and preserving the link between the item and the cost code when a new version is issued.

The point is for construction cost to be accumulated as quantities move and close out, rather than being manually reconstructed at the end of the period.