Earned value reporting only works when the numbers behind it come from one controlled sequence. Most failed EVM cycles I would flag as governance problems, not software problems: the schedule was updated on one date, the costs were keyed on another, and someone quietly overrode progress to make the curves look better. The purpose of this guide is to give your team a repeatable preparation sequence for a cost-loaded Primavera P6 programme, so that by the time you run the earned value report, the programme and the accounting data behind it have already passed a set of reconciliation checks.
This article assumes you already understand the EVM fundamentals (earned value, planned value, actual cost, variance). If you need the conceptual background first, see the Earned Value Management comprehensive guide on this site. What follows is the preparation discipline that comes before you press the report button.
Why sequence matters: schedule data is not accounting data
A cost-loaded programme in P6 holds two different kinds of data that are easy to confuse:
- Schedule data — activity start/finish dates, durations, logic, percent complete, progress status. This data describes when work happens.
- Cost and resource data — budget, actual cost, cost codes, resource calendars and loading. This data describes what the work costs, and usually originates in systems outside P6: timesheets, the cost ledger, purchase orders, invoice receipts.
The two streams live in different control systems and are produced by different people on different cycles. The scheduler’s data date and the accountant’s cost cut-off date are frequently not the same day. If you run earned value straight from a programme where those two streams have not been aligned, you are not measuring performance; you are measuring the gap between your own data processes. So the first principle of this guide is simple:
Prepare the schedule and the cost data separately, check each one against its own source, and only then reconcile them before reporting.
P6 itself supports two ways of updating status: you can estimate progress as of a new data date, or you can update activities and resources individually when work has deviated from plan (Oracle documents both in its schedule-update guidance). Whichever route you use, the update process applies actual dates and adjusts actual and remaining durations according to the data date and the settings you select in the Update Progress dialog. None of that will save you if the data date you chose was not the date your cost data actually covers.
The preparation sequence
Run the steps below in this order. Each step has an exit condition: do not proceed until it is met.
Step 1 — Freeze the reference data date
Choose the data date for the reporting cycle before anyone touches the programme, and make sure it matches the period your actual cost and quantity data covers. If the cost ledger is cut off on the last day of the month and you set the programme data date to the 25th, your earned value and actual cost are measuring different time slices and the variance is meaningless. Write the data date down — in the report header, in the change log, wherever the report lives. This is a control decision, and like all control decisions it should be recorded before execution, not reconstructed afterwards.
Step 2 — Confirm the earned value baseline exists and is intact
Before loading or touching cost data for a period, verify the baseline against which value is measured:
- A baseline has been set for the project and has not been quietly re-baselined without a documented reason.
- Every activity you intend to measure is in the reporting scope — no costed activity left outside the reporting WBS, and no un-costed scope hiding inside a WBS that is being measured.
- The budget (the total you will measure value against) matches the budget your commercial team recognises. If there is a gap between the schedule budget and the contract or cost budget, reconcile it now, not after the EVM chart looks strange.
Step 3 — Align cost loading to the approved measurement basis
Earned value is only as good as the measurement basis behind percent complete. Before loading cost, confirm:
- What counts as complete. Each costed activity has a defined percentage basis — quantities, milestones (0/100), or an approved estimator’s percentage. If a quantity basis exists, use it; an estimator’s percentage should be a fallback, not the default, because it is the least repeatable.
- Cost allocation method. Decide per activity whether cost is spread by time (cost curves), by quantity, or held as a lump sum, and that the choice is consistent across comparable activities. Mixing methods inside one work breakdown area is a classic source of EVM spikes that are really just accounting artefacts.
- Source of actual cost. Identify the system of record for actuals (ERP, cost ledger, timesheets) and confirm the field mapping into P6. P6 records what you put in; it does not validate your source.
Where contract, project procedure, or jurisdiction defines the measurement method, that definition governs — check it with your commercial team rather than assuming P6’s default behaviour matches it. The example calculation in Step 5 is an arithmetic illustration only and must be replaced by your project’s approved measurement basis where one exists.
Step 4 — Update the schedule with a controlled progress update
Now — and only now — update the programme status.
- Use a single, documented update path: either estimated progress at the new data date, or individually recorded activity updates (actual start/finish, percent complete, remaining duration). Both are supported P6 workflows; pick the one your data supports and stick to it for the cycle.
- Keep the entered status, the recalculated forecast dates, and any narrative note explaining deviations consistent with each other. This is a workflow recommendation, not a contractual entitlement — but it is what makes the update auditable later when a variance gets questioned.
- Do not mix a progress-override exercise into this step. If your team uses progress overrides for reporting purposes, treat that as a separate, separately documented procedure — see the method statement for progress override in Primavera P6 — and make sure anyone reading the EVM output knows whether the underlying progress was recorded or overridden.
For the month-to-month mechanics of the schedule update itself, the practical monthly workflow for updating a P6 programme covers the routine steps; this guide assumes that routine is already in place.
Step 5 — Load cost and run the worked checks
With the schedule stable at the agreed data date, load the cost data:
- Enter actual cost (and actual resource hours, if you track them) for each activity from the confirmed source system, for the period that matches the data date from Step 1.
- Enter remaining cost estimates for open activities, using the allocation method agreed in Step 3. If your P6 settings estimate remaining cost automatically, confirm the basis of that estimate matches the approved basis — an automatic estimate is still an estimate and should be checked.
- Run a worked-value sanity check on a sample of costed activities before publishing anything. For a single activity:
Take an activity with a budget of 70,000 currency units, a quantity of 24.5 m³ of concrete, and 14.0 m³ placed to date. Earned value at quantity basis is 70,000 × (14.0 / 24.5) = 40,000. If the ledger shows 40,000 spent, cost variance on that activity is zero. If instead the ledger shows 52,000 spent, the activity is 12,000 over against its earned value — and that number now has a defensible measurement basis behind it rather than an estimator’s opinion. Work the same arithmetic on two or three more activities across different WBS levels; this is a cheap check that catches source-system mapping errors, currency mismatches, and double-entered actuals before they reach the report.
The numbers above are an arithmetic illustration only. Where your project has an approved measurement basis, it supersedes this example.
Step 6 — Reconciliation checks before reporting
Run the checks in the table below. A cost-loaded programme is not ready for EVM reporting until each of these passes or the failure is explicitly documented and owned.
| Check | What to verify | If it fails |
|---|---|---|
| Data date alignment | Programme data date equals the period covered by actual cost and quantity data. | Stop. Re-cut the cost data or re-set the data date; never report across a mismatched window. |
| Budget tie-out | Total budget in P6 equals the commercial/contract budget for the reporting scope. | Reconcile the gap and record which figure governs the EVM baseline. |
| Actual cost tie-out | Total actual cost in P6 equals the source system total for the same period. | Trace to the source; correct P6 entries, not the source system. |
| Scope completeness | Every costed activity is in the reporting WBS; no costed work sits outside it. | Move the scope, or document the exclusion and its value impact. |
| Percent complete basis | Each costed activity’s % complete uses the agreed basis; 0/100 activities are genuinely complete. | Correct the basis or the percentage; do not blend bases quietly. |
| Remaining cost estimate | Open activities carry a remaining cost estimate consistent with the agreed method. | Backfill estimates; EVM on open work with zero remaining cost is misleading. |
| Overridden progress | No progress override is active in the data being reported, or overrides are documented and flagged. | Document overrides separately from recorded progress; state in the report which is which. |
| Consistency narrative | Entered status, recalculated forecast dates, and deviation notes are consistent with each other. | Correct before release; an update that cannot be re-derived by another engineer is not a controlled update. |
Keep the results of these checks — pass or fail, with dates and names — in the report pack. When the earned value variance is later challenged by the client, the auditor, or your own commercial team, the reconciliation record is what turns the report into evidence instead of an opinion.
Common failure modes this sequence prevents
- Reporting against a mismatched period. The single most frequent cause of unexplainable EVM spikes. Prevented by Step 1 and the data date alignment check.
- Ghost cost. Actuals keyed into P6 that never existed in the ledger (or vice versa). Prevented by the actual cost tie-out.
- Measurement drift. Percent complete silently switching from quantity basis to estimator’s opinion between cycles. Prevented by fixing the measurement basis in Step 3 and re-checking it every cycle.
- Override blindness. The report being produced from overridden progress while the team believes it is looking at recorded progress. Prevented by the override check and by labelling which dataset the report used.
- Zero-remaining-cost bias. Open work carrying no remaining estimate, which deflates the forecast and distorts variance at trend level. Prevented by the remaining cost estimate check.
Preparation checklist
Compress the sequence into a per-cycle checklist you can run before every reporting cut:
- Agree and record the data date; confirm it matches the cost data period.
- Verify the baseline is intact and matches the commercial budget.
- Confirm the measurement basis (quantity, milestone, or estimator’s %) for costed work.
- Update the schedule using one documented update path at the agreed data date.
- Load actual cost and remaining cost estimates from the confirmed source.
- Run the worked-value arithmetic on a sample of activities.
- Complete the reconciliation table; document and own every failure.
- Label the report pack: data date, measurement basis, whether progress was recorded or overridden.
Done in this order, the cost-loaded programme stops being a schedule with numbers attached and becomes a control record: every figure in the earned value report can be traced back to a source, a method, and a person who checked it. If you want to build the reporting routine on top of that foundation, the EVM concept reference on this site is the natural next read. And if your question is how a specific P6 update behaves rather than how to govern it, the vendor documentation in the sources below is the authority to check against.
Sources and references
- Oracle Primavera P6 Pro User Guide — Updating the schedule (supports the two update modes: estimated progress at a data date versus individually updated activities).
- Oracle Primavera P6 Client Help — Update Progress dialog box (documents how the update applies actual dates and adjusts actual/remaining durations at the selected data date).
- Google Search Central — Creating helpful, reliable, people-first content.
- Google Search Central — Guidance on generative AI content.
Reconcile the value measures before reporting
For the same data date and approved baseline, reconcile planned value (PV), earned value (EV), and actual cost (AC) before interpreting the forecast. Keep this cost-loading check separate from the time-based illustration: 7 actual working days plus 5 remaining working days across a 12-day planned duration gives 58.3% duration progress (7 ÷ 12). This is arithmetic only, not an earned value result; use the project-approved measurement and cost rules for reporting.
