Every architecture practice in India runs on BOQs, and almost every one of them builds those BOQs in Excel. Which would be fine if a bill of quantities were a static document, but it isn't. It's a living thing that changes every time a drawing revises, a client value-engineers a finish, or a contractor comes back with rates, and Excel handles the arithmetic while quietly destroying the one thing that matters most: knowing which version of the quantities matches which version of the design. So let me talk about what BOQ software for architects should actually do, because the answer is more specific than "not Excel".
What a BOQ really is, and why Excel breaks it
A BOQ is the bridge between design and money: an itemised list of every work item and material with quantities, units and rates, used for budgeting, tendering and contractor payment. The idea is old and solid. The failure is operational, and it happens in three predictable places.
First, versioning. Drawing revision R3 changes the toilet layout, quantities shift, and now there are two BOQ files in the folder, one matching R2, one matching R3, both named "final". The contractor prices one, the client approved the other, and the difference surfaces at billing time as a dispute nobody can adjudicate because nobody can prove which sheet was current when.
Second, rates. Rates in a spreadsheet are typed once and rot silently. Steel moved, the laminate vendor revised, and your BOQ still confidently totals last quarter's numbers. Every downstream decision inherits the error.
Third, traceability. When the contractor's RA bill arrives claiming 340 square metres of flooring, can you trace that line back to the measured quantity, the agreed rate and the drawing it came from, in minutes? In Excel-land, that's an evening of archaeology per bill.
The six things BOQ software must do
Here's my checklist, in priority order, for an Indian practice evaluating anything that calls itself BOQ software:
| Capability | What it means in practice | Why it matters |
|---|---|---|
| Linked to design | Quantities tie back to the drawings and specs they came from | Revisions propagate instead of forking |
| Versioned | Every BOQ revision preserved, clearly superseding the last | Disputes resolve by record, not memory |
| Live rates | Rates update in one place and flow everywhere | No stale totals driving decisions |
| Comparison-ready | Contractor quotes compared line by line against your BOQ | Tendering in hours, not days |
| Connected to POs | Approved lines become purchase orders without re-typing | The order matches what was priced |
| Connected to billing | Quantities and rates feed client invoices and stage fees | RA-bill checking becomes verification |
Read that last column top to bottom and you'll notice something: none of the value is in the arithmetic. Excel does arithmetic perfectly. The value is entirely in the connections, design to quantity to rate to order to bill, which is exactly the thread a spreadsheet can't hold.
The revision cycle is where the hours go
Let me put rough numbers on the pain, because principals consistently underestimate it. A mid-size residential or commercial project might see four to six meaningful BOQ revision cycles: concept budget, post-design-development, tender issue, post-negotiation, and one or two mid-construction changes. Here's where the time goes per cycle in an Excel practice:
Call it 18 hours a cycle, five cycles, that's 90 hours per project of senior-ish time spent maintaining a document instead of designing. Multiply across your live projects and the number stops being funny. This is the same tool-sprawl tax I keep writing about, and the full argument for consolidating it lives in why one connected system beats five disconnected tools.
BOQs don't live alone: the drawing and billing connections
Two connections deserve special attention because they're where practices bleed.
The drawing connection: a BOQ is only as current as the drawings it measures. If your drawing management is folders and email, your BOQ versioning problem is unsolvable, because the upstream is unversioned. Fix both together, and I've laid out the drawing half in working drawings management for architects.
The billing connection: for practices that bill fees on stages and also manage execution, the BOQ feeds two money streams, the client's cost plan and the contractor's payments, and eventually your own invoices. When the BOQ lives in the same system as billing, a completed stage or a delivered scope becomes a compliant GST invoice in one click, a flow I detailed in how to turn a quote into a GST invoice in minutes. When it doesn't, month-end means re-typing quantities into an invoice template and praying.
What about the heavyweight QS tools?
There are serious quantity-surveying and estimation platforms out there, built for large contractors and cost consultants, and if you're a QS firm doing infrastructure work, they're the right category. For an architecture practice of five to twenty people, they're usually the wrong shape: per-seat dollar pricing, a learning curve measured in months, and no answer for the rest of your practice, drawings, site, client approvals, GST billing. You'd be buying a very sharp knife when what you need is a kitchen.
The practice-sized answer is BOQ capability inside a connected workspace. In Designa, specs are built room by room and item by item with live costs, those lines carry quantities and rates, procurement turns approved lines into POs and tracks them to delivery, and billing draws from the same source. One thread from design to money, priced as one flat founding price for the whole studio, billed in rupees. For the wider evaluation, my buyer's guide for studio software in India gives you the full scorecard, and practices in a metro context might want the Mumbai-specific take too.
One more thing on credibility: BOQ discipline isn't just internal hygiene. Registered practices answerable to the Council of Architecture and firms whose work spans architecture and interiors, the overlap community that bodies like the Institute of Indian Interior Designers serve, increasingly face clients who audit numbers. A traceable BOQ trail is professional armour.
Key takeaways
- The BOQ's value is in its connections, design to quantity to rate to PO to bill, and spreadsheets cannot hold that thread
- Versioning is non-negotiable: every BOQ revision must visibly supersede the last and tie to a drawing revision
- An Excel practice spends roughly 90 hours per project just maintaining BOQ revisions
- Heavyweight QS platforms are the wrong shape for a small practice, connected workspaces are the right one
- Fix drawing management and BOQ management together, the second is unsolvable without the first
Frequently asked questions
What is BOQ software for architects?
Software that manages bills of quantities as living, versioned data connected to drawings, rates, purchase orders and billing, instead of static spreadsheets that fork with every revision.
Can I keep making BOQs in Excel?
You can, and the arithmetic will be fine. What you lose is traceability: which quantities match which drawing revision, which rates were agreed, and whether the contractor's bill matches any of it.
How does Designa handle BOQs and quantities?
Specs are built room by room with quantities, units and live costs, approved lines flow into purchase orders and tracked deliveries, and the same data feeds GST-compliant client billing, so nothing is re-typed.
How many BOQ revisions does a typical project go through?
Four to six meaningful cycles is common: concept budget, post-design-development, tender, post-negotiation, and mid-construction changes.
If your BOQs currently live in a folder full of "final" spreadsheets, you don't have a quantities problem, you have a connections problem, and it's very fixable. See how specs, quantities, POs and billing run as one thread at demo.designa.work, and the founding offer, one flat price for the whole practice billed in rupees, is at go.designa.work.