QS and Estimating handbook

QS answers four questions:

• How much is there? Measured from drawings, from a model, or from first principles.
• What does it cost? Rates built from resources, not typed from memory.
• What do we charge? Direct cost plus the markups that make a tender price.
• How confident are we? An estimate with no stated accuracy is a guess wearing a suit.

Because ConstruC is department-first, QS owns the estimate and the bill while Finance owns the money and Site owns the works. The bill is the hinge the whole platform turns on.

The one idea to hold onto. A rate is not a number, it is a build-up. When a rate comes from resources through an assembly, changing the price of cement updates every wall that uses it. When a rate is typed straight in, nothing updates and nobody can see where it came from.

---

FIG 2.1 — the estimating loop. It re-enters at takeoff whenever the drawings change, which is what incoming sets are for.

---

FIG 3.1 — the QS link map. Design supplies what to measure; the bill becomes the budget, the shopping list and the progress yardstick.

---

Before anything is measured, the scope says what is being built, in the team's own words — phases and items, from a template or written from scratch.

It matters more than it looks: the programme is generated from the scope, not from the bill. A bill line is a thing to be priced; a scope item is a piece of work to be sequenced. Keeping them separate is what stops a measurement line turning into a schedule activity nobody can build.

---

A project can hold several estimates. Each has a type, a status and a lock:

Status and lock are separate on purpose: an estimate can be marked final while remaining open for a correction, and locking it is the deliberate act that stops all writes. Once locked, every write path refuses with a conflict rather than quietly editing a submitted tender.

FIG 5.1 — status and lock are separate. Final says the work is done; locked says nobody can change it afterwards.

Which estimate is authoritative. The project's current estimate — the first one created — is what the rest of the platform reads. That is what the material schedule is generated from and what the drift banner counts against.

>

This is called out because it used not to hold. "Generate from BoQ" pooled every estimate in the project, drafts included, so on a real project a material called External works — hubcr2 reached the live procurement schedule from a draft named Manual test 2. Procurement was planning to buy against an estimate nobody had finalised. Both paths now read one estimate.

---

Sections, and items within them. A measurable item carries a description, a unit, a quantity and a rate; the amount is quantity times rate. Section headers carry no money — they total what is beneath them.

Every priced line is a position, and positions are what the platform counts when it judges how complete the estimate is.

Export produces the bill in the format a client or a subcontractor expects, so the estimate leaves the platform looking like a bill rather than a screen capture.

---

Direct cost is not the price. Markups sit in an ordered list and each one compounds on the running total, which is how a tender is genuinely built:

That is 4,500,000 of direct cost becoming 6,988,795. Overhead is 7% of the direct cost plus preliminaries, not 7% of the direct cost — which is why the order matters and why the list is ordered rather than a set.

Markups are either a percentage or a fixed amount, and are categorised (preliminaries, overhead, profit, contingency, insurance) so a tender can be analysed rather than just totalled.

FIG 7.1 — each markup applies to everything before it. Reordering the list changes the price.

Compare it to the contract. The tender price and the signed contract value are different numbers and will not match. Knowing the gap is part of the job.

---

The firm's library of what things cost, by type: material, labour and plant. Each carries a code, a name, a category and a rate.

Resources are the bottom of the build-up. Change a resource's rate and every assembly that uses it re-prices — which is the whole reason for keeping rates here rather than typing them into lines.

Prices can be imported in bulk, and every change keeps its history, so "what were we pricing cement at in March" is answerable.

---

An assembly is a recipe for one unit of work: what resources it consumes, and how much of each. One square metre of 200mm blockwork is blocks, mortar, a mason's hours and a labourer's hours, in fixed proportions.

Price the assembly and you have a rate with a visible derivation. Use it on a bill line and the line inherits that rate.

FIG 9.1 — the build-up chain. The dotted path is the payoff: one resource price moves and every line built on it follows.

This is the difference between an estimate you can defend and one you can only assert. When a client asks why blockwork is priced where it is, an assembly answers; a typed rate does not.

---

Measure quantities directly off the drawing rather than off a printout with a scale rule.

The sheet is calibrated first — you give it a known dimension and it works out the scale — and measurements taken after that are real. Lines, areas and counts become takeoff lines, and takeoff lines become bill items with their measurement attached.

That attachment is the point: a quantity that carries its measurement can be checked. A quantity typed into a cell cannot.

FIG 10.1 — a quantity that carries its measurement can be re-checked; one typed into a cell cannot.

A locked estimate refuses new takeoff. The guard fires before the bill item is created, so a locked tender cannot grow a line by the side door.

---

Where a 3D model exists, quantities can be extracted from it directly — the model already knows how many square metres of wall it contains.

Model-derived quantities carry their provenance, which matters when the model is revised: you can see which lines came from geometry and which were measured by hand.

---

Gross floor area, priced against a rate per square metre by building type — residential, office, warehouse, school — for an order-of-magnitude figure before anything is measured.

It is deliberately crude, and the platform says so. A GFA figure is a check on a detailed estimate, never a substitute for one: if the measured bill and the GFA figure are far apart, one of them is wrong and it is worth knowing which before the tender goes out.

---

Design issues a revision. The incoming-sets view is where QS finds out, and it distinguishes an issue from a revision — a new set to measure versus a change to something already measured.

FIG 13.1 — the impact view is the difference between re-measuring three lines and re-measuring the estimate.

Each incoming set carries an impact view: what in the bill relates to the sheets that changed. That is the difference between re-measuring the whole estimate and re-measuring the three lines that moved.

---

The platform will tell you, in three ways.

AACE class. The international standard for estimate maturity, from class 5 to class 1:

FIG 14.1 — the class is computed from the work actually done, which is why it cannot be talked up.

The class is derived, not chosen: it comes from how many positions are priced, how many carry a resource build-up, and how many are classified. You cannot declare an estimate accurate; you earn the class by doing the work.

Stale rates. Lines whose rate has not been touched while the underlying resource price has moved. A rate that was right in March is not automatically right today.

Validation runs. A rule set over the bill producing passes, failures and warnings. Failures are errors. Warnings are softness — a line with no unit, a quantity with no measurement behind it, a rate with no build-up. A run with no failures and hundreds of warnings is not a clean bill; it is a bill nobody has hardened yet.

---

Bill items can be classified against recognised standards — NRM 1 among them — so the estimate maps onto the structure a client, a cost consultant or a benchmarking database expects.

Classification is also one of the inputs to the AACE class, because an estimate you can compare to others is more defensible than one you cannot.

---

Work packages and their owners, shared with other departments. QS uses it to see who owns the packages being priced, so a query about scope goes to a person.

---

Locking is the control that matters. A locked estimate refuses every write path — takeoff, classification, item edits — with a conflict rather than a silent change. Lock a tender when it goes out.

Roles.

Your company's data is yours alone. Every estimate, rate, assembly and takeoff line carries the company that owns it, and every query is scoped by it. Which company you belong to comes from your signed-in session, never from anything the request can set.

Department boundaries hold. A QS lead reads QS, the drawings they measure from, and the shared programme. Finance, procurement, site and equipment screens are refused at the data layer.

One deliberate exception. RFIs use a universal view permission with an own-rows rule applied underneath: design sees every RFI on the project, and everyone else sees only what they raised, were assigned, or that is aimed at their department. A QS lead therefore sees their own questions to design and nothing else — which is the point, since a QS query about a dimension is QS's business and design's, not the whole firm's.

---

The working discipline

1. Write the scope first — the programme comes from it, not from the bill.
2. Price through resources and assemblies, not by typing rates.
3. Calibrate before measuring.
4. Watch incoming sets — a revision you did not re-measure is a claim later.
5. Read the warnings, not just the failures.
6. Lock the estimate when it goes out, so what you sent is what stays.
7. Know which estimate is current — it is the one the rest of the platform reads.

---

This handbook describes QS & Estimating as built. Where the platform states an AACE class or a warning count, that is it telling you how much weight the number can carry.