The Bill of Quantities is the most precise numeric description of a project you will ever get: every item, its quantity, its unit, its rate. And yet in most firms it lives its entire life inside one spreadsheet — priced before award, then forgotten until the first valuation is due. The result is familiar: you learn the project is losing money three months after it started losing money. This guide is about keeping the BOQ alive.
Key takeaways
- The gap between an item’s rate and an item’s cost is the gap between knowing your margin and knowing why it moved.
- Measuring progress in installed quantity — not an estimated percentage — is what makes a valuation defensible.
- A stable coding structure (WBS) is the precondition that makes cost-to-item attribution possible at all.
- Variations that never enter the BOQ become work you performed for free.
- A weekly quantity update surfaces a cost overrun in two weeks instead of three months.
What the BOQ is actually for
A Bill of Quantities is, first, a contractual document: it decomposes the works into measurable items so every tenderer prices the same scope and the employer can compare bids on one basis. That is its well-understood job.
The second job matters far more to the contractor, and is the one that gets neglected: the BOQ is the measurement structure for the entire project. Every item carries a contract quantity, an installed quantity and a remaining quantity. The sum of (installed quantity × rate) across all items is your earned value — the only number that honestly tells you where you stand.
An item’s rate is not an item’s cost
The single most expensive confusion in contracting is between these two numbers. The rate is what you get paid: direct cost + overhead + margin + risk allowance. The cost is what you actually spend: materials, labour, plant, subcontractors.
Track only the rate and you will know the project is losing money without knowing which item caused it. Track cost only at project level and the information arrives far too late to act on. The one useful measurement is cost per installed unit, per item, against the estimated cost per unit.
| Component | Estimate at tender | Actual at 40% complete | Variance |
|---|---|---|---|
| Materials (per m³) | SAR 390 | SAR 412 | +5.6% |
| Labour (per m³) | SAR 145 | SAR 188 | +29.7% |
| Plant (per m³) | SAR 60 | SAR 55 | −8.3% |
| Total cost | SAR 595 | SAR 655 | +10.1% |
| Sell rate | SAR 750 | SAR 750 | — |
| Item margin | 20.7% | 12.7% | −8 points |
That table tells you something a gross-profit report never will: the problem is labour, not materials. The item is still profitable, but eight points of margin are gone, and if the same rate holds across the remaining 60% you already know the final number today rather than at handover.
Coding: the precondition for everything else
You cannot attribute a material invoice or a labour hour to an item unless the item has a stable code. Ad-hoc naming — “Concrete 1”, “Concrete A”, “Basement concrete” — is the number-one reason cost reports never reconcile with reality.
Build the WBS before you price
Break the project into fixed levels: project → building/phase → floor → work activity. The item code inherits the full path, so 02-B-03-CONC-005 is both readable and aggregatable.
Fix units of measure centrally
m³, m², lm, tonne, number — a closed list nobody extends mid-project. A unit that differs between estimate and execution invalidates every comparison downstream.
Map every item to exactly one cost category
Materials, labour, plant, subcontractor, overhead. An invoice entering the system posts against both the item and the category, so analysis is possible without manual re-classification.
Freeze codes after award
The code is a contractual key. Editing it post-award severs the historical data chain and makes valuation-to-valuation comparison impossible.
Measuring progress: quantity, not percentage
Ask a site engineer “how much of the waterproofing is done?” and the answer is usually “about 70%”. That number is a mental estimate, and it is structurally optimistic early and pessimistic late — the phenomenon known as the 90% syndrome, where a project sits at 90% complete for months.
The fix is simple: stop asking for a percentage, ask for a quantity. “How many square metres of waterproofing have been installed and approved?” is a verifiable number, and percent complete is derived from it arithmetically — not the other way round.
- Installed quantity is captured in the daily site report, not reconstructed in a month-end meeting.
- Approval precedes valuation: quantity the consultant has not signed off does not enter the payment application.
- Percent complete = installed quantity ÷ forecast quantity at completion, not ÷ contract quantity.
- High-value items get measured weekly; low-value items are fine monthly.
The choice of denominator in the third point is exactly what hides overruns. If the contract quantity is 1,000 m³ but you forecast finishing at 1,200 m³, then 600 m³ installed is 50% of reality, not 60% of the contract.
Variations: where the margin leaks out
Every project changes. The problem is never the change itself — it is that the change gets built on site before it enters the BOQ. The engineer receives a verbal instruction, the crew executes it, and when the valuation is prepared there is no item carrying that work. Its cost comes straight out of the project margin.
Record the instruction the day it is given
Even before it is priced: who instructed, what they instructed, on what date. Late documentation of a variation weakens your contractual position regardless of the merits of the claim.
Price it against contract rates first
If a comparable item exists in the BOQ, use its rate — that is what the consultant will accept with the least argument. Genuinely new items need a detailed rate build-up.
Push the approved variation into the BOQ immediately
An approved variation becomes a first-class item: code, quantity, rate, measurement. Anything outside the BOQ stays outside the valuation.
Track pending variations as declared exposure
Work executed under a not-yet-approved variation is money at risk. Show it in the monthly status report as its own line, never folded into forecast revenue.
The weekly rhythm that makes it work
All of the above collapses if the update cycle is monthly. A monthly cycle means a variance is discovered four weeks after it starts — four weeks of materials and labour already spent against it. A weekly cycle shrinks that window to days.
| When | Action | Owner |
|---|---|---|
| Daily | Record installed quantities in the daily report | Site engineer |
| Sunday | Post material invoices and labour hours against items | Cost controller |
| Tuesday | Review every item whose variance exceeds 5% | Project manager |
| Thursday | Update forecast quantity at completion for critical items | Cost controller |
| Month end | Build the valuation from cumulative approved quantities | Project manager |
What this looks like in muqawil
The BOQ module in muqawil is built on exactly this model: every item carries its code, unit, contract quantity and rate, and progress is recorded as installed quantity — straight from the daily site report, including reports written with no connectivity and synced later.
- Items are bilingual at the database level (Arabic and English descriptions as separate columns, not an interface translation).
- Items link to approved expenses, so cost variance surfaces per item rather than only per project.
- Approved change orders are added to the BOQ as items, so they flow into the valuation automatically.
- One-click Excel export for the accountant or auditor, with no manual re-keying.
The point is not that the tool solves the problem by itself — the weekly cadence and the coding discipline are what solve it. The tool makes following them cheaper than ignoring them.
Frequently asked questions
What is the difference between a BOQ and a cost estimate?
The BOQ is a contractual document describing the works at the sell rates agreed with the employer. The cost estimate is an internal document describing what you expect to pay to deliver that same scope. The first defines your revenue, the second defines your margin — and you need them linked through a shared item code.
How often should installed quantities be updated?
Weekly for the items carrying most of the contract value, monthly for the rest. A blanket monthly update surfaces variances only after they have already consumed four weeks of resources.
Can a BOQ be used on lump-sum contracts?
Yes, and it is very useful there. On a lump-sum contract the BOQ does not determine what you get paid, but it remains the best structure for internal progress measurement, for allocating value across payment milestones, and for assessing the effect of any change on the total price.
How do I handle an item built in a larger quantity than the contract quantity?
The excess is either a re-measurement covered by the contract conditions (valued at the contract rate, often up to a stated threshold) or a scope change requiring a variation. Decide which one early and document it, because work executed before that classification is what typically turns into a rejected claim.
What is the simplest starting point if we are on spreadsheets today?
Fix the coding first, then add two columns to your existing file: cumulative installed quantity, and forecast quantity at completion. Update them weekly. Those two columns alone give you about 80% of the benefit before you change any tooling.
Try a living BOQ instead of a spreadsheet
Create a project in muqawil, load your items, and connect daily site progress to installed quantities — in Arabic and English, and it works on site with no signal.