Bill of Quantities: From Specification to Estimate

A Schedule of Quantities (SOQ) is a list of works and materials for a construction project: name, unit of measure, and quantity. It contains no prices, which is its main difference from an estimate: the schedule answers what is done and in what quantity, while the estimate converts those quantities into costs using unit rates. The designer’s specification is the third document in this chain: it lists products and materials for a project section, but it does not have to match the complete list of works required for the estimate.

Therefore, a specification cannot be turned into an SOQ simply by renaming columns: matching, quantity-takeoff, and completeness-check rules are required between them. The owners of these rules are defined jointly by the client and designer. Below, we examine where construction quantities come from, what turns them into works and materials, how the schedule feeds into the estimate and construction contract, what state review requires, who is responsible for this area in a construction company, and how the schedule relates to construction cost.

Let us examine two routes for obtaining quantities. The first source is an information model: element geometry and attributes are extracted from the IFC export, and quantities are calculated directly from the model using quantity-takeoff rules. The second source is the designer’s specification: when working documentation is issued in 2D while the model is maintained for approvals, the specification and drawings become sources 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.

A specification provides design quantities for products and materials: cable length, construction area, and reinforcement weight. To create an SOQ, match them to the works and check which operations are already included and which require a separate calculation.

Master data rules can cover different areas: material consumption and cutting, converting geometry into quantities, and linking a construction element to the works required to install it. Production complexity factors and building height may affect estimate coefficients, but do not themselves increase the geometric quantity in an SOQ. Design quantity, purchasing reserve, and rate coefficient should be stored separately, with the basis for applying each one.

A separate category consists of elements and works not included in a specific model. Route cables, termination devices, and minor consumables may be modelled; their presence depends on the brief, output scope, and level of detail. Items absent from the model are accounted for using specifications, drawings, or justified calculations. Before adding a separate list, verify that these items have not already entered the schedule from another source.

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 bill turns into estimate through unit rates, the price per unit of work together with the resources that the work includes. The key property of rates is that they are regional: the same work costs differently in different regions and from different contractors, so the rate reference is not one table for the whole country, but a set of sets by region, project type, and method of work execution.

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 construction management team is responsible for quantities and their confirmation on site, the estimating department is responsible for rates and the estimate format, TIMthe subdivision 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 be mapped to the financial codifier, the reference list of items in the project's financial model that management uses to review cost construction and the project's 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.

Everything described above is the work of one person on one project. Across a portfolio of projects, the same work looks different, and its problems are different too.

Counting rules and master data live in estimators' heads, not in the system. As long as the person is there, everything matches; when they leave or the number of projects grows beyond what they can keep up with, the knowledge leaves with them, and a new specialist calculates in their own way. A mismatch between two bills for the same node is not an arithmetic error; it is the absence of a single reference data set.

Discrepancies between design documentation and working documentation surface late. The quantity delta is discovered after work has already started and is closed with a revised estimate instead of a planned one. The later the delta is found, the more it costs: at the design stage it is a model revision, and on site it is money and time.

The project's cost becomes known only after the fact. Until the bill is reflected in the financial codifier, plan-versus-actual by cost item is assembled manually by the reporting date, not at the moment when the decision can still be changed.

So the manager's question is not whether the bill was calculated correctly, but how many days pass before we learn about a change in quantities and how many projects one estimator can handle without losing quality. If the answer to the first question is weeks and to the second is one or two, the issue is not the people: the path from the model to the cost item has not been assembled as a system. What it includes and what it looks like end to end is shown in the diagram above.