Check an estimate before you send it
Put a priced bill through the validation rules, clear every warning and error, then export…
Establish which schedule of rates the contract is written against, load that one as a cost base, price the bill from it, and prove every line carries the schedule item it came from before the estimate leaves your desk.
5 steps across the platform - what you do at each one, and why it matters.
Read the tender conditions and record, against the contract, which schedule of rates governs it, which edition, and what price level it is stated at. Central government work names CPWD DSR; state work names the state PWD schedule; a private client may name neither and leave you on market rates.
Why: This is the one decision every later number depends on, and it is the one most often taken by assumption. Writing it down where the contract lives means the next person to open the estimate can see which document it was built from, instead of inferring it from the shape of the rates.
Bring the schedule into the cost database through the ordinary import surface and check it landed with its item numbers, descriptions, units and rates intact. No commercial schedule ships with the product, so this is your own copy or your own cost history, loaded once and reused.
Why: A schedule loaded as data can be searched, versioned and re-priced next year. A schedule transcribed into a spreadsheet column becomes a set of numbers with no provenance the moment the person who typed them moves on, and every query about a rate turns into an archaeology exercise.
Work down the bill sub-head by sub-head, from earthwork to external services, pulling each rate off the loaded schedule and keeping its item number on the line. Where no schedule item fits, price it as a non-schedule item and say so on the line rather than bending a neighbouring item to cover it.
Why: Non-schedule items are normal and are checked differently, by rate analysis rather than by lookup. Marking them at the point of pricing is what lets the department check the rest quickly and concentrate on the few that need argument, instead of treating the whole bill as unverified.
Validate the priced bill and read the findings. The India pack ships a rule that asks every priced line for its schedule item reference, so the lines you meant to mark as non-schedule and the lines you simply forgot both come back in one list.
Why: The difference between a deliberate non-schedule item and a forgotten reference is invisible in a printed bill and obvious in a validation run. Finding it here costs a few minutes; finding it after the tender is opened costs a technical query you answer under a clock.
Record the schedule and edition used, the price level and base date, the lead and lift assumptions, which items are non-schedule and how they were analysed, and what the estimate excludes.
Why: An estimate on a public job is read months later by somebody who was not in the room, often during a query about a single item. The basis is what turns that from a defence of your memory into a reading of the file.
Put a priced bill through the validation rules, clear every warning and error, then export…
Pull priced items from a real cost database, build the bill from them, bundle recurring bui…
Turn a single-point estimate into a range, run a Monte Carlo over the genuinely uncertain l…