The Bill of Quantities (BoQ) and Terms of Payment (ToP) are usually drafted by contracts and procurement teams, often before the detailed schedule is finalised. This sequencing creates a structural risk: payment milestones defined without a precise reference to the schedule activities that actually make them achievable.
The symptom: a payment milestone you can't prove
The most common case: a ToP specifies payment at "50% mechanical completion," but no schedule activity is explicitly designated to measure that threshold. At invoicing time, contractor and client don't share the same reading of actual progress, and the disagreement gets settled by negotiation rather than verification — a situation that could have been avoided had the payment milestone been tied, from the schedule structuring stage, to one or more clearly identified deliverables (completion of a specific activity package, a passed test milestone, an approved document).
Structure the WBS around payment milestones, not the other way around
Good practice is to bring the payment structure into the WBS build early, not retrofit it. Concretely: every significant BoQ line tied to a payment milestone should map to an activity ID or a clearly traceable group of activities in the schedule — ideally via a dedicated activity code ("Payment Milestone") rather than an informal mapping kept separately in a spreadsheet.
This direct mapping makes it possible, at any point in the project, to answer objectively "has this payment milestone been reached?" by consulting the schedule, with no manual reconstruction or interpretation required.
Percentage completion vs discrete milestones: a choice with consequences
Two payment logics structurally compete. Payment based on overall physical percentage complete is smoother for contractor cash flow, but exposes both parties to recurring disagreement over the measurement method. Payment by discrete milestones (completed deliverables, passed tests) is more objective and harder to dispute, but can create cash flow spikes if milestones are poorly spaced over time.
The choice — or the balance between the two approaches within a single contract — should be made deliberately at the initial schedule and BoQ structuring stage, not patched mid-project when the first invoicing disagreement arises.
What this changes in the event of a claim
A BoQ properly tied to the schedule significantly simplifies a later delay analysis or claim: the financial value attached to each delayed activity is directly quantifiable, which speeds up and de-risks impact costing — an advantage that shows up precisely when contractual leverage is most contested.
This structuring is something we systematically check upfront on our delay analysis and project controls assignments, before an invoicing disagreement occurs.