This article sets out a practical review workflow for reconciling field records with programme progress at a reporting cut-off. Its focus is the evidence boundary: what work was physically performed by the agreed data date, how that evidence maps to programme activities, and how differences are recorded for review. It is not a general progress-measurement sheet or a substitute for the contract, approved project procedures, or competent project-controls review.
Use this as general workflow guidance. The project’s reporting rules, approved programme, measurement method, contract requirements, and document-control process govern where they differ. In particular, do not infer that a daily report, quantity entry, photograph, or software status automatically establishes the project’s accepted percent complete.
1. Establish the cut-off and its authority
Before reviewing progress, identify the status period and the exact data date used for the programme update. Confirm the date and any applicable time convention with the project’s reporting procedure or authorised project-controls lead. Record the programme name and revision, update cycle, reporting period, responsible preparer, and reviewer. If the team has not agreed which date or time convention applies, raise that as an open issue rather than silently choosing one.
A data date is the schedule’s reference point for an update. Oracle’s Primavera P6 guidance describes updating a project as of a new data date and reviewing activity progress through selected update settings. Its Update Progress guidance explains that actual dates and remaining durations are applied according to the selected data date and settings. These are software-behaviour descriptions, not universal rules for measuring work or deciding contractual entitlement. Verify the applicable product version, settings, and project procedure before relying on them.
Keep the cut-off distinct from the date a record was written, uploaded, approved, or entered into the programme. A record created after the data date may describe work performed before it; a record dated before the cut-off may not, by itself, prove that the reported work was complete by then. Establish the basis for assigning evidence to the reporting period and document exceptions.
2. Freeze the review inputs
Assemble a controlled review set before comparing progress. Depending on the project, it may include the current approved programme and prior update, activity coding or work-package references, field diaries, daily site reports, inspection requests and results, quantity records, survey information, delivery or installation records, photographs, and relevant approvals. Use only records that apply to the scope under review.
For each input, capture its source, date or period covered, revision or identifier where available, owner, and review status. Note missing, late, superseded, or conflicting records. Preserve the original record and any later correction in accordance with project document control; do not overwrite evidence merely to make the update appear consistent. Where project procedures define a formal record hierarchy or approval status, apply that hierarchy rather than inventing one for this review.
3. Map field evidence to programme activities
Review one activity or agreed work package at a time. Record the programme activity identifier and description, location or asset reference, planned scope, relevant reporting period, and the field evidence offered to support the status. The mapping should be specific enough for another reviewer to follow: identify which record supports which portion of the activity, not just a folder containing several unrelated documents.
Check that the field record and programme activity refer to compatible scope and location. A site report may cover several areas; a programme activity may combine work at multiple locations. If the evidence cannot be allocated reliably, record the limitation and seek clarification. Do not count the same installed quantity or completed work under multiple activities unless the project’s approved measurement and coding rules explicitly provide for that treatment.
Distinguish physical progress from administrative or downstream status. Work may be physically performed while inspection, test evidence, approval, or handover remains open. Conversely, an approval or delivery record does not necessarily establish that installation or other physical work is complete. Report these states separately where the project’s reporting method allows, and do not present physical progress as final acceptance.
4. Test the reported status against evidence
For each activity, compare the reported status with evidence available by the cut-off. Ask what work was performed, where it occurred, when it occurred, and how the evidence supports the claimed extent. Examples may include a dated field record describing installed work, a measured quantity record linked to the relevant location, an inspection record that identifies the work inspected, or photographs that can be tied to a specific area and reporting period. These are evidence examples, not a universal acceptance hierarchy; their sufficiency depends on project requirements and context.
Where progress is expressed as a percent, identify the approved basis used to derive it. That basis might be defined by the project’s measurement rules, activity steps, or documented quantities; do not introduce a calculation method that the project has not approved. Check that the stated percent and any supporting quantities are consistent with the described scope and the records available at the cut-off. If the basis is unclear, mark the status as requiring clarification rather than presenting an unsupported precise value.
For activities spanning the cut-off, separate evidence of work completed by the data date from work performed afterward. Later records can help clarify an earlier event, but the reviewer should note their date and explain why they are being used. Do not backdate a status or imply contemporaneous verification where the record does not support it.
5. Reconcile field records and the programme update
Compare the evidence-based view with the activity’s current programme status, including actual dates, remaining duration, and other progress fields used by the project. Confirm that entries are consistent with the approved update process and selected software settings. In Primavera P6, update behaviour depends on the selected data date and settings; do not assume a particular setting or automatic result without checking the project file and applicable guidance.
Look for discrepancies such as field evidence showing work not represented in the programme, programme progress without identifiable supporting records, dates that cross the cut-off, different quantities for the same scope, inconsistent location descriptions, and activities whose status appears to include work outside their defined scope. Also check whether records describe completed work, ongoing work, or an inspection or approval stage rather than treating these as interchangeable.
Do not silently force the records to agree. Preserve the submitted or source status, describe the evidence-based observation, and state what needs to be confirmed. The planner, field representative, quantity or measurement owner, and other relevant reviewers should resolve the item under the project’s established approval and change-control process. This article does not determine which party has authority to approve a progress value.
6. Record and close discrepancies
Maintain a discrepancy log linked to the affected activity and supporting records. A useful entry includes an identifier, activity reference, data date, description of the mismatch, evidence reviewed, current reported status, question or decision required, responsible owner, target resolution date if the project uses one, and closure evidence. Record who reviewed or approved the resolution according to project procedure.
Keep the language factual. For example, state that a field report describes work in a named area while the programme activity has a different location description, or that the programme shows progress but the review set contains no linked measurement record. Avoid asserting that progress is invalid, accepted, delayed, or contractually due unless the evidence and authorised project decision support that conclusion.
When a discrepancy is resolved, retain the rationale and the record that supports the resolution. If it remains open at submission, identify it as open and explain its effect on the reported status where that effect is known. Do not convert an unresolved item into a confirmed value simply to complete the update.
Cut-off reconciliation checklist
- The authorised reporting period and programme data date are explicit, with any date or time convention confirmed.
- The programme revision, update cycle, preparer, reviewer, and applicable project procedure are identified.
- The review set includes relevant field records and notes missing, late, superseded, or conflicting inputs.
- Each programme activity is mapped to identifiable field evidence, scope, and location.
- Evidence is assessed for when the work occurred, not only when a record was created or entered.
- Physical progress is distinguished from inspection, testing, approval, commissioning, or handover status where relevant.
- Any reported percent or quantities have a project-approved measurement basis, or are flagged for clarification.
- Programme progress fields and dates are checked against the evidence and applicable software settings.
- Discrepancies are logged with an owner and closure evidence; they are not silently reconciled.
- Open limitations and unresolved decisions are visible in the update review record.
Project-specific limits
Evidence requirements, activity coding, rules for measuring percent complete, responsibility for review, and the treatment of late or disputed records can vary by contract and project procedure. Jurisdiction, contract terms, approved programme requirements, and document-control rules may also affect how records are accepted. Confirm those requirements with the authorised project team. This workflow supports a traceable review; it does not establish a contractual entitlement, certify quantities, or approve a programme update.
Related EngineersBlog reading
- Daily Site Report Review: Progress Evidence Checklist
- What Does Data Date Mean in Primavera P6?
- Construction Progress Measurement: A Practical Control Sheet
- How to Review a Construction Programme Update Before Submission
Research sources
- Oracle Primavera P6: Updating the Schedule
- Oracle Primavera P6: Update Progress Dialog Box
- Google Search Central: Creating Helpful, Reliable, People-First Content
- Google Search Central: Guidance on Generative AI Content
Conclusion
A defensible cut-off review makes the boundary, source records, activity mapping, measurement basis, and unresolved differences visible. Confirm the data date, trace field evidence to programme activities, distinguish physical progress from other completion gates, and preserve a clear record of discrepancies and their resolution. Apply the project’s approved procedures and keep any unsupported status open for qualified review.
