Most tools sold as BOQ software are estimating spreadsheets with a database behind them. The difference shows up six months after the tender, when the BOQ has to answer what was executed, what was billed and what is still owed.
A bill of quantities starts as a pricing document: items, units, quantities, rates. Almost every tool handles that, because it is the easy half — it is a table.
The hard half starts the day work begins. The same BOQ now has to carry executed quantities against planned ones, absorb variations and rate changes, feed measurement records, drive interim billing, and account for retention held against each certified amount. That is four or five different jobs demanding one consistent line-item structure, and it is where most tools stop being useful and start being a source of disagreement.
The diagnostic question is simple: six months into a contract, can this tool tell me what item 4.7 was priced at, what has been executed, what has been billed and what is retained? If the answer requires opening a second file, the BOQ is not connected to anything.
The most expensive failure in BOQ management is not a wrong rate. It is two documents.
The estimating team prices a BOQ. The site team works from a printed copy. Variations are agreed by email. The billing clerk maintains a third spreadsheet to raise RA bills. Within a quarter, three versions exist, none is wrong exactly, and no two agree. The variance that surfaces at final account is not a cost overrun — it is a reconciliation failure that has been compounding since month one.
Software solves this only if there is genuinely one BOQ that all three functions write to. Ask any vendor to demonstrate a variation being approved and to then show the same line item on the estimating screen, the measurement screen and the billing screen. If those are separate modules that sync, ask what happens when the sync fails.
Between "work happened" and "work is billable" sits measurement. In Indian contracting that is the measurement book, and it is where BOQ software most often reveals itself as an estimating tool wearing a different label.
The failing pattern is re-entry: a supervisor records what was done in a site log or a diary, and someone later re-types those quantities into a measurement record. Two keystrokes of the same fact, entered by different people at different times, will diverge — and the divergence is discovered when a client certifies less than you billed.
What good looks like is a measurement entry that derives from work already recorded against the BOQ line, with quantity times rate computed rather than retyped. Ask specifically: where does the quantity in the measurement book come from? "The engineer enters it" is a different product from "it comes from the logged progress against that activity".
On most contracts variations are between 5% and 20% of final value, and they arrive under time pressure with incomplete paperwork. Software that models them as a note against the contract rather than as line items with their own quantities and rates cannot tell you your real contract value at any point in time.
Three things separate real variation handling from a text field. Variations should create BOQ line items, not annotations. They should carry their own approval state, so an executed-but-unapproved variation is visible as exposure rather than as revenue. And the contract value shown anywhere in the system should be the original plus approved variations, never the original alone.
Retention is deducted from every certified bill and released, in stages, long after. It is one of the largest amounts a contractor is owed and one of the least visible, because most systems store it as a percentage on the bill header rather than as money owed.
The consequence is that nobody can answer "how much retention is outstanding across all our projects, and when is it due?" — which is a working-capital question, not an accounting curiosity. The correct treatment is a posting to a Retention Receivable ledger account at the time of billing, separate from ordinary accounts receivable, with the defects liability period recorded so release dates can be tracked rather than remembered.
You can test any system in one minute: ask it for total retention outstanding by project, with expected release dates. If the answer is a spreadsheet, retention is not being tracked.
Indian contractors commonly price against published schedules — CPWD DSR and state PWD schedules — adjusted for location and market. Good software does not need to ship those rates, but it does need to accept a rate library, keep rate history so an old bill can be explained, and allow item-level overrides without breaking the link to the schedule item.
Beware any tool that presents a built-in rate database as a headline feature without saying when it was last updated. A stale rate library applied confidently is worse than no library.
In Rebota the BOQ is a live structure rather than an estimating artefact. Measurement entries sync from work-done quantities already logged against the linked site activity, calculating quantity times rate rather than requiring re-entry. Retention is posted to its own Retention Receivable ledger account when an RA bill is invoiced, so outstanding retention is a number you can ask for. Procurement, material consumption and billing all reference the same line items.
What it does not do: there is no critical-path scheduling, so if your programme is managed as a CPM network you will keep Primavera or MS Project alongside; and there is no BIM integration, so quantities come from the BOQ and the measurement book rather than from a model. If model-based take-off is central to how you work, that is a real gap and worth knowing before you evaluate further.
| Feature | Estimating spreadsheet | Generic ERP | Rebota |
|---|---|---|---|
| Price a tender line by line | With setup | ||
| One BOQ shared by estimating, site and billing | Copies diverge | Varies | |
| Measurement derived from logged site work | Re-typed | Usually re-typed | |
| Variations as line items with approval state | Notes | Varies | |
| Retention as a ledger account, not a percentage | Rarely | ||
| Retention outstanding across all projects | Rarely | ||
| Material consumption against BOQ items | With configuration | ||
| Critical-path scheduling | Sometimes | Use P6 or MSP | |
| BIM / model-based take-off | Sometimes | Not built |
Contractors whose BOQ has to survive execution — where measurement, variations, RA billing and retention all reference the same line items and are currently held together by spreadsheets and memory.
A firm that only needs to price tenders and hands execution to someone else. If the BOQ genuinely ends at submission, an estimating spreadsheet with a good rate library is cheaper and faster, and you should keep it.
If quantity take-off from a BIM model is central to how you estimate, or your programme is run as a resource-levelled CPM network, dedicated tools do those jobs properly and Rebota does neither.
One project at a time, one person maintaining the BOQ, and a client who certifies what you bill. Version drift is a problem of more than one person; below that threshold a spreadsheet is honestly fine.
The cost of BOQ software is rarely the licence. It is the discipline of recording site progress against BOQ items daily — without which measurement cannot derive from anything and you are back to re-entry with extra steps.
Judge BOQ software on what happens after the tender, not on how the estimating screen looks. Ask where measurement quantities come from, how a variation becomes a line item, and what retention is outstanding right now. Three questions, and most tools fail at least one.
The contractors who get most value from BOQ software do one unglamorous thing consistently: they record executed quantities against BOQ line items as work happens, not at billing time. Everything else — accurate measurement, defensible variations, real-time contract value, reliable retention tracking — falls out of that habit. Software cannot create the discipline, but it can make it a single entry rather than three, which is usually the difference between a habit that holds and one that lapses in month two.
